zlacker

[parent] [thread] 19 comments
1. userbi+(OP)[view] [source] 2022-07-30 00:17:31
Wouldn't you prefer that this data only be able to be decrypted by a computer that can prove to the world it booted a clean OS image with all the latest security patches installed?

No.

Contrarily unpopular opinion: You cannot own data except what resides on your own property. Once you give someone a copy, it is theirs to do with as they wish. They may tell you what they will and will not do, but it is entirely on you to trust them.

...and that's the peril of things like remote attestation and other "zero trust" crap. They replace the nuanced meaning of trust that holds society together (and has literally done so since the beginning of life) with absolutes enforced by an unrelenting machine controlled by some faceless bureaucracy which is also partly under the command of the government. There should already be enough dystopian sci-fi to convince everyone why that is a really bad idea.

replies(5): >>fleven+v >>game-o+Z >>hedora+e5 >>matheu+k6 >>dap+Ua
2. fleven+v[view] [source] 2022-07-30 00:23:25
>>userbi+(OP)
Right, but if they aren't going to follow best security practices and prove it (via a signed a hardware attestation of the running software that includes the transport key they want me to use to send them the data), then I'm not going to send them the data. That's my choice.
replies(3): >>msla+11 >>unionp+m3 >>nradov+A6
3. game-o+Z[view] [source] 2022-07-30 00:28:46
>>userbi+(OP)
Strongly agree.

We've already seen shades of this in banking. After chips were added to credit cards, people started having their chargebacks denied because "our records show the card was physically present" (even if the charge originated in another country)

How long until companies try to deny responsibility for data leaks because "our records show Windows was fully up-to-date and secure"

replies(2): >>supert+S4 >>mike_h+WV
◧◩
4. msla+11[view] [source] [discussion] 2022-07-30 00:29:08
>>fleven+v
> if they aren't going to follow best security practices and prove it (via a signed a hardware attestation of the running software that includes the transport key they want me to use to send them the data)

You can mandate whatever remote attestation you want, and they'll follow whatever security practices they damn well feel like and you can't do a damn thing about it. So, you've given up your ability to run software that doesn't spy on you, and they're operating business as usual because they don't have a single goddamn reason to care what you think remote attestation mean in the real world.

◧◩
5. unionp+m3[view] [source] [discussion] 2022-07-30 01:00:15
>>fleven+v
> best security practices

as defined by whom? Some government (which one) organization ?

This will end up making everything more ossified and less secure.

But also once that is in place, various organizations and goverments will be able to force you to use whatever spyware they want, in order for your attestation to go through.

replies(2): >>judge2+g4 >>mike_h+aW
◧◩◪
6. judge2+g4[view] [source] [discussion] 2022-07-30 01:08:53
>>unionp+m3
Best security practices as defined by Microsoft, but if I want, I can still create my own arbitrary security requirements and enforce them via software/audits.
replies(3): >>userbi+8c >>patrak+Oj >>dzikim+ks
◧◩
7. supert+S4[view] [source] [discussion] 2022-07-30 01:14:19
>>game-o+Z
The error in logic there is that chip usage is stronger proof, but not infallible. How was the account started? Cards can be stolen from mailboxes and purses. Some smartcard manufacturers have poor key handling security; Gemalto emailed keys before writing them to SIMs. Some EMV chips were vulnerable to replay attacks due to shoddy implementation.

This is why consumer protection laws are more important than any technical means of financial security. Having a super duper hardware wallet to store your cryptocurrency doesn't negate the irreversible nature of transactions.

Raw data is even harder to secure than money. Money in a banking system can be clawed back or frozen. Data can't be un-leaked.

8. hedora+e5[view] [source] 2022-07-30 01:18:01
>>userbi+(OP)
Strongly agree, but even if you are wrong on all those points, I still don't want to be forced to run the same exact monoculture software as everone else.

Good luck getting your x86-64 windows kernel + chrome JavaScript exploit chain to run on my big endian arm 64 running Linux and Firefox.

(Also, the existence of competition like that regularly forces all the alternatives to improve.)

9. matheu+k6[view] [source] 2022-07-30 01:29:18
>>userbi+(OP)
> You cannot own data except what resides on your own property. Once you give someone a copy, it is theirs to do with as they wish.

Completely agree. These outdated notions of information ownership are destroying free computing as we know it. Everything "hacker" stands for is completely antithetical to such notions.

