5 ms·

Let me put it like this – if OpenWhisperSystems had an explicit toggle in their protocol which, after flipping it, would allow them to access all future communi

Let me put it like this – if OpenWhisperSystems had an explicit toggle in their protocol which, after flipping it, would allow them to access all future communications and where the user was unable to tell whether it had or had not been flipped, nobody would call the protocol "secure" or write a "Trust It" headline about it. However, if OWS only supports systems on which such a toggle exists via a third-party provider, that somehow makes them secure? I find this hard to understand. Yes, of course an app which encrypts data against some adversaries is nice, but it should definitely be called "secure-against-some-people", not "secure", and people shouldn’t write "Trust It" but rather "Trust It if you also trust X and Y and Z".

tptacek 10y ago
Again: this is a point that can be made to sound interesting with lots of extra words, but all you're saying is that people run applications on operating systems you don't like. They're not going to switch.
- claudius 10y ago
  And the counterpoint is? ‘People should give Google/Apple root access on their devices to run this new secure messenger’?
  - eganist 10y ago
    > And the counterpoint is? ‘People should give Google/Apple root access on their devices to run this new secure messenger’? I feel like you might've misstated your intended point, but in any case: - Most threat models exclude the situation which you're discussing here because risks are generally low and, in the event of such a threat becoming material, the entity is probably screwed regardless of whether that threat is considered due to the costs of mitigation. (Seriously -- how would a company or person mitigate this short of independently auditing the code for the OS? Or building their own? And what happens after you look at the code? Do you then look at the hardware too? How low would you go? How low would your attackers go, for that matter?) - If you're the target of attackers who would actually try to gain access to your device through compromising the device maker, you've got bigger problems. The philosophical argument doesn't really work here because there's no practical solution that anyone can (or would, really) adequately fund. P.s. just to clarify, I'm not tptacek.
  - sseppola 10y ago
    Sorry, I don't understand. What do you mean by "give Apple/Google root access"? I've always assumed they already have that.. if no, how does OWS give them root access?
    - e12e 10y ago
      You can compile Signal yourself, and install it on a rooted phone, running presumably a Linux kernel and some Android/ASOP sub-system. In that case, excepting base-band backdoors and a few other details, Google won't have access to your phone at all (assuming no Google services etc here). OWS doesn't then allow you to use their servers for routing/discovery etc - so you need to run your own servers, and set up a different network that cannot federate with the one users of the Google Play Appstore version of Signal use. If you do that, and install eg. the F-Droid store, you've now given another actor (the F-Droid store) access to your phone. OWS argues that in general you're less likely to manage to run a safe, patched system this way.
      - haffenloher 10y ago
        > You can compile Signal yourself, and install it on a rooted phone [...] OWS doesn't then allow you to use their servers for routing/discovery etc ? That's a misunderstanding. You can of course use the official servers with your self-compiled version. (side note: I also don't think your phone needs to be rooted for this)
        e12e 10y ago
        Ok, that makes sense. It's only compiled binaries distributed through third party app stores that cannot (should not) use the official servers?
        haffenloher 10y ago
        Yeah, they prefer if you don't distribute your builds (i.e. something named Signal and / or using their servers) to other people (because they don't actually know what's inside the builds, they've got no update channel, etc.)
- eeZah7Ux 10y ago
  Ad-personam attacks are not useful Clarification: "...operating systems you don't like" implies that claudius is biased and that his point about OS security is made invalid by that.
  - deleted 10y ago
    [deleted]
  - cryptarch 10y ago
    It's "ad-hominem", but I agree.
    - pessimizer 10y ago
      "Ad-personem" and "ad-hominem" are equally accurate in this case, because it wasn't either.
      - cryptarch 10y ago
        I done goofed. I wasn't even aware what an "ad-personam" was. I found a related question on Quora and that explained it quite well I think. Quora question: https://www.quora.com/What-are-concrete-examples-of-ad-hominem-and-ad-personam-Are-they-the-same-or-is-there-a-difference https://www.quora.com/What-are-concrete-examples-of-ad-homin...
  - lorenzhs 10y ago
    That's true, but this isn't one. This is what respectfully disagreeing looks like. Ad hominem would be "No, you're an idiot and people don't care what you think just because you disagree with choices they made". That would have been inappropriate.
    - JoeAltmaier 10y ago
      The implication was there - that a point was made 'only' because of an os they didn't like. Its Ad-Hominem. It was pretty far from 'respectfully disagreeing'
- wtbob 10y ago
  > all you're saying is that people run applications on operating systems you don't like No, he's saying that people run applications on fundamentally insecure operating systems. > They're not going to switch. That doesn't make them right, nor him wrong.
