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

61–70 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#61

Post by rfk »

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

Re: Private by Design: How We Built Firefox Sync

#62

Post by rfk »

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.

Re: Private by Design: How We Built Firefox Sync

#63

Post by tomrittervg »

codetrotter wrote: post #30

This might not align with the goals of Mozilla, but what I would love to see is for Firefox Sync to be extracted so that: - It can be integrated into Google Chrome on desktop operating systems. - It can be provided as a stand-alone app on iOS so that I can: a) “Share” links to this hypothetical stand-alone Sync app from Safari in order to send them to Firefox Sync bookmarks storage. b) Copy username and password from…

There's a few children of this comment, noting this, but to tie things together from someone from Mozilla:

- You can self-host your own sync server. It's not something we spend a lot of time making easy, but it is possible and supported in some capacity: https://mozilla-services.readthedocs.io/en/latest/howtos/run...

- You can definitely build extensions for other browsers (or a standalone app) that implement the Sync protocol.

Re: Private by Design: How We Built Firefox Sync

#64

Post by tomrittervg »

thomastjeffery wrote: post #28

If only Firefox Multi-Account Containers were a feature, not an addon. The fact that containers don't sync well is probably my biggest frustration with Firefox at the moment.

It is many folks', and we appreciate the feedback. Hopefully things will get better soon: https://github.com/mozilla/multi-account-containers/issues/3...

Re: Private by Design: How We Built Firefox Sync

#65

Post by kbenson »

nwah1 wrote: post #49
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

There was a substantive suggestion for improvement... to include the javascript calls to grab the authentication inside the source code, rather than a remote call. Maybe an intermediate solution would be to use integrity hashes on the remote calls.

> Maybe an intermediate solution would be to use integrity hashes on the remote calls.

That was my immediate thought upon reading your comment and realizing that the bar to hit is really to be just as secure as if it's baked in the binary, but on reading the bugzilla links that _rfk posted in a comment to your original comment, I'm not sure it really works for their goals (whether or not you think those goals are correct or match yours).

If I maybe understand what they are working towards, it's having the flexibility to provide fixes/features quickly while still providing security. I'm not sure the features portion of that is as important as the credit they give it, given we're talking about security here, but quick fixes is good. I imagine they are looking at a way to provide a specialized context or something similar to lock down what can and cannot be done if the served content is malicious, but I'm not entirely sure what that would look like.

Re: Private by Design: How We Built Firefox Sync

#66

Post by vesinisa »

vedantroy wrote: post #58
nwah1 wrote: post #49

Earlier quoted context omitted.

There was a substantive suggestion for improvement... to include the javascript calls to grab the authentication inside the source code, rather than a remote call. Maybe an intermediate solution would be to use integrity hashes on the remote calls.

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 served by the server at log-in time renders most of the security architecture of the system rather moot, unless user has the time to verify the JavaScript they are served every time they log in.

Re: Private by Design: How We Built Firefox Sync

#67

Post by danillonunes »

thomastjeffery wrote: post #28

If only Firefox Multi-Account Containers were a feature, not an addon. The fact that containers don't sync well is probably my biggest frustration with Firefox at the moment.

Containers are actually built-in into Firefox. The addon only manages the user interface.

Re: Private by Design: How We Built Firefox Sync

#68

Post by garmaine »

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…

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

Re: Private by Design: How We Built Firefox Sync

#69

Post by drdaeman »

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-Last-Modified (which is just like Last-Modified but with UNIX timestamp - seriously?). While I haven't experimented writing an adapter yet, I strongly suspect a plain old' WebDAV (with a tiny little bit of sub-standard collection stuff) would've worked just fine and even better.

3. Poor documentation. The documentation was draft quality when Accounts and Sync were just rolled out (so it required some reverse engineering), but that's understandable. Things have improved since then but I believe a lot of stuff isn't really fully documented even today. For example, some undocumented magic is required to show Accounts sign-in page on iOS.

My point is, the whole thing is absolutely not developer-friendly (unless you're a Mozilla developer), as it makes self-hosting and alternate implementations quite difficult.

Maybe my problem is Accounts and Sync is not a standard (neither a proposal to become one), but just a documented vendor-unique API.

Re: Private by Design: How We Built Firefox Sync

#70

Post by drdaeman »

colemickens wrote: post #47
codetrotter wrote: post #30

This might not align with the goals of Mozilla, but what I would love to see is for Firefox Sync to be extracted so that: - It can be integrated into Google Chrome on desktop operating systems. - It can be provided as a stand-alone app on iOS so that I can: a) “Share” links to this hypothetical stand-alone Sync app from Safari in order to send them to Firefox Sync bookmarks storage. b) Copy username and password from…

Aren't both Chrome and Firefox's sync protocols open? At least, the Firefox Sync server is still self-hostable and open source, and at least the client side of Chrome's sync is open source since Chromium can sync as well... I've never understood why someone didn't implement a Firefox Sync extension for Chrome or vice-versa. Is it technical or are people opinionated enough about browsers that no one has the personal n…

Chrome sync can be also self-hosted, and while I'm not sure how things are today I'd say it used to be significantly easier to self-host.

https://superuser.com/questions/614744/how-to-set-up-a-own-c...

Post reply on HN