Chromium - google will limit access to private API (no sync...)

[jirib]

Google will limit[1] access to private API used by Chrome but used also by other Chromium-based browsers. This will impact sync etc. Maybe this should be visible in chromium packaging - eg. *.msg file ?

Unfortunatelly Google chrome uses restricted in void-packages for licensing reasons.

[1] https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

[pbui]

How about the following?

On March 15, 2021, Google will be limiting access to their private Chrome APIs:

    https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

This means that after this date, chromium users will no longer be able to take
advantage of features such as Google account sync (including bookmarks), spell
checking, translation, and safe browsing.

If you wish to utilize a chromium-based browser with those features, you will
need to build and install the restricted google-chrome package.

[ericonr]

This means that after this date, chromium users will no longer be able to take
advantage of features such as Google account sync (including bookmarks), spell
checking, translation, and safe browsing. These features will only be available with the restricted
google-chrome package.

[pullmoll]

We should probably remove the google-api keys from our browsers then. This is not only chromium, but also firefox, firefox-esr, and thunderbird. Or even more? Icecat does not have or use api keys.

[aeadio]

Perhaps even drop the chromium package.

The Chromium core browser is still fully functional. This just forbids access to premium Google features like built-in full-page translate, and profile sync across devices / platforms.

I think it's absurdly reactionary to consider removing the browser or pushing forks on Void's users that (1) may have less competent maintainers behind them, (2) may lag behind in security updates and (3) are going to lack those same features anyway.

Some other distros have taken the opportunity to make a political statement against Google's actions here, and that's admirable and all -- Google absolutely is pulling the rug out from legitimate users here -- but the scope of impact is a lot smaller than is being suggested in some heated Internet conversations, and a distro's package repository is no place to take a political stance at the expense of users.

Besides, we have at least three other browsers that still have fully functional sync -- Firefox, Vivaldi (restricted) and Google Chrome (restricted). The userbase can make an informed decision about which browser they want to select based on which features they offer in their Linux version. Chromium is now just a slightly less featureful browser.

[pbui]

After some discussion on IRC, I think the current position is to continue shipping the normal Chromium browser (but probably without the API keys in a future release), rather than any other fork.

That said, if other Linux distributions abandon Chromium, it may become very difficult to maintain the package. While I have been updating Chromium for sometime (mainly because noone else wanted to... at one point we went three months without any updates), most of the patch work is taken from either Arch Linux [1], Gentoo [2], or Fedora [3] (the package requires a lot patches to even build properly, let alone support musl and architectures such as PPC). That is, I often look to those distributions to figure out which patches are needed and then adjust them to our package. This is non-trivial and often times tedious work which I am not prepared to do on my own. I have neither the time or expertise to follow upstream Chromium development to figure out what actually needs to be patched or modified for each release and thus rely on the work of other Chromium packagers (from other distributions).

Because I plan on continuing to use Chromium despite the loss of these features, however, I will do my best to update the normal Chromium package (unless Void decides on another direction or someone else steps up to maintain it).

[1] https://github.com/archlinux/svntogit-packages/tree/packages/chromium/trunk
[2] https://github.com/stha09/chromium-patches
[3] https://src.fedoraproject.org/rpms/chromium/tree/master

[jirib]

BTW, has anybody written how to build automatically a package (eg. google-chrome) in cloned void-packages repo when a package in origin changes? I'm not fully educated but IMO this should be way to go:

• automatically sync fork (scheduled time ?)
• check if pulled commits there's a package of our interest
• modify void-packages CI scripts to build only our package of interest

But more detailed howto would be helpful. Thx.

[Gottox]

I may be alone with this opinion, but I consider this a feature.

[ericonr]

@jirib https://github.com/the-maldridge/xbps-mini-builder

[jirib]

@jirib https://github.com/the-maldridge/xbps-mini-builder

I made something similar for myself, but my question was more about exploiting github.com and CI to build it for me automatically, ie. not to build it on my workstation.

#!/bin/bash
set -x
set -o pipefail
set -eu

SRCDIR=$HOME/src/github.com/void-linux/void-packages
PKGS="google-chrome msttcorefonts"

cd ${SRCDIR}

commit=$(git log --pretty=format:"%H%n" -1)
git pull >/dev/null 2>&1
changes=$(git log --name-only --pretty= ${commit}..HEAD)

# main
if ! grep -q '^XBPS_ALLOW_RESTRICTED=yes$' etc/conf; then
    echo 'XBPS_ALLOW_RESTRICTED=yes' >> etc/conf
fi

for pkg in ${PKGS}; do
    if ! xbps-query ${pkg} >/dev/null; then
        ./xbps-src pkg ${pkg}
        xi -y ${pkg} # uses sudo
    fi
done

if [[ -n ${changes} ]]; then
    for pkg in ${PKGS}; do
        egrep -q "srcpkgs/${pkg}" <<< "${changes}" && \
            ./xbps-src pkg ${pkg} || true
    done    
else
    exit 0
fi

[ericonr]

I made something similar for myself, but my question was more about exploiting github.com and CI to build it for me automatically, ie. not to build it on my workstation.

You'd have to figure out how to export artifacts. I'd assume it's possible, but I have no idea how to implement it.

Regarding this issue, the course of action has been decided. The keys will be removed in one of the chromium updates during this month or when the deadline is reached. We have already added an INSTALL.msg as well.

Thanks for reaching out about this and leading to a concrete measure, @jirib