LGTM2
/Daniel
On 2024-03-20 16:14, Yoav Weiss (@Shopify) wrote:
LGTM1
The signals from other vendors and the CG discussion seem encouraging
and I agree that the future risk from an "all" value is probably
outweighed by its developer-facing benefits.
On Wed, Mar 20, 2024 at 12:56 PM Ari Chivukula <[email protected]>
wrote:
I'd guess that, in the future, the semantics around 'all' may
change in one of two ways:
(A) If storage methods included are deprecated, (1) we would start
warning developers via a DevTools issue when they use 'all', (2)
we would start requiring the deprecated method was specifically
included in the call to rSA rather than it being automatically
included in all, (3) the storage method would be removed from rSA.
The timeline for this would likely be rather long (alongside the
timeline for the deprecation of the storage method itself).
(B) If a new storage method were proposed, (1) we would allow
developers to use it if explicitly included in rSA (but not add it
via all) and then (2) add it under 'all' once it had fully launched.
The chances of a new storage method being added we (1) do want in
rSA but (2) wouldn't ever want under 'all' is low I think. All of
the storage/communication mechanisms besides local/session storage
either have async APIs or don't expose events to monitor changes
that would require full loading of data simply because the
handle/constructor was made available. I agree there is a
potential for a footgun here, but given the direction these APIs
seem to be heading I don't think the risk is high. What are the
chances vendors decide to add new storage mechanisms that are
loaded at document initialization with all data synchronously
available?
~ Ari Chivukula (Their/There/They're)
On Wed, Mar 20, 2024 at 7:48 AM Yoav Weiss (@Shopify)
<[email protected]> wrote:
On Wed, Mar 20, 2024 at 12:40 PM Ari Chivukula
<[email protected]> wrote:
I think the last place it came up was in this thread:
https://github.com/mozilla/standards-positions/issues/898#issuecomment-1745688352
I think it came up at TPAC, but I might me missing the
right line:
https://github.com/privacycg/meetings/blob/a27d3ee4c596efb5aec7d16feda2708fbd60eacf/2023/tpac/minutes.md?plain=1#L302
Either way, there hasn't been further concern raised
recently so we moved forward with 'all' since the function
is async (the delay from loading local/session storage
isn't high, and it was often already loaded given the
requirement to have interacted with the iframe's site in a
top-level context in the past).
The only concern I may have on the "all" front is related to
changing semantics. How likely are we to add future storage
mechanisms that users would not want to expose along with
current ones?
~ Ari Chivukula (Their/There/They're)
On Wed, Mar 20, 2024 at 7:29 AM Yoav Weiss (@Shopify)
<[email protected]> wrote:
On Thursday, March 14, 2024 at 2:27:20 PM UTC+1 Ari
Chivukula wrote:
Contact emails
[email protected]
<mailto:[email protected]>,
[email protected]
<mailto:[email protected]>,
[email protected]
<mailto:[email protected]>,
[email protected] <mailto:[email protected]>
Specification
https://privacycg.github.io/saa-non-cookie-storage/
<https://privacycg.github.io/saa-non-cookie-storage/>
Design Doc
https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4JtpaTFgFVlWLXNOQ6c/edit
<https://docs.google.com/document/d/19qCGb4qwOcGiNrQM3ptWvRmB4JtpaTFgFVlWLXNOQ6c/edit>
Feedback
https://github.com/privacycg/saa-non-cookie-storage/issues
<https://github.com/privacycg/saa-non-cookie-storage/issues>
Intent to Prototype
https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0
<https://groups.google.com/a/chromium.org/g/blink-dev/c/inRN8tI49O0>
Intent to Experiment
https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s
<https://groups.google.com/a/chromium.org/g/blink-dev/c/SEL7N-xIE5s>
https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw
<https://groups.google.com/a/chromium.org/g/blink-dev/c/AjH7tGxuVuw>
Summary
This launches the proposed extension of the
Storage Access API
<https://webkit.org/blog/8124/introducing-storage-access-api/>(backwards
compatible and currently in OT) to allow access to
unpartitioned cookie and non-cookie storage in a
third-party context. The current API only provides
access to cookies, which have different use-cases
than non-cookie storage (discussed more in the
Motivation section). The API can be used as
follows (JS running in an embedded iframe):
// Request a new storage handle via rSA (this may
prompt the user)
let handle = await
document.requestStorageAccess({all: true});
// Write some 1P context sessionstorage
handle.sessionStorage.setItem("userid", "1234");
// Write some 1P context localstorage
handle.localStorage.setItem("preference", "A");
// Open or create an indexedDB that is shared with
the 1P context
let messageDB = handle.indexedDB.open("messages");
// Use locks shared with the 1P context
await handle.locks.request(“example”, …);
The same flow would be used by iframes to get a
storage handle when their top-level ancestor
successfully called requestStorageAccessFor
<https://github.com/privacycg/requestStorageAccessFor>,
just that in this case the storage-access
permission was already granted and thus the
requestStorageAccess call would not require a user
gesture or show a prompt, allowing for “hidden”
iframes accessing storage.
Beyond calling this additional extension, access
to non-cookie storage would match the current
requirements for cookie access through the Storage
Access API.
DOM Storage (session and local storage), Indexed
DB, Web Locks, Cache Storage, Origin Private File
System, Quota, Blob Storage, Broadcast Channel,
and SharedWorkers will be available.
Blink component
Blink>StorageAccessAPI
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EStorageAccessAPI>
Motivation
There has been increasing developer
<https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124>and
implementer
<https://github.com/privacycg/storage-access/issues/102>interest
in first-party DOM Storage
<https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API>and
Quota Managed Storage
<https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API>being
available in third-party contexts the same way
that cookies can be today
<https://github.com/privacycg/storage-access>. In
the absence of such a solution, browsers would in
effect be pushing developers to migrate to cookies
from other storage mechanisms. There are tradeoffs
between cookie and non-cookie storage (size,
flexibility, server exposure, network request
size, etc.) that could impact user experience from
a privacy, security and performance perspective
(e.g., cookies are included in HTTP requests and
not just available via JavaScript). To prevent
sub-optimal use of cookies and to preserve
context, we propose a solution for developers to
regain 3p access to unpartitioned storage to avoid
user-facing breakage in browsers shipping storage
partitioning.
TAG review
https://github.com/w3ctag/design-reviews/issues/906
<https://github.com/w3ctag/design-reviews/issues/906>
Compatibility
The Storage Access API is already implemented in
Safari, Firefox, and Chrome
<https://caniuse.com/mdn-api_document_requeststorageaccess>,
but the proposed API shape would preserve existing
behavior until the web developer adds new arguments.
Interoperability
Gecko: No Position Yet
https://github.com/mozilla/standards-positions/issues/898
<https://github.com/mozilla/standards-positions/issues/898>
Despite the lack of an official position, the
discussion seems encouraging. I sympathize with
concerns around "all"'s semantics and their future
compat impact.
Was this point discussed in the CG or elsewhere?
WebKit: No Position Yet
https://github.com/WebKit/standards-positions/issues/262
<https://github.com/WebKit/standards-positions/issues/262>
Web developers: Positive
<https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/124>
Debuggability
Storage written can be examined in devtools.
Is this feature fully tested by web-platform-tests?
Yes
<https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/storage-access-api/>
Tracking bug
https://issues.chromium.org/40282415
<https://issues.chromium.org/40282415>
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5175585823522816
<https://chromestatus.com/feature/5175585823522816>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJvYhyvgmmBgXxH3rXoQtdMJ1_kk4PRqOrNc9Qq16HeEg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJvYhyvgmmBgXxH3rXoQtdMJ1_kk4PRqOrNc9Qq16HeEg%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a640c694-e866-45dd-9268-55f2f992885a%40gmail.com.
