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

141–150 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#141

Post by ViViDboarder »

drdaeman wrote: post #69
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.

If that's the case why Firefox Accounts is not really designed with the end-user in mind? The design totally looks like a nice walled garden, completely custom and non-interoperable. Just a few quick examples: 1. There's HAWK and OAuth2 and BrowserID there, all in the same system. That's a lot of undesirable extra complexity. 2. The Sync 1.5 protocol itself is full of non-standard weirdness, with odd stuff like X-Las…

End-user or developer? I believe it’s plenty friendly to end-users since it’s simple to use and works. However, it’s certainly not so for developers, as I’ve struggled myself at self-hosting Firefox Accounts/Sync.

Re: Private by Design: How We Built Firefox Sync

#142

Post by IshKebab »

rauhl wrote: post #116
riquito wrote: post #48

Earlier quoted context omitted.

If you have that much distrust you shouldn't run Firefox at all since every page you load would be at risk. I doubt that any browser would match such an high bar

Not really, since one can verify the Firefox code oneself, or hire others to do it, or rely on the fact that it’s a matter of public record and do forensics analysis after the fact should one be compromised. But a target JavaScript file sent only to oneself a single time … that’s practically impossible to validate or prove.

Most people download Firefox binaries directly from Mozilla. They can't verify the code (even if they knew how).

Re: Private by Design: How We Built Firefox Sync

#143

Post by IshKebab »

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.

So you never update Firefox? For most users it automatically updates itself.

Re: Private by Design: How We Built Firefox Sync

#144

Post by zeveb »

callahad wrote: post #99
beatle_sauce wrote: post #94

