This is probably due to the patch that reduces referrer granularity on cross-origin transitions; @uazo the preference value seems unused, is that on purpose?

first of all, welcome back @csagan5!

the flag you signal has always been present in chromium, I have inserted it only in the ui, and it manages the complete deactivation of referrers.
For what it can serve to solve this issue is a content setting, which however is not present. if you agree we could insert it, but I fear that the various configurations will confuse less experienced users.

maybe something smarter is needed, like a list of domains and the rules needed to make them work, perhaps external and automatically updated, with a message to the user and the possibility of applying them or not.

For what it can serve to solve this issue is a content setting, which however is not present. if you agree we could insert it, but I fear that the various configurations will confuse less experienced users.

Bromite with recent 2 updates started to block the links. It never blocked previously. May be restore that setting? Or was it intentionally for more added security?

first of all, welcome back @csagan5!

I have not gone anywhere?

the flag you signal has always been present in chromium

I understand, so it works automatically because it re-uses the flag name, similar to flags and switches.

For what it can serve to solve this issue is a content setting, which however is not present. if you agree we could insert it, but I fear that the various configurations will confuse less experienced users.

I think these sites will eventually be fixed when upstream rolls out the change to a larger percentage of users.

maybe something smarter is needed, like a list of domains and the rules needed to make them work, perhaps external and automatically updated, with a message to the user and the possibility of applying them or not.

What is the point of introducing privacy patches if we disable them for all the cases where there is privacy infringement? The list of domains would correspond to the list of infringing sites. I am against any type of snake oil privacy/security, including this one.

In some cases we can have a flag or a site setting, but remember that we have no analytics to know how much breakage is happening.

The best outcome here is to wait for the feature to be rolled out or contact the site author and tell them that they will eventually have to fix it anyways.

when upstream rolls out the change to a larger percentage of users.

this particular one I think never

What is the point of introducing privacy patches if we disable them for all the cases where there is privacy infringement?

none, of course, but one has to think, maybe privacy-related changes should probably also be weighed against those who would like to use bromite who are not normally technical, and judges the site not working as if it is the browser that is not working.
because, in addition, there are times that, as in this case, the "standard w3c" functionality is used correctly and not for the purpose of invading one's privacy. how to distinguish them?
I would like to be unassailable in terms of choices, lately I see comments about the unusability of our browser because of this or that bug caused by our choices.
because, either we explain all the reasons better or we don't give a damn about compatibility and then state it clearly, or maybe there is a third way, I don't know, maybe start a discussion directly with the team doing the specs, but for me it is difficult because of the language.

The list of domains would correspond to the list of infringing sites. I am against any type of snake oil privacy/security, including this one.

but we could communicate this to the user, so that he does not think that it is the browser that does not work but the site that uses features, let us say, on the borderline between 'legitimate' and 'harmful'

but remember that we have no analytics to know how much breakage is happening.

is true, and I am beginning to miss it... also used to reading through the logs of the software I make
is it possible that there is no legitimate way to introduce it? I think the problem is always the user's ip...

contact the site author and tell them that they will eventually have to fix it anyways.

bah, we are neither brave nor google, who would care? we don't even know how many people is using bromite...

when upstream rolls out the change to a larger percentage of users.

this particular one I think never

Care to elaborate?

maybe privacy-related changes should probably also be weighed against those who would like to use Bromite who are not normally technical, and judges the site not working as if it is the browser that is not working.

No, it should not. If you use Bromite you have to understand how it works (and how it breaks), otherwise do not use Bromite.

because, in addition, there are times that, as in this case, the "standard w3c" functionality is used correctly and not for the purpose of invading one's privacy. how to distinguish them?

Can you explain how in this specific case the functionality is not infringing? This site would like to use referrers cross-origin to validate where user is coming from, and deny users downloads if the referrers do not match. This is not the W3C-suggested use for referrers and a very poor form of verification. It infringes privacy because the user has not yet visited the other origin but some information would be carried over (what is in the URL of the referer).

but we could communicate this to the user

What is "this" here?

is true, and I am beginning to miss it... also used to reading through the logs of the software I make
is it possible that there is no legitimate way to introduce it? I think the problem is always the user's ip...

It is never going to be introduced in Bromite.

contact the site author and tell them that they will eventually have to fix it anyways.

bah, we are neither brave nor google, who would care? we don't even know how many people is using bromite...

I did not write "contact site X saying that browser Y does not work with it", I mentioned the upstream link that explains what the privacy problem is about. That is what you should report to site authors, if you care.

I would like to be unassailable in terms of choices, lately I see comments about the unusability of our browser because of this or that bug caused by our choices.

All choices are arguable (as they should be); you will only see reports about the problems here, I already explained it in the past.

