21 ms·

Send is meant to be an improvement on Dropbox & co for a specific use case. Is it perfect? No, it isn't. But it is still a considerable improvement. If you ha

by Yoric 9y ago

Send is meant to be an improvement on Dropbox & co for a specific use case. Is it perfect? No, it isn't. But it is still a considerable improvement. If you have a better solution in mind for the average user crowd, feel free to suggest it, of course.

jhasse 9y ago
Sending the file over an end to end encrypted chat app.
- codebolt 9y ago
  Even then, you are trusting the app to do what it says it's going to do. The only way I feel 100% safe is encrypting the file manually before sending (through whatever platform), and sharing the key through some other medium (preferably word of mouth). As a Windows user I mostly use 7-zip for this purpose, or the encryption plugin in Notepad++ for text.
  - cyphar 9y ago
    If the app is free software it can be audited. The problem with web-based crypto is that you're downloading a new program every page refresh and executing it immediately. If you're worried about a free software app not encrypting things properly, I'd be worried about the tools you use manually doing the right thing as well. While I agree that doing it manually is the only reliable way if you're going to send it over an insecure channel, if the channel is secure then it's much easier for an end-user to just send it in the app.
  - pleasecalllater 9y ago
    And that's still just a feeling. You just feel you can trust the encryption application. Which can be changed any time in the future in a way it is not secure any more. You just need to trust. So what's wrong in trusting Mozilla, if you can easily trust your encryption/decryption software?
  - galaxyLogic 9y ago
    Why would you trust 7-zip or NotePad++ more than FireFox?
    - jhasse 9y ago
      Because I don't trust Mozilla, see https://www.reddit.com/r/linux/comments/6mw1ld/firefox_tracks_users_with_google_analytics_in_the/ https://www.reddit.com/r/linux/comments/6mw1ld/firefox_track... or http://www.zdnet.com/article/firefox-tests-cliqz-engine-which-slurps-user-browsing-data/ http://www.zdnet.com/article/firefox-tests-cliqz-engine-whic...
takeda 9y ago
Well there's reasoning which states that bad security is worse than no security. The reason for it, is that if you trust the site to be secure it might be devastating once security is compromised, but with no security you're typically more careful.
- Nexxxeh 9y ago
  We are more careful, as in the HN crowd. The general public? I'd wager "not so much".
zeveb 9y ago
> But it is still a considerable improvement. When it's secure, it's an improvement; if Mozilla, a Mozilla employee or a government which can compel Mozilla employees chooses to make it insecure, then it's worse than insecure. At least with something like Dropbox users (should) know that they are insecure and should not transmit sensitive files. > If you have a better solution in mind for the average user crowd, feel free to suggest it, of course. The functionality should be built into Firefox, so that users can verify source code & protocols once and know that they are secure thereafter.
- damnyou 9y ago
  And re-check them after every update? And trust that Mozilla won't randomly distribute a backdoor to 1/n of users? The means you're suggesting aren't possible to implement for most people today. If you care about real-world impact I would recommend thinking of other strategies.
  - cyphar 9y ago
    Reproducible builds effectively solve this problem, by making it possible to actually verify that you got the same binary (from the same source) as everyone else. Not to mention that if you're on Linux, distributions build Firefox themselves and so attacks against users need to be far larger in scale for 1/n attacks.
    - damnyou 9y ago
      They're both important steps, but neither solves the problem. Most users don't verify the reproducibility of their builds and don't use Linux.
      - cyphar 9y ago
        It solves the problem for users that use Linux. If other operating systems cared about making software distribution sane, they could also use package managers. It's a shame that they don't. As for verifying reproducibility, if you're using a package manager then this verification is quite trivial (and can be done automatically). Solving the problem for proprietary operating systems that intentionally have horrific systems of managing the software on said operating system is harder due to an artificial, self-inflicted handicap. "Just" switching people to Linux is probably easier (hey, Google managed to get people to run Gentoo after all).
carussell 9y ago
Spec out and implement resource pinning, already. Like RFC 8246, but authored more with the user's interests in mind, rather than the service's. As a show of nothing-up-the-sleeve, a service asserts that it's in a stable state and will continue to serve exact copies of the resources as they exist now—that they will not change out from beneath the client in subsequent requests. When a user chooses to use resource pinning, the browser checks that this is true, and if finding a new deployment has occurred, the browser will refuse to accept it without deliberate consent and action from the user (something on par with invalid cert screen). This means that for a subset of services (those whose business logic can run primarily on the client side), the users need not trust the server, they need only to trust the app, which can be audited. When deploying updated resources, services SHOULD make the update well-advertised and accompany it with some notice out of band (such as a post about the new "release", its changelog, and a link to the repo), so the new deployment may be audited. When new deployments occur, clients SHOULD allow the user to opt for continuing to using the pinned resources, and services SHOULD be implemented in such a way that this is handled gracefully. This gives the user continuity of access while the user (or their org) is carrying out the audit process. Areas where this would be useful: - HIPAA compliance - Web crypto that isn't fundamentally broken - Stronger guarantees for non-local resources used in Web Extensions—in fact, the entire extension update mechanism could probably be more or less rebased on top of the resource pinning policy
- the8472 9y ago
  This would also have the added bonus that one could reload such pinned resources from anywhere once you got the pin. Even without TLS setup or having to trust certificate chains. Caching proxies would suddenly become viable again because only the first download has to through HTTPS while "I don't have this in the local cache anymore, can you serve me this content" requests could go through sidechannels or outside the TLS handshake or something like that. Caches could even perform downgrade non-attacks.
  - Dylan16807 9y ago
    How many pins would you expect a browser instance to have? I feel like most of the time the pinned content could fit in the browser cache and make this variety of proxy-side caching pointless.