The new Firefox sync (v1.5) is surely great and has good usability, I preferred the old Firefox sync (v1.1), because it didn't require a Mozilla account (for password retrieval). The new service requires two servers for one's fully own setup (for managing accounts and a sync server), although it is possible to use Mozillas account server. Also, from the description of the protocol ( https://github.com/mozilla/fxa-aut…

Everything is Class-B. Class-A and Class-C are relics of ideas we had back in 2013 that we did not pursue. Specifically, once of the consequences of Class-B is that your encryption key is derived from your password. If you forget and reset your password, you necessarily lose access to all of your synced data. (Though we did recently add support for recovery keys: https://support.mozilla.org/en-US/kb/reset-your-firefo…

> Our experience with Sync 1.1 taught us that this does not work with real people at scale; people often lost data as a consequence of this design.

Far better to lose passwords, bookmarks & history than to have them exposed — which is what the current design does (because the user's password can be stolen if the users logs in to his Firefox Account via the HTML page).

There are reasonable countermeasures I can take against losing my passwords: I can record them elsewhere; I can reset them if I lose them. But the only reasonable countermeasure I can take against Mozilla stealing my password is to never login to a Firefox Account (the alternative, hand-verifying HTML and a JavaScript bundle myself on every login attempt, is patently unreasonable).

So that's what I do: I don't use the Firefox Sync functionality, because the security of the system is broken.

Re: Private by Design: How We Built Firefox Sync

#145

Post by IshKebab »

rlpb wrote: post #133
IshKebab wrote: post #86

Earlier quoted context omitted.

If Mozilla wants your passwords there's nothing to stop them adding code to Firefox itself that detects when you are typing your password in and sends it to them. It could be limited to just you in that case too. This is really to protect against two things: 1. Legal requests for your data. It's actually not really been tested whether or not the government can force an entity to insert a backdoor for a specific user…

> If Mozilla wants your passwords there's nothing to stop them adding code to Firefox itself that detects when you are typing your password in and sends it to them. It could be limited to just you in that case too. Users who consume Firefox from distributions, rather than directly from Mozilla, are much better protected from this. "Nothing to stop" is not true in this case.

Sure but then you're just trusting a different party (the packagers). Now you have to trust two groups of people.

Re: Private by Design: How We Built Firefox Sync

#146

Post by bjt2n3904 »

While I can appreciate the technical merits of this (and rauhl's valid criticism), Firefox Sync is simply something I don't want, no matter how securely it's implemented.

I don't want anything to carry over between browsing sessions. Nothing. Not cookies, not super-cookies, not browser cache, not fonts. (About all I'm ok with carrying over is my uBlock plugin. There may be some other things like DNS cache and HSTS... though they're deeper than my realm of knowledge. I reckon keeping those are an acceptable trade for security vs tracking.)

As much as possible, I want each browsing session to be fresh, as if I were starting the browser up in a VM, and then reverting state after closing. I reckon that makes it that much harder to track me across the internet.

Firefox Sync seems to be an antithesis to this. (And I'm not very trusting of it's password saving feature, either.)

However, given that YouTube's front page seems to be picking up on my interests, maybe my measures are ineffective. (No 3rd party cookies, clear everything after browser close.) Perhaps I should give up hope and just permanently stay logged in.

(As an aside, one thing I was very sad to find out... I VEHEMENTLY DESPISE Firefox restoring all my tabs after a crash. If something evil caused the crash, I don't want to give it a second shot! ((Or worse, opening a browser in front of a coworker or client, and it restoring tabs I wouldn't want them to see. There's no warning or consent obtained, just... "HEY! Here's all your old tabs!")) However, disabling this feature ALSO disables "open previously closed tab", which I'm OK with. It seems a bit strange that these features are linked, perhaps someone can explain it to me.)

Re: Private by Design: How We Built Firefox Sync

#147

Post by Benjamin_Dobell »

ptx wrote: post #139
Benjamin_Dobell wrote: post #128

Earlier quoted context omitted.

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

It's perfectly normal for Debian packages to be maintained by other people that the original developers of that piece of software, isn't it? Debian has more than 60000 packages but doesn't have 60000 package maintainers – the roles are quite separate. For example, Linus Torvalds doesn't maintain the Debian kernel packages. If whoever does were to put malicious code in the kernel packages, that would be very bad, just…

> Debian has a relatively small set of trusted package maintainers and doesn't let just anyone put code in the official distribution

There are presently 2619 official Debian maintainer GPG keys[1].

Considering the scope, that's not ridiculous, but I wouldn't call it small.

[1] http://ftp.debian.org/debian/pool/main/d/debian-keyring/

Re: Private by Design: How We Built Firefox Sync

#148

Post by mercutio2 »

Benjamin_Dobell wrote: post #93
krageon wrote: post #91

Earlier quoted context omitted.

With attack vectors it's also about ease of exploitation. In this case, the ease is high. If the person you are responding to compiles their own browser, the bar to put an exploit in there is already much higher. Yes, there are still attack vectors. And there always will be. The point is they're harder to access.

Your initial comment was pretty adamant that Mozilla had really messed up by delivering the code as JS. However, what is the attack vector that they've introduced by taking this approach? It sounds to me like you're referring to a man-in-the-middle style attack. However, to be best of everyone's current knowledge, that's simply not possible with SSL. It's only possible if the attack vector includes having already com…

“That’s simply not possible with SSL”

I agree that we don’t currently know of easy attacks on SSL if you’re pinning certs (which it sounds like Mozilla does here). But all you need is a rogue CA to MITM SSL if you’re not pinning certs, so I don’t think “simply not possible” is an accurate description of SSL as generally used by the broad web-dev community.

Re: Private by Design: How We Built Firefox Sync

#149

Post by leetbulb »

rfk wrote: post #62
leetbulb wrote: post #59

I am curious why CBC was chosen over GCM?

For no reason other than "legacy reasons" - much of the client-side crypto code in the current Firefox Sync is inherited from an earlier system that predates widespread acceptance of GCM as a best practice. If we designed it from scratch today it would almost certainly be using GCM instead.

Makes sense. Thank you for your answer!

Re: Private by Design: How We Built Firefox Sync

#150

Post by 24gttghh »

bjt2n3904 wrote: post #146

While I can appreciate the technical merits of this (and rauhl's valid criticism), Firefox Sync is simply something I don't want, no matter how securely it's implemented. I don't want anything to carry over between browsing sessions. Nothing. Not cookies, not super-cookies, not browser cache, not fonts. (About all I'm ok with carrying over is my uBlock plugin. There may be some other things like DNS cache and HSTS...…

>I don't want anything to carry over between browsing sessions. Nothing. Not cookies, not super-cookies, not browser cache, not fonts.

You can customize what you want synced...I for instance only sync bookmarks, logins, add-ons, and firefox settings. History, open tabs, etc, are not synced.

>However, disabling this feature ALSO disables "open previously closed tab", which I'm OK with. It seems a bit strange that these features are linked, perhaps someone can explain it to me.)

I would think both features use the same underlying method for making snapshots of open tabs.

Post reply on HN