Difference between revisions of "Browser Origin Policy"
From MgmtWiki
(→Full Title or Meme) |
(→Cookies) |
||
| Line 15: | Line 15: | ||
** Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4945698250293248 | ** Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4945698250293248 | ||
** To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8xjbL9kh3pV9u7YfXm0t4NzrUANr-tu1g23sdmQrU1zA%40mail.gmail.com. | ** To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8xjbL9kh3pV9u7YfXm0t4NzrUANr-tu1g23sdmQrU1zA%40mail.gmail.com. | ||
| + | ==Solutions== | ||
| + | * Access to file storage on the user's device is determined by the [https://github.com/WICG/proposals/issues/57 Shared Storage API]<blockquote>Shared Storage allows for unpartitioned storage (i.e. not partitioned by top-frame as is planned for other types of storage) that may only be read in a secure environment with carefully constructed output gates. This API is intended to support many cross-site use cases on the web while significantly decreasing cross-site user tracking. This I2E is for Shared Storage's first output gate, called selectURL. It allows Shared Storage to be used to select from a short list of URLS to be displayed in a Fenced Frame. Gates related to aggregate reporting will follow in future experiments. </blockquote> | ||
==References== | ==References== | ||
Revision as of 10:45, 12 June 2022
Full Title or Meme
Browser Origin Policies are used to determine which data and control flows are allowed based on the URL of the page or iFrame..
Context
- Origin Policies were initiated to prevent tracking of users from one site to another.
- Origin and site are confused in many documents. An attempt at a taxonomy explaining the differences can be seen at the wiki page Cross-Origin iFrame.
Cookies
- Cookies stored on the user browser space are the typical means of moving data from one website to another, typically using Cross-Origin iFrames.
- Note that prior to 2022 javascript could read any cookie.
- Schemeful Same-Site overcomes a limitation on SemeSite Cookie not looking at the scheme. Explainer is at https://github.com/sbingler/schemeful-same-site
- Origin-Bound Cookies Explainer https://github.com/sbingler/Origin-Bound-Cookies
- In 2022 over 95% of traffic is over HTTPS, which highlights some problems with cookies as they’re one of the few web platform components that do not respect the origin of their connection:
- Binds cookies to their setting origin (by default) such that they're only accessible by that origin. I.e., sent on a request or visible through `document.cookie`
- Link to entry on the Chrome Platform Status https://chromestatus.com/feature/4945698250293248
- To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8xjbL9kh3pV9u7YfXm0t4NzrUANr-tu1g23sdmQrU1zA%40mail.gmail.com.
Solutions
- Access to file storage on the user's device is determined by the Shared Storage API
Shared Storage allows for unpartitioned storage (i.e. not partitioned by top-frame as is planned for other types of storage) that may only be read in a secure environment with carefully constructed output gates. This API is intended to support many cross-site use cases on the web while significantly decreasing cross-site user tracking. This I2E is for Shared Storage's first output gate, called selectURL. It allows Shared Storage to be used to select from a short list of URLS to be displayed in a Fenced Frame. Gates related to aggregate reporting will follow in future experiments.