- CaptSpify 10y ago
  > They're not going to switch. Only because there's there's nothing to switch to. There's just no solid FOSS phone OS at the moment, and, IMO, fixing that is more important than securing messaging systems.
  - tptacek 10y ago
    Dissidents in places like Iran have already been attacked through weaknesses in secure messaging systems. No, I think you're on the wrong side of this argument.
    - CaptSpify 10y ago
      Don't get me wrong: We absolutely need both But fixing the client when the host is still insecure/unknown is just going to move the target. If messages are secure, governments are just going to move to the OS-layer.
      - cortesoft 10y ago
        So you have two attack vectors, the OS host and the client application; why is it bad to secure the client? It doesn't ADD any attack vectors. What is the point in saying "Let's not secure the client software until the OS is secured"? It isn't like these are the same people working on the problem; Moxie isn't going to suddenly start working on securing iOS if he isn't working on OWS.
        CaptSpify 10y ago
        I don't disagree with you. This is a multi-pronged problem and we need multi-pronged solutions. I just think the OS is a higher priority than a texting-client
    - e12e 10y ago
      And dissidents have been attacked through holes in iOS too. I generally accept Moxie's / OWS's argument that upstream, patched Android with Google services and spyware/backdoor and all, is in general more secure than running a hodgepodge of FOSS software on a rooted phone - especially for less technical minded users (ie: almost everyone if your target market is everyone). I don't think it follows that a transparent platform running fully open and user-controlled software, perhaps backed by some form of web-of-trust cacert-like CA system can't ever work - and might not be a good idea to have available as a fallback if it turns out that the anti-democratic paramilitary organization you have to fight is one backed by the NSA. I'm a little surprised how polarized these discussions tend to get - as if two ideas have to be mutually exclusive. I think I understand OWS reasoning with locking down their network and forcing phone number IDs - I don't really agree - but I understand the reasoning behind it. It's really on all of us that care about open federated protocols to set up an alternative network, and OWS have even graciously provided source code and a protocol as a starting point - but it's a shame that rather than some email-like model where all systems could federate in a predictable way, we are forced to have three different networks (a hypothetical open-signal, signal and whatsapp). I guess there's a lot of people that are still sore about Facebook and Google discarding XMPP, and breaking the unification trend that we saw a glimmer of a few years back. Even without federation, I could have one sane XMPP client, with OTR support, and chat both to my non-technical friends on gtalk and facebook - and have encrypted chats over those same servers, or through the federated XMPP network. Now I have some people in Facebook's silo, some in Google's Hangouts silo, still quite a few on SMS/regular phone service, and a handful on Signal. That's not really the fault of OWS - I actually have a few non-technical contacts I can reach via Signal thanks to their focus on a simple SMS-replacing app. I just still wish I could cut back on the number of clients and have some sane federation.
mtgx 10y ago
The same can be said about a "trusted" OS like say Qubes OS, with untrusted hardware, like Intel's. Actually, that's what the developers of Qubes OS and other "free" operating systems have said as well. http://blog.invisiblethings.org/2015/10/27/x86_harmful.html http://blog.invisiblethings.org/2015/10/27/x86_harmful.html https://www.fsf.org/blogs/licensing/intel-me-and-why-we-should-get-rid-of-me https://www.fsf.org/blogs/licensing/intel-me-and-why-we-shou... If anything, I'm more frustrated with the Signal team that the app doesn't have as good call quality/performance as WhatsApp, nor does it have video call support, and that the Chrome desktop "app" doesn't seem to import my phone contacts for some reason - all of which is making me continue to mostly use less secure and less trusted alternatives. My point is we should aim for getting things "more secure" constantly, and I think we have in the past few years. So rather than just say "what's the point?", we should say "let's put more pressure on X company to open source/prove their system is secure" and hope that in time enough pressure is built that those companies actually agree to do those things. And since I was talking about putting pressure on companies, let me start: Where the hell is Google's End-to-End tool? It hasn't had any commits in over half an year, and we already know NSA's bestie, Yahoo, has given up on it. Should we start drawing some conclusions about the Google/NSA relationship, too? Did Google abandon the project? https://github.com/google/end-to-end https://github.com/google/end-to-end There - who's next?
- haffenloher 10y ago
  > the Chrome desktop "app" doesn't seem to import my phone contacts for some reason Have you tried re-importing them manually via the "Import now" button in the Desktop app's settings? Maybe that helps.
