
Private by Design: How We Built Firefox Sync - feross
https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
======
rauhl
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...](https://accounts.firefox.com/oauth/signin?scope=profile&client_id=3a1f53aabe17ba32)
your browser downloads the JavaScript it will use to derive your
authentication token from Mozilla.

There’s nothing stopping Mozilla from serving all users malicious JavaScript
which sends the password in plaintext; there’s nothing stopping Mozilla from
serving 1% of users, or even a single targeted user. They could be forced to
do so by a government with control over them; presumably some number of their
employees could likewise be suborned by a state or criminal enterprise.

This should all be done by code compiled into the browser and triggered from
the UI, rather than JavaScript run within a web page. Yes, Mozilla could also
serve malicious Firefox binaries, or even publish malicious Firefox source,
but the odds of someone in the world noticing that are significantly higher
than a single targeted individual or small number of targeted individuals
noticing.

Or maybe I’m missing something? I don’t think I am, though: that Firefox
Account page is just HTML served from accounts.firefox.com; it’d be easy
enough to just make it a simple form submission and capture the user’s
password. And with the password, the security of the system fails completely:
it’s simplicity itself to decrypt all stored data with it.

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

~~~
hnaccy
>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 pursuing to try to get the best of both worlds.

The safety of the default installation is crowdsourced across all users and
can't be targeted. The safety of the JS I load from Mozilla is not and I would
have to verify its safety every time. Unless I'm misunderstanding something it
can never be as trustworthy.

~~~
Benjamin_Dobell
How did you install Firefox in the first place?

~~~
hnaccy
You can verify hash with others or compile it yourself.

~~~
Benjamin_Dobell
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 difference?

Sure, this JS can change. Do you have automatic updates running for Firefox,
or _any_ piece of software on your computer?

~~~
krageon
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.

~~~
Benjamin_Dobell
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 compromised
the user's computer and installed a root certificate. At which point this is
all pretty moot.

~~~
krageon
I think you have me confused with someone else. I have made no points except
the ones in the post you are responding to.

In this case it looks like you're missing the fact that you can change the JS
on the server with a high amount of ease and a low discoverability (it can be
changed just for you and it won't show anywhere else).

~~~
Benjamin_Dobell
> _I think you have me confused with someone else. I have made no points
> except the ones in the post you are responding to._

My apologies, that's what I get for reading on my mobile.

> _In this case it looks like you 're missing the fact that you can change the
> JS on the server with a high amount of ease and a low discoverability (it
> can be changed just for you and it won't show anywhere else)._

You raise a reasonable point. It is indeed something everyone should be aware
of. It's mostly a matter of trust, not security.

However, the same is equally true of someone you _trust_ changing the
binaries, source and/or hashes that are delivered to you; whether you got
those from Mozilla, or somewhere else.

For example, the relatively recent Handbrake release compromise -
[https://news.ycombinator.com/item?id=14281808](https://news.ycombinator.com/item?id=14281808)

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

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

~~~
arctux
Yes, but it's not the default. From the article:

> One could, however, add a second passphrase that is never sent to the
> server, and encrypt the data using that. Chrome provides this as a non-
> default option.

The average user doesn't have the expertise to know that they have to
configure an additional "master password" to keep Google from mining their
data for ads.

~~~
tprnz
That is true, defaults are important. Firefox users know that because they
have to disable the advertisements that appear in the Firefox new tab page by
default.

[https://prod-
cdn.sumo.mozilla.net/uploads/gallery/images/201...](https://prod-
cdn.sumo.mozilla.net/uploads/gallery/images/2017-10-11-15-35-09-6b82a5.png)

~~~
arctux
I strongly dislike that they've done that. In their partial defense, the
selection of recommended articles based on your browsing history is done on
device.

~~~
mintplant
In fact this was one of the primary motivations behind Sponsored Tiles in
Firefox, to prove the viability of a privacy-preserving monetization model for
the web.

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

~~~
noisem4ker
Thanks for sharing your experience.

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

~~~
Barrin92
ever since they've switched to the quantum engine it also feels really fast,
almost faster than chrome with the exception of youtube, which feels sluggish
sadly.

~~~
ndnxhs
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.

~~~
chupasaurus
Even though it's still not there, YT team is working towards standard
compliance [0]

[0]
[https://news.ycombinator.com/item?id=18053935](https://news.ycombinator.com/item?id=18053935)

~~~
ndnxhs
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?

~~~
M2Ys4U
Works on Chrome, Google doesn't care about anything else.

------
codetrotter
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 the stand-alone Sync app when using Safari
on iOS.

It might sound like a peculiar setup but bear with me.

The situation is that I run Firefox as the main browser on my laptop, Chromium
as main browser on desktop and Safari as main browser on iOS.

For a long time I’ve used Firefox Sync as the “main” storage of passwords, and
I would go into Firefox settings and copy username and password from there on
desktop and mobile. Even though I store the passwords and usernames in the
other browsers on first login it’s still a bit cumbersome whenever I add a new
account, log in for the first time, or change a password.

Recently on desktop I started using KeePassXC on my desktop and the browser
plugins for it in order to make it a bit smoother. Today I installed
MiniKeePass on iOS and am going to find a good way of keeping it in sync with
my desktop. In the end though, KeePassXC is not quite what I want, whereas the
core of Firefox Sync is exactly what I want.

As for my bookmarks, they are all over the place. Some in Firefox, some in
Chromium, some in Safari, some in exported files or copies of old homedirs,
and a lot of bookmarks probably lost at various points in time. Again, the
core of Firefox Sync is what I want.

~~~
tomrittervg
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...](https://mozilla-
services.readthedocs.io/en/latest/howtos/run-sync-1.5.html)

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

~~~
Vinnl
> \- 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...](https://blogs.gnome.org/mcatanzaro/2017/08/09/on-firefox-sync/)

------
qwerty456127
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 API should also get optimized in a way so privacy-enchancing
extensions (like Ghostery, Adblock Plus and NoScript) would work faster.

And there is a favourite extension of mine called "self destroying cookies"
that currently is blocked for sending user data to remote servers
unnecessarily, and potential for remote code execution - I believe it's actual
functionality (not sending user data to remote servers but what it is meant
for - one-click whitelisting particular domains and only keeping cookies for
these while deleting cookies for others as you close them) should be built
into the browser.

~~~
tomrittervg
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 explaining what you would
like and what you would use it for, and the Web Extension team will consider
it.

~~~
qwerty456127
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).

------
porphyrogene
This is a really great article. The level of detail is perfect. I feel that I
could implement a similar encryption system as a proof of concept after
reading it. It seems so obvious but it really does go against the grain of
many of the more common approaches (as explained in the article) because
respecting the privacy of a user is so unusual.

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

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

~~~
thomastjeffery
Even if that is the case, they are effectively not.

The UI has serious holes, and containers do not work with Firefox sync.

I also haven't been able to find a way to clear the cache or history for a
specific container.

At this point, containers are barely even useful. Putting the UI in an addon
was an awful decision.

------
the_clarence
People who still use Chrome nowadays probably haven't heard of Firefox' tree
style tabs plugin.

~~~
how_to_bake
What plugin? What does it do?

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

~~~
nsriv
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...](https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/)

~~~
Vinnl
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.

~~~
dcrn
Here's a list of tweaks that you can try:
[https://github.com/piroor/treestyletab/wiki/Code-snippets-
fo...](https://github.com/piroor/treestyletab/wiki/Code-snippets-for-custom-
style-rules#for-userchromecss)

~~~
Vinnl
Thanks! I was looking for the best snippet to hide it, and this one is a bit
more specific than the one I was using. (Plus, it allowed me to hide the bar
in full-screen.)

------
pwg
> Other approaches > [ list of 3 options ]

I would like to see an option 4:

Option 4: The server side of sync is open sourced, and I can run it on my own
machine, and point my browsers at my personal instance. Then no data is ever
on Mozilla's servers.

~~~
mbrumlow
I was just looking into this. I thought it was?

I have not set it up yet. But is this not what you are looking for ?

[https://mozilla-
services.readthedocs.io/en/latest/howtos/run...](https://mozilla-
services.readthedocs.io/en/latest/howtos/run-sync-1.5.html)

~~~
J_tt
Mozilla seems to keep this very quiet, but from what I can see in this
documentation it's extremely easy to implement your own sync server, with only
one flag in about:config needing to be changed and minimal build dependencies.

The harder aspect comes with the Firefox accounts server, as that requires a
bit more configuration and deployment.

I would be very interested in seeing someone build a docker-composer setup for
this, such that it can be automatically deployed for those who don't have the
time/skills to set it up.

------
owaislone
How does Firefox Sync handle a user changing their password? What if the
password is changed from another device? Does it force users to first sign in
with old password and only then allow to change it, essentially re-encrypting
everything and syncing again? If so, does that mean forgetting the password
equals to losing all synced data?

~~~
yoklov
Yes, sort of (more about the process: [https://github.com/mozilla/fxa-auth-
server/wiki/onepw-protoc...](https://github.com/mozilla/fxa-auth-
server/wiki/onepw-protocol#changing-the-password)). Key difference: you don't
need to sync all the data up again, since there's a separate key for that,
which doesn't change.

That said, if you forget your password you do lose remote synced data. The
hope is that you have at least one device connected that still has the data,
which will upload it in that case. This doesn't work in all cases (there's a
pretty common and unfortunate pattern where someone reinstalls their OS,
doesn't remember their password, and loses data as a result)

You can also generate and store a separate recovery key to help avoid data
loss, [https://support.mozilla.org/en-US/kb/reset-your-firefox-
acco...](https://support.mozilla.org/en-US/kb/reset-your-firefox-account-
password-recovery-keys).

~~~
owaislone
Thanks. I've been using Firefox Sync ever since it came out but I don't
remember it ever mentioning these risks. I think Firefox should mention this
when new users enable sync for the first time. It should also offer users to
generate recovery keys when they start using sync and for some time after if
they haven't.

~~~
yoklov
There's no risk to your data. It's not like this will delete your local data,
the only risk is when doing a password reset in some (fairly rare) cases,
which does attempt to make the risk of doing so clear.

I don't disagree about recovery keys, they're rather new though, eventually it
wouldn't surprise me if we did something like that.

~~~
aiiane
There is a risk if you were relying on sync to be a backup solution (which in
the absence of discussing the risk of remote data loss, someone might be
tempted to do).

~~~
yoklov
Sure, and we do warn during password reset.

I’m unsure of what alternative there is that avoids that risk while still
providing the current privacy benefits.

------
abuckenheimer
I've never heard of HKDF before but it is really an elegant solution to this.
My first guess on how to do this would have been something stupid like split
the Authentication token in half and 0 pad it. But this would have
significantly reduced the entropy available on both keys, reducing the search
space on the authentication token and the encryption key making them much more
brute force able. HKDF instead expands the key and essentially requires the
server to be able to reverse HMAC-Hash to find the encryption key from the the
authentication token.

What I'm confused about is that they seem to be using HKDF as a hash [1] and
not as a key generation funciton. I think this is just as secure as what I was
expecting but it seems more complicated and doesn't jive with the purpose of
the RCA[2] as I read it.

[1] [https://github.com/mozilla/fxa-js-
client/blob/1d92f0ec458ace...](https://github.com/mozilla/fxa-js-
client/blob/1d92f0ec458aceb56ef1619b5365ad8621183a1d/client/lib/credentials.js#L71)
(separate HKDF calls with the same IKM)

[2] [https://tools.ietf.org/html/rfc5869](https://tools.ietf.org/html/rfc5869)

~~~
tomrittervg
From the RFC: "Its goal is to take some source of initial keying material and
derive from it one or more cryptographically strong secret keys."

In our case, the initial keying material is the output of PBKDF; and the two
outputs we use are used as an encryption key and a bearer token (essentially a
password but I call it an authentication token to avoid confusion with your
actual password). There are less complicated ways to do this; but this one is
cryptographically conservative.

"essentially requires the server to be able to reverse HMAC-Hash to find the
encryption key from the the authentication token" \- the server can't do that;
which is why the server can't figure out your encryption key from your
authentication token. (The best the server could do would be to try a password
guessing attack.)

~~~
abuckenheimer
Right what I'm confused about is that first bit, my understanding from the RFC
is that the implementation should have look something like

    
    
        return pbkdf2.derive(password, email, PBKDF2_ROUNDS, STRETCHED_PASS_LENGTH_BYTES)
          .then((quickStretchedPW) => {
            result.quickStretchedPW = quickStretchedPW;
            // stretch to twice the length necessary
            return hkdf(quickStretchedPW, kw('generated'), HKDF_SALT, HKDF_LENGTH * 2)
              .then((generated) => {
                // split output into two cryptographically strong keys
                result.unwrapBkey = generated.slice(0, HKDF_LENGTH);
                result.authPW = generated.slice(HKDF_LENGTH);
              }
            );
          }
        )
    

but my read in pseudo code of what they end up doing is closer to this:

    
    
        hashed_password = hash(password, 'salt1')
        hashed_auth_tok = hash(hashed_password, 'salt2')
        hashed_unwrap_key = hash(hashed_password, 'salt3')
    

which seems secure because the server can't reverse hashed_unwrap_key to find
hashed_password and thus shouldn't be able to calculate hashed_auth_tok.
However the point of HKDF is to make multiple cryptographic keys while it
looks like in practice we are just using it as a one way funciton.

~~~
tomrittervg
Ah okay, I understand better.

The (second) pseudocode you have is right (the second two 'hash()' should be
'hkdf()', and the first should be 'pbkdf()'.)

The first is an alternate way to do it. But for cryptographic reasons that
tend to be buried in formal proofs; you generally don't want to derive twice
the keylength you need and then split for two keys. (Besides the necessity for
formal proofs (as I understand it) - it's just easier to make an indexing
mistake and reuse key material. One also becomes more vulnerable to a
collision attack, although that might not make sense in this context it
related to the formal proofs.) I will note that sometimes - especially in
embedded spaces - you'll see people taking this shortcut in the name of speed
or codesize.

Instead you want to fully derive two keys using separate HKDF calls with
separate 'labels'. This provides strong domain separation for the keys.

But I'm mostly trying to provide with a pointer to what to read about to
convince yourself. I'd start at
[https://crypto.stackexchange.com/search?q=domain+separation](https://crypto.stackexchange.com/search?q=domain+separation)

If you find out we're doing something that still seems weird though, please
send me an email!

~~~
abuckenheimer
got it, thanks for the response!

------
beatle_sauce
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-
auth-server/wiki/onepw-protoc...](https://github.com/mozilla/fxa-auth-
server/wiki/onepw-protocol#firefox-accountssync-protocol) ) it was not clear
to me, what exactly is encrypted? Only the passwords? I had the impression
that the bookmarks were stored in a way readable by Mozilla.

Update. It is not clear what kind of data is in "Class-A" as described here:
[https://wiki.mozilla.org/Identity/AttachedServices/Architect...](https://wiki.mozilla.org/Identity/AttachedServices/Architecture)
... It also says:

> we can share e.g. bookmarks with a third party (by telling them the
> decryption key)

~~~
callahad
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-firefox-acco...](https://support.mozilla.org/en-US/kb/reset-your-firefox-
account-password-recovery-keys))

The idea behind Class-A was to let users choose to place some less sensitive
data--like bookmarks--into a bucket which survived password resets at the cost
of Mozilla holding a copy of the encryption key.

The idea for Class-C was to allow users to generate and an entirely separate
encryption key entirely separate from their password, as with Sync 1.1, but at
the cost of more complex setup when adding a new device: you have to either
maintain a backup copy of the key, or always have a previously configured
device on hand for PAKE. 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.

~~~
zeveb
> 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.

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

~~~
rocqua
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.

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

~~~
bad_user
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](https://news.ycombinator.com/item?id=18048844)

------
amelius
> Another interesting wrinkle is that Brave does not keep track of how many or
> what types of devices you have. This is a nuanced security trade-off: having
> less information about the user is always desirable… The downside is that
> Brave can’t allow you to detect when a new device begins receiving your sync
> data or allow you to deauthorize it. We respect Brave’s decision. In
> Firefox, however, we have chosen to provide this additional security feature
> for users (at the cost of knowing more about their devices).

Why not store a _hash_ of the user's devices instead?

------
superflyguy
I love Firefox but sync is by far the worst aspect. You can't use password
syncing if you have a master password. Why, and more importantly, why doesn't
the user get told this rather than passwords just silently not syncing? Who
decided that was that the user would want or expect? Even without the master
password I find password syncing rather hit and miss.

------
xte
Hum, personally I would love to have a more human-manageable profile, so I can
forge a personal FF profile template with not only user CSS, options etc but
also extensions that get picked-up and updated by FF from first run and after.

I'm not interested in sync my stuff on other's computers, private or not,
encrypted or not. I know how to backup my data and I prefer my own system.
This may not conflict with casual PC users unable to backup their data and
unable to manage anything by themself. It's only a matter of choice:
mainstream only or mainstream+tech savvy users through simplicity, MIT school.

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

~~~
24gttghh
>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.

------
czei002
Option 4: Use Fejoa auth to use the same password for authentication and for
encryption without revealing the password to the remote party:

[https://fejoa.org/fejoapage/auth.html](https://fejoa.org/fejoapage/auth.html)

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

~~~
tomrittervg
There are more details above but the short version is that it is possible to
build extensions for other browsers that work with Firefox Sync. But the only
one linked seemed to be for Gnome's browser, so no one may have actually done
it.

------
Tepix
What self-hosted alternatives are there to Firefox Sync these days? (i know
that Sync itself can be self-hosted).

There used to be at least one bookmark add-on that allowed syncing with your
own WebDAV server.

------
d0100
I use sync. Unfortunately, sending tabs works very randomly. Sometimes I have
to send tabs from one device, just to receive tabs I had sent (like
"refreshing" the tab sender)...

~~~
alpaca128
My experience with that feature is better. It may take a couple of minutes
until it's actually synced and opened on the other device, but recently it's
been quite reliable for me.

------
johnchristopher
I wish there was a sane way to run your own Sync server (without email
registration and authentification).

------
mosselman
Is there a good open-source self-hostable cross-browser alternative?

------
htor
all privacy aside. i think mozilla is doing good lately. firefox is fast and
it has a great dev tool since i last checked. today i'm switching from chrome!

------
leetbulb
I am curious why CBC was chosen over GCM?

~~~
rfk
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.

~~~
leetbulb
Makes sense. Thank you for your answer!

------
auslander
Apple publishes detailed whitepapers on how they implement security. I'd
suggest to Mozilla, get iCloud paper and copy the implementation. Way more
reliable.

------
adobeeee
I like, actually love Firefox. So as a major user I resent them for posting
this article, its somewhat inethical when no recent work has been done on sync
and they are , as they claim themselves, not willing to touch this code in
fear of breaking it. If you are don't understand enough to make changes, maybe
don't make an article about itm

~~~
yoklov
This is not true. I work on Firefox Sync full time, as do multiple other
engineers.

Admittedly, the current version in Desktop/iOS/Android is in a sort of
'maintenance mode' (we still fix bugs, but don't work on new features or
actively fix it up).

The reason for this is basically that those three versions are entirely
separate implementations that share no code (they're also in languages that
have integration difficulties on the other platforms, unfortunately, so we
can't just settle on one).

We're currently rewriting it as a cross-platform module, and planning on
replacing them.

~~~
dralley
>We're currently rewriting it

...in Rust?

(I kid, although, it's a serious quesiton)

~~~
yoklov
....

Yes >_>

[https://github.com/mozilla/application-
services](https://github.com/mozilla/application-services)

~~~
ArrayList
Lmfao! That's amazing! Did not expect this response, and it really is >60%
Rust code!

