6 ms·

What a pointless display of security theater. As long as both end-points are google it doesn't matter. It's like a centralized company using a blockchain instea

What a pointless display of security theater. As long as both end-points are google it doesn't matter. It's like a centralized company using a blockchain instead of a database. Yeah, neat, you implemented it... but it doesn't get you anything except press.

mort96 4y ago
This is my feeling about... well, basically every "end-to-end encrypted" product. With Signal, both endpoints are Signal-controlled (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). WhatsApp also claims to be "end-to-end encrypted", but there the app isn't even open source so both ends are just 100% Facebook-controlled without even a facade of transparency. Same with Apple's end-to-end encrypted stuff, where everything is encrypted on their servers but for all I know they can just ask my device that's running their closed software to send them information. I don't understand the hype around end-to-end encrypted software where you have to trust the organization behind the software to not steal your data through their complete control of the endpoints.
- crgwbr 4y ago
  Even if the app is open source with reproducible builds, you have to trust the OS. Are you going to audit every line of the entire operating system? If you do that, are you going to audit every transistor in the SoC to ensure the hardware isn’t compromised in some way? No one person can do that. Even if a team of people could do it, do you trust the other people? At some point, you have to trust _something_. If you don’t, you simply can’t use computers.
  - yazzku 4y ago
    This does not take away from the parent's point. You need to trust something, yes; we just don't trust Google in particular in that whole chain of trust.
    - scarface74 4y ago
      It does take away from their point because they aren’t willing to trust Apple. It goes back to you have to trust someone.
      - mort96 4y ago
        I haven't said I'm not willing to trust Apple. The Apple example is included exactly because you have to trust Apple, whether they use E2EE or not, so E2EE doesn't make a difference and is security theatre. E2EE has value in the case where it (at least in principle) allows you to remove something from the list of trusted entities. Signal on the desktop is one such case, where E2EE lets us avoid trusting the Signal organisation.
        scarface74 4y ago
        I’m not trying to protect myself from Apple. Apple doesn’t have a reason to lie. I want to protect myself from the police. I trust Apple much more than I trust law enforcement. I found that it could remain secret for too long if Apple were forced to compromise its encryption. Besides, they can afford better lawyers than Signal.
  - mort96 4y ago
    What you're saying isn't wrong, but it misses the point. I'm not saying, "you have to trust someone so you shouldn't use it". I'm questioning whether the E2EE is adding anything or if it's security theatre. Take the case of WhatsApp. Without E2EE, you have to trust the platform (Apple) and the people behind the app (Facebook). With E2EE, you still have to trust Apple, but you also still have to trust Facebook, since Facebook controls the endpoint and you have no insight into what it does or if there are any back doors. The same applies to Signal obtained from the App Store or (AFAIK) Google Play. And Apple's E2EE stuff is obviously not adding anything, since we're already trusting them as the OS vendor. Something like Signal on the desktop is different though. There, we still have to trust the OS vendor, but we and anyone else can inspect the source code, verify that it does what it's supposed to and doesn't have any back-doors, compile it for ourselves, and then we can exchange messages without trusting Signal. In the case of Signal on the desktop, E2EE lets us distrust the Signal organisation, which has value even though we still need to trust our OS and our hardware. You could argue that we should trust the Signal organisation. That's not unreasonable, but that still makes E2EE no better than normal client-server encryption a la TLS and the promise of a solid no-logging policy. (We could also discuss the feasibility of verifying that there are no back-doors purely from reading source code and how well a back-door could be hidden. But that's sort of a tangent.)
    - nicce 4y ago
      I thought Signal has reproducible builds in Google Play too? It was one of the first apps to do so. https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/main/reprod...