- lrk_sirius 10y ago
  > The same can be said about a "trusted" OS like say Qubes OS, with untrusted hardware, like Intel's. Actually, that's what the developers of Qubes OS and other "free" operating systems have said as well. If you're really paranoid, go for open hardware supported by libreboot [0] or the Talos Workstation and run a hardened "free" OS. However, I don't think Intel ME (or similar firmware in AMD and ARM) has ever been used to compromise user security and privacy. The threat probably exists and is real but has it ever been exploited? On the other hand, I suspect that there is no lack of zero-days and other vulnerabilities for iOS and Android. [0] https://libreboot.org/ https://libreboot.org/ [1] https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation https://www.crowdsupply.com/raptor-computing-systems/talos-s...

tptacek 10y ago

Again: this is a point that can be made to sound interesting with lots of extra words, but all you're saying is that people run applications on operating systems you don't like. They're not going to switch.

claudius 10y ago
And the counterpoint is? ‘People should give Google/Apple root access on their devices to run this new secure messenger’?
- eganist 10y ago
  > And the counterpoint is? ‘People should give Google/Apple root access on their devices to run this new secure messenger’? I feel like you might've misstated your intended point, but in any case: - Most threat models exclude the situation which you're discussing here because risks are generally low and, in the event of such a threat becoming material, the entity is probably screwed regardless of whether that threat is considered due to the costs of mitigation. (Seriously -- how would a company or person mitigate this short of independently auditing the code for the OS? Or building their own? And what happens after you look at the code? Do you then look at the hardware too? How low would you go? How low would your attackers go, for that matter?) - If you're the target of attackers who would actually try to gain access to your device through compromising the device maker, you've got bigger problems. The philosophical argument doesn't really work here because there's no practical solution that anyone can (or would, really) adequately fund. P.s. just to clarify, I'm not tptacek.
- sseppola 10y ago
  Sorry, I don't understand. What do you mean by "give Apple/Google root access"? I've always assumed they already have that.. if no, how does OWS give them root access?
  - e12e 10y ago
    You can compile Signal yourself, and install it on a rooted phone, running presumably a Linux kernel and some Android/ASOP sub-system. In that case, excepting base-band backdoors and a few other details, Google won't have access to your phone at all (assuming no Google services etc here). OWS doesn't then allow you to use their servers for routing/discovery etc - so you need to run your own servers, and set up a different network that cannot federate with the one users of the Google Play Appstore version of Signal use. If you do that, and install eg. the F-Droid store, you've now given another actor (the F-Droid store) access to your phone. OWS argues that in general you're less likely to manage to run a safe, patched system this way.
    - haffenloher 10y ago
      > You can compile Signal yourself, and install it on a rooted phone [...] OWS doesn't then allow you to use their servers for routing/discovery etc ? That's a misunderstanding. You can of course use the official servers with your self-compiled version. (side note: I also don't think your phone needs to be rooted for this)
      - e12e 10y ago
        Ok, that makes sense. It's only compiled binaries distributed through third party app stores that cannot (should not) use the official servers?
        haffenloher 10y ago
        Yeah, they prefer if you don't distribute your builds (i.e. something named Signal and / or using their servers) to other people (because they don't actually know what's inside the builds, they've got no update channel, etc.)
eeZah7Ux 10y ago
Ad-personam attacks are not useful Clarification: "...operating systems you don't like" implies that claudius is biased and that his point about OS security is made invalid by that.
- deleted 10y ago
  [deleted]
- cryptarch 10y ago
  It's "ad-hominem", but I agree.
  - pessimizer 10y ago
    "Ad-personem" and "ad-hominem" are equally accurate in this case, because it wasn't either.
    - cryptarch 10y ago
      I done goofed. I wasn't even aware what an "ad-personam" was. I found a related question on Quora and that explained it quite well I think. Quora question: https://www.quora.com/What-are-concrete-examples-of-ad-hominem-and-ad-personam-Are-they-the-same-or-is-there-a-difference https://www.quora.com/What-are-concrete-examples-of-ad-homin...
- lorenzhs 10y ago
  That's true, but this isn't one. This is what respectfully disagreeing looks like. Ad hominem would be "No, you're an idiot and people don't care what you think just because you disagree with choices they made". That would have been inappropriate.
  - JoeAltmaier 10y ago
    The implication was there - that a point was made 'only' because of an os they didn't like. Its Ad-Hominem. It was pretty far from 'respectfully disagreeing'
