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

121–130 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#121

Post by jniedrauer »

fro0116 wrote: post #108
hnaccy wrote: post #81

Earlier quoted context omitted.

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

You're still not addressing the ease with which a targeted attack can be directed at a single user.

In order to compromise firefox native code, they would have to compile malicious code and ship it to everyone. My distro maintainers would need to include the malicious binary in their repos, including a signed hash of the compromised binary, and I'd need to install it, where my package manager would verify the hash.

In order to compromise a single user's browser session, they'd simply need to fingerprint the user's browser and then serve them different content than everyone else gets. No hashes or signatures on javascript, no safety in numbers, etc.

Re: Private by Design: How We Built Firefox Sync

#124

Post by rocqua »

jniedrauer wrote: post #121
fro0116 wrote: post #108

Earlier quoted context omitted.

"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 cod…

You're still not addressing the ease with which a targeted attack can be directed at a single user. In order to compromise firefox native code, they would have to compile malicious code and ship it to everyone . My distro maintainers would need to include the malicious binary in their repos, including a signed hash of the compromised binary, and I'd need to install it, where my package manager would verify the hash.…

if someone is using a package-manager that uses code signing then indeed, the binary is harder to attack than the JS. (only because the package-manager would need to collude).

However, a lot of people get their software from downloaded .exe's or auto-upgrading installations. For them, JS or binary are equally vulnerable. (All it takes is a mozilla signature)

Besides, it is undeniably better to only be vulnerable to an active attack from mozzila, than to be vulnerable against a passive attack from them.

Re: Private by Design: How We Built Firefox Sync

#125

Post by rocqua »

Scarbutt wrote: post #6
arctux wrote: post #3

This is a good example of why Firefox is so important. Mozilla's incentives, unlike those of companies making significant revenue from tracking-based advertising, align with the user. Google, for example, could have implemented Chrome's sync feature in a privacy preserving manner, but instead chose to use it as a method to collect their users' complete browsing histories.

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

Yes, but that leaves you with 2 passwords and isn't default.

The advantage here is twofold. - Your encryption key is derived from your single Firefox password, rather than having 2 passwords. - The ease of use of this system makes it possible to have e2e encryption by default rather than by opt-in.

Re: Private by Design: How We Built Firefox Sync

#126

Post by bad_user »

pgm8705 wrote: post #123

Firefox has really been appealing to me lately. Unfortunately, on my MacBook Pro, Safari is more energy efficient and it's not even close. If Firefox could close the gap there a bit I would make the switch.

I'm a long time Firefox user and I haven't noticed a difference in battery usage. I have a MacBook Pro and I've got other things that drain my battery of course, like the Scala or Haskell compilers :-)

That said Mozilla is apparently working on it and to improve energy efficiency, try setting gfx.compositor.glcontext.opaque to true in about:config.

Courtesy of @pcwalton: https://news.ycombinator.com/item?id=18048844

Re: Private by Design: How We Built Firefox Sync

#127

Post by rocqua »

erikbye wrote: post #111

1000 is a very low number for PBKDF2 iterations. OWASP recommends 10 000, and also recommends using Argon2 instead. Apple does 10 million.

They have an open bug to change the number of iterations. Also, there are more rounds server side, so at least the values in a database are pretty safe in case of a leak.

Re: Private by Design: How We Built Firefox Sync

#128

Post by Benjamin_Dobell »

eadmund wrote: post #113
Benjamin_Dobell wrote: post #88

Earlier quoted context omitted.

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…

> Do you have automatic updates running for Firefox … No. > … or any piece of software on your computer? Also, no. But even did I, there’s a world of difference between automatic updates from e.g. Debian and automatic updates from Mozilla.

> there’s a world of difference between automatic updates from e.g. Debian and automatic updates from Mozilla.

In what way?

This is obviously somewhat anecdotal, but...

I'm the developer of Heimdall. Software that flashes firmware onto Samsung phones. The software quite literally has the ability to replace almost every piece of software running on your phone. If it were compromised, it could not only own a user's phone, but also potentially everything a user accesses on said phone.

Sure my software is open-source, and I encourage anyone interested to inspect the code, I'm sure there are bugs. However, the `heimdall-flash` package in the official Debian repositories... I didn't make it, and I have no connection with whoever did. Now, don't be alarmed, despite being several years out of date, to the best of my knowledge it's a perfectly good package, and I'm thankful that the maintainer went to the effort. However, it would be so easy for someone to have published a malicious package. This is pretty powerful software, it has significantly more power than root on your mobile phone.

I love Debian, both philosophically and in practice. But does it really deserve your trust more than Mozilla?

Re: Private by Design: How We Built Firefox Sync

#129

Post by maccard »

vesinisa wrote: post #118
maccard wrote: post #110

Earlier quoted context omitted.

> 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

There's actually a great difference, because for binary distribution it simply suffices that the user verify the cryptographic hash of the binary they downloaded. Then they can be confident that they were served the correct publicly distributed binary, and not a subverted version. JavaScript by its very nature can not be easily, if at all, verified. Even if you verify that you are being served the same code as other…

> JavaScript by its very nature can not be easily, if at all, verified.

Yes it can, in the same way you mentioned in your previous paragraph. Mozilla post the hash of the JS source file, and any user who wants to can verify the hash of the source file they have can do so in exactly the same way they verify a binary. It's literally calling sha1sum on the js file isntead of the binary.

> This is also probably the very reason why Mozilla implemented it like this (so that they can update the Sync experience branding without updating the browser.)

I'd partially agree here - it's implemented like this so that they can update sync without updating the browser. If there's an issue found, mozilla can fix it, change the JS that is being served, and update the hash of the file. Sync branding (to me) has nothing to do with it.

> Even if you hard-coded the signature of the JavaScript library file responsible for the cryptographic operations in the binary, browser DOM by itself would require modifications so that any other UI logic script in the page would not be able to sniff your password as you enter it..

Yes, but this is moving the goalposts from the user verifying the js. This is true whether the code is in the binary or not. If the code goes in the binary, and is shown as part of the DOM, you need to modify the DOM logic to ensure nothing else can see it.

Re: Private by Design: How We Built Firefox Sync

#130

Post by m000 »

How portable is Firefox Sync to other browsers? I find myself in need to keep both Firefox and Chrome open at all times (different websites work better with either of them). I would like to have at least my bookmarks and passwords synced—don't really care for history or tabs.

LastPass and others provide a cross-browser password sync service. But after Xmarks having been discontinued, I could not find find any cross-browser bookmark sync service. I was hoping Firefox Sync would be open enough for someone (preferably Mozilla Foundation) to have built a Chrome extension to support it, but this hasn't happened, and doesn't even seem to be on the works.

I'm actually willing to pay a subscription for this functionality (i.e. bookmarks/password sync across the the major browsers) for anyone who supplies it without trying to lock me in their service or browser.

Post reply on HN