20 ms·

The key is the hash, which isn't sent over the wire when loading a page. Now granted it's accessible via location.hash in the client, but one has to trust Mozi

The key is the hash, which isn't sent over the wire when loading a page. Now granted it's accessible via location.hash in the client, but one has to trust Mozilla not to do that.

sarabande 9y ago
Thanks. I was just looking at the screenshots and didn't seen any hashes, but when I tried it out and copied to the clipboard I saw the form "https://send.firefox.com/download/xxxxx/#yyyyy" https://send.firefox.com/download/xxxxx/#yyyyy".
- snvzz 9y ago
  #yyyyy would be the encryption key. The webserver end never sees it. It can, however, easily be read via javascript, so mozilla needs to be trusted in any case.
  - madeofpalk 9y ago
    at least you can check that its not going back to the server.
    - jhasse 9y ago
      How?
      - sushisource 9y ago
        Inspect network traffic. Or more arduously, analyze the JS.
        recursive 9y ago
        There are a lot of bytes moving around. I mean, I basically trust mozilla, but if they were a bad actor, it could easily be hidden steganographically.
        Spivak 9y ago
        And if your client is compromised then you're basically hosed in any secure application.
        jhasse 9y ago
        Network traffic could be encrypted, so you'd have to analyze the JavaScript.
  - TuringTest 9y ago
    > It can, however, easily be read via javascript, so mozilla needs to be trusted in any case. Or you (and some friends from organizations like the EFF and FSF) can read the source code to see what it does, and even compile it yourself. If you do that, you only need to trust the compiler.
    - carussell 9y ago
      No, you still need to trust that Mozilla's deployment corresponds to the publicly available release—that they aren't using a version with changes nor have they been breached by an attacker who can change it to sample 1/n transactions.
  - claudius 9y ago
    If one were to build a marketing spyware add-on to analyse user traffic from within the browser and send all visited URLs to some remote server, would those sent URLs then possibly contain the anchor?
    - SquareWheel 9y ago
      If it's running on the client, then yes it could read the anchor text.
    - codingdave 9y ago
      Yes, but would that matter if these are one-time downloads? You couldn't go get the file even if you did grab the data needed to do so... or am I missing something?
      - claudius 9y ago
        The add-on could tell Mozilla which files to keep because it saved the decryption key for those files. Mozilla could then select those files to decrypt, e.g. to prove to authorities that its file-sharing service was not used for illicit purposes. Alternatively, the add-on could filter the IP addresses used to upload the files for potentially sensitive blocks and then tell Mozilla to decrypt the files uploaded by people from such blocks, e.g. in an attempt to engage in corporate espionage (of course one shouldn’t use third-party services for sensitive files in the first place, but if you have to use a third-party service, certainly an ‘open-source’, ‘private’ and ‘encrypted’ one from such a reputable company as Mozilla, right?)
        floatingatoll 9y ago
        Several of the alternatives linked in this post’s comments make no effort to encrypt at all; they simply try to con users into sharing files with their intermediate server in plaintext, as if somehow that’s an acceptable thing to do. If you don’t trust Mozilla or you are sharing information that a nation-state attacker would coerce Mozilla into revealing, then you’re already set up to encrypt the file first yourself - at which point you can send it with any service, include Firefox Send.
zeveb 9y ago
> one has to trust Mozilla not to do that. Exactly. One has to trust Mozilla every time one visits the page. They could easily configure it to be malicious one time out of a million (say); what are the odds that they would be caught? Web-page-based crypto is fundamentally insecure, and Mozilla is committing an extremely grave error in encouraging users to trust it (as they also do with their Firefox Accounts). Security is important, and snake-oil solutions are worse than worthless.
- edanm 9y ago
  The way this gets solved in the real world is through contracts - they have a certain contract with you, and if they break it, they can get sued and lose a lot of money. This is one of the goals of the legal system - make it so we usually trust each other. There are no real long-term technical solutions to this problem. So if you want to make sure you're safe, read their EULA or equivalent.
  - cyphar 9y ago
    Or you can design a system (like any number of crypto systems) that aren't vulnerable to these sorts of attacks. A compromised CDN could cause this problem, which now means that Mozilla would be liable for things that they don't administer. And resolving technical problems through the legal system never works well. If you can design something so users don't have to constantly trust you, then that's a much better solution. Not to mention that Send likely doesn't have a warranty (like most software under a free software license).
- 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.
Vinnl 9y ago
> one has to trust Mozilla not to do that Well, the advantage of the client is that you can inspect the source, so you can verify that it doesn't actually access location.hash.
- the8472 9y ago
  But software loaded from webpages are not immutable. They could be manipulated at any given time. So even if someone audits the code you still cannot trust it because all the audit would show is that the specific downloaded version which the auditor saw was non-malicious. As long as websites have no fingerprints that encompasses all loaded resources and can't be pinned to that fingerpint crypto in the webbrowser is not trustworthy.
  - eugeniub 9y ago
    In that case, wouldn't an alternative like OnionShare always be safer? The code is open source, it's a desktop app, and the source code is obviously immutable on your computer.
    - Nexxxeh 9y ago
      Surly the safest option is to encrypt it yourself first?
      - ArneBab 9y ago
        You could upload it to Freenet, then there won’t even be a record what was up- and downloaded by whom: No one will have the metadata. Info: http://www.draketo.de/light/english/freenet/effortless-password-protected-sharing-files http://www.draketo.de/light/english/freenet/effortless-passw... Install: https://freenetproject.org https://freenetproject.org
  - Jach 9y ago
    https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... can help verify everything loaded is what it's supposed to be. However you'd still need to verify that the set of things loaded is the set of things you expect, not just that the things are the things, and that requires having an out-of-band checklist or extension...