wtbob 10y ago
> all you're saying is that people run applications on operating systems you don't like No, he's saying that people run applications on fundamentally insecure operating systems. > They're not going to switch. That doesn't make them right, nor him wrong.
CaptSpify 10y ago
> They're not going to switch. Only because there's there's nothing to switch to. There's just no solid FOSS phone OS at the moment, and, IMO, fixing that is more important than securing messaging systems.
- tptacek 10y ago
  Dissidents in places like Iran have already been attacked through weaknesses in secure messaging systems. No, I think you're on the wrong side of this argument.
  - CaptSpify 10y ago
    Don't get me wrong: We absolutely need both But fixing the client when the host is still insecure/unknown is just going to move the target. If messages are secure, governments are just going to move to the OS-layer.
    - cortesoft 10y ago
      So you have two attack vectors, the OS host and the client application; why is it bad to secure the client? It doesn't ADD any attack vectors. What is the point in saying "Let's not secure the client software until the OS is secured"? It isn't like these are the same people working on the problem; Moxie isn't going to suddenly start working on securing iOS if he isn't working on OWS.
      - CaptSpify 10y ago
        I don't disagree with you. This is a multi-pronged problem and we need multi-pronged solutions. I just think the OS is a higher priority than a texting-client
  - e12e 10y ago
    And dissidents have been attacked through holes in iOS too. I generally accept Moxie's / OWS's argument that upstream, patched Android with Google services and spyware/backdoor and all, is in general more secure than running a hodgepodge of FOSS software on a rooted phone - especially for less technical minded users (ie: almost everyone if your target market is everyone). I don't think it follows that a transparent platform running fully open and user-controlled software, perhaps backed by some form of web-of-trust cacert-like CA system can't ever work - and might not be a good idea to have available as a fallback if it turns out that the anti-democratic paramilitary organization you have to fight is one backed by the NSA. I'm a little surprised how polarized these discussions tend to get - as if two ideas have to be mutually exclusive. I think I understand OWS reasoning with locking down their network and forcing phone number IDs - I don't really agree - but I understand the reasoning behind it. It's really on all of us that care about open federated protocols to set up an alternative network, and OWS have even graciously provided source code and a protocol as a starting point - but it's a shame that rather than some email-like model where all systems could federate in a predictable way, we are forced to have three different networks (a hypothetical open-signal, signal and whatsapp). I guess there's a lot of people that are still sore about Facebook and Google discarding XMPP, and breaking the unification trend that we saw a glimmer of a few years back. Even without federation, I could have one sane XMPP client, with OTR support, and chat both to my non-technical friends on gtalk and facebook - and have encrypted chats over those same servers, or through the federated XMPP network. Now I have some people in Facebook's silo, some in Google's Hangouts silo, still quite a few on SMS/regular phone service, and a handful on Signal. That's not really the fault of OWS - I actually have a few non-technical contacts I can reach via Signal thanks to their focus on a simple SMS-replacing app. I just still wish I could cut back on the number of clients and have some sane federation.

mtgx 10y ago

The same can be said about a "trusted" OS like say Qubes OS, with untrusted hardware, like Intel's. Actually, that's what the developers of Qubes OS and other "free" operating systems have said as well. http://blog.invisiblethings.org/2015/10/27/x86_harmful.html http://blog.invisiblethings.org/2015/10/27/x86_harmful.html https://www.fsf.org/blogs/licensing/intel-me-and-why-we-should-get-rid-of-me https://www.fsf.org/blogs/licensing/intel-me-and-why-we-shou... If anything, I'm more frustrated with the Signal team that the app doesn't have as good call quality/performance as WhatsApp, nor does it have video call support, and that the Chrome desktop "app" doesn't seem to import my phone contacts for some reason - all of which is making me continue to mostly use less secure and less trusted alternatives. My point is we should aim for getting things "more secure" constantly, and I think we have in the past few years. So rather than just say "what's the point?", we should say "let's put more pressure on X company to open source/prove their system is secure" and hope that in time enough pressure is built that those companies actually agree to do those things. And since I was talking about putting pressure on companies, let me start: Where the hell is Google's End-to-End tool? It hasn't had any commits in over half an year, and we already know NSA's bestie, Yahoo, has given up on it. Should we start drawing some conclusions about the Google/NSA relationship, too? Did Google abandon the project? https://github.com/google/end-to-end https://github.com/google/end-to-end There - who's next?

haffenloher 10y ago
> the Chrome desktop "app" doesn't seem to import my phone contacts for some reason Have you tried re-importing them manually via the "Import now" button in the Desktop app's settings? Maybe that helps.
lrk_sirius 10y ago
> The same can be said about a "trusted" OS like say Qubes OS, with untrusted hardware, like Intel's. Actually, that's what the developers of Qubes OS and other "free" operating systems have said as well. If you're really paranoid, go for open hardware supported by libreboot [0] or the Talos Workstation and run a hardened "free" OS. However, I don't think Intel ME (or similar firmware in AMD and ARM) has ever been used to compromise user security and privacy. The threat probably exists and is real but has it ever been exploited? On the other hand, I suspect that there is no lack of zero-days and other vulnerabilities for iOS and Android. [0] https://libreboot.org/ https://libreboot.org/ [1] https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation https://www.crowdsupply.com/raptor-computing-systems/talos-s...