To consider removing NavigatorUAData.getHighEntropyValues()

[uazo]

Is your feature request related to privacy?

Yes

Is there a patch available for this feature somewhere?

No, but it's trivial

Describe the solution you would like

since even with ua reduction it is possible to obtain the browser version (see https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData/getHighEntropyValues) is perhaps better completely remove the method from the idl

Describe alternatives you have considered

removing the method could lead to unmanaged errors in scripts. While it may be fair from a privacy standpoint, we may break some sites.
the alternative is to delete only the uaFullVersion

[csagan5]

since even with ua reduction it is possible to obtain the browser version (see https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData/getHighEntropyValues)

Hiding the browser version is not a goal of Bromite and it is not possible anyways because of the adblock filters.

the alternative is to delete only the uaFullVersion

The client hint for model was disabled here: https://github.com/bromite/bromite/blob/master/CHANGELOG.md#9304577110

So we could also disable this one, or provide a dummy version.

[uazo]

So we could also disable this one, or provide a dummy version.

perfect, I'll do so.

Hiding the browser version is not a goal of Bromite

ok

is not possible anyways because of the adblock filters.

can you explain to me why?

[csagan5]

is not possible anyways because of the adblock filters.

can you explain to me why?

It is possible to verify which ad filters are present by checking what resources do not get loaded. This allows to detect Bromite; it is not a secret and was discussed in multiple places; it is also the reason why Bromite does not try to look like any other browser.

[uazo]

This allows to detect Bromite;

sure, i understand this, but the goal of the reduced ua was to not make people understand what the build version is for any unresolved security flaws?

[csagan5]

This allows to detect Bromite;

sure, i understand this, but the goal of the reduced ua was to not make people understand what the build version is for any unresolved security flaws?

Which reduced UA are you referring to, specifically?

[uazo]

Which reduced UA are you referring to, specifically?

w3ctag/design-reviews#640
what are you referring to?

[csagan5]

Which reduced UA are you referring to, specifically?

w3ctag/design-reviews#640

Out of the list in https://developer.mozilla.org/en-US/docs/Web/API/NavigatorUAData/getHighEntropyValues model and uaFullVersion should not be provided by Bromite as they are useful for fingerprinting; the adblock filters provide another fingerprinting venue but regardless we should not make it easier by providing model and uaFullVersion.

[miketaylr]

You could also just always reject the Promise for any high-entropy hints you don't wish to support (or all of them). See step 2 in https://wicg.github.io/ua-client-hints/#getHighEntropyValues

[csagan5]

That sounds indeed like the correct way to handle this.

[csagan5]

You could also just always reject the Promise for any high-entropy hints you don't wish to support (or all of them). See step 2 in https://wicg.github.io/ua-client-hints/#getHighEntropyValues

I have been checking the Chromium code about this; it currently does not implement any NotAllowedError for the promise, but I expect something will be added once WICG/ua-client-hints#151 is resolved.

Until that I opt for providing fake values, which is consistent with past/current Bromite behavior and should reduce client-side breakage (there is currently no way to say NotAllowedError for a single permission from the array and client-side are following up with Chromium/Webkit until this becomes more stable).

Note: in Chromium the feature policy for client hints has been removed: chromium/chromium@9b85b2a

[miketaylr]

I have been checking the Chromium code about this; it currently does not implement any NotAllowedError for the promise, but I expect something will be added once WICG/ua-client-hints#151 is resolved.

Yep, that's correct.

[csagan5]

@uazo the headers part is now addressed, what is the behaviour of the Javascript side when headers are not provided?
Also: is there anything we should do to address this issue before upstream makes it more granular?

[uazo]

what is the behaviour of the Javascript side when headers are not provided?

about what?

Also: is there anything we should do to address this issue before upstream makes it more granular?

yes, we could return the same version of the header instead of the complete one

[csagan5]

Also: is there anything we should do to address this issue before upstream makes it more granular?

yes, we could return the same version of the header instead of the complete one

Ok, let's go with that for now. Do you want to make a PR or shall I?

[uazo]

Ok, let's go with that for now. Do you want to make a PR or shall I?

the first thing I have to do is merge my branch with yours, then I do.
obviously if you want to do it tell me.

[csagan5]

Please open a PR for it.