4 ms·

There are plenty of casual users who want the capability to have one-off conversations without worrying about who might be intercepting and storing the conversa

by eganist 11y ago

There are plenty of casual users who want the capability to have one-off conversations without worrying about who might be intercepting and storing the conversations, let alone without having to install anything new and try to convince their friends to use it too. This is made with them in mind. I see where you're coming from with the added attack surface argument, though I'd counter that browser sandboxing actually makes a web application safer for this use compared to creating a native application on the basis that if the native application is exploited, all user-mode data is now at risk. At least with the containment of the browser, the only things at risk are (potentially) your messages assuming successful XSS. So long as the proper mitigations are in place, it really makes no difference. The largest future improvement for Cyph in the future would be to incorporate one of the CSP2 changes for more safely allowing inlining, notably hash-src. However, since CSP2 adoption isn't all that widespread quite yet, it's better to hold off until the implementation details between the largest browsers are equalized. Edit to address your last paragraph: "[Users] won't install an app because people keep luring the away with insecure web-page based secure messengers." Native encrypted messaging apps have been around for a while and haven't really caught on unless integrated into existing apps a la iMessage. That's where the need for in-browser apps is coming from. My 2 cents. I'm likely entirely wrong; you've got more experience in general AppSec than I do, so my assumption of risks here might be off-base.

