> which seems to directly oppose the CCPA.

I have some background in data privacy compliance.

It sounds like they are claiming to be a Service Provider under CCPA, which is similar to a Processor under GDPR. Long story short, a Controller is the one legally responsible for ensuring the rights of the data subject, and a service provider/processor is a "dumb pipe" for a Controller that does what they're told. So IF they are actually a Service Provider, they're correct that the legal responsibility for CCPA belongs to their customers and not them.

That's a big IF, though.

Being a Processor/Service Providor means trade-offs. The data you collect isn't yours, you're not allowed to benefit from it. If Flock aggregates data from one customer and sells that aggregate to a different customer, they're no longer just a service provider. They're using data for their own purposes, and cannot claim to be "just" a service provider.

My personal conspiracy theory is that in some cases, the "loser" is in on the graft to. It's a way to launder bribes.

That still begs the question though: There are existing tools and solutions that do this. Why not, and would this being AI make a difference?

"My boss would be more likely to approve it" is a cynical but valid answer.

ALL existing product simply let you set up alerting system, and that alerting system is manually done by you. still un-expected issue can arise. LogClaw is not altering system. you just send all your logs, its capable of injecting terabytes of logs per day, and it automatically ignores all the successful logs, and it works on the uncaught exceptions, errors from all services, infrastructure itself.

That type of experimental set-up is forbidden due to ethical concerns. It goes against medical ethics to give patients treatment that you think might be worse.

The Gaussian integers usually aren't considered interesting enough to have disagreements about. They're in a weird spot because the integer restriction is almost contradictory with considering complex numbers: complex numbers are usually considered as how to express solutions to more types of polynomials, which is the opposite direction of excluding fractions from consideration. They're things that can solve (a restricted subset of) square-roots but not division.

This is really a disagreement about how to construct the complex numbers from more-fundamental objects. And the question is whether those constructions are equivalent. The author argues that two of those constructions are equivalent to each other, but others are not. A big crux of the issue, which is approachable to non-mathematicians, is whether it i and -i are fundamentally different, because arithmetically you can swap i with -i in all your equations and get the same result.

I don't think anyone thinks is "i and -i are fundamentally different". What they care more about is whether the 5 5th roots of 2 have an natural ordering or not.

They weren't "just" raw dumps of internal C structures. It takes careful design work to dump raw memory in a usable fashion. Consider: You can't just write a pointer to disk and then read it back next week.

Binary MS Office format is a phenomenal piece of engineering to achieve a goal that's no longer relevant: fast save/load on late-80's hard drives. Other programs took minutes to save a spreadsheet, Excel took seconds. It did this by making sure it's in-memory data structures for a document could be dumped straight to disk without transformation.

But yes, this approach carries a shitton of baggage. And that achievement is no longer relevant in a world where consumer hardware can parse XML documents on the fly.

I have heard it argued, though, that the "baggage" isn't the file format. It's actually the full historical featureset of Excel. Being backwards-compatible means being able to faithfully represent the features of old Excel, and the essential complexity of that far outweighs the incidental complexity of how those features were encoded.

HIPAA is not a privacy law, nor even a healthcare law. It's an insurance law. It does not cover medical records generally. It deals strictly with how doctors bill insurance companies, and mandates security for health information being billed about.

For the same reason, health & wellness apps are not generally covered by HIPAA, and in fact quite a few of those exist solely for the purpose of selling medical data to data brokers. Especially ones related to women's health.

It very much is something that exists in hardware. One of the major reasons why people finally discovered the provenance UB lurking in the standard is because of the CHERI architecture.

So it's something that exists in some hardware. Are you claiming that it exists in all hardware, and we only realized that because of CHERI? Or are you claiming that it exists in CHERI hardware, but not in others.

If it only exists in some hardware, how should the standard deal with that?

> If it only exists in some hardware, how should the standard deal with that?

Generally seems to me the C standard makes things like that UB. Signed integer overflow, for example. Implemented as wrapping two's-complement on modern architectures, defined as such in many modern languages, but UB in C due to ongoing support for niche architectures.

The issues around pointer provenance are inherent to the C abstract machine. It's a much more immediate show-stopper on architectures that don't have a flat address space, and the C abstract machine doesn't assume a flat address space because it supports architecture where that's not true. My understanding is that reflects some oddball historical architectures that aren't relevant anymore, nowadays that includes CHERI.

Historically, the reason was was often niche architectures. But sometimes certain behavior dies out and we can make semantics more strict. For example, two's complement is now a requirement for C. Still, we did not make signed overflow defined. The reasons are optimization and - maybe surprising for some - safety. UB can be used to insert the compile-time checks we need to make things safe, but often we can not currently require everyone to do this. At the same time, making things defined may make things worse. For example, finding wraparound bugs in unsigned arithmetic - though well-defined - is a difficult and serious problem. For signed overflow, you use a compiler flag and this is not exploitable anymore (could still be a DoS).

People keep forgetting that SPARC ADI did it first with hardware memory tagging for C.

Even if you can't answer that question, if it can be answered, that's still personal data.

What's the minimum size of an operation before the GDPR kicks in? In other words, are all sites governed by GDPR, or are some companies considered too small to be under the GDPR regulations? I know that there are some regulations that get a pass for smaller outfits. I know nothing about GDPR as a European audience is not my target and not kowtowing for them.

GDPR does not currently have explicit business size thresholds. Its provisions are all framed as personal rights of the data subject, so its provisions are always in effect. By contrast, CCPA in California is framed as a consumer protection law so it only applies to companies of a certain size.

In practice, small fries are not an enforcement priority. Regulators in most countries are not well-funded so they have to be frugal with their enforcement actions.

The EU is currently reviewing an option to relax GDPR requirements for smaller businesses. Not remove GDPR requirements, just streamline some of the process overhead.

We passed the tipping point where bot traffic outnumbered human traffic fifteen years ago. LLMs are an order of magnitude worse by most first-hand accounts, but it's just a continuation of a very long trend.