The key is the hash, which isn't sent over the wire when loading a page. Now granted it's accessible via location.hash in the client, but one has to trust Mozilla not to do that.

sarabande 9y ago

Thanks. I was just looking at the screenshots and didn't seen any hashes, but when I tried it out and copied to the clipboard I saw the form "https://send.firefox.com/download/xxxxx/#yyyyy" https://send.firefox.com/download/xxxxx/#yyyyy".

snvzz 9y ago
#yyyyy would be the encryption key. The webserver end never sees it. It can, however, easily be read via javascript, so mozilla needs to be trusted in any case.
- madeofpalk 9y ago
  at least you can check that its not going back to the server.
  - jhasse 9y ago
    How?
    - sushisource 9y ago
      Inspect network traffic. Or more arduously, analyze the JS.
      - recursive 9y ago
        There are a lot of bytes moving around. I mean, I basically trust mozilla, but if they were a bad actor, it could easily be hidden steganographically.
        Spivak 9y ago
        And if your client is compromised then you're basically hosed in any secure application.
      - jhasse 9y ago
        Network traffic could be encrypted, so you'd have to analyze the JavaScript.
- TuringTest 9y ago
  > It can, however, easily be read via javascript, so mozilla needs to be trusted in any case. Or you (and some friends from organizations like the EFF and FSF) can read the source code to see what it does, and even compile it yourself. If you do that, you only need to trust the compiler.
  - carussell 9y ago
    No, you still need to trust that Mozilla's deployment corresponds to the publicly available release—that they aren't using a version with changes nor have they been breached by an attacker who can change it to sample 1/n transactions.
- claudius 9y ago
  If one were to build a marketing spyware add-on to analyse user traffic from within the browser and send all visited URLs to some remote server, would those sent URLs then possibly contain the anchor?
  - SquareWheel 9y ago
    If it's running on the client, then yes it could read the anchor text.
  - codingdave 9y ago
    Yes, but would that matter if these are one-time downloads? You couldn't go get the file even if you did grab the data needed to do so... or am I missing something?
    - claudius 9y ago
      The add-on could tell Mozilla which files to keep because it saved the decryption key for those files. Mozilla could then select those files to decrypt, e.g. to prove to authorities that its file-sharing service was not used for illicit purposes. Alternatively, the add-on could filter the IP addresses used to upload the files for potentially sensitive blocks and then tell Mozilla to decrypt the files uploaded by people from such blocks, e.g. in an attempt to engage in corporate espionage (of course one shouldn’t use third-party services for sensitive files in the first place, but if you have to use a third-party service, certainly an ‘open-source’, ‘private’ and ‘encrypted’ one from such a reputable company as Mozilla, right?)
      - floatingatoll 9y ago
        Several of the alternatives linked in this post’s comments make no effort to encrypt at all; they simply try to con users into sharing files with their intermediate server in plaintext, as if somehow that’s an acceptable thing to do. If you don’t trust Mozilla or you are sharing information that a nation-state attacker would coerce Mozilla into revealing, then you’re already set up to encrypt the file first yourself - at which point you can send it with any service, include Firefox Send.

zeveb 9y ago

> one has to trust Mozilla not to do that. Exactly. One has to trust Mozilla every time one visits the page. They could easily configure it to be malicious one time out of a million (say); what are the odds that they would be caught? Web-page-based crypto is fundamentally insecure, and Mozilla is committing an extremely grave error in encouraging users to trust it (as they also do with their Firefox Accounts). Security is important, and snake-oil solutions are worse than worthless.

edanm 9y ago
The way this gets solved in the real world is through contracts - they have a certain contract with you, and if they break it, they can get sued and lose a lot of money. This is one of the goals of the legal system - make it so we usually trust each other. There are no real long-term technical solutions to this problem. So if you want to make sure you're safe, read their EULA or equivalent.
- cyphar 9y ago
  Or you can design a system (like any number of crypto systems) that aren't vulnerable to these sorts of attacks. A compromised CDN could cause this problem, which now means that Mozilla would be liable for things that they don't administer. And resolving technical problems through the legal system never works well. If you can design something so users don't have to constantly trust you, then that's a much better solution. Not to mention that Send likely doesn't have a warranty (like most software under a free software license).
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.

Vinnl 9y ago

> one has to trust Mozilla not to do that Well, the advantage of the client is that you can inspect the source, so you can verify that it doesn't actually access location.hash.

the8472 9y ago
But software loaded from webpages are not immutable. They could be manipulated at any given time. So even if someone audits the code you still cannot trust it because all the audit would show is that the specific downloaded version which the auditor saw was non-malicious. As long as websites have no fingerprints that encompasses all loaded resources and can't be pinned to that fingerpint crypto in the webbrowser is not trustworthy.
- eugeniub 9y ago
  In that case, wouldn't an alternative like OnionShare always be safer? The code is open source, it's a desktop app, and the source code is obviously immutable on your computer.
  - Nexxxeh 9y ago
    Surly the safest option is to encrypt it yourself first?
    - ArneBab 9y ago
      You could upload it to Freenet, then there won’t even be a record what was up- and downloaded by whom: No one will have the metadata. Info: http://www.draketo.de/light/english/freenet/effortless-password-protected-sharing-files http://www.draketo.de/light/english/freenet/effortless-passw... Install: https://freenetproject.org https://freenetproject.org
- Jach 9y ago
  https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... can help verify everything loaded is what it's supposed to be. However you'd still need to verify that the set of things loaded is the set of things you expect, not just that the things are the things, and that requires having an out-of-band checklist or extension...