by Yoric 9y ago

jhasse 9y ago

Sending the file over an end to end encrypted chat app.

codebolt 9y ago
Even then, you are trusting the app to do what it says it's going to do. The only way I feel 100% safe is encrypting the file manually before sending (through whatever platform), and sharing the key through some other medium (preferably word of mouth). As a Windows user I mostly use 7-zip for this purpose, or the encryption plugin in Notepad++ for text.
- cyphar 9y ago
  If the app is free software it can be audited. The problem with web-based crypto is that you're downloading a new program every page refresh and executing it immediately. If you're worried about a free software app not encrypting things properly, I'd be worried about the tools you use manually doing the right thing as well. While I agree that doing it manually is the only reliable way if you're going to send it over an insecure channel, if the channel is secure then it's much easier for an end-user to just send it in the app.
- pleasecalllater 9y ago
  And that's still just a feeling. You just feel you can trust the encryption application. Which can be changed any time in the future in a way it is not secure any more. You just need to trust. So what's wrong in trusting Mozilla, if you can easily trust your encryption/decryption software?
- galaxyLogic 9y ago
  Why would you trust 7-zip or NotePad++ more than FireFox?
  - jhasse 9y ago
    Because I don't trust Mozilla, see https://www.reddit.com/r/linux/comments/6mw1ld/firefox_tracks_users_with_google_analytics_in_the/ https://www.reddit.com/r/linux/comments/6mw1ld/firefox_track... or http://www.zdnet.com/article/firefox-tests-cliqz-engine-which-slurps-user-browsing-data/ http://www.zdnet.com/article/firefox-tests-cliqz-engine-whic...

takeda 9y ago

Well there's reasoning which states that bad security is worse than no security. The reason for it, is that if you trust the site to be secure it might be devastating once security is compromised, but with no security you're typically more careful.

Nexxxeh 9y ago
We are more careful, as in the HN crowd. The general public? I'd wager "not so much".

zeveb 9y ago

> But it is still a considerable improvement. When it's secure, it's an improvement; if Mozilla, a Mozilla employee or a government which can compel Mozilla employees chooses to make it insecure, then it's worse than insecure. At least with something like Dropbox users (should) know that they are insecure and should not transmit sensitive files. > If you have a better solution in mind for the average user crowd, feel free to suggest it, of course. The functionality should be built into Firefox, so that users can verify source code & protocols once and know that they are secure thereafter.

damnyou 9y ago
And re-check them after every update? And trust that Mozilla won't randomly distribute a backdoor to 1/n of users? The means you're suggesting aren't possible to implement for most people today. If you care about real-world impact I would recommend thinking of other strategies.
- cyphar 9y ago
  Reproducible builds effectively solve this problem, by making it possible to actually verify that you got the same binary (from the same source) as everyone else. Not to mention that if you're on Linux, distributions build Firefox themselves and so attacks against users need to be far larger in scale for 1/n attacks.
  - damnyou 9y ago
    They're both important steps, but neither solves the problem. Most users don't verify the reproducibility of their builds and don't use Linux.
    - cyphar 9y ago
      It solves the problem for users that use Linux. If other operating systems cared about making software distribution sane, they could also use package managers. It's a shame that they don't. As for verifying reproducibility, if you're using a package manager then this verification is quite trivial (and can be done automatically). Solving the problem for proprietary operating systems that intentionally have horrific systems of managing the software on said operating system is harder due to an artificial, self-inflicted handicap. "Just" switching people to Linux is probably easier (hey, Google managed to get people to run Gentoo after all).

carussell 9y ago

Spec out and implement resource pinning, already. Like RFC 8246, but authored more with the user's interests in mind, rather than the service's. As a show of nothing-up-the-sleeve, a service asserts that it's in a stable state and will continue to serve exact copies of the resources as they exist now—that they will not change out from beneath the client in subsequent requests. When a user chooses to use resource pinning, the browser checks that this is true, and if finding a new deployment has occurred, the browser will refuse to accept it without deliberate consent and action from the user (something on par with invalid cert screen). This means that for a subset of services (those whose business logic can run primarily on the client side), the users need not trust the server, they need only to trust the app, which can be audited. When deploying updated resources, services SHOULD make the update well-advertised and accompany it with some notice out of band (such as a post about the new "release", its changelog, and a link to the repo), so the new deployment may be audited. When new deployments occur, clients SHOULD allow the user to opt for continuing to using the pinned resources, and services SHOULD be implemented in such a way that this is handled gracefully. This gives the user continuity of access while the user (or their org) is carrying out the audit process. Areas where this would be useful: - HIPAA compliance - Web crypto that isn't fundamentally broken - Stronger guarantees for non-local resources used in Web Extensions—in fact, the entire extension update mechanism could probably be more or less rebased on top of the resource pinning policy

the8472 9y ago
This would also have the added bonus that one could reload such pinned resources from anywhere once you got the pin. Even without TLS setup or having to trust certificate chains. Caching proxies would suddenly become viable again because only the first download has to through HTTPS while "I don't have this in the local cache anymore, can you serve me this content" requests could go through sidechannels or outside the TLS handshake or something like that. Caches could even perform downgrade non-attacks.
- Dylan16807 9y ago
  How many pins would you expect a browser instance to have? I feel like most of the time the pinned content could fit in the browser cache and make this variety of proxy-side caching pointless.