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

[AramZS]

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.

[martinthomson]

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]

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]

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

[npdoty]

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]

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