Investigate showing update notification

[csagan5]

Investigate whether it's feasible to use the update icon with some simple update mechanism (like the adblock filters do).

[csagan5]

Some people do it with Tasker: https://www.reddit.com/r/tasker/comments/iduriz/bromite_updater/

[uazo]

what about reactivating omaha?

here https://source.chromium.org/chromium/chromium/src/+/master:chrome/android/java/src/org/chromium/chrome/browser/omaha/RequestGenerator.java;l=35 the request and here https://source.chromium.org/chromium/chromium/src/+/master:chrome/android/java/src/org/chromium/chrome/browser/omaha/ResponseParser.java parsing the response

in android it seems the necessary ui is already present

[uazo]

I guess you already know, but here's the patch ready to use

https://github.com/ungoogled-software/ungoogled-chromium-android/blob/master/patches/ungoogled-chromium-android/Enable-update-notification.patch

or maybe I misunderstood what you are asking?

[csagan5]

what about reactivating Omaha?

Yes, that was my plan. And point it to the GitHub releases.

I guess you already know, but here's the patch ready to use

No, I did not know. This could be usable, but I wanted to use the same mechanism used for the AdBlock filters: a check on Last-Modified header time of the download URL.

This is how it would work:

• on start check if there is a PREF_LAST_TIME_UPDATE_NOTIFICATION_KEY timestamp stored in preferences (like in the patch of ungoogled-chromium); if not present then set it to the build time
• instead of the UPDATE_VERSION_URL it would contact directly https://fdroid.bromite.org/latest/bromite_arm64.apk or https://fdroid.bromite.org/latest/bromite_arm.apk (depending on architecture)
• as it happens for the AdBlock filters, the first request is just a HEAD request
• parse Last-Modified from the HEAD request and compare to PREF_LAST_TIME_UPDATE_NOTIFICATION_KEY; if newer then proceed with GET request

The logic above pretty much all exists for the current AdBlock filters patch.

If you are interested you could port the patch; if you find the logic above too complicated I can add it later myself. We will also need a mechanism to disable the auto-updates, and #691 becomes even more important (we should not perform update checks before that exists and is accepted; ideally we would even put a checkbox there for people to disable update checks from the get-go).

[uazo]

if you find the logic above too complicated

no problem

If you are interested you could port the patch;

I don't know, I have to take a closer look. that patch is all java side, I would be more interested in reactivating the native, because it may be necessary to reactivate the component_update, which i think are then used for #244

EDIT:
so I was wrong, there is nothing native about it.
or rather, there is something, but it is related to windows (and apple) and among other things they communicate via dcom (at least in windows). Nothing usable directly.

and I checked, the component_updater has nothing to do with it (here the registration of components https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/component_updater/registration.cc;l=86;bpv=0;bpt=1).

so two possibilities, either use that patch, or duplicate the adblock logic

[uazo]

@csagan5 i am working on this now. the idea is to use as a suffix TARGET_CPU taken from the gn args, but I can't find
https://fdroid.bromite.org/latest/bromite_x64.apk
could you activate that too?

[csagan5]

Fixed in 94.0.4606.94; it will be disabled by default for the time being.

[csagan5]

@uazo I am thinking that it would be best to enable the auto-update by default; I am generally against any update functionality enabled by default but I am thinking that it would be beneficial for the average user and right now it is practically impossible to discover this feature.

When we implement #691 we could let the user toggle this on/off there on the first run welcome screen (and toggle also adblock filters updates, which is currently enabled by default and does not ask for permission: directly downloads the new filters).

From privacy perspective it is still the same liability as the filters: GitHub collecting IP address and user agent (nothing else); this is already covered in https://www.bromite.org/privacy

@uazo what do you think?

[uazo]

enable the auto-update by default

fully agree.
I just checked the installation of bromite on my friend's device and it was stopped at 92 due to f-droid not notifying the update.

When we implement #691

yes, next step, I am looking - in the free time of the free time :) - for which way that costs less to develop and maintain.

From privacy perspective it is still the same liability as the filters

but aren't there really privacy friendly proxy services that we can use for these things?

[csagan5]

enable the auto-update by default

fully agree. I just checked the installation of bromite on my friend's device and it was stopped at 92 due to f-droid not notifying the update.

I will enable it on next release.

When we implement #691

yes, next step, I am looking - in the free time of the free time :) - for which way that costs less to develop and maintain.

No worries; I might also try, but cannot say when, feel free to assign it to yourself if/when you start.
It should be theoretically easy to enable this because the existing welcome screen is usable for the purpose.

From privacy perspective it is still the same liability as the filters

but aren't there really privacy friendly proxy services that we can use for these things?

It is unnecessary: the proxy can also gather the same information, and most proxies/VPNs are bad actors because they sell this information. The footprint is small (IP address + headers), and since there are no cookies I don't think that the information can be used for anything nefarious; I have read their privacy policy multiple times, they would only be able to tell that this IP connected at this time with this user agent. Ultimately the only reasonable thing to do is tell users to go read such policy in the welcome screen, so they make a conscious choice about what interactions with GitHub servers are enabled or not.

I would be more concerned about vulnerable users in hostile countries where a "ping" to GitHub can be seen as something subversive if that country has blocked GitHub, but this should be addressed by #691 and anyways we advise in README that such users shall not use Bromite.

[uazo]

It is unnecessary: the proxy can also gather the same information, and most proxies/VPNs are bad actors because they sell this information.

look what I found.
(source https://developer.chrome.com/blog/privacy-sandbox-update-2021-jan/)

[csagan5]

(source https://developer.chrome.com/blog/privacy-sandbox-update-2021-jan/)

This post does not link to that repository, how is it a source for that?

look what I found.

It is snake oil. It contains two proposals:

Near-path NAT
This proposal aims to solve this by allowing groups of users to send their traffic through the same server

You can stop reading there. It needs trust on a server; the browser has no authority to trust a server (the near-path NAT server) over another (GitHub), thus delegates the user to choose. That is because the browser is an user agent.

Willful IP Blindness
We propose introducing a signed attestation (perhaps in the form of an HTTP header) that advertises the fact that a server masks IP addresses and other identifying network information from the application layer of the services that it hosts.

Again this requires trusting a certain server over another, and the browser has no authority on that.

[uazo]

This post does not link to that repository, how is it a source for that?

happened by chance here, one of the links in the Chrome Privacy Sandbox section

Again this requires trusting a certain server over another

Sure, you are right

[csagan5]

This post does not link to that repository, how is it a source for that?

happened by chance here, one of the links in the Chrome Privacy Sandbox section

Do they link to this repository? https://github.com/bslassey/ip-blindness I cannot find the link.

[uazo]

I cannot find the link.

wow, yes it was there, but now it's gone ...

[uazo]

ah, no, it's here

[csagan5]

Yes, so it is a Google-backed proposal and it has the problems I outlined before. To my eyes this is still not a serious effort at providing any privacy to the user.