LGTM2
On Wed, Aug 16, 2023 at 7:31 PM Chris Harrelson
<chris...@chromium.org> wrote:
I agree with Chris F. that it's not worth the disruption to change
the name or its location, and that leaving the name as-is, even if
suboptimal, is a better outcome for web developers.
LGTM1
On Wed, Aug 16, 2023 at 9:37 AM 'Jeffrey Yasskin' via blink-dev
<blink-dev@chromium.org> wrote:
I see this as the other vendors endorsing Blink's general
policy, implied by the wording in
https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/#browser-engine-reviews,
that there's a high bar for name changes after shipping. If
this API, which has a clearly inaccurate name and was shipped
with no invitation for cross-vendor feedback, isn't worth
changing after shipping, then it's not worth changing most
APIs that Blink ships first either.
Jeffrey
On Wed, Aug 16, 2023 at 8:52 AM Alex Russell
<slightly...@chromium.org> wrote:
Hrm; the TAG had (many years ago, when I served) noted big
problems with the shape of this API. It's surprising we're
taking it as-is.
On Tuesday, August 8, 2023 at 9:08:43 AM UTC-7 Chris
Fredrickson wrote:
Hi Alex,
I hear you about the method names. However since
Safari, Firefox, and Edge had all previously shipped
this API using these names and web developers have
already begun using it, it would have been disruptive
for Chrome to force a rename. We opted to limit the
disruption we caused to improving the ergonomics and
security posture of the API instead (1
<https://github.com/privacycg/storage-access/pull/138>,
2
<https://github.com/privacycg/storage-access/pull/141>,
3
<https://github.com/privacycg/storage-access/pull/132>,
4
<https://github.com/privacycg/storage-access/pull/159>,
5
<https://github.com/privacycg/storage-access/pull/169>,
6
<https://github.com/privacycg/storage-access/pull/174>),
since that was indeed disruptive but there was at
least cross-browser interest in making those changes.
Re: navigator vs document, there was previous
discussion of this here
<https://github.com/privacycg/storage-access/issues/22>.
We did not specifically ask the TAG about which object
they preferred, but they closed their review with no
comments. Considering that each document's access is
independent of access obtained by other documents (due
to the per-frame security model), the choice of
document makes some sense to me, personally - but
there may be some best practice I'm unaware of.
FWIW, Chrome is exploring
<https://github.com/privacycg/storage-access/issues/102#issuecomment-1550967682>
ways to use document.requestStorageAccess() to provide
access to unpartitioned DOM storage in the future, in
which case the current name would be more appropriate.
Chris
On Monday, August 7, 2023 at 6:46:41 PM UTC-4 Alex
Russell wrote:
Hey Chris,
Thanks for the details here.
Can you perhaps outline why we didn't take the
opportunity here to rename this to better
represent what the API actually does? E.g.,
`requestUnpartitionedCookieAccess()`? And was any
effort made to move the API to a more suitable
object; e.g. `navigator`? Was this discussed with
the TAG?
Best,
Alex
On Monday, August 7, 2023 at 11:47:45 AM UTC-7
Chris Fredrickson wrote:
Hi Mike,
Sure. MDN has a section
<https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API#browser_storage_access_policy_variations>(which
may be incomplete or outdated) on the
implementation differences between Safari,
Firefox, and Chromium-based browsers. But
specifically related to the prompt
requirements, there are two aspects that may
cause compat issues:
1.
Permission lifetime. Storage Access grants
have different lifetimes in different
browsers, so web developers may have to
show a prompt more often than they expect:
1.
Firefox: 30 calendar days.
2.
Chrome: 30 calendar days.
3.
Safari: 30 days of browser usage.
2.
User interaction requirement. Whether a
user gesture is required by
document.requestStorageAccess() is
inconsistent across browsers:
1.
Firefox: always requires user
interaction. (This is a nonstandard
behavior, but it appears Firefox is
being updated
<https://phabricator.services.mozilla.com/D183175>to
not require user interaction in some
cases.)
2.
Chrome: requires user interaction
unless the user has already granted
access.
3.
Safari: always
<https://github.com/privacycg/storage-access/issues/172#issuecomment-1521653447>requires
user interaction. (This is a
nonstandard behavior.)
Since Firefox and Safari currently impose
stricter user interaction requirements than
what the spec dictates, this could lead to
compat issues if web developers assume that
browsers don't impose additional
browser-specific constraints.
There's one additional aspect, where web
developers may not need to call
document.requestStorageAccess() at all in
certain situations in some browsers (which
could lead to broken experiences if web
developers assume they can always omit the
explicit call):
* Firefox: if foo.example has obtained
storage access while embedded under
bar.example, and the user loads a
bar.example page that includes a
foo.example iframe, then that iframe will
load with implicit storage access --
without having to call
document.requestStorageAccess() first.
(This is a deviation from the
specification, but this part of the spec
was changed relatively recently
<https://github.com/privacycg/storage-access/issues/113>
for security reasons; Firefox is planning
<https://bugzilla.mozilla.org/show_bug.cgi?id=1837648> to
incorporate the recent changes.)
Chris
On Wednesday, August 2, 2023 at 5:02:35 PM
UTC-4 Mike Taylor wrote:
On 8/2/23 4:47 PM, Chris Fredrickson wrote:
Contact emails
cfred...@chromium.org,
johann...@chromium.org, shuu...@chromium.org
Explainer
https://github.com/privacycg/storage-access/blob/main/README.md
<https://github.com/privacycg/storage-access/blob/main/README.md>
https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md
<https://github.com/cfredric/chrome-storage-access-api/blob/main/README.md>
Specification
https://privacycg.github.io/storage-access
<https://privacycg.github.io/storage-access>
Summary
The Storage Access API provides a means
for authenticated cross-site embeds to
check whether access to unpartitioned
cookies is blocked and request access if
it is blocked. This request may be
surfaced to the user as a prompt, or
auto-granted/auto-denied. Chrome will
support the Storage Access API by
implementing all the behaviors listed in
the specification, i.e. with user
prompts, and additionally having its own
user-agent-specific behaviors. Chrome’s
implementation is available for testing
<https://github.com/cfredric/chrome-storage-access-api#testing-instructions>starting
in Chrome 117.
The Storage Access API is related to
other cookie-focused projects like CHIPS
<https://developer.chrome.com/en/docs/privacy-sandbox/chips/>and
First-Party Sets
<https://github.com/WICG/first-party-sets>as
preparation for phasing out third-party
cookies
<https://developer.chrome.com/en/docs/privacy-sandbox/third-party-cookie-phase-out/>in
Chrome.
Note that Edge previously sent an I2I
<https://groups.google.com/a/chromium.org/g/blink-dev/c/e5fu5Q06ntA/m/UUqPuA8hEQAJ>for
the Storage Access API feature (with
their own user-agent-specific behavior),
and Chrome has previously sent an I2S
<https://groups.google.com/a/chromium.org/g/blink-dev/c/V9PzoCvIIIs/m/CZ4JT7YaAgAJ>for
support for the Storage Access API gated
on First-Party Sets membership (without
user prompts). This I2S is intended for
support for the API across sites that are
not within the same First-Party Set.
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>(review
of overall API, not of prompts)
TAG review status
Positive
<https://github.com/w3ctag/design-reviews/issues/807#issuecomment-1431464692>
Risks
Interoperability and Compatibility
There is minor compatibility risk as
Firefox and Safari already differ
slightly in their user-agent-specific
prompt requirements. Chrome's planned
behavior
<https://github.com/cfredric/chrome-storage-access-api>is
closest to Safari's current behavior, and
we aim to standardize as much of this
user-agent-specific behavior as possible
over time.
Could you elaborate on the differences for
prompt requirements, and how that might
lead to compat issues?
Gecko: Shipping
WebKit: Shipping
Web developers: 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
onhttps://github.com/whatwg/html/issues/3338
<https://github.com/whatwg/html/issues/3338>and
filed issues
onhttps://github.com/privacycg/storage-access
<https://github.com/privacycg/storage-access>.
Other signals: Edge has shipped Blink's
previous implementations of this API,
which differ from Chrome's plans. We have
kept (and intend to continue keeping)
Edge engineers in the loop about these
changes and there will be feature flags
to control Blink's behavior.
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
None
Will this feature be supported on all six
Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)?
No. It will be supported on all Blink
platforms except Android WebView
initially. We may add WebView support in
the future.
Is this feature fully tested by
web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
No. Browser UI is not testable by WPTs,
since that is UA-specific. (The Storage
Access API spec itself is tested by WPTs
<https://wpt.fyi/results/storage-access-api>.)
Flag name on chrome://flags
#storage-access-api,
#permission-storage-access-api
Finch feature name
StorageAccessAPI, PermissionStorageAccessAPI
Non-finch justification
None
Requires code in //chrome?
True
Estimated milestones
Shipping on desktop: 117
Shipping on Android: 120
Anticipated spec changes
Some minor changes are expected in order
to properly take user settings into
account:
https://github.com/privacycg/storage-access/pull/174
<https://github.com/privacycg/storage-access/pull/174>and
an analogous change for
document.requestStorageAccess.
There is ongoing discussion
<https://github.com/privacycg/storage-access/issues/102>on
how to offer access to unpartitioned DOM
storage via this API.
The spec has been in incubation being
co-developed by all three browser engines
for a while and is close to graduation as
tracked here:
https://github.com/whatwg/html/issues/9000
<https://github.com/whatwg/html/issues/9000>.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5085655327047680
<https://chromestatus.com/feature/5085655327047680>
Links to previous Intent discussions
Intent to prototype: Intent to Prototype:
Storage Access API with Prompts
<https://groups.google.com/a/chromium.org/g/blink-dev/c/zt-nqGpURNY/m/FF6ciM6qAwAJ>
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/5e44f071-97ba-41e0-a0cd-7bd3a210d6bdn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e44f071-97ba-41e0-a0cd-7bd3a210d6bdn%40chromium.org?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/8884e737-21c8-4c01-9cc3-caaf125e52e2n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8884e737-21c8-4c01-9cc3-caaf125e52e2n%40chromium.org?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/CANh-dXnGvxVw8CwP1sPk-%2Bxf-ObjuTxXe2a9LdaSe2g6wv0d1w%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANh-dXnGvxVw8CwP1sPk-%2Bxf-ObjuTxXe2a9LdaSe2g6wv0d1w%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/CAOMQ%2Bw9iRq4Z75qEhWP9rFAGUStasGVCi6wc4btVT2-CoJiuHw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9iRq4Z75qEhWP9rFAGUStasGVCi6wc4btVT2-CoJiuHw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
