Plans to introduce Chrome Sync (settings, extensions, bookmarks) functionality?

[dryshirt]

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?

[Tank-Missile]

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.

[Eloston]

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?

[diocletiann]

I don't mind using Resilio or Syncthing to sync the entire profile. Which file/folder should I sync? Using Mac and Windows 10.

[Eloston]

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 chrome://version under "Profile Path". The user data directory is the parent directory of the Profile Path.

[dryshirt]

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:

1. Update intervals: Whenever there is an update to the directory, Resilio Sync attempts to send the changes to all other peers. Paired with an unstable or slow network (like my school's, for example) - this quickly becomes tiresome. There is no way to manually adjust sync intervals in order to reduce bandwidth usage (not that I would anyways - with the frequency of changes that are made, syncing on any reasonable interval of time (>1min) isn't very useful due to the large amount of changes made)
2. File sync failure/corruption: If Chromium is opened and incoming changes are made, then after restarting the app and visiting the settings page you will be told settings have been corrupted, and that they have been reset to default. This is by far the largest issue: there is no built-in method to prevent the corruption from happening, and it can happen very easily. After it happens, the user is forced to reconfigure their settings - there is no failsafe to easily revert changes.
3. File versioning: Another problem occurs after some usage: if the sync service doesn't start itself reliably, then point 2 happens repeatedly. This doesn't really have anything to do with Chromium, but it's worth thinking about when recommending third-party services in order to synchronize files across two or more systems.

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.

[Eloston]

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

[t00]

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.

[Eloston]

@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 speculate that reverse-engineering based on the code alone could be difficult, especially for determining any stateful logic on the server-side.
• Also, we would need to create a solution for authentication (Maybe some secret token generated from the server that we add to the browser? Maybe reverse engineer sign-in logic to the custom server?)
• Creating a reliable and secure web service takes time to get right.

I won't have time to work on something like this, but I think it would be a nice feature to have.

[f4most]

Could this new option perform local encryption prior to upload?

We can haz privacy?

[midenok]

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?

[t00]

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

[midenok]

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

[jstkdng]

I'd say google having any kind of data about ourselves is a bad thing.
And we do take the good things google does, just look at this project, is chromium but without the stuff that gives google our data (bad thing) and just a nice browser with good performance.

And the solution @t00 gave would be a good one. Sort of how firefox does:
https://mozilla-services.readthedocs.io/en/latest/howtos/run-sync-1.5.html
But do it how nextcloud does, allowing users to setup their own server or being a provider for other people who can't setup a server, of course, encrypting everything server side.