◧◩
10. nradov+A6[view] [source] [discussion] 2022-07-30 01:32:24
>>fleven+v
In the US healthcare industry, providers are legally mandated to share patient data with certain other organizations. You don't have a choice.
replies(1): >>salawa+431
11. dap+Ua[view] [source] 2022-07-30 02:34:25
>>userbi+(OP)
It's not necessarily "you" vs. "someone else". You could be one person with two computers and want one computer to be able to attest to the other computer something about its software. (Imagine it's not two computers, but a thousand computers that are exposed to both physical and network attacks.)
◧◩◪◨
12. userbi+8c[view] [source] [discussion] 2022-07-30 02:49:47
>>judge2+g4
Microsoft. The same company which strongly pushes a spyware-filled, user-hostile OS. "best"? Really?

but if I want, I can still create my own arbitrary security requirements and enforce them via software/audits

Try doing that to your bank or whatever other large company you interact with...

replies(1): >>judge2+vc
◧◩◪◨⬒
13. judge2+vc[view] [source] [discussion] 2022-07-30 02:56:48
>>userbi+8c
You can't have your cake and eat it too. Everyone has agency, to decide who they interact with and who they give money to or, on the other side, who they sell products to/provide services to, and there are remarkably few exceptions to this rule (most based on things that the victim can't control). If a company wants to require you only use their products, or only use a allowlist of approved products, they can do that, just as you can decide not to use their services if they charge too much, perform unethical actions, or even if their company name contains the letter 'Y'.
replies(1): >>accoun+Nz5
◧◩◪◨
14. patrak+Oj[view] [source] [discussion] 2022-07-30 04:49:17
>>judge2+g4
Best security practices as defined by Microsoft = "You can't have a computer if your country is under US sanctions". Important word: US, a single country. I don't want to punch such a huge hole in any of my systems.
◧◩◪◨
15. dzikim+ks[view] [source] [discussion] 2022-07-30 06:54:46
>>judge2+g4
SP500 corp I often work with has security department filled with mindless drones, who say things like "regular enforced passwords changes are well regarded best practice".

You almost certainly use software that calls their server at some point. Hope you will enjoy their vision of security. I'm moving into the woods if they can define how my _personal_ computer behaves.

◧◩
16. mike_h+WV[view] [source] [discussion] 2022-07-30 13:38:09
>>game-o+Z
That seems to be an argument for damned if you do, damned if you don't. Yes, people need some incentive for deploying security upgrades and being able to say "we are sure it wasn't us" in disputes is part of that incentive. Otherwise why bother? If people get treated the same whether they made a genuine good faith effort to be secure, or do nothing, then you're just rewarding the companies that ignored security to focus on other things.
◧◩◪
17. mike_h+aW[view] [source] [discussion] 2022-07-30 13:40:26
>>unionp+m3
"as defined by whom? Some government (which one) organization ?"

As defined by the user.

RA doesn't care what software you run. In fact RA is better supported by Linux than any other OS! And, although the discussion in this thread is about RA of entire machines, that's actually pretty old school. Modern RA is all about attesting the tiniest slice of code possible, hence the "enclave" terminology. The surrounding OS and infrastructure doesn't get attested because it can be blinded with encryption. This is beneficial for both sides. I don't actually necessarily care how you configure your OS or even if it's up to date with security patches, if the security model treats the entire OS as an adversary, which is how Intel SGX works. You just attest the code inside the enclave and I send/receive encrypted messages with it.

◧◩◪
18. salawa+431[view] [source] [discussion] 2022-07-30 14:43:24
>>nradov+A6
They actually aren't. The only reason that is necessitated is A) medicare/medicaid integration is strongly predicated on EMR, and our damn insurance model is cripplingly dependent in it.

There's nothing that keeps a medical provider from going old school.

Unless I'm completely overlooking something... It may have snuck in with ACA.

replies(1): >>nradov+Jx1
◧◩◪◨
19. nradov+Jx1[view] [source] [discussion] 2022-07-30 18:23:11
>>salawa+431
Yes you are overlooking a variety of more recent federal laws and associated interoperability regulations, some of which apply even to providers that only accept direct payments from patients and don't bill third-party payers (insurers).

The basic guiding principle in force since HIPAA in 1996 is that patients, not providers, control access to their medical records regardless of whether those are stored on paper or in an EHR. If the patient authorizes sharing those records with another healthcare organization then the provider can charge a small fee for that service but they can't introduce additional spurious technical requirements on the receiving system.

◧◩◪◨⬒⬓
20. accoun+Nz5[view] [source] [discussion] 2022-08-01 11:36:01
>>judge2+vc
Corporations are an artificial construct that we as a society let exist. We can decide to add additional restrictions to that existence like requiring them to not discriminate based on what software you run on your own devices.
[go to top]