Privacy-related: Consider enabling these two Chromium flags by default.

[Peacock365]

Please consider enabling chrome://flags/#reduced-referrer-granularity and chrome://flags/#prefetch-privacy-changes by default. The former is purely privacy-related, I don't know if you are already doing something similar. The latter prevents data leakage as described here:

https://terjanq.github.io/Bug-Bounty/Google/cache-attack-06jd2d2mz2r0/index.html

Here is the "Intent to implement" in Chromium:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/bSMOY-evrV4

I have raised the same issue in the Brave browser repo, with the result that the flags got enabled by default:

brave/brave-browser#8319

I have also raised this in the Vanadium repo, still under review:

GrapheneOS/Vanadium#71

Thank you for your attention.

[Poopooracoocoo]

you might also want to make an issue on the android version too :) https://git.droidware.info/wchen342/ungoogled-chromium-android

[wchen342]

Changes applied here will automatically be applied to Android version, so no need for a separate issue.

[Eloston]

Why must we enable these two flags ourselves? If they're that impactful, why hasn't the Chromium team enabled them by default already?

I understand the privacy motivation for enabling these flags, but I'm having troubles seeing the impact on stability and retaining the default Chromium experience (however granular the experience can get). Any clarifications will be appreciated.

[Peacock365]

OK, so this is what the Chromium team has to say regarding chrome://flags/#prefetch-privacy-changes:

"The compatibility risk is mostly low, but not completely clear. Changing the credentials mode for prefetch requests may cause more cache-misses and therefore double-downloads, however could also introduce a correctness problem if prefetch responses do not have the Vary: Cookie header attached when their content actually relies on credentials. In this case, it is possible that a user can navigate (with credentials) to a resource, and the user will be served the uncredentialed response from the HTTP cache. We don’t expect the changes to service-workers mode, referrer policy, and redirect mode to break existing content. It is likely they will cause more cache-misses and double-downloads though."

source: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/bSMOY-evrV4

As I have mentioned in the issue I've opened in the Brave repo, I have used the following websites with no compatibility issues:

• Google
• Facebook
• Twitter
• Instagram
• Amazon
• eBay
• YouTube

I realize that this is no scientific test or something, but it goes to show that there really is not a problem with enabling this flag by default. Brave did, and so did Bromite recently, and there are no reports of related issues yet.

As for chrome://flags/#reduced-referrer-granularity, its effect is documented here:

https://github.com/brave/brave-browser/wiki/Deviations-from-Chromium-(features-we-disable-or-remove)#modified-features-and-functionality

Seems like a sane referrer header policy to me. The Chromium team is currently testing these changes, evaluating whether or not they can be enabled by default. But as said, I have had no issues with both of these flags set to "Enabled".
I understand that you want to maintain the default Chromium behavior, but may I remind you that Ungoogled Chromium differs from it on several occasions already? Furthermore, I think we should strive to enable all built-in privacy protections by default, especially if the web compatibility risk is as low as it is in this case.

[Eloston]

The Chromium team is currently testing these changes, evaluating whether or not they can be enabled by default. But as said, I have had no issues with both of these flags set to "Enabled".

Seems like it'll start being enabled in 85 and onward: https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default

Thanks for explaining. I agree that the impact is low for these flags, so I'll enable them.