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.

[rom4ster]

No i mean google chrome, the browser that I use on my android phone.

[pdf]

I think you've wandered into the wrong project @rom4ster - integrating with Google applications/services is an anti-goal of this project.

[rom4ster]

This project does not differ much from an unsigned in chromium browser. Optional integration with google services is exactly what this needs as it seems to want the user to be able to control their experience.

[dm17]

@pdf right, this project is about de-googling, not re-googling.

[networkException]

Optional integration with google services is exactly what this needs as it seems to want the user to be able to control their experience.

Yea uh that won't happen. In my opinion you should only be using this browser if you actually need something that doesn't connect anywhere by default, as mentioned above Firefox for example is a perfectly fine choice for anything else

[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?

[rom4ster]

A big consideration may be payments. Google pay for example is part of why I am trapped on chrome.

[dm17]

@rom4ster Google Pay doesn't really sound like a de-googled part of the chromium experience - is it? I wouldn't want its lack to hold back the majority of us who are not locked into Google Pay.

[rom4ster]

There are a strong amount of Android users in the world.

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

[rom4ster]

External syncing ignores mobile users. This will not be a good solution for those trapped on chrome with android phones.

[dm17]

@rom4ster Bromite and Vanadium are kind of the "ungoogled-chromium for Android". I don't think bending the knee to Chrome is what ungoogled-chromium should be doing.

[rom4ster]

yes but they are seperate and dont work together. If you simply want to have a worse experience, you can de google so many ways. The idea is to do the same things you love to do, and then de google.

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

[TheJags]

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 Ungoogled Chromium on Ubuntu Focal and Ungoogled Chromium Extensions on Android 10 (LineageOS 17.1)

Has anyone found a solution by Oct 2020? Thanks alot.

[mind-overflow]

Hey @TheJags, I'm actually working on this.
I've been working on a self-hosted server that allows you to sync browsing data between different browsers (even both Firefox & Chrome) since August, as I would've really liked something like that which, however, didn't exist.
Development has, however, stalled for the moment, as I'm getting busier everyday, having to study and work.
This does not mean that I'm abandoning the project, just that it might take a little longer to complete. I really can give no ETA, since I'll have to dig deep into Chrome & Firefox's databases structure and extensions API to make this all work good.
There is a GitHub organization already set up for this, however, all repos are currently private as they are still in experimental/alpha state. Just give it a quick check sometime, I'll try to remember to update the status here with another comment!

[wchen342]

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.
Encryption is a separate topic: it can be done locally and the server doesn't need to know anything about it. I don't think git is necessary unless your want your profile history but why? If you want to save bandwidth then just use delta-transfer and compression. Usually the profiles are just text databases.

[Tronic]

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

[wchen342]

@Tronic There are a bunch of problems with Brave sync:

1. It is not as easy to port it as it looks. The sync v2 PR is based on existing sync they have, which includes a lot of UI codes and other useless stuff here. If you have a look at the PR it spans 255 files, I won't call that maintainable. Beside the sync code is incrementally modified between versions which makes things even harder. This is a known problem with porting anything in Brave.
2. Brave generally does not allow anyone using their brand or server without permission. If the sync code has a configurable server for user (which it should), and someone (accidentally or not) point their address to Brave servers then there will be troubles for this project. I don't want to risk that.

[Tronic]

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.

@Eloston or @Ahrotahn care to weigh in?

[Tronic]

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.

[dm17]

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.

[AE720]

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

[PF4Public]

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.

[Tronic]

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.

[networkException]

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.

[dm17]

Most people in this thread don't seem to be in the official ungoogled-chromium Matrix chat. I would suggest the following:

1. Everyone who cares join the official ungoogled-chromium matrix chat ASAP
2. Schedule a time to have a discussion therein
3. Eloston gets veto power & grant a few top devs in this area decision power
4. Present the implementation you think is the most coherent for UG-Sync
5. Eloston & the devs discuss & decide the path forwards.

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

[PF4Public]

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!

[jpsoutlook]

sorry, I missed it but...is there an easier way just to sync the install files rather than having to manually install step by step on each device crx, store, extenstions windevien bookmarks...on LAN and I also I have winsvr2016. Literally just copying same files and going through the same process...its like having a Nvidia shieldx5 FML....

[dm17]

Not officially it seems, but officially it seems there shouldn't be a problem copy-pasting these files between chrom(e)ium profiles.

[NayamAmarshe]

#1896 (comment)
#1896 (comment)

I pretty much gave up and switched to Brave, It's a better solution imo. Native sync functionality, better privacy than Ungoogle Chromium (https://privacytests.org), works exactly like chromium and just great overall. If anyone is looking for sync and better privacy, I'd recommend switching to Brave if Ungoogled Chromium is looking like a hard choice.

[jstkdng]

yeah, just use whatever you want. I'd have used brave but you have to doxx yourself to redeem their token.

[jpsoutlook]

What if I do a clean install again on my server and just put all the files in a share and use short cuts on all my pc to the server install?

[NayamAmarshe]

What if I do a clean install again on my server and just put all the files in a share and use short cuts on all my pc to the server install?

Sync would be extremely slow in that case and you won't get anything on mobile.

[jpsoutlook]

I currently stream 90 gig lossless movies on plex to 5 Nvidia Shields like butter. May I ask what files or folder need to be synced for just browser plugin state, bookmarks and history?

[tomasz1986]

There are two files called literally Bookmarks and History located in the profile folder. When it comes to extensions though, the situation is quite convoluted and everything is scattered across multiple folders. You should probably look up information on how a Chrome profile folder is structured to find out which files and folders are relevant specifically, but there's also a chance that this may actually not be documented anywhere, and you will just have to experiment on your own.

Please keep in mind though that you will likely end up with conflicts and overwritten data if you try to use the browser on multiple devices simultaneously with a server-based sync set up like that.

[kendofriendo]

So, uh. How's this goin'.