search

WICG / fenced-frame

Proposal for a strong boundary between a page and its embedded content
https://wicg.github.io/fenced-frame/
Other
127 stars 31 forks source link

Add definitions for event reporting opt in headers #159

Closed blu25 closed 4 months ago

blu25 commented 5 months ago

This issue was brought up in https://github.com/WICG/fenced-frame/issues/158.

This PR adds official definitions for the Allow-Fenced-Frame-Automatic-Beacons and the Allow-Cross-Origin-Event-Reporting response headers that are used for cross-origin opt in for their respective features.

Preview | Diff

cbiesinger commented 4 months ago

I'm curious, why is this a structured header with a string "true" or "false" instead of a boolean structured header?

blu25 commented 4 months ago

I'm curious, why is this a structured header with a string "true" or "false" instead of a boolean structured header?

The implementation of this expects string literals (true/false) rather than boolean values (?0/?1). I wasn't aware of the precedent set in RFC8941 at the time, and I had copied the syntax of an existing flag that was also not using the boolean convention when I had implemented this feature. Since the code is already in place, and since changing this to a boolean would delay getting this feature out by at least a month, I think it's better to keep the implementation as is and make sure the spec matches the implementation.

miketaylr commented 4 months ago

would delay getting this feature out by at least a month

As far as long-term web platform health is concerned - 1 month is basically nothing. Any other compelling reasons to not do this work?

shivanigithub commented 4 months ago

As far as long-term web platform health is concerned - 1 month is basically nothing. Any other compelling reasons to not do this work?

Update: The team is proceeding with the change to boolean: https://chromium-review.googlesource.com/c/chromium/src/+/5542760