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

101–110 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#101

Post by rndgermandude »

rfk wrote: post #61
rauhl wrote: post #44

Sadly, I believe that Firefox Accounts — upon which Firefox Sync is built — are insecure in execution. The security of the whole system relies on keeping your password secret from Mozilla, but as you can see when accessing https://accounts.firefox.com/oauth/signin?scope=profile&clie... your browser downloads the JavaScript it will use to derive your authentication token from Mozilla. There’s nothing stopping Mozilla…

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…

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 "", 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/" and "chrome://firefox-account/".

Re: Private by Design: How We Built Firefox Sync

#102

Post by NewEntryHN »

joekrill wrote: post #100
rauhl wrote: post #44

Sadly, I believe that Firefox Accounts — upon which Firefox Sync is built — are insecure in execution. The security of the whole system relies on keeping your password secret from Mozilla, but as you can see when accessing https://accounts.firefox.com/oauth/signin?scope=profile&clie... your browser downloads the JavaScript it will use to derive your authentication token from Mozilla. There’s nothing stopping Mozilla…

How could this even possibly be mitigated, though? At some point you have to trust something , right? This argument could extend all the way down to your OS, chipset, whatever. Unless you've built every part of your machine from scratch it's always going to rely on trusting a component you know nothing about.

Trusting the binary is a one-time effort. Here you have to trust the JS everytime you authenticate.

Re: Private by Design: How We Built Firefox Sync

#103

Post by rndgermandude »

hnaccy wrote: post #81
rfk wrote: post #61

Earlier quoted context omitted.

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…

>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 p…

> You saved some sprints but invalidated the purpose of the project. Very agile.

This sums it up indeed quite keenly and with an amount of snark I personally appreciate. Thanks

Re: Private by Design: How We Built Firefox Sync

#104

Post by raffomania »

joekrill wrote: post #100
rauhl wrote: post #44

Sadly, I believe that Firefox Accounts — upon which Firefox Sync is built — are insecure in execution. The security of the whole system relies on keeping your password secret from Mozilla, but as you can see when accessing https://accounts.firefox.com/oauth/signin?scope=profile&clie... your browser downloads the JavaScript it will use to derive your authentication token from Mozilla. There’s nothing stopping Mozilla…

How could this even possibly be mitigated, though? At some point you have to trust something , right? This argument could extend all the way down to your OS, chipset, whatever. Unless you've built every part of your machine from scratch it's always going to rely on trusting a component you know nothing about.

If you include this code in firefox itself, you can review the code and verify that the official firefox binaries use that code.

Re: Private by Design: How We Built Firefox Sync

#105

Post by zimbatm »

Benjamin_Dobell wrote: post #88
hnaccy wrote: post #85

Earlier quoted context omitted.

You can verify hash with others or compile it yourself.

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 di…

The question is how hard it is to detect tampering. My linux distribution builds firefox from source and signs the build. The builds are also checked to be reproducible.

Raising the bar is a good thing.

Re: Private by Design: How We Built Firefox Sync

#106

Post by chupasaurus »

ndnxhs wrote: post #42
Barrin92 wrote: post #29

Earlier quoted context omitted.

ever since they've switched to the quantum engine it also feels really fast, almost faster than chrome with the exception of youtube, which feels sluggish sadly.

That's because YouTube uses non standard HTML features that only work in chrome and then polyfills it for every other browser so it works like shit unless you use chrome.

Even though it's still not there, YT team is working towards standard compliance [0]

[0] https://news.ycombinator.com/item?id=18053935

Re: Private by Design: How We Built Firefox Sync

#107

Post by fro0116 »

NewEntryHN wrote: post #102
joekrill wrote: post #100

Earlier quoted context omitted.

How could this even possibly be mitigated, though? At some point you have to trust something , right? This argument could extend all the way down to your OS, chipset, whatever. Unless you've built every part of your machine from scratch it's always going to rely on trusting a component you know nothing about.

Trusting the binary is a one-time effort. Here you have to trust the JS everytime you authenticate.

For this use case, authenticating is a one-time effort as well, per browser. If you're authenticating again, you're almost certainly doing it on a different device/browser, at which point you'd have to verify the new browser binary anyways.

Re: Private by Design: How We Built Firefox Sync

#108

Post by fro0116 »

hnaccy wrote: post #81
rfk wrote: post #61

Earlier quoted context omitted.

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…

>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 p…

"Every time" for this use case is once per browser install, at the moment you perform the authentication with Firefox Sync, which is the same as the number of times you'd want to verify the binary right before authenticating.

The tradeoff they made here has essentially zero impact on the number of times you need to verify their code, it's just a matter of whether you'd have to verify browser native authentication code or authentication code delivered through a website written in JS, at the moment you authenticate.

A concern like the one raised in this thread is certainly valid for websites that have expiring sessions, where you can switch accounts and log in and out of. And we certainly do need better tools around signature verification and version pinning for websites like we do for binaries (content-addressed networks like IPFS may have good answers there).

But for this use case, it's not a practical concern by any measure, and all this alarmism seems really misdirected.

Re: Private by Design: How We Built Firefox Sync

#109

Post by xte »

Hum, personally I would love to have a more human-manageable profile, so I can forge a personal FF profile template with not only user CSS, options etc but also extensions that get picked-up and updated by FF from first run and after.

I'm not interested in sync my stuff on other's computers, private or not, encrypted or not. I know how to backup my data and I prefer my own system. This may not conflict with casual PC users unable to backup their data and unable to manage anything by themself. It's only a matter of choice: mainstream only or mainstream+tech savvy users through simplicity, MIT school.

Re: Private by Design: How We Built Firefox Sync

#110

Post by maccard »

vesinisa wrote: post #66
vedantroy wrote: post #58

Earlier quoted context omitted.

I don't think the Javascript for authentication can be client-side. Authentication of passwords must be done on the server.

Did you read the article? The system is designed so that an authentication token is derived from the password, and this token, rather than the password itself, is authenticated against on the server. Since the encryption key can not be derived from the authentication token, this shields the content of the encrypted data the server stores from itself. GP rightly noted that deriving the authentication token with code s…

> unless user has the time to verify the JavaScript they are served every time they log in.

Which is once per install, the same amount of times then user would have to verify the native code

Post reply on HN