LGTM2 (shame we can't rename this the Cookie Access API... :))
On 3/29/23 5:40 AM, Yoav Weiss wrote:
LGTM1
On Mon, Mar 20, 2023 at 10:34 PM 'Johann Hofmann' via blink-dev
<blink-dev@chromium.org> wrote:
Contact emails
bra...@microsoft.com, johann...@chromium.org, cfred...@chromium.org
Explainer
https://github.com/privacycg/storage-access
<https://github.com/privacycg/storage-access>
Specification
https://privacycg.github.io/storage-access
<https://privacycg.github.io/storage-access>
(Merging to HTML is tracked in
https://github.com/whatwg/html/issues/9000
<https://github.com/whatwg/html/issues/9000>)
Design docs
Original Design
<https://docs.google.com/document/d/1q5Q-8MJcfZamGAXLpjiXiPYR1Tov5JOGw0Z8Fv0TWFk>
Updates to enable per-frame grants
<https://docs.google.com/document/d/1tMFYW_6Av8x-6ercbnMFUtBqpfvT97Nt8Jffsx1qve0/edit>
Summary
Browsers may block third-party resources from accessing cookies
and other storage for privacy and security reasons. The most
popular reason is cross-site tracking prevention. Such blocking
breaks authenticated cross-site embeds such as commenting widgets,
embedded payment providers, and subscribed video services.
The Storage Access API provides a means for authenticated
cross-site embeds (iframes) to check their blocking status and
request access to cross-site cookies if they are blocked.
As a Chromium default, we intend to ship the Storage Access API
without user-facing permission prompts, instead relying on
information from First-Party Sets to determine which sites should
be granted storage access. The request is auto-denied outside of
First-Party Sets <https://github.com/WICG/first-party-sets>.
However, there is a flag that allows other Chromium-based browsers
to show user permission prompts. This is utilized e.g. in
Microsoft Edge, but the Edge team also intends to support
integration with First-Party Sets after Chrome ships (see separate
I2S on FPS).
Blink component
Blink>StorageAccessAPI
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI>
TAG review
https://github.com/w3ctag/design-reviews/issues/807
<https://github.com/w3ctag/design-reviews/issues/807>
TAG review status
Positive
<https://github.com/w3ctag/design-reviews/issues/807#issuecomment-1431464692>
Risks
Interoperability and Compatibility
The API surface itself is simple (examples here
<https://github.com/privacycg/storage-access#the-api>). The API
does not impact the web platform unless pages explicitly invoke
it. Different browser implementations may react differently to
storage access requests (e.g. the user flow for Safari
<https://webkit.org/blog/11545/updates-to-the-storage-access-api/>or
Firefox using heuristics
<https://searchfox.org/mozilla-central/rev/611660bff9e6d52f1769bf216a7fbd12ece4d2d2/dom/base/Document.cpp#17626>)
and likely will choose to use different heuristics and/or
user-signals. These heuristics already vary among browsers
shipping this API, so sites cannot rely on the storage access
request succeeding in any specific situation. A goal of the API is
to allow browser vendors to apply rules that they think best serve
their users while allowing sites to navigate those implementation
differences. We are still working on reaching alignment across
browsers where possible.
Gecko: Shipped
(https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API
<https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API>)
WebKit: Shipped
(https://webkit.org/blog/8124/introducing-storage-access-api
<https://webkit.org/blog/8124/introducing-storage-access-api>)
Web developers: Positive
There has been great developer interest in the Storage Access API,
given that it provides the only predictable way of working with
cross-site cookies in many browsers. Various developers have
chimed in on https://github.com/whatwg/html/issues/3338
<https://github.com/whatwg/html/issues/3338>and filed issues on
https://github.com/privacycg/storage-access
<https://github.com/privacycg/storage-access>.
To summarize, there seems to be general support for the idea of
providing an API like this, but opinions have greatly differed on
what the provided capabilities should be. We recognize that the
current iteration of the SAA is limited in some capabilities, e.g.
no access to DOM Storage (recently also removed in Firefox
<https://groups.google.com/a/mozilla.org/g/dev-platform/c/qXbgQc7WoxM/m/wQ5MrQ5ABwAJ>),
and are considering potential future improvements.
An example of this kind of mixed-but-positive feedback is a recent
presentation by the Google Workspace team:
https://github.com/privacycg/meetings/issues/25
<https://github.com/privacycg/meetings/issues/25>
Other signals:
Ergonomics
The Storage Access API doesn't provide the same developer
ergonomics as "plain" cookies, for privacy and anti-abuse reasons.
Notably, it is built for specific use cases that involve an iframe
that a user interacts with to perform some kind of
login/authentication, such as embedded comment widgets. Cross-site
cookie access in non-interacted/non-authenticated user flows, such
as for online ads, is generally out of scope for this API.
To provide better developer ergonomics in non-iframe use cases for
access to cross-site cookies within a first-party set, we intend
to ship an extension to the Storage Access API called
"requestStorageAccessFor
<https://github.com/privacycg/requestStorageAccessForOrigin/>"
(see related I2S). However, that API should be considered an
enhancement and not directly covered by this intent
Activation
For this initial release, Chrome is shipping the Storage Access
API without a user prompt. Access will be granted based on
First-Party Sets (see related I2S). This means the same activation
risks as for the First-Party Sets I2S apply here as well.
WebView application risks
Does this intent deprecate or change behavior of existing APIs,
such that it has potentially high risk for Android WebView-based
applications?
No
Debuggability
Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, Android, and Android
WebView)?
No. This will be supported on Windows, Mac, Linux, Chrome OS, and
Android, but will not initially be supported on Android WebView.
Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
Yes, https://wpt.fyi/results/storage-access-api
<https://wpt.fyi/results/storage-access-api>
Note that in writing these tests we're dealing with some
underlying test framework issues, such as
- Flaky testdriver.bless/click support in cross-origin iframes
(https://bugs.chromium.org/p/chromium/issues/detail?id=1066891
<https://bugs.chromium.org/p/chromium/issues/detail?id=1066891>)
- Lack of a (well-functioning) WebDriver API for blocking 3P
cookies (https://crbug.com/1408969
<https://bugs.chromium.org/p/chromium/issues/detail?id=1408969>)
The resulting test coverage isn't terrible, but we're still
working to improve these underlying conditions to ensure better
coverage of edge cases and less flakiness on CI.
Flag name
StorageAccessAPI
Requires code in //chrome?
True, as we’re adding a new permission and integrating with FPS.
As mentioned in the FPS I2S, Chromium-based browsers should be
able to consume the list through component updater.
Tracking bug
https://crbug.com/989663 <https://crbug.com/989663>
Estimated milestones
Shipping in M113.
Anticipated spec changes
We recently made significant changes
<https://github.com/privacycg/storage-access/issues/122>to the SAA
that improve the security posture and overall API design. Most
notably, the new design has consensus across all three browsers,
greatly reducing interop and compat risks.
There are still some aspects of the API that are under active
discussion <https://github.com/privacycg/storage-access/issues>.
Most of the discussed changes will extend the capabilities of the
API and should be backwards-compatible (with one known exception
<https://github.com/privacycg/storage-access/issues/154>, where
it’s TBD whether the breaking change across all browsers is worth
the gain).
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5612590694662144
<https://chromestatus.com/feature/5612590694662144>
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4hnt1Rd5WSC%3DFU9dQriOP%3DKF0Cz9McxoT2_7UgP0u%3DKPw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4hnt1Rd5WSC%3DFU9dQriOP%3DKF0Cz9McxoT2_7UgP0u%3DKPw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUr%2BD%2BS0okoTeHy8dDA61JvLnmAqmRt96-1QQcwsC6nZw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUr%2BD%2BS0okoTeHy8dDA61JvLnmAqmRt96-1QQcwsC6nZw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68bdc703-b3cb-d393-8056-bab7dab7e63b%40chromium.org.
