Ask HN: Is anyone successfully self-hosting Firefox Sync?
However, I do not want to risk storing absolutely sensitive data (browsing history, auth cookies, credentials, etc) at some third party.
Everytime this comes up in HN comments, someone says that Firefox Sync can be self-hosted. And while this was true in the older versions of Firefox, it seems to me that self-hosting is currently neither supported nor documented. And it has been like this for at least since 2020[1][2]. It seems self-hosting is not a priority for Mozilla.
Is anyone actually self-hosting Firefox Sync? If so, how do you do it? How is it working for you? Any issues to be aware of?
[1]: https://github.com/mozilla-services/syncstorage-rs/issues/681 (opened on Jun 22, 2020)
[2]: https://github.com/mozilla-services/syncstorage-rs/issues/550 (opened on May 26, 2020)
120 comments
[ 3.2 ms ] story [ 183 ms ] threadFWIW Firefox says they do not have the capability to read your data: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/
I like to imagine it as having a safe deposit box provided by a local bank. I have the only key and have proven that to be the case. I also store the key at home in another safe which is regularly serviced by bank employees. While they probably don’t abuse their position in the latter to access the former, it would be completely wrong to say they do not have the capability to get at my stuff.
All that aside, I love FF sync and rely on it everyday for work stuff. It is like magic and I’m very grateful for the feature. I am realistic about the NSA’s level of interest in my work calendar and the threat they pose to my day to day life.
Hosting your own sync server doesn't prevent this.
The only realistic way to stop it would be to only use a specific audited version of FF. If that's the case then there's no need to use your own sync server because you already know it's not backdoored.
Anyone _that_ concerned can operate a whitelist-only policy on their network, now nothing goes anywhere they don't want it to.
Edit: Also, I don't think this is as much about trust as it is about avoiding being part of the huge target that the centrally hosted Firefox Sync servers must be.
While Firefox developers and Mozilla might be wholly trustworthy, they might become compromised by some configuration error or zero day vulnerability. So someone might steal the sweet sweet treasure that is in the Sync servers. Now, that is encrypted of course, but they might have made a simple error[1] in how encryption is implemented and the encryption may be defeated.
[1]: See for example: https://www.schneier.com/blog/archives/2008/05/random_number...
Agreed, but that was an extreme example. Blocking FFs known addresses should be sufficient with some additional network monitoring just in case.
I can't response to the rest of your comment, as my point was specifically about not needing to trust FF/MZ if you're running your own sync server. Once the software is within your network, it is entirely up to you, your tools and your skills to determine what does and does not leave it and to where.
Locksmiths will get through that lock in a couple of minutes, probably without you ever knowing
The only thing stopping the bank and/or government from accessing your box is the law
A very motivated actor will just knock on your door and ask you for the key(digital or otherwise) at gun point and it is game over.
Like one of the replies above, model your threat and enjoy like free of paranoia. It is a beautiful world out there! Ah and be politically active so your representatives preserve common freedom and well being.
The article is from 2018. Isn't this only relating to the old version of Firefox Sync - the one in which self-hosting is actually supported?
The design looks reasonable. However, my main problem with it is that putting all this extremely valuable data in one place makes it a huge target. A supply-chain attack or an implementation error in the crypto would be devastating.
At that time i stoped selfhosting & using it :(
[1]: https://github.com/balu-/FSyncMS
It still uses the Firefox identities service, since I haven't bothered to try setting that one up myself. That means I need a Firefox/Mozilla account even with a self-hosted sync server, which isn't ideal.
Note that Mozilla do provide a script to delete all your data from their servers[1], in case you were using Firefox sync before going self-hosted.
I originally went through the setup instructions manually. Now I've created a Nix package[2] and NixOS module for it[3], which was an adventure by itself. I can now easily reproduce the setup, which I did while migrating my webserver to a different provider.
As for why I didn't try syncstorage-rs, it's rather petty, but the old syncserver was working well for me, and it doesn't yet support SQLite.
[0] https://github.com/mozilla-services/syncserver
[1] https://github.com/mozilla-services/syncserver#removing-mozi...
[2] https://git.sr.ht/~williamvds/config/tree/master/item/nix/pk...
[3] https://git.sr.ht/~williamvds/config/tree/master/item/nix/mo...
> Note that this repository is no longer being maintained. Use this at your own risk, and with the understanding that it is not being maintained, work is being done on its replacement, and that no support or assistance will be offered.
And its replacement syncserver-rs is in this forever-unfinished state so they've effectively killed self-hosting. At least from a support standpoint.
Of course, everything self-hosted is at my own risk etc. And official support is a luxury in this kind of FOSS, I generally don't count on it.
But since it works for me, it may be worth sharing the details.
I really wish they'd just finish the Rust version. That would solve everything.
https://en.wikipedia.org/wiki/Second-system_effect
Instead, they went for a Big Rewrite in Rust, resulting in a much bigger codebase that will be much harder to maintain... and broke it anyway.
https://github.com/mozilla-services/syncserver/issues/264#is...
I’m sure it wouldn’t be that hard to port but if they’re committed to a different direction it’s probably best not to give the impression that you should plan to keep using it.
I mean, as a job-security device, I'm sure it works out great. As a strategic business decision, though, it looks debatable as a minimum - and I'm being charitable.
First comment under "The Adoption of Rust in Business": https://news.ycombinator.com/item?id=34691509
A bit further down: https://news.ycombinator.com/item?id=34691893
This is better - still a self-selected audience but a large one - and it shows around 10%. That’s not huge but I think it’s larger than “niche” given the growing popularity and impact.
https://survey.stackoverflow.co/2022
- The new replacement package, syncserver-rs, has already been added to Nixpkgs, along with a NixOS module [0]
- Python 2 and the package itself are no longer supported, meaning...
- support in Nixpkgs is pretty rough - dependencies have been updated such that they no longer support Python 2, or have been removed outright, meaning...
- syncserver has already been removed from Nixpkgs
- in order to avoid the problem of unsupported dependencies, I delegated dependency resolution to a community project, poetry2nix[1]. Even so, it was a nightmare to get working, lots of hacks and workarounds were needed
Of course, my repo is public, so anyone is welcome to use the Flake within. If they do, I'd suggest dropping me a line so I don't do anything drastic to the package or module.
[0] https://github.com/NixOS/nixpkgs/pull/176835
[1] https://github.com/nix-community/poetry2nix
Struggle is a good way to put it! I feel I hit one of Nix's pain points here: packaging software whose dependencies are largely missing from Nixpkgs. On top of that, it was a Python app, and the state of Python packaging is quite a mess.
I also feel it Nix was the right choice. My journey was rather harsh, but I do believe in its approach.
I'm dealing with an app that is breaking every time I try to upgrade a few-years-old version of Node, a version that is no longer on nixpkgs. Right now I just want something that works; I didn't sufficiently budget for ongoing maintenance as the whole site's behind a login.
So in its own way, Nix and Nixpkgs do serve the purpose of software preservation, as long as you have the full commit history for Nixpkgs.
Preservation doesn't imply maintenance however. It's fair for Nixpkgs to delete packages that are no longer supported, as that's a burden on the limited number of maintainers.
By recreating the package and module in my own Flake, I've taken on responsibility for maintaining it myself, and not adding any work to the Nixpkgs maintainers.
NixOS modules in particular aren't easy to extend, so I ended up copying it entirely. And to be honest, the thought of using an old version of Nixpkgs didn't cross my mind while setting up syncserver. Hopefully it's easier to maintain with poetry2nix now that I've got the package working.
Note : You'll need to disable 2fa first on your account before you can delete the data.
I see there are bookmark sync extensions, but only bookmarks (and I didn't check if those extensions allow self hosting).
I suppose you could always run Firefox portable from a location that was Dropbox/Nextcloud/syncthing/whatever synced. Just don't run two instances at once, or the SQLite DBs will have a bad time?
I do something to that effect. However, it does not come without problems. Running parallel instances is one of them... Also, cross platform is a problem.
https://en.wikipedia.org/wiki/Xmarks_Sync
It does not really solve your problem for browser-history/credentials etc. But as long as you use a client that you verified you can be kinda sure the data is E2E encrypted and can't be read by Mozilla.
Also on a side note: To this day the weave protocol is one of the more (needlessly) complex protocols I ever implemented and I'm still not sure what problems some of the design decisions solve...
[1] github.com/mikescher/firefox-sync-client
There's also a big list of different projects here: https://github.com/awesome-selfhosted/awesome-selfhosted#boo...
[0] https://www.xbrowsersync.org/ [1] https://raindrop.io/
it syncs to the webdav server on my synology but there's also the option to sync it using decsync (which is sort of like a local webdav server for each device) and some other sync service like syncthing or dropbox to sync the files.
floccus has an android app or it can also be installed as a normal extension with the kiwi browser.
i tried xbrowsersync first but i had some issue when i used it with vivaldi where a new copy of my bookmarks showed up in the "deleted bookmarks" section every time a sync happened, and i couldn't see any way of fixing that either which is why i went with floccus in the end
I run a simple little docker container (found the image on github)[1] to host the webdav server myself, since I don't run Nextcloud or anything else that exposes webdav. It works quite well for me.
[1]: https://github.com/marlluslustosa/Floccus-WebDavDocker
I do hope that syncstorage-rs will become usable eventually and hopefully improve performance.
Note: contrary to your post, cookies are not synced.
[1]: https://hub.docker.com/r/mozilla/syncserver
Their docs[0] make it seem like little would be gained from a privacy/security perspective as it seems pretty secure/private (at least to me).
[0] https://support.mozilla.org/en-US/kb/how-firefox-sync-keeps-...
But honestly, while encryption theoretically can make any data "safe" to hand to a 3rd party, it's just good "data hygiene" to keep it under your own control. If someone steals the Firefox sync database now, and some part of the encryption scheme is later broken by e.g. quantum computers, the thieves could retroactively decrypt your sync account data.
And there's also the question of metadata - when does your Firefox send data to sync, and how much? Are you sure there's nothing to glean from that?
Since cookies and sensitive site data aren't a part of syncing, I guess I could see this being pertinent to your point of data being used to identify you.
That being said, if I were a malicious actor, this sounds like a really low reward if you manage to compromise/crack encrypted Firefox Sync data.
Ultimately, I agree with your point of reducing information exposure by self-hosting. My line of thought was more wondering what arguments there were on why this may or may not be worth setting up.
A more pedestrian failure mode that occurred to me would be a simple bug, or a configuration format change causing the URL of my private sync server to be ignored. If using Mozilla auth, this would cause my data to simply be silently uploaded to Mozilla's sync server -- and I'd be unlikely to find out about it until much later. If not, it would likely cause an authentication error instead.
To Mozilla: fire your overpaid activist CEO Mitchell Baker and use the resulting funds to hire (back) the developers she got rid of, clean up the mess, get rid of the social justice nonsense and take back your place as a browser development organisation instead of a 'colours of change' peddler.
TLDR: If you're OK with piggybacking on them for auth, it's straightforward, easy and lightweight. If you want to be fully self-sufficient and leak no data you need to either implement a replacement for fxa (seriously this would be appreciated and maybe less effort if you're coming in fresh) or host that whole machinery of microservices - this is where the head-scratching starts and you need some dedication for it.
I encourage other people to do it, and do go to whichever is more appropriate of the Matrix room or the GitHub Issues and engage when you hit things that are out of date, unclear, or broken.
[0]: https://news.ycombinator.com/item?id=30315816
[1]: https://news.ycombinator.com/item?id=30727935
But other than that, it's an interesting design choice.
I don't really understand how Mozilla continues to function at all as an org.
Con: no „real“ Firefox Sync - Pro: no „real“ Firefox Sync - it works on any device with any browser, data is self-hosted
I'd like to sync just bookmarks without joining the "Firefox ecosystem" or any other ecosystem.
Is there some bookmark sync extension with a self hosted sync solution or that will just sync via a (service similar to) Dropbox folder?
Edit: syncing via a git repo would be fine for example :)
So self hosting isn't as necessary.
This makes tons of sense to me with extensions and the other profile data, but not that.
I stopped doing that after some time, it seemed too futile. Errors are hard to debug and you're on your own, plus I was not using it for passwords or CC, so it just wasn't worth it.
Shameless plug: https://vasvir.wordpress.com/2021/03/30/firefox-sync-server-...
Simply because the URL of Firefox Sync hosting is hardcoded into the Firefox iOS app.
Hence thwarted my zeal to self-host Firefox Sync.
Heck, there is NOTHING configurable about Firefox iOS, not even an URL config:about.
But that press five times on the version menu item does not reveal anything useful from a self-hosting POV.