Difference between revisions of "Browser Origin Policy"
From MgmtWiki
(→Cookies) |
m (→Cookies) |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | [[Browser Origin Policy|Browser Origin Policies]] are used to determine which data and control flows are allowed based on the URL of the page. | + | [[Browser Origin Policy|Browser Origin Policies]] are used to determine which data and control flows are allowed based on the URL of the page or iFrame.. |
==Context== | ==Context== | ||
* Origin Policies were initiated to prevent tracking of users from one site to another. | * 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== | ||
| − | * Cookies stored on the user browser space are the typical means of moving data from one | + | * Cookies stored on the user browser space are the typical means of moving data from one [[Web Site]] to another, typically using [[Cross-Origin iFrame]]s. |
| + | * Note that prior to 2022 javascript could read any cookie. | ||
| + | * Schemeful Same-Site overcomes a limitation on [https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-05#section-8.8 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 | * 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` | ** 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 | ** 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== | ||
Latest revision as of 10:45, 27 April 2023
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 Web Site 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.
