This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Plans to introduce Chrome Sync (settings, extensions, bookmarks) functionality? #667
Comments
|
This is where altnerative services come in. For bookmarks, you can use Floccus with a nextcloud instance or provider, or xBrowserSync. For passwords, you can sync a KeePassXC database using the nextcloud client along with the browser extension. As for syncing extensions, history, and settings... Yeah I got nothing there at the moment. |
|
It is possible to do this, but it won't be easy. The syncing code in Chromium is deeply tied with Google-specific services and specifications. We would need to define how we would want this syncing to work (as you implied at the end), and then investigate what we would need to do to implement it in the Chromium code. It will a large undertaking, to say the least. If you don't use all three systems at the same time, maybe you could consider an external syncing system that can synchronize the entire profile directory? |
|
I don't mind using Resilio or Syncthing to sync the entire profile. Which file/folder should I sync? Using Mac and Windows 10. |
|
I'm not entirely sure if the profile directories will be compatible under such platforms, but you'll need to synchronise the user data directory. The path to the currently-used profile can be found under |
|
I tried out Resilio Sync for a couple days, and although it works most of the times, there are a couple key points which are definitely worsening the issue instead of fixing it:
Apart from that, I suppose the solution works as a temporary bandaid. However, after navigating the initial setup (and following mess), and the problem-filled days after that, I won't be likely to try it again. |
|
Yes, blindly applying a generic file-synchronization service to the profile directory is a bad idea. File synchronization services make assumptions about how the files are used that are not valid for a Chromium profile (as you experienced first-hand). For example, generic file sync assumptions about consistency and how to approach consistency do not work for Chromium profile files; the atomic changes (e.g. adding a new bookmark, adding a new website to the history) made to the Chromium profile may require changes across multiple files. If there is some way to translate the atomic changes to a format that conform to the assumptions of generic file synchronization services (e.g. DecSync, which assumes Syncthing), then it should be possible to use a generic file sync service to sync changes. However, this still isn't a trivial task... |
|
How about reverse-engineering google services api and keeping the changes in ungoogled chromium to a bare minimum, possibly only introducing a setting which points to a custom api server. This would require a separate project implementing the api and user can host their personal api themselves or possibly have a cheap encrypted hosting service available for anybody. This would definitely improve ungoogled chromium adoption while preserving all advantages of the stock chrome. There might be many urls needed but hopefully these share a common domain. By default as currently this domain would point to a non-existent site. As a bare minimum sync settings can be hidden as currently until user manually changes the domain in chrome://flags/, until the new api implementation will be production ready. I understand this will be another chromium feature to chase to keep up with api changes but it should not add any noticeable additional ongoing workload for ungoogled-chromium developers. |
|
@t00 Sounds like a fun idea. For ungoogled-chromium, I also think the changes can be manageable. The only downside with this approach is the time and effort required to reverse engineer and implement the server:
I won't have time to work on something like this, but I think it would be a nice feature to have. |
|
Could this new option perform local encryption prior to upload? We can haz privacy? |
|
Sorry, but I don't understand what's the problem. Chromium syncs with Google, therefore the API is open source. Why this project can't sync with Google like Chromium does? |
|
@midenok Sure the api client code is open source but the idea behind ungoogled chromium is not to use google services so instead a new open source api service needs to be implemented, identical in behaviour to the original google api, to allow sync without ties to google. |
|
That looks not very wise idea to me. It would be better to take good things from Google and don't take bad things. Having Google account probably is a no-go for this browser for users like me. Though I'm pretty happy with Slimjet (which syncs just fine). |
|
I'd say google having any kind of data about ourselves is a bad thing. And the solution @t00 gave would be a good one. Sort of how firefox does: |
|
I know this is an old thread but I just came across this, while searching for an option to sync (bookmarks, passwords, custom search engines, history) between Has anyone found a solution by Oct 2020? Thanks alot. |
|
Hey @TheJags, I'm actually working on this. |
|
Perhaps an interesting approach might be to integrate Mozilla's Firefox Sync into Chromium? As @jstkdng pointed out, Firefox sync server is completely open source, and you can run your own sync endpoint. Furthermore, the guts of the sync client behaviour has been split out into a set of Rust components called Firefox Application Services. This appears to handle all the heavy lifting of the low-level sync engine. The higher level manager behaviour is then implemented differently in Fenix (Firefox Android), Firefox iOS, and Desktop. So, theoretically, one could try hacking those components into Chromium. No idea how feasible such a feat might be. I've started looking at the Firefox code to understand their Sync stuff better, but I've not looked at the Chromium side at all. |
|
@samcday what's the difference between this and what I'm working on? yes, obviously Firefox Sync is already supported in Firefox. but we are talking about Chromium, so either way the thing needs to be implemented from scratch. also, implementing Firefox Sync would mean that you need to do it from Chromium's source code, which is worse, since you obviously can't move to mainstream Chrome or any other Chromium browser for that matter... while an extension would be more versatile, and more os-independent. I'm pretty sure Ungoogled Chromium maintainers are not interested in this, since at that point anyway you'd be developing a Chromium-based browser such as Brave or Opera, with your own custom homemade features, and not simply providing an "ungoogled" version of Chromium anymore. |
No idea, haven't seen what you're working on, there's no repos in that org you linked in your previous comment! :)
My point is that Firefox Sync already has what appear to be fairly portable clients written in Rust to handle all of the complexity of low level syncing. Put differently, I think the Mozilla folks have been thinking about and dealing with a large deployment of a browser data syncing service for a while, so the possibility of reusing most of that client + server logic seems appealing, at least to me. However I acknowledge the higher level manager / UI code will be bespoke and may not be able to reuse much of what already exists in either the Firefox or Chromium code.
Sure, this could be one way of doing it. I'm not sure an extension gets deep enough access into the guts of Chromium to achieve the kind of sync that native Chrome / Firefox Sync offer though. You might end up needing to write bridge glue in Chromium codebase to make such an extension possible?
Perhaps. I'm certainly curious what opinions said maintainers actually have on the matter! |
You make me sound like I don't know what I'm doing. I wouldn't have started nor even tried undertaking such a huge project if I already knew this wasn't possible, and obviously I checked and digged deeply before even considering the idea. What I'm trying to do is have both browsers sync to a server, by using an extension. The server provides a REST API including login/registration; the extension sends GET or POST requests signed with a JWT. Finally, all history is saved in a remote SQL database (SQLite for the moment, given that I wanted simplicity over complexity of setting up MySQL or Postgres). I don't really care if Firefox Sync can be modified in such a way that it'd be compatible with this, as I wanted this project to be a self-challenge, and also, I wanted to put in practice everything I know about database management, REST APIs and such. But I really struggle to understand your attitude towards me. I'm not here to hide anything, I'm not here to sell any product. You will obviously be able to both see the source code and download + self-host the thing all by yourself. Heck, even compile it if you want to. I'm not trying to prove I'm better than anyone, I'm just a dev hitting up and saying that there's actually someone working on this - which by the way is far more on-topic and very similar to what both the OP and other participants were talking about, suggesting things like xBrowserSync or Floccus, that are missing the history syncing feature. Even if the underlying structure is gonna be totally different, the experience for the end user will be comparable to using any of the said extensions: install it, connect to your server, automatically sync. Again, I'm not trying to convince you or anyone about anything. I just wanted to share something that might interest the ones who partecipated in this issue, as I started developing this exactly for the same reason. |
|
@mind-overflow your solution from what you described is implemented using extensions - there is not much relation to this issue of making Chromium inbuilt sync possible. @samcday suggests using a working and tested library written by Mozilla to sync with Mozilla sync server, also open sourced. All this means that only a thin bridge layer needs to be implemented and maintained for Ungoogled chromium, which would need to be hooked up in place of existing chromium sync code and translate structures expected by Chromium to these implemented in the Firefox Application Services. Such undertaking requires "only" considerable knowledge of Chromium codebase, as the Mozilla part is well documented and client-server compatible. It also means more patches for Chromium code are needed - Rust interop + build tools and new facade code to translate structures, all of it more fragile to Chromium changes (many times a day). It is hard to balance to be honest which solution is better - reverse engineering Chromium sync logic or swapping it for Mozilla - reverse engineering has a value of making all of Chromium codebase usable without additional dependencies on the client side while the Mozilla path will make a robust and tested sync most likely quicker to finish but harder to maintain. I am also interested in maintainers opinion on that |
|
https://github.com/brave/brave-browser has sync, is based on Chromium, and is open source, seeing how they bolt on their sync engine might also be a good starting point. Relevant PR: https://github.com/brave/brave-core/pull/5294/commits |
|
@jbalme wow, that's very interesting stuff! It appears that brave/go-sync is the code for the server endpoint that Brave v2 Sync uses. Some things I found interesting from a cursory glance:
|
|
I didn't read too far into the PR, mostly just the new UI. Nice to know they use upstream sync, should make it more maintainable. I just had a look at brave/go-sync and it appears that replacing DynamoDB with something else wouldn't be too difficult as they abstract datastore operations into a simple interface and the language in the README ("Currently we use dynamoDB as the datastore") implies they want to leave the possibility of migrating to/adding other backends open. |
|
Is there a favorite so far between floccus, xbrowsersync, or another? |
|
How about using Mozilla's own Firefox Sync endpoint? Ephiphany browser seems to do it. https://github.com/GNOME/epiphany/blob/master/lib/sync/README It has end to end encryption, so privacy is good and it just requires a Mozilla account, it would be much more convenient for the end-user (no need to manage your own sync server). The only thing is I don't know how it works from a legal standpoint. Can anyone just use Mozilla's API in their products? Ephiphany browser seems to get a pass. |
Considering that Mozilla is actively working on censoring the web, I would never purposefully use it - especially in a way they could easily rationalize blocking. |
|
I think being able to periodically sync my profile to a file would suffice for me. I could then use cloud services to sync that file between computers. Maybe an sq3 file or something. |
I think that it is a good middle point purpose |
|
I did not see any discussion of using the existing chrome/chromium self-hosted sync servers. There are fairly simple Python scripts available, e.g. https://github.com/trexx/chrome-sync-server or Google's own test server |
Notes on securityYou'll want to use a strong password hash function on the encryption password. MUCH stronger than what Google did. It should take several seconds to hash the password into an encryption key, which is then stored locally by the browser. Argon2 would be ideal but pbkdf2 with a very high number of rounds might be more practical because it is supported by browsers/openssl while Argon2 needs third party code (webasm or native implementation). The encryption key should then be used in AES256-GCM mode on the data blobs, along with a randomly generated 12-byte nonce. The data blob can be plain binary, JSON, MsgPack or other suitable format. Pseudo code for blob encryption and decryption: def encrypt(data: bytes, key: bytes[16]) -> bytes:
nonce = random.bytes(12)
encrypted = aes256gcm_encrypt(
message=data,
additional_data=b"",
nonce=nonce,
key=key,
)
return nonce + encrypted
def decrypt(ciphertext: bytes, key: bytes[16]) -> bytes:
nonce = ciphertext[:12]
# Raises an exception if a wrong key was used or if the ciphertext was modified in any way
data = aes256gcm_decrypt(
ciphertext=ciphertext[12:],
additional_data=b"",
nonce=nonce,
key=key,
)
return dataIf the profile data is broken into smaller blobs rather than one monolithic one, it may be useful to add an extra layer where the master key is used to encrypt a blob that only contains the key for all actual data blobs, where the secondary key is randomly generated at profile creation but then never modified. This allows changing the password without re-encrypting all data blobs. The reasoning for all that is lengthy but I can go into details if you don't take my word on that it is necessary and important to do it like this. |
I'm curious what your thoughts are on using self-hosted Firefox Synx with ungoogled-chromium. Thanks for the input. |
|
Not sure what exactly Firefox Synx (sic?) entails, but I need full Chrome sync, including settings, extensions and passwords. Cross-browser compatibility where possible is of course a plus (i.e. keep track of Firefox and Chrome extensions separately but share passwords and history between browsers). Self hosted is my choice even if reliable encryption is used (with Chrome you'd better be using a very long passphrase at least - the improved hashing would allow moderately long passwords to be secure). For now I am sticking with Google Chrome because of the lack of sync in others. Ended up here looking for solutions. Interestingly Android Firefox can sync passwords with Google, and thus with desktop Chrome too, so on phone I can use Firefox which is not practical on desktop. Offtopic: Eventually I'd prefer some fork like Ungoogled where privacy is a concern. Even using DuckDuckGo in Chrome the browser calls back to improving.duckduckgo.com every time I "switch to tab" without even searching anything. Advertising ids and all, it is completely intolerable. Firefox still lacks support for BLE and HDR, both of which are essential for me, so Chrome forks seem better. Re: encryption. Ping me if you need help with a Javascript implementation. I believe I have some existing code lying around that could be used. C++/openssl, Python and others should work pretty much similar to that pseudo code but the Javascript crypto api stores keys differently. |
How about Brave Sync v2? https://brave.com/sync-v2/#:~:text=to%20be%20more%20directly%20compatible%20with%20the%20Chromium%20sync%20system |
|
@raisehero Looks like they are just using Google's sync code, with some changes. Most notably the user cannot choose a passphrase but must use the randomly generated seed, and they set it to use Brave's servers instead of Google's. I would assume that including this feature and thus supporting this sync would be trivial in the ungoogled fork too. Since Brave makes their server code open source, you could run it self-hosted as well. Despite the E2E encryption quite a bit of (meta)data is still leaked to the server. |
|
That's the point, the ease of integration to ungoogled-chromium and any other Chromium fork. |
|
Any simple way it could just be configured to use a git server to sync such things - and so we could have diff-ing? |
|
@dm17 Due to encryption you would not get any useful diffs from git itself. The server is not supposed to know what you sync. I am hoping that someone makes a PR for the Brave sync integration. This bug has been open for years and I don't know if any of the developers or just random users are commenting here, but seeing some progress on this would be nice. |
I would qualify as a "random user" in this case :P But I think @wchen342 has the leverage you seek. |
|
Data is symmetrically encrypted with a secret, yes - you don't want your browsing data lying around somewhere untrusted in cleartext. |
Unless it is self-hosted. I thought self-hosting was the standard implementation of the proposed sync setup. Also, there do exist encrypted git archives. Perhaps it is worth gaining something from git... It would save us from the potential scenario of deleting everything and then syncing, right? |
|
I briefly looked around for a bit, and it seems there is no immediately good candidate for a sync solution. I personally think Nextcloud's REST API is the best bet but it needs to be tested. |
|
@wchen342 Did you not read the last few messages where Brave Sync was discussed? It is a complete solution already implemented on Chromium codebase. Is there something wrong with that, considering that the implementation itself actually seems quite nice, and maintains compatibility between Chromium forks? |
|
@Tronic There are a bunch of problems with Brave sync:
|
|
There actually are a lot of separate things that syncing needs to handle in Chromium, and thus I am not surprised that it touches so many files. You could start with the Google Chromium sync if you so much dislike Brave: both are the same, and it is not that long since Google removed the feature from Chromium, so that should not be impossible to port either. The server side implementation is far easier, and as stated, Brave already offers their implementation in open source. NextCloud does not even begin to solve the problem, where the difficulty is really within the client side, and depending either on a commercial service or self-hosting PHP crap does not look a good idea. I believe the Brave server code would work even if you used Google's sync code on the browser side, and it is written in Go, not in some slow bug-ridden script language. Regarding any "problems" with contacting Brave servers, the only thing you might need to worry about is bug reports if there are incompatibilities or if Brave actively blocks users of other browsers. There is no legal issue with someone contacting them, and nothing to do with this project anyway. In any case, if you insist on being incompatible, it is not hard to change the API just enough to make connections impossible. I would assume that Brave intends to keep their servers open to others, because that pretty much is the idea of browser sync. |
|
Okay, looks like the developers of this project are just blatantly going to ignore this. I am now switching to Brave because I cannot keep using a browser with such a crucial feature missing. |
I think a lot is going on these days... Even companies with billion dollar budgets can't deliver these days. So we gotta have the mentality - especially with projects we like - to just try to contribute if we can and then see the maintainer's thoughts on the contribution. |
|
While I understand this mindset. I'm sick to DEATH of the attitude everyone has in neglect how important it is to have that kind of syncing solution. I've spend hundreds of hours easily trying to match the "Just works" nature of Chrome Sync in vain and Brave is THE only browser to actually implement a keychain based solution. I'm sick of the blanket statement of "xbookmarksync' and "bitwarden". Those are all a PITA on their own accord and they always have given me misc problems that I don't want to have to deal with. Then everything is thrown out the window for history, and extensions. If it's officially acknowledged that it's important but at the moment it's on the back burner, that's enough for me. But coming from someone that has a nextcloud server, the password extensions (all of them) break for me all the time and Tusk for a database file to point to via WebDAV doesn't work on Ungoogled Chromium so I have to remember to manually add it later which is a HUGE pain plus I have to put in my super long master password every time I open the browser. It's not unreasonable to ask. It's one thing with all of the solutions being half baked, it's all the fighting I still have to get things synced between my phone, my personal PC and my work laptop that I have to side with Tronic on until everyone else leans towards the middle |
|
If everyone would be leaving hated coments for this issue instead of implementing the feature/behaviour they want, things aren't going to change. Just FYI. |
|
Are you saying that if someone makes a PR fixing this issue, the developers will be willing to merge it, rather than keep ignoring the issue? I guess you can then always fork the project and try to get distros to distribute your fork along with the zillion other Chromium forks that there are. Sure, yeah. Or you can just switch to Brave, and skip all those steps, and sync everything. Unsubscribing this issue, something I should have done a long ago, too, rather than just switching browsers. |
|
Yes we are saying that if someone is willing to work on the issue and can find a compromise between all the requirements that have been brought up in this thread, we would merge it. I don't know how you get to a mindset in which you feel entitled to get a feature at the cost of the free time of the developers and maintainers of a project. The open source community does not owe you anything, not features and not support. Our license clearly states that the software is provided as "AS IS". That we maintain the project anyways is just the believe in contributing to a greater good. Demanding features is not a great way to keep up that believe. |
|
Most people in this thread don't seem to be in the official ungoogled-chromium Matrix chat. I would suggest the following:
In terms of this solution affecting the other top chromium forks (ungoogled-chromium being the top chromium fork in my view) - this is the best thing to push on to that effect: #1395 |
|
I'd like to mention that even if the feature does not fit/align with ungoogled-chromium, there is ungoogled-software/contrib, which is a good target for such a feature. Other users may use particular features from there and possibly improve them. Win-win! |
manual steps and tips for syncingfor password import/export. on a new profile:
day-to-day work backup
notes: for sessions/history. use session buddy. bookmarks manual export/import is well known don't keep CSV passwords files, hard-delete them (not recycle-bin) as soon as you are done with them. you can keep bookmarks and session buddy backups in your Google drive. if this is too much, will work with any sync service (box/dropbox/etc...) |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
and others
Currently, one of the features that I use Chrome for is the cross-platform sync of browser-related items, such as extensions, settings, passwords, etc. In addition with user profiles, this feature is what makes Chrome indispensable: being able to separately manage profiles (and the related extensions, browser settings, etc.) without hassle makes my life a lot easier. Unfortunately, since the goal of ungoogled-chromium is to remove all instances of Google in the browser, this means that synchronization no longer functions.
I would have opened a feature request, but I'm not exactly sure what kind of solution to offer; in addition, owing to the lack of relevant issues/feature requests, it seems more like a personal use-case problem. In my case, I typically use three computers - one laptop, one desktop, and (occasionally) public machines (library, school lab, etc) - having to re-configure chrome after an install or on adding a new user profile is a hassle, and maintaining settings, extensions, and bookmarks (foregoing passwords and history) is very time-consuming.
With that in mind, I'd like to open a discussion on the implications of implementing this feature; specifically, for settings, extensions and history. (bookmarks and passwords are possible via third party services, and open tabs seems impossible.) Is it possible?
The text was updated successfully, but these errors were encountered: