9 ms·

Hi, Firefox Accounts developer here. You're correct in your understanding that that login flow is ultimately driven by a webpage, and this is a deliberate trad

by rfk 8y ago

Hi, Firefox Accounts developer here. You're correct in your understanding that that login flow is ultimately driven by a webpage, and this is a deliberate trade-off that we made in the interests of reach and usability of the system. It's certainly a trade-off that not everyone is comfortable with, but we're confident it's the right one for the majority of our users. You can read some previous discussions on the topic in these bugs (and additional suggestions/feedback therein is definitely welcome): * https://bugzilla.mozilla.org/show_bug.cgi?id=1034526 * https://bugzilla.mozilla.org/show_bug.cgi?id=1447656

garmaine 8y ago
Why not ship the password handling logic in the Firefox binary?
CoolGuySteve 8y ago
This is very interesting and thanks for clarifying, but if you concede that there is a security trade-off here for the sake of usability, then isn't this, by definition, not "Private by Design". As in: you chose other principals to guide your design other than privacy?
- Benjamin_Dobell 8y ago
  The privacy is at least verifiable. In the sense that users can at least look at the implementation themselves, and (granted with some difficult) potentially detect changes. This is much better than simply sending your password off to a third-party and having to trust that the company is doing what they say they're doing.
- danShumway 8y ago
  Nobody purely chooses privacy or security to guide their design. An implementation of Firefox sync that was purely, 100% private by design would be airgapped, it wouldn't sync over a network. Arguably, a private by design implementation of Firefox sync wouldn't even exist. You significantly increase your number of attack vectors by making your session available on multiple devices. What happens if your Android phone is compromised? Better to only have your session on one device. Obviously I'm being hyperbolic here, but the point I'm getting at is that security isn't black and white, and you will always be making tradeoffs for usability, no matter what the context is. What that means for "private by design", I dunno. Maybe it's just a buzzword. Maybe it's just a matter of degree. Other people can debate that if they really want to. But I do know that the moment you put doors on your house, it's less secure than it used to be. The actual valuable question is, "is Mozilla's tradeoff good enough for usability that it justifies the decrease in security?" I'm not sure whether the answer to that is yes or no.
throwawaylolx 8y ago
This response reminds me of this discussion https://news.ycombinator.com/item?id=17804916 https://news.ycombinator.com/item?id=17804916
hnaccy 8y ago
>The reason the login form is delivered as web content is to increase development speed and agility You saved some sprints but invalidated the purpose of the project. Very agile. >Ultimately I think we can have web content from accounts.firefox.com be just as trustworthy as, say, a Mozilla-developed addon which might ship in the browser by default, which is a pretty high bar. We're not there yet, but it seems worth pursuing to try to get the best of both worlds. The safety of the default installation is crowdsourced across all users and can't be targeted. The safety of the JS I load from Mozilla is not and I would have to verify its safety every time. Unless I'm misunderstanding something it can never be as trustworthy.
- Benjamin_Dobell 8y ago
  How did you install Firefox in the first place?
  - qbaqbaqba 8y ago
    Dist repo?
  - hnaccy 8y ago
    You can verify hash with others or compile it yourself.
    - Benjamin_Dobell 8y ago
      Did you personally, and at least one other trusted party, sign off on every single commit, or are you trusting Mozilla? Where did you get the hash you're comparing against? Firstly, no matter what you're trusting the developers of the software you're running on your computer. Secondly, the software (and/or its hash), just like this JavaScript, is delivered to you in a verifiably secure fashion i.e. SSL. What's the difference? Sure, this JS can change. Do you have automatic updates running for Firefox, or any piece of software on your computer?
      - krageon 8y ago
rndgermandude 8y ago
Sorry, but you (mozilla) deliberately crippled your system to the point where mozilla or certain key personnel of mozilla/whoever operates the data centers or anybody running some MITM middlebox - if they wanted to/where compelled to - could easily target specific users or large groups of users rather stealthily, by your servers (and any successful MITM) having the capability to underhand compromised code on a request-by-request basis that could sneak out the actual password thus compromising all the user's data you store. Then you go ahead and publish articles how your system is "Safe" and "Private by Design" underpinned by "here is SOME MATH to prove it!". And just now, you state that you "traded off" the "Safe" and "Private by Design" properties for "<unspecific marketing speech, something about reach and usability>", but are somehow "confident" that falsely advertising your broken implementation as having properties it does not possess is the right thing to do (for most users). wat?! Why is the code that derives stuff from the password and the UI for entering the password not in the browser itself? Surely not for the merit of the users, as there is no real usage/UX difference for them between "https://accounts.firefox.com/" https://accounts.firefox.com/" and "chrome://firefox-account/".
- OpenBSD-reich 8y ago
  This is why I use chrome on my wintoy, and w3m on my darknet surfer. It started going downhill before Pocket, but Pocket was the major signal flare the Titanic was surely sinking.
