Enable the prefetch-privacy-changes flag by default

[Peacock365]

Description

The Brave flags "Reduce default 'referer' header granularity." and "Prefetch request properties are updated to be privacy-preserving" should be enabled by default, in order to improve the default privacy of Brave users. No website breakage is expected here, no performance degradation is expected here. I have visited several major websites so far with both of these settings enabled (Facebook, Google, YouTube, eBay, Twitter, Amazon, Instagram - you name it), and the websites do behave normally. Please consider enabling these settings by default.

Steps to Reproduce

1. Go to chrome://flags/#reduced-referrer-granularity
2. Go to chrome://flags/#prefetch-privacy-changes

Actual result:

The settings are disabled by default.

Expected result:

The settings should be enabled by default.

Reproduces how often:

Easily reproduced.

Brave version (brave://version info)

Brave | 1.3.115 Chromium: 80.0.3987.87 (Official Build) (64-bit)
Revision | 449cb163497b70dbf98d389f54e38e85d4c59b43-refs/branch-heads/3987@{#801}
OS | macOS Version 10.15.3 (Build 19D76)

(Reproducible on other OSes as well, though.)

Version/Channel Information:

Does this issue happen on any other channels? Or is it specific to a certain channel?

I use the release channel, but it can be reproduced on all channels.

Other Additional Information:

Is the issue reproducible on the latest version of Chrome?

Yes.

Miscellaneous Information:

Is there any good reason why those settings are disabled by default as it stands? Anything I am unaware of?

[bsclifton]

cc: @snyderp @tomlowenthal

[pes10k]

I think we already do this, but just w/o using the code paths Chrome uses. We aught to just remove the flags.

[tildelowengrimm]

Removing the flags is another thing that we need to maintain on rebases, so if they're redundant, ley's just ignore them. I'm personally not sure what either of the flags do. François says that the referer one is less protective than our Shields default, and Chrome is going to enable it by default if their tests pan out, so that one's easy to ignore. Looks like #prefetch-privacy-changes is pretty good. No reason not to enable it IMO? Is it redundant with some other protection?

[fmarier]

The referrer flag will be enabled as part of fixing #8696. Let's keep this issue open for the prefetch flag:

[fmarier]

Here is more information about this flag:

• Apple proposal
• Intent to implement in Chromium
• Tracking Chromium bug
• Tracking Safari bug

and the risks identified by the Chromium team:

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.