“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.”
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.
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.
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.
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.
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?
How about "lets just not spend medically sensitive information to third party services"
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.
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.
"Avoid third parties" is an occasional effect of conscientious care of data, not a cause of it.