4 ms·

> Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it? That's how literally any website works. How do y

> Your server can feed arbitrary Javascript to browsers and subvert encryption in a variety of ways, can't it? That's how literally any website works. How do you encrypt in the browser if the server doesn't send JavaScript to encrypt data? You also trust Signal not to issue an update that sends data in plaintext over the network. Unless you're building an app from source, you implicitly trust the developer to some extent.

raggi 3y ago
Signal doesn’t have a web client. Most of the stores it is distributed through have fairly strong resistance to compel orders.
- dannyobrien 3y ago
  Yep, but Signal is still a potential adversary, and could roll out a backdoor. A couple of things that are easier in a web-delivered tool is deliver a backdoor to a user or group of users (which Skiff can track), or deliver a backdoor over a particular window of time across many users to decrease the chance of detection. I know Skiff uses IPFS in some of parts of their solutions, and there's something they could do with that for the first -- essentially making visiting a particular version of the code part of how it is accessed, but there's some real UI challenges, which maybe they're looking into (it's been a while since I checked them out: they have some great UX in other parts of their suite). The other tactic I've seen is to bundle the page into a browser extension, which moves you closer to Signal's status.
  - tptacek 3y ago
    Signal's servers can't backdoor the Signal Client. From what I understand of Skiff, Skiff's servers are the client.
    - josephg 3y ago
      Not directly. They would have to roll out an update with the backdoor to the App Store. But as a user I’d be none the wiser. I wish there was some way on iOS to prove that some particular version of an app was built from a certain git hash. That way these sort of attacks would be easier to detect.
      - progbits 3y ago
        That would be ideal. F-Droid on android can do this: https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ However there is still one advantage of even appstor: They have to push the backdoored version to everyone (or large set of users). So that drastically increases risk of being caught. Website under their control can backdoor one specific user or even just one session, making detection harder.
        josephg 3y ago
        > So that drastically increases risk of being caught. Only if someone out there is extracting, decompiling and auditing each version of the Signal iOS app in the app store. But I doubt anyone is doing this. If a backdoor is ever snuck into the signal ios app for a few users for a few weeks, I highly doubt anybody would notice.
        actionfromafar 3y ago
        xkcd://386 Of course someone is doing this. I’m not sure they are the kind to tell it to the world, though.
        progbits 3y ago
        Not just someONE, whole bunch of researchers and automated scans.
        rvnx 3y ago
        You can change remote configuration flags post-release (e.g. to enable diagnostics). Even “secure” softwares like Google Chrome can capture your whole browsing history if they suddenly decide to enable a flag on your IP address. No need for conspiracy or update, though Chrome is considered perfectly secure. In Android you can also distribute updates to specific e-mail addresses, which is very convenient.
  - holmesworcester 3y ago
    Group invite links in Signal work similarly to Skiff: they reveal a key to the client side js so it can either present users with a Signal download link or open a URI, depending on whether they already have Signal or not. (Signal chooses not to use a URI in this case because it would break for anyone without Signal.) So if a Signal group is using group invite links they have the same problem Skiff does. What I would like to exist is something like Subresource Integrity [1] but for a URL itself, so that you could include a hash in a URL and let the browser warn you if the page source doesn't match the hash. 1. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
ignoramous 3y ago
> How do you encrypt in the browser if the server doesn't send JavaScript to encrypt data? Meta has done some work along with Cloudflare on this for WhatsApp Web, specifically. In general, JS crypto is always going to be suspect if the threat model involves distrusting the server (like in e2ee protocols like Signal).
- amilich 3y ago
  JS crypto functions now interface with browser crypto functions for the last decade or so. https://developer.mozilla.org/en-US/docs/Web/API/Crypto https://developer.mozilla.org/en-US/docs/Web/API/Crypto
  - tptacek 3y ago
    What difference does this make to the thread model in the previous comment?
    - amilich 3y ago
      Before this basic cryptography was downloaded via JS files which yields no security and gave web cryptography a bad reputation. That is not true now.
      - onereplyac2 3y ago
        Huh? It is very concerning to hear this from a founder. It is the same exact level of security as it is executing the same code, just at a different level. Really does not matter what crypto lib you are using if at the end of the day the surrounding code dictates all the security. Regardless of all this, your open source crypto library doesn't even use the Web Crypto APIs at all, but rather the dreaded js based crypto you are badmouthing (tweetnacl, stablelib)
        amilich 3y ago
        That's just false. Downloading crypto libraries over the web plagued Javascript crypto for years. We use tweetnacl, stablelib, and webcrypto - and tweetnacl also uses webcrypto!
