Ensure consistency between HTTP and JavaScript #38
Conversation
As written, the current spec implies that: - HTTP headers always reflect the current GPC preference - JavaScript properties always reflect the preference when the top-level browsing context started loading This is inconsistent, and seems like it will lead to weird edge cases if the preference is changed mid-load. I propose that we adopt the approach of JavaScript for HTTP so both return the preference cached at the time of the last top-level navigation.
|
@darobin for review |
Co-authored-by: Martin Thomson <mt@lowentropy.net>
|
CG came to agreement for an update to this text. @arichiv will author. |
|
@AramZS how does this look? |
|
@npdoty for review |
There was a problem hiding this comment.
Thanks for writing up this text for making signals consistent to the scope of a navigation.
I've made some minor suggestions, mostly editorial. Also, I think the UA prompt recommendation can be less specific while still accomplishing the goal of not confusing the user about how the preference will go into effect.
|
Thanks, Ari. One editorial correction. Editors, feel free to merge and make any fixes yourself. |
|
@martinthomson, would you like to review this PR? (If you are busy, feel free to let me know, and I can do it.) |
|
@martinthomson for review |
There was a problem hiding this comment.
This seems broadly OK, at least as far as this captures the outcome of the discussion.
FWIW, I'm of the view that inconsistency isn't inherently a problem. If values could change, that doesn't mean that they will. The only concrete problem I'm aware of is providing high resolution access that might allow a site to learn about when the preference changes. Then changes that appear at the same time might be used to leak cross-site information. That problem is fixed more readily by advising implementers not to allow that to happen. Being specific about the fix, at this level of detail, constrains implementations in ways that - at least in my experience - can have unwanted effects. A looser specification gives implementers more latitude in how they respond to evolving threats.
Co-authored-by: Martin Thomson <mt@lowentropy.net>
|
@martinthomson have time to take another look and merge? |
|
I'm OK with this, but the decision to merge is up to editors. |
@martinthomson, can you approve your review? Then, I will merge. |
As written, the current spec implies that:
This is inconsistent, and seems like it will lead to weird edge cases if the preference is changed mid-load. I propose that we adopt the approach of JavaScript for HTTP so both return the preference cached at the time of the last top-level navigation.
Further, we should encourage the browser add a mechanism that encourages the user to refresh any pages started with an outdated GPC preference.
Closes #49