View source for Browser Origin Policy

==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 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 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==

[[Category: Browser]]
[[Category: User Agent]]