because, either we explain all the reasons better or we don't give a damn about compatibility and then state it clearly, or maybe there is a third way, I don't know, maybe start a discussion directly with the team doing the specs, but for me it is difficult because of the language.

All reasons should be explained better in the patches' description, README and Wiki (depending on the type of information).

we don't give a damn about compatibility

Compatibility with what, the entire internet? This is an open source project, it breaks stuff and fixes stuff. There is no guarantee about anything and there never will be.

I have no intention to start discussions with the teams doing the specs but I am not stopping anyone else from doing that either.

Once again this is a very off-topic discussion that has nothing to do with this issue, please use Discussions in the future because here it is off-topic and there it would be visible to other people not checking each single issue.

when upstream rolls out the change to a larger percentage of users.

this particular one I think never

Care to elaborate?

I try. I don't think that blocking referrers to third parties will ever be the default, because all the necessary tools to block them (norel attributes, http headers, meta, document policy ecc...) are already present in the standards, if the site has the will to do so.

maybe privacy-related changes should probably also be weighed against those who would like to use Bromite who are not normally technical, and judges the site not working as if it is the browser that is not working.

No, it should not. If you use Bromite you have to understand how it works (and how it breaks), otherwise do not use Bromite.

Of course, it is correct that the user must know the software he/she installs and uses, also because this applies to all software you install.
However, I was referring to something else, namely whether there might be a way to warn the user of a possible site breakdown, i.e. whether there might be conditions we can check to notify the user, that's all.

because, in addition, there are times that, as in this case, the "standard w3c" functionality is used correctly and not for the purpose of invading one's privacy. how to distinguish them?

Can you explain how in this specific case the functionality is not infringing? This site would like to use referrers cross-origin to validate where user is coming from, and deny users downloads if the referrers do not match. This is not the W3C-suggested use for referrers and a very poor form of verification. It infringes privacy because the user has not yet visited the other origin but some information would be carried over (what is in the URL of the referer).

I don't know the use suggested by w3c, nor did I find it in the specs (https://www.w3.org/TR/referrer-policy/), can you tell me where you read them?
In this specific case I think the motivation is trivially to go through the site before downloading for the advertising, in principle I see nothing wrong with that, webdesigners know that users can use adblocks, but maybe that one specifically does not know about the referrers' policies.
But here's another point: is it possible to warn the user?

but we could communicate this to the user

What is "this" here?

I realise that I have explained myself incorrectly.
I am thinking about whether it is possible to determine whether the site WANTS the referrer to be passed on, in which case it will notify the user who decides how he wants to behave.

is true, and I am beginning to miss it... also used to reading through the logs of the software I make
is it possible that there is no legitimate way to introduce it? I think the problem is always the user's ip...

It is never going to be introduced in Bromite.

yes, of course neither do I. It was just a thought.

contact the site author and tell them that they will eventually have to fix it anyways.

bah, we are neither brave nor google, who would care? we don't even know how many people is using bromite...

I did not write "contact site X saying that browser Y does not work with it", I mentioned the upstream link that explains what the privacy problem is about. That is what you should report to site authors, if you care.

this time it is me who does not understand. what link? who are the authors you are referring to?

we don't give a damn about compatibility

Compatibility with what, the entire internet? This is an open source project, it breaks stuff and fixes stuff. There is no guarantee about anything and there never will be.

I can't answer that, I'll have to think about it further

I have no intention to start discussions with the teams doing the specs but I am not stopping anyone else from doing that either.

there are various ways, perhaps a comment such as 'Privacy and Security section should mention that a user agent may choose to not expose cross-origin referrer' is sufficient. I will probably give it a try.

Once again this is a very off-topic discussion that has nothing to do with this issue, please use Discussions in the future because here it is off-topic and there it would be visible to other people not checking each single issue.

I don't see anything OT about it, maybe poorly written, but the aim is to see if the patch could be improved

I try. I don't think that blocking referrers to third parties will ever be the default, because all the necessary tools to block them (norel attributes, http headers, meta, document policy ecc...) are already present in the standards, if the site has the will to do so.

So the patch breaks the standards? I realize my misunderstanding now: I thought that with that patch we were anticipating some change from upstream.

However, I was referring to something else, namely whether there might be a way to warn the user of a possible site breakdown, i.e. whether there might be conditions we can check to notify the user, that's all.

The best that could be done is printing a message in the JavaScript console, other similar changes from upstream do it.

I don't know the use suggested by w3c, nor did I find it in the specs (https://www.w3.org/TR/referrer-policy/), can you tell me where you read them?

https://www.w3.org/TR/referrer-policy/#user-controls

