Difference between revisions of "Browser Origin Policy"
From MgmtWiki
(Created page with "==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. ==Contex...") |
(→Smart on FHIR) |
||
| (12 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 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 | ||
| + | ** 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 [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> | ||
| + | ==Problems== | ||
| + | ===Smart on FHIR=== | ||
| + | This is a post "smart>Deprecating authorize-post?" on [https://chat.fhir.org/#narrow/stream/179170-smart chat stream] | ||
| + | <pre> | ||
| + | Dan Cinnamon 2024-02-04 | ||
| + | |||
| + | FYI - I was finally able to get to the bottom of this late last week. I thought I'd post a summary of what I found since there's a lot of content out there that's easy to mix together without a nuanced understanding. It finally took some RFC cave diving to get some confirmation on this. Maybe this was obvious to others- but I'm posting here in the event that questions come up about it. I hope it's useful to someone. | ||
| + | |||
| + | TL;DR- I am still of the opinion that we supercede authorize-post with PAR over time for the additional security benefits that it provides. That being said it appears that any urgent cookie concerns are largely behind us- other than the fact that we're requiring authz servers to use the least secure cookie settings (SameSite=none). | ||
| + | |||
| + | Details: | ||
| + | Turns out there are 2 closely related browser updates that have implications with cross-site requests. | ||
| + | |||
| + | SameSite enforcement: This initiative is largely done, and impacts authorize-post. It impacts it by requiring all authz server cookies to be set to the least secure setting: SameSite=None. To my knowledge, and in our testing, we've found popular authorization servers to have done this already. | ||
| + | -3rd party cookie deprecation: This initiative is just getting started, and I've been able to finally confirm that it does not impact authorize-post. | ||
| + | |||
| + | It's easy to get confused here because most articles, including information from google, seem to equate SameSite=none cookies with third party cookies. However I've found that our cross-origin POST cookies to fall into a slightly different bucket. Since cross-origin POST cookies are flagged as "unsafe", they require the same SameSite=none setting as a 3rd party cookie would. However, since authorize-post involves a "top-level navigation" of the browser (the url bar changes), it is not flagged as a "3rd party request", and thus is not currently being targeted for exclusion. This is why the authorize-post capability still works even with google's testing tools enabled. | ||
| + | </pre> | ||
==References== | ==References== | ||
Latest revision as of 16:23, 24 February 2024
Contents
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.
Problems
Smart on FHIR
This is a post "smart>Deprecating authorize-post?" on chat stream
Dan Cinnamon 2024-02-04 FYI - I was finally able to get to the bottom of this late last week. I thought I'd post a summary of what I found since there's a lot of content out there that's easy to mix together without a nuanced understanding. It finally took some RFC cave diving to get some confirmation on this. Maybe this was obvious to others- but I'm posting here in the event that questions come up about it. I hope it's useful to someone. TL;DR- I am still of the opinion that we supercede authorize-post with PAR over time for the additional security benefits that it provides. That being said it appears that any urgent cookie concerns are largely behind us- other than the fact that we're requiring authz servers to use the least secure cookie settings (SameSite=none). Details: Turns out there are 2 closely related browser updates that have implications with cross-site requests. SameSite enforcement: This initiative is largely done, and impacts authorize-post. It impacts it by requiring all authz server cookies to be set to the least secure setting: SameSite=None. To my knowledge, and in our testing, we've found popular authorization servers to have done this already. -3rd party cookie deprecation: This initiative is just getting started, and I've been able to finally confirm that it does not impact authorize-post. It's easy to get confused here because most articles, including information from google, seem to equate SameSite=none cookies with third party cookies. However I've found that our cross-origin POST cookies to fall into a slightly different bucket. Since cross-origin POST cookies are flagged as "unsafe", they require the same SameSite=none setting as a 3rd party cookie would. However, since authorize-post involves a "top-level navigation" of the browser (the url bar changes), it is not flagged as a "3rd party request", and thus is not currently being targeted for exclusion. This is why the authorize-post capability still works even with google's testing tools enabled.
