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

161–170 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#161

Post by drdaeman »

ViViDboarder wrote: post #141
drdaeman wrote: post #69

Earlier quoted context omitted.

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.

Both. Developers are end-users as well, and an ability to self-host (and protocol standardization and availability of alternate implementations) matters to non-developer end-users too, even though they don't ask for it.

Openness is in the same boah as privacy. Average user would buy just a "we pinky swear it respect your privacy" sticker on the product, but we know they want real privacy. Same with openness. And Firefox Account & friends is not an open system, it just happens to be partially documented and have a few FLOSS implementations of varying quality.

Kinto is a step in the right direction, though.

Re: Private by Design: How We Built Firefox Sync

#162

Post by qbaqbaqba »

rem7 wrote: post #2

I’ve been using Firefox since I heard about their containers. I’m happy they are pushing for all these privacy tools. For me these are the features that will make me chose over chrome.

Illusion of safety is worse than the lack of it. Firefox and Mozilla are just untrustworthy as google.

Re: Private by Design: How We Built Firefox Sync

#163

Post by srazzaque »

tomrittervg wrote: post #156
zimbatm wrote: post #105

Earlier quoted context omitted.

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.

I wasn't aware that any distribution (besides Tor Browser) was building Firefox (or anything really) reproducibly. There's debian's https://reproducible-builds.org/ effort, but I thought that wasn't making much progress lately, nor was it deployed. Could you provide more info on what distro you're using, or how they're doing this?

S/he may be referring to Gentoo Linux.

Re: Private by Design: How We Built Firefox Sync

#164

Post by jniedrauer »

martin-adams wrote: post #135
jniedrauer wrote: post #121

Earlier quoted context omitted.

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

>> then serve them different content than everyone else gets To help my understanding, to achieve an attack like this, would the attacker need to circumvent SSL on the client, or takeover the script serving web server? Or is there another attack vector that I'm not seeing?

The attacker in this case would be Mozilla itself. No need for an MITM. In this hypothetical, a government agency contacts Mozilla and says "Here is a canvas/HSTS/other fingerprint. Please serve this malicious code when this fingerprint accesses the login."

The point is that Mozilla can single out individual users for targeted attacks, whereas they could not do that if they had to put the malicious code into Firefox itself.

Re: Private by Design: How We Built Firefox Sync

#165

Post by cyphar »

rocqua wrote: post #153
cyphar wrote: post #131

Earlier quoted context omitted.

Most distributions disable auto-upgrade in Firefox, for many reasons (security and auditability being one of the main ones) so you won't get auto-upgrade from a distribution. And even the "download .exes from the internet" usecase is precisely as secure as downloading JS from the internet that is verified once per install. To attack someone who has an auto-updating Firefox and downloaded it from the internet, you nee…

> So therefore it is strictly less secure in the optimal case, and it is no more secure in the sub-optimal case. So security really isn't a strong argument I agree. I was arguing for having some form of e2e encryption (like Firefox currently has) as opposed to not having e2e encryption. I wanted to argue against the idea that, because the e2e was implemented in JS, one might as well not have it. Then, regarding the g…

In openSUSE our build system can be configured to auto-check the signatures of the source archives used for building, so you can check the builds to make sure that we are building from an official source releases (assuming the GPG detach-sign their source tarballs -- something I recommend any software release manager do).

But most distributions do their own builds, and without reproducible builds being universally available -- not to mention that distributions usually have minimal compiler hardening flag requirements as well as patches in some cases -- you couldn't reuse signatures for the final binary. Also the entire package is getting signed, so the binary's signature wouldn't be sufficient (and checking it on-install would be quite complicated as well).

> Still, it would be weird that, as far as Mozilla trust goes, a signed exe from internet is better than a signed package from your preferred package manager.

I think that has always been the general case, since distributions are an additional layer of people maintaining a downstream copy of a project. But don't get me wrong, most distributions have processes that allow you to verify that the source used for builds of large projects like Firefox are built using the real sources.

There's also usually several layers of human and automated review before a package upgrade can actually land in a distribution.

Re: Private by Design: How We Built Firefox Sync

#166

Post by qwerty456127 »

tomrittervg wrote: post #158
qwerty456127 wrote: post #112

Cool but there is a lot more that can be done to improve a browser privacy by fighting fingerprinting. I.e. provide standardized sets of data about the host system via JS APIs: only list a standard set of fonts (+ those a user consciously chooses to expose), a most common display resolution that is less or equal to the real display resolution of the machine, obfuscate canvas/webgl/cache response time etc. Extensions…

I happen to also work on Firefox/Tor Browser's anti-fingerprinting work, so yea - we're trying to make improvements there too =) Containers is a big Firefox feature (exposed through an Add-On) in this category too. As far as Web Extension APIs, I don't know much about that, but if you have an API that would enable a use case that Mozilla doesn't have a bug on and haven't considered; you are welcome to file a bug expl…

Thanks. Great to read you work on anti-fingerprinting, I'd name this among the most important subjects today.

I don't code privacy enhancing extensions myself (that feels like "inventing my own crypto" for me - not enough competence to be sure I won't make it worse actually), I've just noticed Firefox becomes significantly more slow when I enable them so I guess there probably are some sorts of bottlenecks in the Web Extension APIs (or maybe not really).

Re: Private by Design: How We Built Firefox Sync

#167

Post by danShumway »

CoolGuySteve wrote: post #77
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…

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?

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.

Re: Private by Design: How We Built Firefox Sync

#168

Post by ndnxhs »

chupasaurus wrote: post #106
ndnxhs wrote: post #42

Earlier quoted context omitted.

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

Its amazing how low the bar for quality is on major google websites. How did such a broken feature end up running on YouTube for a year?

Re: Private by Design: How We Built Firefox Sync

#169

Post by franga2000 »

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…

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.

Re: Private by Design: How We Built Firefox Sync

#170

Post by martin-adams »

jniedrauer wrote: post #164
martin-adams wrote: post #135

Earlier quoted context omitted.

>> then serve them different content than everyone else gets To help my understanding, to achieve an attack like this, would the attacker need to circumvent SSL on the client, or takeover the script serving web server? Or is there another attack vector that I'm not seeing?

The attacker in this case would be Mozilla itself. No need for an MITM. In this hypothetical, a government agency contacts Mozilla and says "Here is a canvas/HSTS/other fingerprint. Please serve this malicious code when this fingerprint accesses the login." The point is that Mozilla can single out individual users for targeted attacks, whereas they could not do that if they had to put the malicious code into Firefox…

Right I see. So the barrier with Firefox itself, is that the malicious code wouldn't get built into the product and served as an update. However, in that scenario, Firefox could serve a malicious update to a single user, only that it's harder to fingerprint that.
Post reply on HN