Nothing in this specification should be interpreted as preventing user agents from offering options to users which would change the information sent out via a Referer header. For instance, user agents MAY allow users to suppress the referrer header entirely, regardless of the active referrer policy on a page.

I think this passage is extraordinarily clear, while usually others are not as clear as this one; and coincidentally also covers what the current patch does. Perhaps the best we could do is have another global setting (not site setting) to control the patch behavior (this is also another misunderstanding of mine: I thought that the preference was controlling that, but it does not).

this time it is me who does not understand. what link? who are the authors you are referring to?

The website is https://www.celsoazevedo.com and the link would have been the upstream Chromium tracking bug (but there is none, I understand now); the authors are the authors of the website.

In this specific case I think the motivation is trivially to go through the site before downloading for the advertising, in principle I see nothing wrong with that, webdesigners know that users can use adblocks, but maybe that one specifically does not know about the referrers' policies.

Too bad if they don't know that user agents can omit the referrer, we are not going to change the user agent to accommodate for that.

there are various ways, perhaps a comment such as 'Privacy and Security section should mention that a user agent may choose to not expose cross-origin referrer' is sufficient. I will probably give it a try.

It is already in the standard? https://www.w3.org/TR/referrer-policy/#user-controls

I don't see anything OT about it, maybe poorly written, but the aim is to see if the patch could be improved

The off-topic part is about:

• adding analytics to Bromite
• unusability of the browser
• documentation of choices for the patches
• etc

They are very general topics and only incidentally related to this issue; we cannot discuss them properly here because otherwise we thrash the issue.

To go back on topic, for this issue we should probably:

• add another preference near the existing one (to respect what the W3C standard says: the user agent allows the user to drop referrers)
• add a message in console when the referrer has been dropped (to allow better troubleshooting of this issue)

Why we cannot show pop-ups? Because there could be possibly tens of these pop-ups, it would quickly become comically useless.

• add another preference near the existing one (to respect what the W3C standard says: the user agent allows the user to drop referrers)

But then I would not be able to differentiate the behaviour according to the site. then perhaps an additional site setting is better.

• add a message in console when the referrer has been dropped (to allow better troubleshooting of this issue)

is similar to the pop-up solution, the message would always be there for all sites, with the complication that the user would never see it directly from the device.
Among other things, it is difficult to develop, because the console is deleted when navigation is in the commit phase, which is after the first request.

a third possibility is to add a new 'open with custom' command to the popup on right-click links (long press).
The command could open an intermediate page that would allow the user to choose from a number of options, including, for example, allowing the referrer.
and, with the use of a trottle, we could have that intermediate page open automatically if the conditions exist (the standard methods) for which the site expressly requires the referrer to be passed.
that information comes from blink, as does the request to open the link, so I think it is possible to develop it.

But then I would not be able to differentiate the behaviour according to the site. then perhaps an additional site setting is better.

More costly to develop and maintain.

Among other things, it is difficult to develop, because the console is deleted when navigation is in the commit phase, which is after the first request.

I see; then it could be logged so that it is visible via adb logcat.

a third possibility is to add a new 'open with custom' command to the popup on right-click links (long press).
The command could open an intermediate page that would allow the user to choose from a number of options, including, for example, allowing the referrer.
and, with the use of a trottle, we could have that intermediate page open automatically if the conditions exist (the standard methods) for which the site expressly requires the referrer to be passed.
that information comes from blink, as does the request to open the link, so I think it is possible to develop it.

Sites that do not follow the standard do not deserve this; the standard is clear: referrer is not guaranteed to be there. The sites are in breach, not the browser. I am against having this complex functionality for even 1 of these sites.

I propose to do only this part:

• add another preference near the existing one (to respect what the W3C standard says: the user agent allows the user to drop referrers)

@uazo shall I assign it to me or you?

Let me get this straight, what is that flag supposed to do?

This patch does 3 things:

1. add a preference to completely disable referrals
2. change default referrer policy from NEVER_CLEAR to REDUCE_GRANULARITY_ON_TRANSITION_CROSS_ORIGIN
3. remove referrals if the navigation is cross-origin and occurs in the top frame (here)

(1) is a preference for the whole referrals functionality. However even with (1) enabled users cannot decide about (2) and (3); I am proposing to add another preference (or make the existing one a tri-state) that allows toggling the (2)+(3) on/off when referrals are allowed (default as it is in the current patch).

OK, I got it. assign it to me, I'll finish what I started.

make the existing one a tri-state

I like it better this way

Just an idea:
Isn't possible to add a message like this with the message: wants to send referrer cross-domain?

The idea is just to save the user choice per-domain and per-session, so never store it on disk and clicking outside the box make it blocking referrers.
Note: This would expose the website choices and would also allow temporary exceptions that are never infinite grants.

@uazo I think the issue seems to be resolved.