Bromite: Recent Bromite makes calls to www.gstatic.com and www.googleapis.com FQDN

Created on 26 Oct 2019  路  15Comments  路  Source: bromite/bromite

Bromite version

Versions:

  • 78.0.3904.63
  • 77.0.3865.104

Arch: arm64

Android versions:

  • LOS 16 (Android 9)
  • /e/ 0.7-o-2019102228017 (Android 8)

Device model: dumpling

Is this bug about the SystemWebView?
No

Is the bug reproducible with latest version?
Yes

Can the bug be reproduced with corresponding Chromium version?

Please pick the same version of Chromium as Bromite from here: https://github.com/bromite/chromium/releases
If the bug is reproducible then it might be a configuration issue or an upstream bug. Upstream bugs can be reported on the Chromium issue tracker and do not forget to read Chromium project bug reporting guidelines first.

Yes, but won't complain chrome targeting google APIs

Is the bug a crash?

No

Describe the bug

Snif network traffic from the acces point on the device where Bromite is installed (by using Wireshark), and notice calls to

are made

To Reproduce

Start Wireshark on Bromite access point.

Just run Bromite for the first time (or after cleaning all Storage cache) without browsing wait a minute.

Read Wireshark traces statistics and notice calls to Google FQDN

Expected behavior

No call to any Google FQDN.

Screenshots

N/A

* Additional information *

By using Bromite 76.0.03089.129version did not notice calls to www.gstatic.com

But trace of www.googleapis.com are still present.

help wanted

All 15 comments

I suggest inspecting the content of such requests, so that you can tell exactly what the browser is trying to do. See https://wiki.wireshark.org/TLS or https://danq.me/2018/08/07/android-emulator-https-intercept/

Are there requests or only name resolutions?

Yes, but won't complain chrome targeting google APIs

That is not Chrome, it's Chromium.

@Eloston I think the www.gstatic.com resolution might come from probing happening here: https://chromium.googlesource.com/chromium/src/+/HEAD/net/dns/dns_transaction.cc#823

The one about googleapis.com is most probably related to https://github.com/Eloston/ungoogled-chromium/issues/520 and I am currently giving a try again to removing the Gaia code from compilation, although I expect little success.

I see that in ungoogled-chromium you have binary pruning and domain substitution (https://github.com/Eloston/ungoogled-chromium/blob/5f81f45764e5fc28a19fe45bd44d08ed6d5c1680/docs/design.md#source-file-processors), that is a neat feature and does cover these problems found here.

I suggest inspecting the content of such requests, so that you can tell exactly what the browser is trying to do. See https://wiki.wireshark.org/TLS or https://danq.me/2018/08/07/android-emulator-https-intercept/

Are there requests or only name resolutions?

Both, we can notice TCP & UDP(53) calls to gstatic & googleapis.

Yes, but won't complain chrome targeting google APIs

That is not Chrome, it's Chromium.

@csagan5

I think the www.gstatic.com resolution might come from probing happening here: https://chromium.googlesource.com/chromium/src/+/HEAD/net/dns/dns_transaction.cc#823

That sounds reasonable given what is stated in the OP's report, but I don't know where else www.gstatic.com is being used.

The one about googleapis.com is most probably related to Eloston/ungoogled-chromium#520 and I am currently giving a try again to removing the Gaia code from compilation, although I expect little success.

That is a better longer-term solution, since any new changes to Gaia code will break the build, thus requiring the patch to be updated. An easier short-term solution is to remove the code that initiates requests to googleapis.com (but this approach will not catch new code that makes requests to googleapis.com).

I see that in ungoogled-chromium you have binary pruning and domain substitution (https://github.com/Eloston/ungoogled-chromium/blob/5f81f45764e5fc28a19fe45bd44d08ed6d5c1680/docs/design.md#source-file-processors), that is a neat feature and does cover these problems found here.

Would https://github.com/ungoogled-software/ungoogled-chromium-android be able to help you?

we

@frankpreel I assume you mean the /e/ foundation; I am not pleased of how you removed all references to Bromite in the browser you ship, but still ask here about fixing the bugs. This is at the very least ethically questionable.

Would https://github.com/ungoogled-software/ungoogled-chromium-android be able to help you?

@Eloston thanks for your reply; I was aware of @wchen342 efforts but did not know it was officially part of ungoogled-software, nice developments there.

I checked the build script, I think I am going to try using the domain substitution script from the ungoogled-chromium repository, merging from/into ungoogled-chromium-android seems like not something easy to accomplish at this time.

we

@frankpreel I assume you mean the /e/ foundation; I am not pleased of how you removed all references to Bromite in the browser you ship, but still ask here about fixing the bugs. This is at the very least ethically questionable.

Why are you writing this?
Look:

image

That's a fork, that's FLOSS, what would you expect more?

@csagan5 I use the same python script from the main repo for pruning and substitution, just added two additional lists. You can just grab the two lists if you want.

Why are you writing this?

@leag1234 you did not mention your affiliation, and now you even changed your Github username. A normal interaction would have been to cross-link with the bug that was reported to you, if any. It feels like you are expecting some kind of OEM support now, but let me say it clearly: you have rebranded Bromite, this is not considered nice behaviour in the FLOSS community. Your credits also claim that your fork adds all those features.

Good morning!

Why are you writing this?

@leag1234 you did not mention your affiliation,
and now you even changed your Github username.

I created the GitHub account to answer this thread. Didn't rename anything.
Where is the issue?

Actually I don't have any problem fully disclosing my affiliation: I'm Ga毛l, /e/ project founder (https://e.foundation). We already exchanged by email in the past. Do you remember?

A normal interaction would have been to cross-link with the bug that was reported to you, if any.

If we missed something in the process, I apoligize...

The fact is that we did some internal tests with Wireshark on our latest builds and detected some connexions between our Bromite fork and some Google servers.

So we tried to figure out about why this happened, and first we thought the reason was how we were building the browser. So we compared with Bromite builds, but we discovered that you have the same issue. So Frank reported this to you, on my suggestion.

It feels like you are expecting some kind of OEM support now,

Not at all. You already told me in the past wouldn't help in any way, and that's the reason we are building ourselves.

So we are kindly reporting this issue, as a contribution, for the benefit of all. That's FLOSS.

Would you have preferred that we silently fix it for /e/'s own profit only?

but let me say it clearly: you have rebranded Bromite, this is not considered nice behaviour in >the FLOSS community. Your credits also claim that your fork adds all those features.

  • Regarding your "rebranding" claim: you should actually be happy that we don't call "Bromite" a fork of Bromite, because it's not your build, it's not Bromite as you distribute it. We modify some things and instinctively, I find it fair not letting people think they are using Bromite if it's not Bromite. The same way that it wouldn't be fair that you call Bromite "Chromium" because with the ungoogling patches it's no more exactly Chromium. As a side note, your attitude interesting because 20 years ago, I started a Linux distro, which was a fork of Red Hat. And Red Hat did the exact opposite as you: they contacted me in a friendly manner but asked me NOT using Red Hat name or let people think they would be using Red Hat because it was not a Red Hat anymore. It was a great lesson. Very smart indeed.

  • Our behaviour, as FLOSS users, is lead by FLOSS licensing terms. People who disagree with this are proprietary minded. If you find anything in licenses that prevent anyone to fork a FLOSS project and change a project name, please tell me. Actually, my personal view is that FLOSS licensing terms should probably require that forks don't use the same name as the initial project.

  • Once again we clearly state that the browser we ship with /e/ OS is a fork of Chromium/Bromite. And you could this as a fair attitude since there is not any rule that forces us to do so. However, I understand your point about the so-called "claims". I agree that the way it is written can be misleading. We will improve this in our next builds.

I created the GitHub account to answer this thread. Didn't rename anything.
Where is the issue?

I thought the original poster had renamed the account, now I see that you replied on behalf of @frankpreel

So we are kindly reporting this issue, as a contribution, for the benefit of all. That's FLOSS.

Would you have preferred that we silently fix it for /e/'s own profit only?

GPL license forces anyone to release the source (thus the patches) when someone distributes the binary form. It would be hard to enforce it here because of all the licenses that apply to Chromium different sub-projects, but theoretically speaking: no, you cannot do that, you would be in violation of the license already (which is more akin to a fair agreement between parts in this case).

  • And Red Hat did the exact opposite as you: they contacted me in a friendly manner but asked me NOT using Red Hat name or let people think they would be using Red Hat because it was not a Red Hat anymore.

I would have the done the same; I am not asking you to call it Bromite.

My complaint is that the /e/ browser is not adding anything of its own, yet it seems to do so and it's very hard to get back to Bromite if you are an user.

Are you following FLOSS principles? Yes, the bare minimum.
Are you perhaps "leeching" on open source? Perhaps...but I will have to live with this unsolvable doubt for the time being.

Once again, I am not saying that there is any legal violation, I was talking about the ethical aspect. I hope you can agree that the rule of law and ethics might differ by some little bits.

We already exchanged by email in the past. Do you remember?

Yes.

  • I agree that the way it is written can be misleading. We will improve this in our next builds.

Glad to hear so.

I created the GitHub account to answer this thread. Didn't rename anything.
Where is the issue?

I thought the original poster had renamed the account, now I see that you replied on behalf of @frankpreel

Not at all.

So we are kindly reporting this issue, as a contribution, for the benefit of all. That's FLOSS.
Would you have preferred that we silently fix it for /e/'s own profit only?

GPL license forces anyone to release the source (thus the patches) when someone distributes the binary form. It would be hard to enforce it here because of all the licenses that apply to Chromium different sub-projects, but theoretically speaking: no, you cannot do that, you would be in violation of the license already (which is more akin to a fair agreement between parts in this case).

Thank you for the lesson but actually I'm quite aware of FOSS licenses.

By Silently fixing it, I didn't mean releasing builds without sources. I meant fixing on our side without commiting upstream or notifying.

  • And Red Hat did the exact opposite as you: they contacted me in a friendly manner but asked me NOT using Red Hat name or let people think they would be using Red Hat because it was not a Red Hat anymore.

I would have the done the same; I am not asking you to call it Bromite.

My complaint is that the /e/ browser is not adding anything of its own, yet it seems to do so and it's very hard to get back to Bromite if you are an user.

Yes we are adding different settings, different search engines etc. It's not Bromite anymore.

Are you following FLOSS principles? Yes, the bare minimum.

I've not any problem with the bare minimum if it was the case, but it's not the case.

Are you perhaps "leeching" on open source? Perhaps...but I will have to live with this unsolvable doubt for the time being.

I think your problem is that you are considering that if /e/ is not actively contributing to the Bromite project to add features, it should only receive some disdain from the pure people like you who consider FLOSS as a political thing, and obviously consider themselves as representative of the Free Software community. However, this big ecosystem is made of different people, with different approaches, who are doing different things. In our case, assembling Free Software components into something consistent that can be used by the largest possible number of users, and bring them to FLOSS is also something important for FLOSS. Unless you think that FLOSS should be only for a small elite of people who know.

Once again, I am not saying that there is any legal violation, I was talking about the ethical aspect. I hope you can agree that the rule of law and ethics might differ by some little bits.

I'm not aware of any consensus regarding your so called "rules of ethics". However, I think that we are acting in a fair way:
1- I contacted you at the begining to explore how we could cooperate or co-brand a specific build of Bromite, but you declined.
2- Therefore, we did the job to rebuild for our own puprose, we added specific configuration and settings, we removed the Bromite name for the main build and we added a statement in "About" that makes it super clear that we are releasing a fork of Bromite/Chromium.
3- our codebase if fully available at https://gitlab.e.foundation/e/apps/browser and clearly states that we are doing a fork of Bromite/Chromium. We even left all the to explain what Bromite is, links to donation etc. https://gitlab.e.foundation/e/apps/browser

We already exchanged by email in the past. Do you remember?

Yes.

  • I agree that the way it is written can be misleading. We will improve this in our next builds.

Glad to hear so.

@leag1234 a fork which re-brands an open source project without any other change is not fair to such open source project; of course this is simply my opinion but I stand behind it.

I contacted you at the beginning to explore how we could cooperate or co-brand a specific build of Bromite, but you declined.

I do not have to, nor I have to like the re-branding that you did.

Let's not discuss this any further because it's already off-topic here; thanks for your contribution, the issue will be fixed in next release. Please open a new issue after new release if this is not the case.

@leag1234 a fork which re-brands an open source project without any other change is not fair to such open source project; of course this is simply my opinion but I stand behind it.

I contacted you at the beginning to explore how we could cooperate or co-brand a specific build of Bromite, but you declined.

I do not have to, nor I have to like the re-branding that you did.

We're not doing a rebrand since we're modifying it, like explained above.

Let's not discuss this any further because it's already off-topic here; thanks for your contribution, the issue will be fixed in next release. Please open a new issue after new release if this is not the case.

Sure, we are off-topic.

@csagan5 , have this issue been solved . If yes , can you link me to the relevant patches which fixes it ?

@sooorajjj the current version of the patch is https://github.com/bromite/bromite/blob/master/build/patches/Automated-domain-substitution.patch

It is included for completeness but it is better to look at the ungoogled-chromium python script instead.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

csagan5 picture csagan5  路  32Comments

Eddi2015 picture Eddi2015  路  26Comments

randomshell picture randomshell  路  19Comments

spinoza-dat picture spinoza-dat  路  20Comments

lowtrucks picture lowtrucks  路  48Comments