- eitland 4y ago
  > (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). It is doable. Telegram has a procedure you can run to verify the binaries, also from the Apple App Store. Yes, it requires a jailbroken phone, but it is doable.
  - mort96 4y ago
    I didn't know that. If accurate, this puts Telegram more in the category of something like Signal on the desktop than WhatsApp or this Google thing.
    - deleted 4y ago
      [deleted]
    - eitland 4y ago
      Unlike Signal, Telegram provides both end-to-end encrypted chats and point-to-point-encrypted chats. (But unlike Signal Telegram also haven't been caught with glaring zero days or caught sending images to anyone except the intented recipient the last fee years.)
      - m4lvin 4y ago
        What is the difference between end-to-end- and point-to-point-encrypted?
        eitland 4y ago
        End-to-end-encrypted means without significant, unexpected breakthroughs in mathematics, no one can read it between the sender and the recipient, even if the traffic pass through FSB, NSA, Telegram, Google and Facebook headquarters and they all conspire to break it. Point-to-point-encrypted means it can theoretically[1] be read by the vendor (Telegram in this case) or anyone who can coerce the vendor. This is the standard for mail, online banking etc. The reason for providing both end-to-end-encrypted and point-to-point-encrypted is that point-to-point-encryption is significantly simpler, which makes it easiee to create useful and or cool features. [1]: vendors can do a nunber of things to make it hard/next to impossible for employees and others to access data, like for example restricting access to user data to service accounts, only allow debugging access in special circumstances and auditing such debugging access. Telegram used to claim they solve it by sending/storing encrypted data through/in different data centers from the keys, and keeping these days centers in different jurisdictions. Done properly should mean that two or more employees across the company would have to conspire to get access to customer data, or two or more judges in different countries would have to demand data. But unlike with end-to-end-encryption we have to take their word for it.
- amelius 4y ago
  Also your Android keyboard may be listening to anything you say in those E2EE apps.
  - helloworld11 4y ago
    Is this a persistent problem in android phones? Is there any way to avoid it (except using iOS)?
    - izacus 4y ago
      There's no difference in this problem between Android and iOS. On both phones the keyboard software "listens" to what you type, how else would it function?
      - helloworld11 4y ago
        Yes but the key question is, where is the listening done and where is the data stored?
- gregmac 4y ago
  > at least on the App Store and Google Play you can't verify that the open source code is what's shipped Is there a reason Google and Apple couldn't change their deploy flow to pull from a git repository? As in: 1. Developer pushes to a specific remote (or pushes a specific tag or branch) 2. Apple/Google run the build on their systems, sign it, etc 3. If passed, the app deploys and the published app is annotated with the specific git hash (which can also be displayed in the app store) For open source, it gives the public verification ability. For closed source, it is still useful for internal verification. I work adjacent to some mobile teams and most still do builds on a developer's desktop and upload that. I am working towards getting CI for everything, partly to reduce dependence on any one developer's system (eg: I hear things like "Only Tom knows how to do builds to give to Apple, but he's out today") and partly for security. As much as I believe we don't have developers with malicious intent, there's still no way to know that a build uploaded from a developer's desktop really is what's in source control.
  - aaomidi 4y ago
    Binary transparency is slowly getting more popular
  - kelnos 4y ago
    > Is there a reason Google and Apple couldn't change their deploy flow to pull from a git repository? Because doing so isn't something they'd realistically care about. They'd still have to maintain the existing flow for closed-source apps (the vast majority of them) that don't want to give outside parties access to their source code, so this would just mean more work for them. Another big downside is that app authors would not be signing the final product with their own keys. That would have to be done by Google/Apple, so authors would lose a bit of control over future distribution of their app.
  - tadfisher 4y ago
    Google supports code transparency attestations in app bundles[0], which allows third parties to verify the shipped binaries. [0]: https://developer.android.com/guide/app-bundle/code-transparency https://developer.android.com/guide/app-bundle/code-transpar...
- MattPalmer1086 4y ago
  You are correct to identify that end to end encryption without control of the software is not perfect. However, you have reduced the attack surface to the organisation distributing a signed and compromised version of their software to your phone. This is much less likely than any admin in the company looking at your stuff, or anyone who can hack into the company. Don't let the perfect be the enemy of the good.
  - mort96 4y ago
    That's not a bad point. That moves the conversation from "which organisations must we trust" to "which individuals in the organisations must we trust". After thinking about it for a bit, I find that argument rather convincing in the case of Signal: very few people would be in a position to add code to the distributed binary without it ending up in the git repo. So with E2EE, we still have to trust the organisation overall, but we don't have to trust any individuals with access to the servers, and the open-source nature lets us avoid trusting any of the individual app developers other than the person/group responsible for producing the final binaries. It's slightly less convincing in the case of WhatsApp or this GMail thing though. You don't have to avoid a back-door ending up in the git repo, you just have to make it past code review. So in that case, with E2EE, we still have to trust the organisation overall, we have to trust the individuals with access to the app source-code, but it lets us avoid trusting any individuals with access to the back-end. Still a win I suppose. Just a pretty far cry from how I usually see it advertised, which is more like "thanks to E2EE you don't even have to trust them".
    - godelski 4y ago
      Just beware that there are Signal forks where people do have modifications like being able to ignore delete commands. That's the downside of open source, that people can easily modify programs. This is also why Signal keeps a tight control over their servers. I'm happy that Signal has things open source, I think it is the better option, but I want to point this out because we need to recognize that the problem itself is over-constrained and there are not globally optimal solutions. It then becomes easy to justify several solutions and have us fight and go nowhere because we are arguing with different weighting criteria than the person we're arguing with. Those discussions are fruitless because we're speaking different languages despite being able to understand one another. And just to be clear, Signal says that they try to reduce the trust on them to as little as possible. Not zero trust/trustless. They sell "low trust" instead.
- dvngnt_ 4y ago
  you wait for court cases to see what can be taken
- godelski 4y ago
  > With Signal, both endpoints are Signal-controlled (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). While I agree with the concern here, is there an alternative mass market model in which software can be distributed in a way that ensures no one but the user controls the device? I mean mass market, so the barrier is that my tech illiterate grandma has to be able to install this with the help of my tech illiterate parents.
- nicce 4y ago
  You can verify in Google Pay. Just download the app from API and calculate checksum. Signal has reproducible builds https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/main/reprod...
- LinAGKar 4y ago
  Thus the value in being able to bring your own client which you trust, as you can do with e-mail and Matrix.
yazzku 4y ago
Where in that word vomit from Bleeping Computer are the keys stored? It says that decryption is handled by the browser, so unless you synchronize browsers the painful way, I assume Google has the key somewhere. I also wouldn't be surprised if the shit only works in Chrome. Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people? https://www.businessinsider.com/zoom-ftc-lawsuit-end-to-end-encryption-claims-2020-11?op=1 https://www.businessinsider.com/zoom-ftc-lawsuit-end-to-end-...
- ccouzens 4y ago
  The page links to a page which then links to https://support.google.com/a/answer/10801691 https://support.google.com/a/answer/10801691 They're either stored in your choice of third party service or you can host it yourself if you really want. I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text. > I also wouldn't be surprised if the shit only works in Chrome. I don't see any evidence of this in the documentation. I can't think what API it would require beyond the widely adopted fetch API. > Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people? I don't see any reason to think this is much different from any other end-to-end system. All the mobile end-to-end apps require you trust the code they run on your device. As described this requires you to trust the JavaScript they run on your browser.
  - yazzku 4y ago
    Good points! > I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text. I checked out the ref for that encryption API. Seems like the service stores the key, and the API exposes encrypt/decrypt calls: https://developers.google.com/workspace/cse/reference https://developers.google.com/workspace/cse/reference So yeah, go trust that third-party provider, or if you have the technical skill, set up your own. Since most people would do the former, this is basically back to square one, and to call this "end-to-end" is misleading. The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.

mort96 4y ago

This is my feeling about... well, basically every "end-to-end encrypted" product. With Signal, both endpoints are Signal-controlled (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). WhatsApp also claims to be "end-to-end encrypted", but there the app isn't even open source so both ends are just 100% Facebook-controlled without even a facade of transparency. Same with Apple's end-to-end encrypted stuff, where everything is encrypted on their servers but for all I know they can just ask my device that's running their closed software to send them information. I don't understand the hype around end-to-end encrypted software where you have to trust the organization behind the software to not steal your data through their complete control of the endpoints.

crgwbr 4y ago
Even if the app is open source with reproducible builds, you have to trust the OS. Are you going to audit every line of the entire operating system? If you do that, are you going to audit every transistor in the SoC to ensure the hardware isn’t compromised in some way? No one person can do that. Even if a team of people could do it, do you trust the other people? At some point, you have to trust _something_. If you don’t, you simply can’t use computers.
- yazzku 4y ago
  This does not take away from the parent's point. You need to trust something, yes; we just don't trust Google in particular in that whole chain of trust.
  - scarface74 4y ago
    It does take away from their point because they aren’t willing to trust Apple. It goes back to you have to trust someone.
    - mort96 4y ago
      I haven't said I'm not willing to trust Apple. The Apple example is included exactly because you have to trust Apple, whether they use E2EE or not, so E2EE doesn't make a difference and is security theatre. E2EE has value in the case where it (at least in principle) allows you to remove something from the list of trusted entities. Signal on the desktop is one such case, where E2EE lets us avoid trusting the Signal organisation.
      - scarface74 4y ago
        I’m not trying to protect myself from Apple. Apple doesn’t have a reason to lie. I want to protect myself from the police. I trust Apple much more than I trust law enforcement. I found that it could remain secret for too long if Apple were forced to compromise its encryption. Besides, they can afford better lawyers than Signal.
- mort96 4y ago
  What you're saying isn't wrong, but it misses the point. I'm not saying, "you have to trust someone so you shouldn't use it". I'm questioning whether the E2EE is adding anything or if it's security theatre. Take the case of WhatsApp. Without E2EE, you have to trust the platform (Apple) and the people behind the app (Facebook). With E2EE, you still have to trust Apple, but you also still have to trust Facebook, since Facebook controls the endpoint and you have no insight into what it does or if there are any back doors. The same applies to Signal obtained from the App Store or (AFAIK) Google Play. And Apple's E2EE stuff is obviously not adding anything, since we're already trusting them as the OS vendor. Something like Signal on the desktop is different though. There, we still have to trust the OS vendor, but we and anyone else can inspect the source code, verify that it does what it's supposed to and doesn't have any back-doors, compile it for ourselves, and then we can exchange messages without trusting Signal. In the case of Signal on the desktop, E2EE lets us distrust the Signal organisation, which has value even though we still need to trust our OS and our hardware. You could argue that we should trust the Signal organisation. That's not unreasonable, but that still makes E2EE no better than normal client-server encryption a la TLS and the promise of a solid no-logging policy. (We could also discuss the feasibility of verifying that there are no back-doors purely from reading source code and how well a back-door could be hidden. But that's sort of a tangent.)
  - nicce 4y ago
    I thought Signal has reproducible builds in Google Play too? It was one of the first apps to do so. https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/main/reprod...
eitland 4y ago
> (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). It is doable. Telegram has a procedure you can run to verify the binaries, also from the Apple App Store. Yes, it requires a jailbroken phone, but it is doable.
- mort96 4y ago
  I didn't know that. If accurate, this puts Telegram more in the category of something like Signal on the desktop than WhatsApp or this Google thing.
  - deleted 4y ago
    [deleted]
  - eitland 4y ago
    Unlike Signal, Telegram provides both end-to-end encrypted chats and point-to-point-encrypted chats. (But unlike Signal Telegram also haven't been caught with glaring zero days or caught sending images to anyone except the intented recipient the last fee years.)
    - m4lvin 4y ago
      What is the difference between end-to-end- and point-to-point-encrypted?
      - eitland 4y ago
        End-to-end-encrypted means without significant, unexpected breakthroughs in mathematics, no one can read it between the sender and the recipient, even if the traffic pass through FSB, NSA, Telegram, Google and Facebook headquarters and they all conspire to break it. Point-to-point-encrypted means it can theoretically[1] be read by the vendor (Telegram in this case) or anyone who can coerce the vendor. This is the standard for mail, online banking etc. The reason for providing both end-to-end-encrypted and point-to-point-encrypted is that point-to-point-encryption is significantly simpler, which makes it easiee to create useful and or cool features. [1]: vendors can do a nunber of things to make it hard/next to impossible for employees and others to access data, like for example restricting access to user data to service accounts, only allow debugging access in special circumstances and auditing such debugging access. Telegram used to claim they solve it by sending/storing encrypted data through/in different data centers from the keys, and keeping these days centers in different jurisdictions. Done properly should mean that two or more employees across the company would have to conspire to get access to customer data, or two or more judges in different countries would have to demand data. But unlike with end-to-end-encryption we have to take their word for it.
amelius 4y ago
Also your Android keyboard may be listening to anything you say in those E2EE apps.
- helloworld11 4y ago
  Is this a persistent problem in android phones? Is there any way to avoid it (except using iOS)?
  - izacus 4y ago
    There's no difference in this problem between Android and iOS. On both phones the keyboard software "listens" to what you type, how else would it function?
    - helloworld11 4y ago
      Yes but the key question is, where is the listening done and where is the data stored?
gregmac 4y ago
> at least on the App Store and Google Play you can't verify that the open source code is what's shipped Is there a reason Google and Apple couldn't change their deploy flow to pull from a git repository? As in: 1. Developer pushes to a specific remote (or pushes a specific tag or branch) 2. Apple/Google run the build on their systems, sign it, etc 3. If passed, the app deploys and the published app is annotated with the specific git hash (which can also be displayed in the app store) For open source, it gives the public verification ability. For closed source, it is still useful for internal verification. I work adjacent to some mobile teams and most still do builds on a developer's desktop and upload that. I am working towards getting CI for everything, partly to reduce dependence on any one developer's system (eg: I hear things like "Only Tom knows how to do builds to give to Apple, but he's out today") and partly for security. As much as I believe we don't have developers with malicious intent, there's still no way to know that a build uploaded from a developer's desktop really is what's in source control.
- aaomidi 4y ago
  Binary transparency is slowly getting more popular
- kelnos 4y ago
  > Is there a reason Google and Apple couldn't change their deploy flow to pull from a git repository? Because doing so isn't something they'd realistically care about. They'd still have to maintain the existing flow for closed-source apps (the vast majority of them) that don't want to give outside parties access to their source code, so this would just mean more work for them. Another big downside is that app authors would not be signing the final product with their own keys. That would have to be done by Google/Apple, so authors would lose a bit of control over future distribution of their app.
- tadfisher 4y ago
  Google supports code transparency attestations in app bundles[0], which allows third parties to verify the shipped binaries. [0]: https://developer.android.com/guide/app-bundle/code-transparency https://developer.android.com/guide/app-bundle/code-transpar...
MattPalmer1086 4y ago
You are correct to identify that end to end encryption without control of the software is not perfect. However, you have reduced the attack surface to the organisation distributing a signed and compromised version of their software to your phone. This is much less likely than any admin in the company looking at your stuff, or anyone who can hack into the company. Don't let the perfect be the enemy of the good.
- mort96 4y ago
  That's not a bad point. That moves the conversation from "which organisations must we trust" to "which individuals in the organisations must we trust". After thinking about it for a bit, I find that argument rather convincing in the case of Signal: very few people would be in a position to add code to the distributed binary without it ending up in the git repo. So with E2EE, we still have to trust the organisation overall, but we don't have to trust any individuals with access to the servers, and the open-source nature lets us avoid trusting any of the individual app developers other than the person/group responsible for producing the final binaries. It's slightly less convincing in the case of WhatsApp or this GMail thing though. You don't have to avoid a back-door ending up in the git repo, you just have to make it past code review. So in that case, with E2EE, we still have to trust the organisation overall, we have to trust the individuals with access to the app source-code, but it lets us avoid trusting any individuals with access to the back-end. Still a win I suppose. Just a pretty far cry from how I usually see it advertised, which is more like "thanks to E2EE you don't even have to trust them".
  - godelski 4y ago
    Just beware that there are Signal forks where people do have modifications like being able to ignore delete commands. That's the downside of open source, that people can easily modify programs. This is also why Signal keeps a tight control over their servers. I'm happy that Signal has things open source, I think it is the better option, but I want to point this out because we need to recognize that the problem itself is over-constrained and there are not globally optimal solutions. It then becomes easy to justify several solutions and have us fight and go nowhere because we are arguing with different weighting criteria than the person we're arguing with. Those discussions are fruitless because we're speaking different languages despite being able to understand one another. And just to be clear, Signal says that they try to reduce the trust on them to as little as possible. Not zero trust/trustless. They sell "low trust" instead.
dvngnt_ 4y ago
you wait for court cases to see what can be taken
godelski 4y ago
> With Signal, both endpoints are Signal-controlled (yes, the apps are open source, but at least on the App Store and Google Play you can't verify that the open source code is what's shipped). While I agree with the concern here, is there an alternative mass market model in which software can be distributed in a way that ensures no one but the user controls the device? I mean mass market, so the barrier is that my tech illiterate grandma has to be able to install this with the help of my tech illiterate parents.
nicce 4y ago
You can verify in Google Pay. Just download the app from API and calculate checksum. Signal has reproducible builds https://github.com/signalapp/Signal-Android/blob/main/reproducible-builds/README.md https://github.com/signalapp/Signal-Android/blob/main/reprod...
LinAGKar 4y ago
Thus the value in being able to bring your own client which you trust, as you can do with e-mail and Matrix.

yazzku 4y ago

Where in that word vomit from Bleeping Computer are the keys stored? It says that decryption is handled by the browser, so unless you synchronize browsers the painful way, I assume Google has the key somewhere. I also wouldn't be surprised if the shit only works in Chrome. Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people? https://www.businessinsider.com/zoom-ftc-lawsuit-end-to-end-encryption-claims-2020-11?op=1 https://www.businessinsider.com/zoom-ftc-lawsuit-end-to-end-...

ccouzens 4y ago
The page links to a page which then links to https://support.google.com/a/answer/10801691 https://support.google.com/a/answer/10801691 They're either stored in your choice of third party service or you can host it yourself if you really want. I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text. > I also wouldn't be surprised if the shit only works in Chrome. I don't see any evidence of this in the documentation. I can't think what API it would require beyond the widely adopted fetch API. > Also, wasn't Zoom sued for bastardizing the concept of "end-to-end encryption" to mislead people? I don't see any reason to think this is much different from any other end-to-end system. All the mobile end-to-end apps require you trust the code they run on your device. As described this requires you to trust the JavaScript they run on your browser.
- yazzku 4y ago
  Good points! > I don't see if the private half of the key is shared with the web app to decrypt the cypher text, or if the cypher text is sent to the key service which responds with plain text. I checked out the ref for that encryption API. Seems like the service stores the key, and the API exposes encrypt/decrypt calls: https://developers.google.com/workspace/cse/reference https://developers.google.com/workspace/cse/reference So yeah, go trust that third-party provider, or if you have the technical skill, set up your own. Since most people would do the former, this is basically back to square one, and to call this "end-to-end" is misleading. The idea of storing your keys on an Internet-facing server baffles me too. It will 100% get hacked sooner or later.