Why would you ever default to an opt-out for that information? That's like saying "people should read the contracts" while waving about a 10,000 EULA in 6 point type, or burying an option checklist so deeply that most users don't even know it's there.
“But the plans were on display…”
“On display? I eventually had to go down to the cellar to find them.”
“That’s the display department.”
“With a flashlight.”
“Ah, well, the lights had probably gone.”
“So had the stairs.”
“But look, you found the notice, didn’t you?”
“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”
I don't think the distinction between "third party service" and "hosting company" is all that clear. You're sending data to a third party service when you host an app on AWS. The only data protection you have is contractual.
> You're sending data to a third party service when you host an app on AWS.
Amazon neither receives nor requires access to the raw underlying data (in this case: data in your database indicating HIV status, or decrypted bodies of requests sent over TLS indicating same) when you host your web services on AWS. While, yes, it's possible for a dedicated attacker to intercept and snoop on this data, it's (a) not easy, and (b) very much outside the bounds of the scope of the relationship you have with them.
Contrast to the setup described here, where the third parties in question both received and required access to the raw underlying data in order to perform the services they were explicitly contracted for.
You may not think this is an important distinction, but legally, it is, and it makes a world of difference.
I honestly don't get the distinction you're making here. I understand how people _can_ use AWS without ever letting sensitive data touch their disks, but most apps hand everything over wholesale (and frequently in a nicely structured format on RDS).
The legal distinction you're making doesn't sound right to me. Contractors for companies that access your data aren't usually about whether or not an attacker can get at it, but about what kind of access an employee of the service itself has.
Amazon _technically_ has complete access to your data when you run on AWS, but they're contractually limited in how they can use it. The same goes for third party SaaS services. The major difference is "who writes the logic".
But I'm not a lawyer and won't ever have to argue that somewhere it matters.
Amazon is selling an abstraction, and goes to great expense to not have access to customer data. If you are a HIPPA covered entity, they sign a BAA that puts them on the hook.
It's like the difference between putting your papers in a storage locker versus your friends garage. The storage company ultimately has access to the locker, but is less likely to snoop (either consciously or accidentally) than any of the folks with access to that garage.
AWS does not care about the data, does not want to see the data and goes out of its way to make it damn hard for it to see the data. The data is a black box to them and this is by design. You are not sending them the raw data in a format that they require for analyses. You are just sending them bits and bytes that they store for you.
The analyses third-parties in this case are the exact opposite. They explicitly require access to their data in a certain format for analysis. In fact, their business fails if they don't have access to this data.
They are both technically third parties but the way they handle the data is completely different.
One has every incentive to avoid reading the data, the other has every incentive to hoover everything it can.
I just don't think that's a meaningful distinction. There's no distinct line between "company that hosts all your data but doesn't analyze it" and "company that does data analytics on your data". It's a gradient, there are all kinds of companies that fit on that gradient, and it's weird to lambast people for using those companies as if it's a technical choice, when what we really want is people making good choices about the data protections their providers have in place.
AWS even has analytics products that require access to your data. I generally trust those more than sketchy analytics companies, but it's entirely because of the contractual protections AWS has in place, not because they're inherently different.
What is the privacy distinction between a third party with a contractual agreement and an employee with a contractual agreement?
Remember that Russian intelligence got a spy hired by Microsoft: https://www.theguardian.com/technology/2010/jul/14/russian-s... Will your interview questions find a foreign spy, or someone who isn't even a spy but is interested in looking at private data for personal amusement?
If Microsoft implemented proper security policies, I imagine that guy didn't have access to all of Microsoft's user data.
So that would be the main difference. Virtually all of a company's employees shouldn't have access to user data at all, and those that do would only have access to parts of it.
>If Microsoft implemented proper security policies, I imagine that guy didn't have access to all of Microsoft's user data.
This is precisely the sort of thing Microsoft takes incredibly seriously internally. Tim Cook may be a more vocal spokesman for treating user data with care but Microsoft is fanatical about it internally. They recognize the risk they face in the event of compromise and have made just enough mistakes in the past to appreciate how hard it is to actually protect their customers’ information.
This might be a naive view, but I think companies that are good at this sort of segmentation will also be good at picking trustworthy third parties and limiting (both technically and legally) what they can do, and conversely, that companies that just send a bunch of sensitive data to third parties out of laziness have no meaningful internal controls either.
"Avoid third parties" is an occasional effect of conscientious care of data, not a cause of it.
