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.

> You also have to remember that individual countries fining on global revenue runs the risk of fines "duplicating" each other for the same or similar behavior, again bankrupting a corporation when the goal should be to change behavior.

This is explicitly not a concern under GDPR. The "one-stop shop" mechanism means that all issues across the EU get funneled to the lead supervisory authority, which is always Ireland because that's where EU subsidiaries are headquarters for tax purposes.

Yes, but there are countries outside of the EU who may also decide to fine based on global revenue.

Either obey the law in those countries, or don't do business there.

Per a reddit comment, modules are allowed to have circular dependencies while crates are not.

That website is not authoritative and should not be given more credence than your median tech blog.

And not more credence than TFA. GDPR has legally very little to do with cookie banners as other comments have already pointed out. I am pretty sure nobody has been ever improsened because of not asking consent for storing cookies. Even for hefty fines you first need a hefty turnover, so that site seems unaffected. And obviously a couple of 100 millions are not hefty for Meta, Google & Co. They make bigger profits by taking the risks of not being in compliance.

GP are wrong about which law applies, but they are applying that law correctly.

The ePrivacy Directive requires consent to read or write from the user's terminal device, except when strictly required for the functionality the user requested. Unlike GDPR, it does not allow a different Legal Basis. It must be consent, or strictly functionally necessary. Nothing else.

The passage of GDPR did impact the ePrivacy Directive in that it updated the definition of "consent." The ePD doesn't have one; it referenced the definition in the DPD, which was replaced by GDPR. This is why people blame the GDPR for cookie banners, although really it's incidental.

Great clarification, thank you.

It depends on the jurisdiction and law, but a "data breach" is when data is accessed by a party who is not authorized, or who should not be authorized. It's not just hackers. Sending data to the wrong recipient is a form of data breach. Under some definitions, sending data to the intended recipient without appropriate safeguard is a form of data breach.

In this case, health care data covered by HIPAA was sent to a party without a legal contract that extends HIPAA to the receiving party. By law, that's a data breach.

Under some legal definitions, "data breach" includes not just breakdowns of confidentiality, but also of availability and/or integrity. So a company deleting your data by accident would be considered a data breach, even though it's being accessed by fewer parties than intended. This can be important: imagine a bank or credit agency losing some or all of the data about you, this would materially impact your ability to do business in the modern world.