Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Private by Design: How We Built Firefox Sync

hacks.mozilla.org

Post reply on HN
Print view View original

11–20 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#11

Post by adobeeee »

yoklov wrote: post #7
owaislone wrote: post #4

How does Firefox Sync handle a user changing their password? What if the password is changed from another device? Does it force users to first sign in with old password and only then allow to change it, essentially re-encrypting everything and syncing again? If so, does that mean forgetting the password equals to losing all synced data?

Yes, sort of (more about the process: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... ). Key difference: you don't need to sync all the data up again, since there's a separate key for that, which doesn't change. That said, if you forget your password you do lose remote synced data. The hope is that you have at least one device connected that still has the data, which will upload it in that case. This…

You seem to know a bit about encryption. Which is why it baffles me- how does telegram do this? Does it need a connected device in this way too? So one can upload the encryption key if its lost? If no device is connected, can/how do they do it? If yes, can Firefox copy that way?

Re: Private by Design: How We Built Firefox Sync

#12

Post by [deleted] »

arctux wrote: post #10
Scarbutt wrote: post #6

Earlier quoted context omitted.

Doesn't chrome lets you use your own encryption key?

Yes, but it's not the default. From the article: > One could, however, add a second passphrase that is never sent to the server, and encrypt the data using that. Chrome provides this as a non-default option. The average user doesn't have the expertise to know that they have to configure an additional "master password" to keep Google from mining their data for ads.

[deleted]

Re: Private by Design: How We Built Firefox Sync

#13

Post by tprnz »

arctux wrote: post #10
Scarbutt wrote: post #6

Earlier quoted context omitted.

Doesn't chrome lets you use your own encryption key?

Yes, but it's not the default. From the article: > One could, however, add a second passphrase that is never sent to the server, and encrypt the data using that. Chrome provides this as a non-default option. The average user doesn't have the expertise to know that they have to configure an additional "master password" to keep Google from mining their data for ads.

That is true, defaults are important. Firefox users know that because they have to disable the advertisements that appear in the Firefox new tab page by default.

https://prod-cdn.sumo.mozilla.net/uploads/gallery/images/201...

Re: Private by Design: How We Built Firefox Sync

#14

Post by owaislone »

yoklov wrote: post #7
owaislone wrote: post #4

How does Firefox Sync handle a user changing their password? What if the password is changed from another device? Does it force users to first sign in with old password and only then allow to change it, essentially re-encrypting everything and syncing again? If so, does that mean forgetting the password equals to losing all synced data?

Yes, sort of (more about the process: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... ). Key difference: you don't need to sync all the data up again, since there's a separate key for that, which doesn't change. That said, if you forget your password you do lose remote synced data. The hope is that you have at least one device connected that still has the data, which will upload it in that case. This…

Thanks. I've been using Firefox Sync ever since it came out but I don't remember it ever mentioning these risks. I think Firefox should mention this when new users enable sync for the first time. It should also offer users to generate recovery keys when they start using sync and for some time after if they haven't.

Re: Private by Design: How We Built Firefox Sync

#15

Post by yoklov »

adobeeee wrote: post #9

I like, actually love Firefox. So as a major user I resent them for posting this article, its somewhat inethical when no recent work has been done on sync and they are , as they claim themselves, not willing to touch this code in fear of breaking it. If you are don't understand enough to make changes, maybe don't make an article about itm

This is not true. I work on Firefox Sync full time, as do multiple other engineers.

