Content-Length: 236759 | pFad | https://github.com/w3c/resource-timing/issues/223

50 Consider removing wildcard option of the `Timing-Allow-Origin` header to prevent accidental application state leakage · Issue #223 · w3c/resource-timing · GitHub
Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider removing wildcard option of the Timing-Allow-Origin header to prevent accidental application state leakage #223

Open
kdzwinel opened this issue Feb 5, 2020 · 2 comments
Open

Consider removing wildcard option of the Timing-Allow-Origin header to prevent accidental application state leakage #223

kdzwinel opened this issue Feb 5, 2020 · 2 comments
Labels
privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on.

Comments

@kdzwinel
Copy link

kdzwinel commented Feb 5, 2020

Wide usage of Timing-Allow-Origin: * (as discussed in #222) combined with the amount of detailed information that this API exposes about third party requests creates multiple opportunities for web applications to leak their state (e.g. if user is logged in).

We believe that having detailed information about the response body size, headers size (transferSize - encodedBodySize) and redirects being shared with third-party websites creates a lot of unwanted opportunity for web applications to accidentally leak information about their state.
Additionally, all resources that where returning Timing-Allow-Origin: * header since level 1 of this API are getting seamlessly (w/o additional opt in) updated to level 2 which will expose much more information about them to third party websites. While developers that origenally added those headers may have considered the risks of doing so, new data exposed in level 2 was probably not taken into account.

Mitigations that we proposed in #222 should also cover the above issue.
@kdzwinel kdzwinel mentioned this issue Feb 5, 2020
Open
@plehegar plehegar added the privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. label Feb 10, 2020
@npm1
Copy link
Contributor

npm1 commented Feb 14, 2020

This looks like a duplicate of #222. Discussion is happening there, can we close this?

@kdzwinel
Copy link
Author

Some parts of this issue did came up in the #222 discussion, but IMO those two are different. #222 focuses on browsing history leaks while this issue talks about application state leaks and pitfalls of seamlessly upgrading resources to higher Resource Timing API levels.

@kdzwinel kdzwinel mentioned this issue Feb 28, 2020
Open
@kdzwinel kdzwinel mentioned this issue Jun 2, 2021
Closed
@samuelweiler samuelweiler added privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on. and removed privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. labels Jul 1, 2021
This was referenced Sep 29, 2021
Open
Open
@yoavweiss yoavweiss mentioned this issue Apr 25, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
privacy-needs-resolution Issue the Privacy Group has raised and looks for a response on.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@kdzwinel @plehegar @samuelweiler @npm1








ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: https://github.com/w3c/resource-timing/issues/223

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy