Use HTTP structured field values

[darobin]

Filed on behalf of @yoavweiss: "Use https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#boolean"

[pes10k]

I don't have strong feelings about this, but structured headers are mostly useful if you want to encode complex values (i.e. something beyond 1 / 0). Unless we expect to need something more complex in the future (which I'm nervous about, re the extension conversation) I don't see the value of adoption this yet-to-be-standardized approach.

That said, sincerely, i dont have strong feelings about this, so if others are into it, im not going to argue :)

[SebastianZimmeck]

Per @hober in the Privacy CG call

Surprised the Sec-GPC header doesn't use Structured Headers. Issue already filed
When a structured header represents a boolean and the header is absent, the boolean is true, which maybe is not what you're looking for

The easiest way to avoid this behavior would be to not use structured headers. Per our discussion with some of you today, I am closing this issue. Feel free to reopen.

[darobin]

This was further discussed and it wasn't clear that @hober's assessment was correct. She seems to have been thinking of boolean fields in deeper structures, and not at the top level. It's still worth checking, this came back twice from two browser vendors — it's worth investigating.

[elvey]

FYI, I tried implementing this with a not-widely used extension,
Man in the Middle v 3.5.3, from @dangkyokhoang. https://github.com/dangkyokhoang/man-in-the-middle#text-headers has documentation.
I Added a rule wherein I put Sec-GPC: 1 in Text headers.

After I put http in URL filters, Firefox started appearing to be doing the right thing, per Server-side detection at https://global-privacy-control.glitch.me/

I'm posting that as an FYI, but it leads me to ask: are we saying that this should be in every single HTTP request? [Edit: Sebastian cleared up my confusion: Ignore: Reading between the lines of issues here, it seems like we're switching to something less verbose (hopefully more sensible) where the browser queries a well-known with this header set and done], but perhaps it really does need to be in every request. Servers die, get rebooted, etc, so session state can't be guaranteed, especially when many actors are motivated for minimal (or less) effort.

[elvey]

And is it intentional that we're not specifying a California-specific string? Good idea, or mistake? I've no idea, but choice should be intentional.

[SebastianZimmeck]

but it leads me to ask: are we saying that this should be in every single HTTP request?

Yes, that is the case. The GPC signal should be in every single HTTP request. The reasoning is exactly as you are describing, @elvey. We want to relieve the signal recipient from keeping state.

where the browser queries a well-known

The .well-known is intended as an answer. So, a browser or browser extension can surface to the user that a site respects GPC signals, for example.

And is it intentional that we're not specifying a California-specific string? Good idea, or mistake?

Intentional. You can think of GPC as a mechanism that by itself does not have a legal meaning. It will receive its legal meaning from laws and regulations. For example, under the California Consumer Privacy Act Regulations, a GPC signal means the opt out from the sale of personal information. However, the signal can have a different legal meaning under another law. Legislators and regulators will specify the meaning for their jurisdiction.

[mnot]

When a structured header represents a boolean and the header is absent,

That isn't true (with all deference to the otherwise perennially correct @hober)

are we saying that this should be in every single HTTP request?

I think it would be necessary in this approach, yes. I don't think that's an efficiency concern on the modern Web -- HPACK and QPACK will effectively amortise this to one transmission per connection, and (slightly) compress it in the process.

WRT how many bytes; it's literally two bytes (?1) vs one (1). If future, binary encodings of Structured Fields get off the ground, it will be significantly more efficient (both in terms of bytes-on-the-wire and processing overhead) to use them.

I think the extensibility question is the right thing to focus on here. If the value were under advertiser control (as P3P was), I'd say this is an easy decision; what problems are foreseen by allowing extension in a request header?

[hober]

When a structured header represents a boolean and the header is absent,

That isn't true (with all deference to the otherwise perennially correct @hober)

Sorry for the noise caused by my terrible reading comprehension!

[SebastianZimmeck]

I think we clarified this point and can move on as is, right?

[martinthomson]

Another consideration that comes up routinely when dealing with HTTP fields is the potential for them to be repeated, which can happen by accident more often than expected. Under those conditions, it is possible that the values are combined.

In this case, that could produce results like Sec-GPC: 1, 1 at a receiving entity. A simple parser that does simple comparisons (headers.get("sec-gpc") == "1") will make a mistake.

I think the extensibility question is the right thing to focus on here.

I agree. Though we do want this to be easy to process, there is no guarantee that a very simple - and franky, bespoke - design is going to be more robust. That is true even in if extensibility is never sought or even expressly forbidden, as shown above.

[darobin]

Concerning repetition, the registration for the header has it as non-repeatable. (I assume that this will make no difference in most implementations, but just flagging for the few cases in which it'll help.)

Concerning extensibility, when I started working on this I went and grabbed every server-side DNT processor I could find. (It wasn't that many, so I'm not claiming any kind of statistical relevance here, just directional indication.) For reference, DNT can be 0 or 1, followed by extension data. I mostly found implementations testing for strict equality with 1. Yes, that fails with repeated headers (a corner case I would think) but it fails with extensions — meaning that extensions wouldn't work and possibly couldn't be deployed. We could reach out to GPC server-side implementers, but that's a lot of people.

Concerning ?1, I have some pretty strong misgivings about changing the syntax of an active compliance method in a way that would render sites non-compliant overnight.

[mnot]

This issue was raised in 2020; AIUI there's been enough pre-standards deployment to make what would have been a reasonable change then unwise now.

What I'd suggest is that if SF is going to be used, a new field name be defined. You might only consider that if other breaking changes are made -- syntactically or semantically.