Comment by 7777777phil
5 hours ago
The encryption requirement makes sense on paper, but it basically breaks the whole value proposition of SaaS. If you need true end-to-end encryption where the provider can't see plaintext, you lose search, real-time collaboration, most of the AI features everyone's been bolting on lately, etc. You're essentially left using these services as fancy file storage with your own crypto layer on top.
Which is fine for IaaS use cases - spin up VMs, encrypt your disks, manage your own keys. But for productivity software like M365? The Swiss government is basically saying "yeah you can use it but only in a way that makes it almost pointless."
The Cloud Act part is what really matters here though. US providers can be compelled to hand over data regardless of where it's physically stored, and they've been pretty clear they'll comply with US law over local data protection rules when push comes to shove. For a foreign government storing legally confidential citizen data, that's a real problem. I suspect this will get quietly ignored like the previous declarations, because the alternative is either building everything in-house or relying on local providers that frankly don't have the same feature set or reliability.
> The encryption requirement makes sense on paper, but it basically breaks the whole value proposition of SaaS.
Good. It's high time to flip the status quo on its head - instead of data being something we ship to specific cloud services, for them to lock it away and charge for access, it should be code that should be a commodity, shipped to servers of our choosing and granted access to operate on our data without owning it.
Just like regular, old-school desktop software, back in the day before SaaS was a thing. The provider didn't get to "see plaintext", because the software was operating on your hardware and not communicating with the provider. And if it tried to communicate back to the "mothership", we'd rightfully call it spyware, tell people not to use it, and wonder if there's legal action that could be taken.
> If you need true end-to-end encryption where the provider can't see plaintext, you lose search, real-time collaboration, most of the AI features everyone's been bolting on lately, etc.
Proton has all of these features, despite being end-to-end encrypted. Search works well with their Mail and Calendar solutions, real-time collaboration is a core offering of their Document editor. It surely is harder to implement, but not impossible for many use cases.
And proton is a Swiss company operating under the Swiss Jurisdiction too.
The funny thing is that Proton is considering moving our of Switzerland, because of the new proposed surveillance laws...
https://www.swissinfo.ch/eng/ai-governance/proton-does-not-t...
1 reply →
How do they do that? Either they 1) transfer your entire data to your system before searching, 2) use shoddy cryptography, or 3) you have to expose your private key to them. I doubt it's 1).
Apparently, it's (1): https://proton.me/support/search
There are obvious UX/performance issues, but it's an honest approach.
Based on link below:
> Click Enable to confirm. Your messages will then be downloaded from Proton Mail’s servers, decrypted, and indexed locally in an encrypted state.
They just download your emails into your browser and make them locally searchable.
I battled the same issue, in the end I have unencrypted data for fulltext search. But none of these are sensitive. I was thinking that maybe with AES, which is just a XOR, you could do search if you have the key as you just need to know how to XOR the search query and which phrases you can include. So instead of "hello" the XOR would yield "arpe5," and you just look for that in the db. But this could only work with exact matches or prefixes, it would not allow elastic search or anything complex like that.
> The Swiss government is basically saying "yeah you can use it but only in a way that makes it almost pointless."
this is the typical way governments ban things
they write the rules such as the thing they want are explicitly targeting can't meet them (rather than explictly banning something)
> relying on local providers that frankly don't have the same feature set or reliability.
what, as microsoft?
> because the alternative is either building everything in-house or relying on local providers that frankly don't have the same feature set or reliability.
Neither of these seem like a terrible outcome. Relying on local providers would be better for privacy and would help the local economy. It would also push them to implement the remaining feature set and work on reliability - though I must sincerely question the idea that local providers cannot reach the same level of reliability - particularly when you throw in global network problems that affect the largest cloud providers but don't always affect the smaller guys.
> Relying on local providers would be better for privacy
This is a massive leap. Switching to local providers can eliminate a lot of imaginary threats, but opens the door to a lot of real ones, since most service providers outside of the big clouds have extremely weak or non-existent countermeasures against insider threats.
The threat profile changes, sure, but framing all the threats imposed by using large-scale foreign clouds as "imaginary", and every threat introduced by local providers as "real", is very disingenuous.
> most service providers outside of the big clouds have extremely weak or non-existent countermeasures against insider threats.
Another claim that needs some citations, please.
Anyway, many of those concerns can be addressed by security regulations, hiring processes, etc - which, I would guess, is a pretty critical part of why the large-scale providers supposedly don't have such threats.
Also, this thread is talking about the effects of US companies having access to sensitive data that they're more than willing to hand over to the US government. In other words... there are 2 major insider threats at every US cloud provider, from the perspective of a foreign government: the company, and the US government. That's mostly what I was referring to with the privacy bit.
whatsapp has e2e encrypted messages and searching works fine.
Realtime collaboration — assuming you use CRDTs — can be achieved with e2e encryption as well, with backend acting like a mere router of requests.