Admittedly, the current version in Desktop/iOS/Android is in a sort of 'maintenance mode' (we still fix bugs, but don't work on new features or actively fix it up).

The reason for this is basically that those three versions are entirely separate implementations that share no code (they're also in languages that have integration difficulties on the other platforms, unfortunately, so we can't just settle on one).

We're currently rewriting it as a cross-platform module, and planning on replacing them.

Re: Private by Design: How We Built Firefox Sync

#16

Post by yoklov »

owaislone wrote: post #14
yoklov wrote: post #7

Earlier quoted context omitted.

Yes, sort of (more about the process: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... ). Key difference: you don't need to sync all the data up again, since there's a separate key for that, which doesn't change. That said, if you forget your password you do lose remote synced data. The hope is that you have at least one device connected that still has the data, which will upload it in that case. This…

Thanks. I've been using Firefox Sync ever since it came out but I don't remember it ever mentioning these risks. I think Firefox should mention this when new users enable sync for the first time. It should also offer users to generate recovery keys when they start using sync and for some time after if they haven't.

There's no risk to your data. It's not like this will delete your local data, the only risk is when doing a password reset in some (fairly rare) cases, which does attempt to make the risk of doing so clear.

I don't disagree about recovery keys, they're rather new though, eventually it wouldn't surprise me if we did something like that.

Re: Private by Design: How We Built Firefox Sync

#17

Post by arctux »

tprnz wrote: post #13
arctux wrote: post #10

Earlier quoted context omitted.

Yes, but it's not the default. From the article: > One could, however, add a second passphrase that is never sent to the server, and encrypt the data using that. Chrome provides this as a non-default option. The average user doesn't have the expertise to know that they have to configure an additional "master password" to keep Google from mining their data for ads.

That is true, defaults are important. Firefox users know that because they have to disable the advertisements that appear in the Firefox new tab page by default. https://prod-cdn.sumo.mozilla.net/uploads/gallery/images/201...

I strongly dislike that they've done that. In their partial defense, the selection of recommended articles based on your browsing history is done on device.

Re: Private by Design: How We Built Firefox Sync

#18

Post by owaislone »

yoklov wrote: post #16
owaislone wrote: post #14

Earlier quoted context omitted.

Thanks. I've been using Firefox Sync ever since it came out but I don't remember it ever mentioning these risks. I think Firefox should mention this when new users enable sync for the first time. It should also offer users to generate recovery keys when they start using sync and for some time after if they haven't.

There's no risk to your data. It's not like this will delete your local data, the only risk is when doing a password reset in some (fairly rare) cases, which does attempt to make the risk of doing so clear. I don't disagree about recovery keys, they're rather new though, eventually it wouldn't surprise me if we did something like that.

Ah, so local data is not encrypted. It's only encrypted before packets are sent to the servers?

Re: Private by Design: How We Built Firefox Sync

#19

Post by yoklov »

owaislone wrote: post #18
yoklov wrote: post #16

Earlier quoted context omitted.

There's no risk to your data. It's not like this will delete your local data, the only risk is when doing a password reset in some (fairly rare) cases, which does attempt to make the risk of doing so clear. I don't disagree about recovery keys, they're rather new though, eventually it wouldn't surprise me if we did something like that.

Ah, so local data is not encrypted. It's only encrypted before packets are sent to the servers?

Yes, for the most part. For passwords the story is a bit more complex (they're encrypted locally on all platforms, either with your master password (Desktop, probably Android but I don't remember), or a random key stored in the OS storage for iOS),

But we don't use the sync key to encrypt local data ever; many users never set up sync, and have no sync key

Re: Private by Design: How We Built Firefox Sync

#20

Post by toomuchtodo »

yoklov wrote: post #15
adobeeee wrote: post #9

I like, actually love Firefox. So as a major user I resent them for posting this article, its somewhat inethical when no recent work has been done on sync and they are , as they claim themselves, not willing to touch this code in fear of breaking it. If you are don't understand enough to make changes, maybe don't make an article about itm

This is not true. I work on Firefox Sync full time, as do multiple other engineers. Admittedly, the current version in Desktop/iOS/Android is in a sort of 'maintenance mode' (we still fix bugs, but don't work on new features or actively fix it up). The reason for this is basically that those three versions are entirely separate implementations that share no code (they're also in languages that have integration diffic…

Thank you for your efforts.
Post reply on HN