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

71–80 of 180 posts

Re: Private by Design: How We Built Firefox Sync

#71

Post by drdaeman »

yoklov wrote: post #53
colemickens wrote: post #47

Earlier quoted context omitted.

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…

For firefox sync on chrome: It’s completely possible, but the crypto is enough of a pain in the ass to deter most people. (It’s also going to be very difficult to implement a robust sync system this way, integration with the underlying storage is all but required for that)

In my opinion, crypto is the easy part. I think the only problem I had when I worked on my own Accounts&Sync re-implementation (a crude hack, I admit) was some MAC-related issue with BrowserID, where different (old) Firefox versions had generated different assertions. Don't really remember what it was.

The real problem is data model is significantly different. It's possible, but a lot of boring work, designing the appropriate transformations.

Re: Private by Design: How We Built Firefox Sync

#72

Post by auslander »

mygo wrote: post #27
adtac wrote: post #25

Earlier quoted context omitted.

>keep Google from mining their data for ads I just got this morbid idea of Google mining storing passwords to recommend LastPass/1Password in ads based on your password strength.

Hmm I wonder if LastPass/1Password advertises on websites listed on haveibeenpwned

1Password is promoted by the HIBP itself, a.k.a Troy Hunt. I would not use it.

Re: Private by Design: How We Built Firefox Sync

#73

Post by Vinnl »

tomrittervg wrote: post #63
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 Syn…

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

In fact, GNOME's web browser already did so: https://blogs.gnome.org/mcatanzaro/2017/08/09/on-firefox-syn...

Re: Private by Design: How We Built Firefox Sync

#74

Post by Vinnl »

nsriv wrote: post #45
zymhan wrote: post #41

Earlier quoted context omitted.

I'd love to know, I've never stopped using Firefox and idk what plugin they mean.

Probably this one [0], though I dislike the branding at the top of the sidebar and the fact that since FF lacks native support, you'll still have tabs on top of the window. [0]: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...

You can disable those tabs on the window, you just have to mess with the browser chrome's CSS yourself. Which is relatively easy, but basically the reason I haven't used it so far.

But now that you mention it - I'm going to give it a shot now.

Re: Private by Design: How We Built Firefox Sync

#75

Post by Quai »

I was involved in implementing the first browser-to-browser, and browser-to-mobile sync. Opera Link (codename Pangea) was my first really large project in the company, and while desktop team had multiple persons working on the feature, the server side was designed, implemented and maintained by two guys plus a QA person.

We decided not to encrypt the user information for multiple reasons; user friendliness, data recovery and naivety. The internet was a different place back in 2008 (Opera 9.50). Both me and the other guy used the service our self, and was paranoid about the user data. Only we had access, and only we would see user data while fixing bugs.

I especially remember one bug where the database suddenly started growing faster than we expected. The frontend servers started eating more and more memory. In the end, we discovered that a larger porn site network had started serving their full size images as favicons, and that Opera Link had started syncing multi-megabytes of Base64-encoded favicons in our already bloated XML protocol. That was the first time I was introduced to 'Rule 34'.

We maintained the control over the server side and userdata until the end of the Opera Link project. We where never asked to turn over userdata to the company, except for aggregated stats for speeddials (only top X lists, not including unique URLs).

After we had announced the end of Opera Link, the userdata was scheduled for deletion, but we had to shut down the service a few weeks early, after a sysadmin started dban on the userdata mount instead of the local disk ;-)

Re: Private by Design: How We Built Firefox Sync

#77

Post by CoolGuySteve »

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…

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?

Re: Private by Design: How We Built Firefox Sync

#79

Post by throwawaylolx »

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…

This response reminds me of this discussion https://news.ycombinator.com/item?id=17804916

Re: Private by Design: How We Built Firefox Sync

#80

Post by Benjamin_Dobell »

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?

The privacy is at least verifiable. In the sense that users can at least look at the implementation themselves, and (granted with some difficult) potentially detect changes.

This is much better than simply sending your password off to a third-party and having to trust that the company is doing what they say they're doing.

Post reply on HN