cracked-behem 3y ago
I built something that solves this problem. It uses an open source program installed on the client to encrypt and store data in a way that doesn't allow the website to access the plaintext data. https://redact.ws https://redact.ws

raggi 3y ago

Signal doesn’t have a web client. Most of the stores it is distributed through have fairly strong resistance to compel orders.

dannyobrien 3y ago
Yep, but Signal is still a potential adversary, and could roll out a backdoor. A couple of things that are easier in a web-delivered tool is deliver a backdoor to a user or group of users (which Skiff can track), or deliver a backdoor over a particular window of time across many users to decrease the chance of detection. I know Skiff uses IPFS in some of parts of their solutions, and there's something they could do with that for the first -- essentially making visiting a particular version of the code part of how it is accessed, but there's some real UI challenges, which maybe they're looking into (it's been a while since I checked them out: they have some great UX in other parts of their suite). The other tactic I've seen is to bundle the page into a browser extension, which moves you closer to Signal's status.
- tptacek 3y ago
  Signal's servers can't backdoor the Signal Client. From what I understand of Skiff, Skiff's servers are the client.
  - josephg 3y ago
    Not directly. They would have to roll out an update with the backdoor to the App Store. But as a user I’d be none the wiser. I wish there was some way on iOS to prove that some particular version of an app was built from a certain git hash. That way these sort of attacks would be easier to detect.
    - progbits 3y ago
      That would be ideal. F-Droid on android can do this: https://f-droid.org/en/docs/Reproducible_Builds/ https://f-droid.org/en/docs/Reproducible_Builds/ However there is still one advantage of even appstor: They have to push the backdoored version to everyone (or large set of users). So that drastically increases risk of being caught. Website under their control can backdoor one specific user or even just one session, making detection harder.
      - josephg 3y ago
        > So that drastically increases risk of being caught. Only if someone out there is extracting, decompiling and auditing each version of the Signal iOS app in the app store. But I doubt anyone is doing this. If a backdoor is ever snuck into the signal ios app for a few users for a few weeks, I highly doubt anybody would notice.
        actionfromafar 3y ago
        xkcd://386 Of course someone is doing this. I’m not sure they are the kind to tell it to the world, though.
        progbits 3y ago
        Not just someONE, whole bunch of researchers and automated scans.
        rvnx 3y ago
        You can change remote configuration flags post-release (e.g. to enable diagnostics). Even “secure” softwares like Google Chrome can capture your whole browsing history if they suddenly decide to enable a flag on your IP address. No need for conspiracy or update, though Chrome is considered perfectly secure. In Android you can also distribute updates to specific e-mail addresses, which is very convenient.
- holmesworcester 3y ago
  Group invite links in Signal work similarly to Skiff: they reveal a key to the client side js so it can either present users with a Signal download link or open a URI, depending on whether they already have Signal or not. (Signal chooses not to use a URI in this case because it would break for anyone without Signal.) So if a Signal group is using group invite links they have the same problem Skiff does. What I would like to exist is something like Subresource Integrity [1] but for a URL itself, so that you could include a hash in a URL and let the browser warn you if the page source doesn't match the hash. 1. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

ignoramous 3y ago

> How do you encrypt in the browser if the server doesn't send JavaScript to encrypt data? Meta has done some work along with Cloudflare on this for WhatsApp Web, specifically. In general, JS crypto is always going to be suspect if the threat model involves distrusting the server (like in e2ee protocols like Signal).

amilich 3y ago
JS crypto functions now interface with browser crypto functions for the last decade or so. https://developer.mozilla.org/en-US/docs/Web/API/Crypto https://developer.mozilla.org/en-US/docs/Web/API/Crypto
- tptacek 3y ago
  What difference does this make to the thread model in the previous comment?
  - amilich 3y ago
    Before this basic cryptography was downloaded via JS files which yields no security and gave web cryptography a bad reputation. That is not true now.
    - onereplyac2 3y ago
      Huh? It is very concerning to hear this from a founder. It is the same exact level of security as it is executing the same code, just at a different level. Really does not matter what crypto lib you are using if at the end of the day the surrounding code dictates all the security. Regardless of all this, your open source crypto library doesn't even use the Web Crypto APIs at all, but rather the dreaded js based crypto you are badmouthing (tweetnacl, stablelib)
      - amilich 3y ago
        That's just false. Downloading crypto libraries over the web plagued Javascript crypto for years. We use tweetnacl, stablelib, and webcrypto - and tweetnacl also uses webcrypto!

cracked-behem 3y ago

I built something that solves this problem. It uses an open source program installed on the client to encrypt and store data in a way that doesn't allow the website to access the plaintext data. https://redact.ws https://redact.ws