franga2000 8y ago
Could this be solved by creating a WebExtension that completely replaces the frontend with a bundled copy and then including it in Firefox? If you trust the browser and therefore the bundled extension, you don't need to trust the server at all.

by rfk 8y ago

garmaine 8y ago

Why not ship the password handling logic in the Firefox binary?

CoolGuySteve 8y ago

This is very interesting and thanks for clarifying, but if you concede that there is a security trade-off here for the sake of usability, then isn't this, by definition, not "Private by Design". As in: you chose other principals to guide your design other than privacy?

Benjamin_Dobell 8y ago
The privacy is at least verifiable. In the sense that users can at least look at the implementation themselves, and (granted with some difficult) potentially detect changes. This is much better than simply sending your password off to a third-party and having to trust that the company is doing what they say they're doing.
danShumway 8y ago
Nobody purely chooses privacy or security to guide their design. An implementation of Firefox sync that was purely, 100% private by design would be airgapped, it wouldn't sync over a network. Arguably, a private by design implementation of Firefox sync wouldn't even exist. You significantly increase your number of attack vectors by making your session available on multiple devices. What happens if your Android phone is compromised? Better to only have your session on one device. Obviously I'm being hyperbolic here, but the point I'm getting at is that security isn't black and white, and you will always be making tradeoffs for usability, no matter what the context is. What that means for "private by design", I dunno. Maybe it's just a buzzword. Maybe it's just a matter of degree. Other people can debate that if they really want to. But I do know that the moment you put doors on your house, it's less secure than it used to be. The actual valuable question is, "is Mozilla's tradeoff good enough for usability that it justifies the decrease in security?" I'm not sure whether the answer to that is yes or no.

throwawaylolx 8y ago

This response reminds me of this discussion https://news.ycombinator.com/item?id=17804916 https://news.ycombinator.com/item?id=17804916

hnaccy 8y ago

>The reason the login form is delivered as web content is to increase development speed and agility You saved some sprints but invalidated the purpose of the project. Very agile. >Ultimately I think we can have web content from accounts.firefox.com be just as trustworthy as, say, a Mozilla-developed addon which might ship in the browser by default, which is a pretty high bar. We're not there yet, but it seems worth pursuing to try to get the best of both worlds. The safety of the default installation is crowdsourced across all users and can't be targeted. The safety of the JS I load from Mozilla is not and I would have to verify its safety every time. Unless I'm misunderstanding something it can never be as trustworthy.

Benjamin_Dobell 8y ago
How did you install Firefox in the first place?
- qbaqbaqba 8y ago
  Dist repo?
- hnaccy 8y ago
  You can verify hash with others or compile it yourself.
  - Benjamin_Dobell 8y ago
    Did you personally, and at least one other trusted party, sign off on every single commit, or are you trusting Mozilla? Where did you get the hash you're comparing against? Firstly, no matter what you're trusting the developers of the software you're running on your computer. Secondly, the software (and/or its hash), just like this JavaScript, is delivered to you in a verifiably secure fashion i.e. SSL. What's the difference? Sure, this JS can change. Do you have automatic updates running for Firefox, or any piece of software on your computer?
    - krageon 8y ago

rndgermandude 8y ago

Sorry, but you (mozilla) deliberately crippled your system to the point where mozilla or certain key personnel of mozilla/whoever operates the data centers or anybody running some MITM middlebox - if they wanted to/where compelled to - could easily target specific users or large groups of users rather stealthily, by your servers (and any successful MITM) having the capability to underhand compromised code on a request-by-request basis that could sneak out the actual password thus compromising all the user's data you store. Then you go ahead and publish articles how your system is "Safe" and "Private by Design" underpinned by "here is SOME MATH to prove it!". And just now, you state that you "traded off" the "Safe" and "Private by Design" properties for "<unspecific marketing speech, something about reach and usability>", but are somehow "confident" that falsely advertising your broken implementation as having properties it does not possess is the right thing to do (for most users). wat?! Why is the code that derives stuff from the password and the UI for entering the password not in the browser itself? Surely not for the merit of the users, as there is no real usage/UX difference for them between "https://accounts.firefox.com/" https://accounts.firefox.com/" and "chrome://firefox-account/".

OpenBSD-reich 8y ago
This is why I use chrome on my wintoy, and w3m on my darknet surfer. It started going downhill before Pocket, but Pocket was the major signal flare the Titanic was surely sinking.

franga2000 8y ago

Could this be solved by creating a WebExtension that completely replaces the frontend with a bundled copy and then including it in Firefox? If you trust the browser and therefore the bundled extension, you don't need to trust the server at all.