Comments (20)
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?
from gpc-spec.
I continue to think this is important to address before this is more widely adopted. This gives us some extensibility and also overall consistency with all new headers we add to the web platform.
from gpc-spec.
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.
from gpc-spec.
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.
from gpc-spec.
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.
from gpc-spec.
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.
from gpc-spec.
Thanks @mnot !
I think this is a candidate to be closed. Does anyone strongly feel otherwise? If not, I'll close by the end of this month.
from gpc-spec.
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 :)
from gpc-spec.
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.
from gpc-spec.
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.
from gpc-spec.
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!
from gpc-spec.
I think we clarified this point and can move on as is, right?
from gpc-spec.
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.
from gpc-spec.
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.
from gpc-spec.
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.
Indeed, but there was a total a lack of implementer interest at the time. Also, the fact that @hober would get it wrong made me think that it couldn't be mature tech :)
Could this be a candidate for retrofitting?
from gpc-spec.
Could this be a candidate for retrofitting?
It's not syntactically a SF, so it'd need to be mapped. That's basically just creating a new header with the same semantics but different syntax.
from gpc-spec.
@darobin @mnot What is the feeling here? Should we close and drop or does this need further development?
from gpc-spec.
My .02 - close this, but keep it in mind if you find that you need to create a new, incompatible version of the header.
from gpc-spec.
If this is going to be re-opened, I'd suggest we also consider whether the Sec-
prefix is needed.
from gpc-spec.
That should probably be a separate issue as that raises the question of what should happen when a website sets it.
from gpc-spec.
Related Issues (20)
- Update gpc-spec links
- Ensure consistency between HTTP and JavaScript HOT 6
- Make the architecture support other privacy laws HOT 10
- Give UAs more help in establishing user intent HOT 7
- Legal Effects section may fall out of date HOT 5
- Set up explainer document in this repo with more detail for implementers HOT 6
- Are implementers expected to always have the header active or not? HOT 3
- Should the navigator property always have the property active or not? HOT 5
- Create consumer-facing GPC instructions HOT 1
- Mixed documentation on navigator.globalPrivacyControl returning 1 or true HOT 5
- Clarify when a Global Privacy Control preference needs to be conveyed
- Add direct identification for each jurisdiction HOT 1
- GPC spec status HOT 4
- Move laws to Explainer HOT 2
- ยง5 should end after the sentence "For additional details on legal effects, consult the explainer." HOT 2
- Respec
- I'll merge this. If any devs think we should change the glob pattern instead we can change the behavior in a secondary PR. HOT 1
- F
- Evaluation
- Notion
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gpc-spec.