Enable referrer to-origin trimming feature

[RKNF404]

Phase 1 of reducing referrer tracking, see the relevant issue.

[qoijjj]

The only potential problem I see with this is that it's a rather aggressive default. But this is still overridable by passing the feature in the command line, right?

[RKNF404]

overridable

100%, its a regular feature. It can be disabled.

rather aggressive

How so? This only removes everything after the origin on cross origin.

[qoijjj]

overridable

100%, its a regular feature. It can be disabled.

rather aggressive

How so? This only removes everything after the origin on cross origin.

Oh, wait. I may have misunderstood the feature. let me read more.

[qoijjj]

@RKNF404 Do you know why GOS makes this configurable (if I'm reading their code right) if there's no functionality impact?

[qoijjj]

I'm also not entirely sold on whether there are security advantages to this

[RKNF404]

@qoijjj do you have GOS? You can see it in the settings under privsec. I detailed functionality impact under the issue, to summarize not very significant. This has very little impact to begin with, but breakage is negligable. We can also expose flags, like this one, in about:flags to allow easier configurability.

[qoijjj]

@RKNF404 yep I see it, and it looks like the vanadium default is the chromium default with the option to harden it further?

It's going to be very difficult to test for breakage thoroughly. Having a similar setup to vanadium where we keep the default but expose a chrome://flags flag would be optimal, I agree.

Although it would be significantly more work I assume

[RKNF404]

@qoijjj i think i know how to go about exposing it in about:flags. I'll go into more detail when i have more time.

[RKNF404]

@qoijjj

Do you know why GOS makes this configurable (if I'm reading their code right) if there's no functionality impact?

Completely misread this sorry, it's configurable for rare cases I guess. To allow for 100% compat if needed. There isn't zero impact of referrer reduction, just very very mild. It only really affects 2 referrer policies, one which is rare and the other which is less rare but not functionality dependent usually (afaia).

I'm also not entirely sold on whether there are security advantages to this

It's not really a security feature, but it does close a pretty stupid tracking hole. Since it allows websites to track across redirects by setting referrer to expose information and send UIDs and such (unsafe-url or no-referrer-when-downgrade). It could have security benefit on websites that are poorly configured and use some sort of token in the parameters, but that is an edge of an edge case.

It's going to be very difficult to test for breakage thoroughly.

With a full disable of cross-origin referrers, there is breakage, especially for media players. Otherwise, yeah breakage testing is difficult. A quick example for the visual, and context on how breakage could be caused. You search on example.org/search?q=query with referrer no-referrer-when-downgrade, this is the referrer other websites get: Without stripping: example.org/search?q=query With stripping: example.org (this is what this patch would do) Cross-origin disabled: (Vanadium's default)

Having a similar setup to vanadium where we keep the default but expose a chrome://flags flag would be optimal, I agree.

Well, I can commit a change to expose the flag in this PR to about:flags to let users disable it. For disabling all cross-origin referrers, yeah I don't think disabling them by default would make sense. That should be a hardening option to opt into.

Although it would be significantly more work I assume

Realistically no, I don't think so. I haven't tried it yet, tbf, but it seems feasible. Significant work would be adding to the actual settings page, that would be some work and a half.

[RKNF404]

My branch got royally messed up somehow, I'll update changes in another PR and add an about:flags exposure of the feature.