tptacek 11y ago
If you want to have a one-off conversation without worrying about someone intercepting and storing your conversation, use Google's IM protocol. You won't have to install anything. If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a messaging application that boots from a web page. For those serious adversaries, users need real secure messaging solutions, and today, they need to install software to do that.
- eganist 11y ago
  > all of them are likely to be able to compromise a messaging application that boots from a web page. All of them are likely to be able to compromise your OS, the Intel Management Engine (http://hackaday.com/2016/01/22/the-trouble-with-intels-management-engine/ http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...), your flash drives, the baseband on your blackphone... There's so much code, so many layers of abstraction involved in doing even the most basic things and so many things for which the US IC (let alone the 5E) almost certainly has exploits for that this quoted line is entirely moot when put in the context of attack economics. I was looking for any insight you might have into why a web application with the latest in protections surrounding the execution of unauthorized code and running in a sandboxed browser would still be more vulnerable compared to a native application running in usermode, but then you said... > and today, they need to install software to do [address serious adversaries]. I guess I can keep looking forward to someone else to address the point you tried to raise, since your position seems to be more of an emotional one. The only way we'll be able to advance privacy is by advancing ease of use. Web applications do a good job of providing that, and the IETF and browser makers are doing an excellent job of creating and integrating security standards to allow developers to bring that ease of use to realms of secure computing which traditionally required extensive manual configuration. Do you want wider adoption of security and privacy-assuring technologies by the general public? Be like the rest of us in the AppSec community and support the devs who try to advance the state of the art.
  - tptacek 11y ago
    That's what people who supported Cryptocat said. It's also what people who supported Telegram said. Not interested in this argument, sorry.
    - eganist 11y ago
      > That's what people who supported Cryptocat said. It's also what people who supported Telegram said. > Not interested in this argument, sorry. You shouldn't have started it then.
      - 11y ago
- buu700 11y ago
  all of them are likely to be able to compromise a messaging application that boots from a web page So this is really the fundamental disagreement. What makes you think that running a WebSigned app in a browser is significantly more exploitable than a native app? The way I see it, the worst thing that can be said about WebSign is that it breaks the chain of trust — i.e. that first download is implicitly trusted without any validation from a root certificate preloaded on the OS, whereas an app installed through a well designed package manager wouldn't have that problem. However, downloading a regular old executable through HTTPS is no different, and I don't see you calling that out in the same way. Beyond that issue, I would argue that the browser sandbox offers a more sophisticated and well vetted layer of protection than you would see in just about any native app framework, which leaves XSS as the primary risk (and Cyph has never had a known XSS bug anyway).
  - tptacek 11y ago
    Zero is the number of software security researchers who would agree with you that a program booted from a web page via content-controlled Javascript code running in a browser tab is as secure as a native application. Beyond that, I'm sorry, I'm just not going to go into further details in an HN thread. I don't think many people here think I'm just making stuff up, but in case you're worried about me saying "I told you so" down the road when someone else publishes, here's a fingerprint: b2b90c80626b1ba036bd87abc0741e1c69d2f6da398018de00b52a3cb9fe2121
    - buu700 11y ago
      Sure, "zero", except the researchers who actually audited it and concluded exactly that: http://pastebin.com/HcL5bneg http://pastebin.com/HcL5bneg Every reply you've made here seems to have been either an appeal to your own authority or a claim based on a browsing environment circa 2005. You haven't pointed to a single specific flaw in WebSign's architecture, so I can only assume you won't go into further detail because there is no further detail. This conversation was certainly enlightening (if nothing else, at least on our technical messaging). Thank you for the feedback.
      - 11y ago

by eganist 11y ago

tptacek 11y ago

If you want to have a one-off conversation without worrying about someone intercepting and storing your conversation, use Google's IM protocol. You won't have to install anything. If you want to protect your communications from the kinds of adversaries who can defeat Google's security, you're talking about a class of adversary that is largely government sponsored, and all of them are likely to be able to compromise a messaging application that boots from a web page. For those serious adversaries, users need real secure messaging solutions, and today, they need to install software to do that.

eganist 11y ago
> all of them are likely to be able to compromise a messaging application that boots from a web page. All of them are likely to be able to compromise your OS, the Intel Management Engine (http://hackaday.com/2016/01/22/the-trouble-with-intels-management-engine/ http://hackaday.com/2016/01/22/the-trouble-with-intels-manag...), your flash drives, the baseband on your blackphone... There's so much code, so many layers of abstraction involved in doing even the most basic things and so many things for which the US IC (let alone the 5E) almost certainly has exploits for that this quoted line is entirely moot when put in the context of attack economics. I was looking for any insight you might have into why a web application with the latest in protections surrounding the execution of unauthorized code and running in a sandboxed browser would still be more vulnerable compared to a native application running in usermode, but then you said... > and today, they need to install software to do [address serious adversaries]. I guess I can keep looking forward to someone else to address the point you tried to raise, since your position seems to be more of an emotional one. The only way we'll be able to advance privacy is by advancing ease of use. Web applications do a good job of providing that, and the IETF and browser makers are doing an excellent job of creating and integrating security standards to allow developers to bring that ease of use to realms of secure computing which traditionally required extensive manual configuration. Do you want wider adoption of security and privacy-assuring technologies by the general public? Be like the rest of us in the AppSec community and support the devs who try to advance the state of the art.
- tptacek 11y ago
  That's what people who supported Cryptocat said. It's also what people who supported Telegram said. Not interested in this argument, sorry.
  - eganist 11y ago
    > That's what people who supported Cryptocat said. It's also what people who supported Telegram said. > Not interested in this argument, sorry. You shouldn't have started it then.
    - 11y ago
buu700 11y ago
all of them are likely to be able to compromise a messaging application that boots from a web page So this is really the fundamental disagreement. What makes you think that running a WebSigned app in a browser is significantly more exploitable than a native app? The way I see it, the worst thing that can be said about WebSign is that it breaks the chain of trust — i.e. that first download is implicitly trusted without any validation from a root certificate preloaded on the OS, whereas an app installed through a well designed package manager wouldn't have that problem. However, downloading a regular old executable through HTTPS is no different, and I don't see you calling that out in the same way. Beyond that issue, I would argue that the browser sandbox offers a more sophisticated and well vetted layer of protection than you would see in just about any native app framework, which leaves XSS as the primary risk (and Cyph has never had a known XSS bug anyway).
- tptacek 11y ago
  Zero is the number of software security researchers who would agree with you that a program booted from a web page via content-controlled Javascript code running in a browser tab is as secure as a native application. Beyond that, I'm sorry, I'm just not going to go into further details in an HN thread. I don't think many people here think I'm just making stuff up, but in case you're worried about me saying "I told you so" down the road when someone else publishes, here's a fingerprint: b2b90c80626b1ba036bd87abc0741e1c69d2f6da398018de00b52a3cb9fe2121
  - buu700 11y ago
    Sure, "zero", except the researchers who actually audited it and concluded exactly that: http://pastebin.com/HcL5bneg http://pastebin.com/HcL5bneg Every reply you've made here seems to have been either an appeal to your own authority or a claim based on a browsing environment circa 2005. You haven't pointed to a single specific flaw in WebSign's architecture, so I can only assume you won't go into further detail because there is no further detail. This conversation was certainly enlightening (if nothing else, at least on our technical messaging). Thank you for the feedback.
    - 11y ago