Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The sync contents are encrypted between devices.

EDIT: After writing this, I realized I should investigate the claim, because new devices are added just by logging in, not by giving them any sort of password.



Logging in includes giving the device a password.

There's no off-channel key synchronization. What means that the encryption is only as good as your password. But AFAIK no browser has it anyway, and nearly no sync service.


Brave uses a QR code to exchange the key.


Actually, I have redone the steps on my computer after that comment, and well, I was wrong.

Firefox sync seems to work by key authorization, that is done by in-channel sharing and user confirmation for PCs and a QR code for phones. It's a quite good process, that looks similar to what you are describing.

I just don't know why I remembered something different.


They posted an article a while ago with a high level overview of how FF Sync encryption works, but the TL;DR is that the key for E2EE is derived from your account password.

https://hacks.mozilla.org/2018/11/firefox-sync-privacy/


Yes, E2EE.


The parent raised a good point tho. If you can add devices without entering encryption info, how can it be properly E2E?


I don't know what criteria is required to meet an E2EE (End to end encryption?) standard.

In general though, the info is stored on Mozilla's (or an affiliate's) cloud.[0]

1. If you lose your password and didn't setup a separate password recovery code (one time codes), then your data is toast. You can't reset your password via email without wiping your cloud data because mozilla uses your password in a hashing algorithm to store your data.

2. If I recall, you have to setup a 2FA to login on new devices.

[0] https://www.mozilla.org/en-US/firefox/features/sync/

*EDIT: revised above to clarify mozilla password reset wipes data unless you have recovery key.


> I don't know what criteria is required to meet an E2EE (End to end encryption?) standard.

Only sender and receiver (the “ends”) can decrypt the data, ie have the keys. In this case both ends are “you”, and the passphrase is the authentication for new devices. For e2ee to hold, neither the passphrase nor the key can be shared with another party, for instance Mozilla.

> 1. If you lose your password and didn't setup a separate password recovery code (one time codes), then you're toast.

That sounds right, and is similar to password managers. Your data is encrypted as a vault with a key derived from the passphrase. The vault is opaque to anyone without the key. Though you still have to trust the software.


OK. It sounds like E2EE encryption in effect because Mozilla encrypts your cloud data with a password hashing algorithm.

[I edited my comment above to get into more nuance about password reset is possible, but wipes data.]

If you lose your Mozilla account password, you can reset it, but

> Any data you have on the server will be erased when you reset your password (unless you use recovery keys). Your other devices will stop synchronizing unless you update them with the new password.[0]

[0] https://support.mozilla.org/en-US/kb/ive-lost-my-firefox-syn...


Erasing cloud data is not a biggie, because as soon as you log back in (with the new password) from a device with the old data, it will get reuploaded. FF does the safe thing when synchronising.


That makes sense to not delete the client-side data and gracefully continue.


> If you can add devices without entering encryption info, how can it be properly E2E?

It can’t. I don’t know about FF, but if you can add a device without explicit approval of one of your existing provisioned devices it is what I call Fake E2EE.

You see different providers go to great lengths to do device local encryption etc but due to product requirements (“what if a user loses their device or forgets their passphrase”) they keep a copy of the key, yet slaps the e2ee label on their product. So now it’s just regular encryption at rest with all the risks (subpoenas, rogue employees, company gets acquired, new CEO starts drooling over data broker dollars etc), only with much more technical complexity since data now needs to be read-writable client side by different software versions, increasing the risk of corruption, data loss and bugs.

Password managers with true e2ee actually suffer from these corruption issues from time to time. But that’s a price that must be paid for the e2ee level of security. It’s not for everyone – I wished there was more honesty around this instead of diluting meaningful and precise terms.

Edit: seems like FF has e2ee, see sibling comment.


If the encryption info is derived from the password it can be done without visual encryption keys for the user. It is the case with Firefox Sync. They have no way to recover the data if you forget the password.


You do enter encryption info: your password.

FF sync "splits" your password into an encryption key and the service password on the client side. The service never sees the key (or real password).

Bitwarden works in a similar way.


The original Firefox sync did this "right" (from a privacy and encryption perspective) but required user out-of-band transfer of key material to add a new device. Apparently this was too difficult for users, so they dropped it in favour of "user accounts" with passwords instead.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: