On Tue, Apr 26, 2022 at 5:48 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote:

> 1. Enable Chrome's auto-detection of DNS-over-HTTPS. It ships as > disabled by default in Chrome currently, but it can be set to an > 'auto' mode that will prefer DoH if it can determine that the DNS > server supports it. > This breaks corporate VPNs very hard, so probably not.

> 2. Drop the user-agent extension. Ever since the advent of Chrome > v100, various sites (particularly those that rely on Cloudflare[2] > such as Gitlab.com) have been having difficulties when this is > enabled. As its utility is limited (mostly just for metrics purposes), > I think the easiest solution is to just remove it. > I'd like to keep this, and this seems like something where Cloudflare should be fixed to deal with it. :(

> 3. There's a KDE Plasma integration extension too, maintained by the > KDE upstream. Do we want to install that by default as well? > Yes, we should!

On Tue, Apr 26, 2022 at 6:52 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > > On Tue, Apr 26, 2022 at 5:48 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote: ... > > 1. Enable Chrome's auto-detection of DNS-over-HTTPS. It ships as > > disabled by default in Chrome currently, but it can be set to an > > 'auto' mode that will prefer DoH if it can determine that the DNS > > server supports it. > > > > This breaks corporate VPNs very hard, so probably not. Could you expand on this please? I'd just like to have some information to kick back at the requesting parties.

> > 2. Drop the user-agent extension. Ever since the advent of Chrome > > v100, various sites (particularly those that rely on Cloudflare[2] > > such as Gitlab.com) have been having difficulties when this is > > enabled. As its utility is limited (mostly just for metrics purposes), > > I think the easiest solution is to just remove it. > > > > I'd like to keep this, and this seems like something where Cloudflare > should be fixed to deal with it. :( I have no reason to believe that Cloudflare will do anything about this in the immediate future and in the meantime our users are suffering. If you have a better alternative, I'm all ears.

> > 3. There's a KDE Plasma integration extension too, maintained by the > > KDE upstream. Do we want to install that by default as well? > > > > Yes, we should! For the record, I'm talking about: https://chrome.google.com/webstore/detail/plasma-integration/cimiefiiaegb... I forgot to include the link in the previous message.

On Tue, Apr 26, 2022 at 7:22 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > > On Tue, Apr 26, 2022 at 7:15 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote: > > > > On Tue, Apr 26, 2022 at 6:52 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote: > > > > > > On Tue, Apr 26, 2022 at 5:48 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote: > > ... > > > > 1. Enable Chrome's auto-detection of DNS-over-HTTPS. It ships as > > > > disabled by default in Chrome currently, but it can be set to an > > > > 'auto' mode that will prefer DoH if it can determine that the DNS > > > > server supports it. > > > > > > > > > > This breaks corporate VPNs very hard, so probably not. > > > > Could you expand on this please? I'd just like to have some > > information to kick back at the requesting parties. > > > > Last time I tried it a few months back, Chrome switched to DoH > automatically under a variety of corporate VPN configurations I tested > from my workplace (split DNS, tunnel DNS, etc.). The experience when > that happens is confusing depending on how the VPN works. Mine just > results in unresolvable things some of the time, but I know other > workplaces have more painful experiences when that happens. > I just did a bit of research on it. I guess I can see where it might be problematic enabled by default, but Firefox (upstream, not sure about our build) has had it enabled by default for three years. I guess I don't love the idea of being inconsistent here.

> > > > > > 2. Drop the user-agent extension. Ever since the advent of Chrome > > > > v100, various sites (particularly those that rely on Cloudflare[2] > > > > such as Gitlab.com) have been having difficulties when this is > > > > enabled. As its utility is limited (mostly just for metrics purposes), > > > > I think the easiest solution is to just remove it. > > > > > > > > > > I'd like to keep this, and this seems like something where Cloudflare > > > should be fixed to deal with it. :( > > > > I have no reason to believe that Cloudflare will do anything about > > this in the immediate future and in the meantime our users are > > suffering. If you have a better alternative, I'm all ears. > > > > Yeah, I dunno. Does Cloudflare know about it yet? I don't know. I've reported it to Gitlab and asked them to reach out to Cloudflare via their support channels, but I don't think that's happened yet. They haven't even responded to our bug report at all so far. Even if they do, Fedora represents such a small percentage of Cloudflare's potential user base that I cannot see them prioritizing a fix very highly. > > > > 3. There's a KDE Plasma integration extension too, maintained by the > > > > KDE upstream. Do we want to install that by default as well? > > > > > > > > > > Yes, we should! > > > > For the record, I'm talking about: > > https://chrome.google.com/webstore/detail/plasma-integration/cimiefiiaegb... > > I forgot to include the link in the previous message. > > I figured that was the one you're talking about. There's also a > Firefox counterpart too that I think would be worth having too. https://addons.mozilla.org/en-US/firefox/addon/plasma-integration/ I presume?

It probably is worthwhile, but as I'm only maintainer of the fedora-chromium-config package, it's out of scope for this particular discussion. (Long-term, it might not be a bad idea to rename from fedora-chromium-config to fedora-browser-config and handle Firefox and/or other browsers in a common place. For now, though, I'm trying to limit it to what I am already familiar with.)

2. Drop the user-agent extension. Ever since the advent of Chrome v100, various sites (particularly those that rely on Cloudflare[2] such as Gitlab.com) have been having difficulties when this is enabled. As its utility is limited (mostly just for metrics purposes), I think the easiest solution is to just remove it.

We are?

Why?

On Wed, May 4, 2022 at 1:05 PM Michael Catanzaro <mcatanzaro(a)gnome.org&gt; wrote: > > On Wed, May 4 2022 at 12:38:55 PM -0400, Neal Gompa > <ngompa13(a)gmail.com&gt; wrote: > > Why? > > It was added to get usage statistics from some Wikimedia site that shut > down 5+ years ago, so we haven't used it in a real long time. There's > some value to website operators who find it interesting, I suppose, but > that doesn't outweigh the disadvantages: > > For Chrome, it has to go because of the version 100 Cloudflare trouble. > > For WebKit, it's nice to remove it because of persistent troubles with > specific websites that require debranding quirks. > > For Firefox, I don't know any specific problems, but I wouldn't be > surprised if it encounters version 100 trouble too. > > For all of the above, it's another data point for fingerprinting users. > Admittedly it is not a very big one, but it's better to not have it > than to have it. > I disagree. I *deliberately* want Fedora showing up and growing in this manner. If Chrome OS can advertise itself uniquely so it's broken out and people take note enough to test for it, I think it's equally worth it for Fedora to show up. I know it has positively influenced things in Fedora users' favor before in less than obvious ways, so I'd prefer to keep it. In any case, Alberto Ruiz reached out to Cloudflare via Twitter, and it is now being looked into on their part.

I disagree. I *deliberately* want Fedora showing up and growing in this manner. If Chrome OS can advertise itself uniquely so it's broken out and people take note enough to test for it, I think it's equally