Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the navigator property always have the property active or not? #62

Closed
AramZS opened this issue Dec 14, 2023 · 5 comments
Closed
Assignees

Comments

@AramZS
Copy link
Contributor

AramZS commented Dec 14, 2023

Spinning off from comment on #61 I realized there is something that is not 100% clear.

Is it a concern that the navigator property is a behavior inconsistent with the header? Does this open an avoidable fingerprinting risk?

I had assumed that it would mirror the header behavior in being true or not present to avoid fingerprinting issues and maintain consistency with the header (pending #60), but I see the spec has a bool for that property, so if we want it to be 'true or not present' I think the spec needs to change? Opening an issue on this questions.

@AramZS AramZS added the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Dec 14, 2023
@martinthomson
Copy link
Contributor

From an implementation perspective, having support for a feature means that the associated interfaces and items are present.

The difference with HTTP is that boolean fields that are not present are simply assumed to be false (I know you aren't using modern definitions for fields -- naughty -- but that is the best way to model Sec-GPC).

I guess the real question is whether we should invest in making the attribute hidden when GPC has not been enabled. That is irregular, but I believe it is technically feasible. Is there a good reason not to expose a value of false?

@annevk
Copy link

annevk commented Jan 9, 2024

Correcting the HTTP field is still an open issue: #6.

The member of Navigator should always be present as conditionally hiding interface members is rather unprecedented and there's no good reason to do so.

As with the header we should just give guidance that websites only pay attention to the true state.

(And yes, we wouldn't transmit the header in its false state, but that's just because it's a different mechanism and we want to be efficient on the wire.)

@AramZS
Copy link
Contributor Author

AramZS commented Jan 11, 2024

In the meeting of PrivacyCG for Jan 11 2024 we have concluded that the specification should note that the navigator property should always be present, regardless of value. This is standard practice and the fingerprinting risk at the browser level is already going to be there because it will be known from the major browser version number. Documents will be updated to make this clear

@SebastianZimmeck SebastianZimmeck removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Jan 11, 2024
@npdoty
Copy link
Contributor

npdoty commented Jan 11, 2024

Browser extension providers might possibly make a different choice (because their presence on a browser that doesn't support GPC could then be detected, and that could be an unnecessary and meaningful addition to fingerprinting surface), but could also reasonably conclude that not including the header at all when the user hasn't turned it on is compatible with feature-detection requirement in the spec: the user may not know about the feature at all and that effectively the feature isn't present for this user.

We could note somewhere in the spec that the navigator property definitely shouldn't be used to indicate that a user turned the setting off after turning it on at some point in the past. That is not what GPC means and not what this property should be used for. Probably no implementer would do that anyway and so a warning may be unnecessary; up to the editors.

@AramZS AramZS self-assigned this Jan 25, 2024
@AramZS
Copy link
Contributor Author

AramZS commented Jan 25, 2024

I think that #61's changes the explainer to make this clearer and makes the answer clear.

@AramZS AramZS closed this as completed Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants