Hi blink-dev,
> Hmm, that extra complexity seems a bit unfortunate, but oh well; I'm
happy to trust your judgement that it's the best path. Please keep us
updated on the spec and test work for that extra integration!
The Storage Access API non-cookie storage spec [1] and corresponding
Chromium implementation had already planned to allow access to
first-party Blob URLs from third-party contexts after a storage handle
had been granted, and I think it makes sense w.r.t. consistency
(effectively providing workarounds for all of the APIs changed as part
of the Storage Partitioning effort). Regarding spec work for this, I
opened a spec bug [2] to discuss this further and it seems that what's
needed is the core work still required to make the Storage Access API
for non-cookie storage spec actually bypass storage partitioning for
the other storage APIs as well (which is still blocked on the Storage
Key having more than just an origin [3]). I plan to follow-up on that
spec work, but propose we don't block shipping this Blob URL
partitioning effort on this broader work. Regarding testing, we've
added WPTs for the integration, including for cases such as when a
Blob URL fetch occurs from a dedicated worker created after storage
access has been granted to the document context that created it.
Regarding potential for breakage, the new use counter we added that
better reflects the potential for breakage is in Chrome Beta, Dev, and
Canary and the % of page loads affected is very low (currently
0.000001%) [4]. For Chrome we have an enterprise policy that can be
used if there is breakage, we have a killswitch we can use to disable
the feature broadly if major breakage is encountered, and we've also
added a chrome://flags entry that can be used to disable the feature
by users directly. I think it's safe to conclude that this change is
safe but in the worst case we can mitigate breakage effectively if we
need to.
Assuming Domenic's LGTM still stands, it looks like we still need two
more. Would any other Blink API owners support moving forward with this?
Thank you!
-Andrew
[1] https://privacycg.github.io/saa-non-cookie-storage/#document-changes
[2] https://github.com/privacycg/saa-non-cookie-storage/issues/34
[3] https://github.com/whatwg/storage/pull/144
[4] https://chromestatus.com/metrics/feature/timeline/popularity/5330
On Tue, Mar 4, 2025 at 8:46 PM Domenic Denicola <dome...@chromium.org>
wrote:
On Wed, Mar 5, 2025 at 2:35 AM Andrew Williams
<awil...@chromium.org> wrote:
Hi everyone,
Quick update on this. We landed a new use counter
implementation last week that better gauges actual breakage,
and preliminary data from Chrome Canary shows that no
instances of breakage were detected except for a few from
yesterday, and those likely correspond to me running the
partitioning tests on wpt.fyi locally to confirm that the use
counter actually works as intended. :) For reference, there
are orders of magnitude more instances of
the BlobStoreAccessAcrossTopLevelSite use counter (which we
used for the previous breakage analysis) being reported for
the same Chrome Canary clients and during the same time
period. I'll check the "real" use counter data once it's
available in Chrome Status, but I suspect the percentage of
page loads that would break will be significantly lower than
we calculated earlier.
Also, before launching we plan to integrate with the Storage
Access API so that contexts that have been granted a
StorageAccessHandle will still be able to fetch Blob URLs in
the same way they could before this change (so, without regard
to top-level site or the "has-cross-site-ancestor" boolean)
Hmm, that extra complexity seems a bit unfortunate, but oh well;
I'm happy to trust your judgement that it's the best path. Please
keep us updated on the spec and test work for that extra integration!
-Andrew
On Mon, Feb 10, 2025 at 2:34 PM Andrew Williams
<awil...@chromium.org> wrote:
Thanks Yoav, responses inline!
> So the upper bound for potential breakage is 0.04%?
I believe this is a reasonable estimate, although I think
it assumes that page loads are evenly distributed across
UMA-enabled clients and I'm not sure whether that's the case
> Are there ways to tighten it? (e.g. through manual
sampling or use-counter changes)
Regarding manual sampling, we could investigate by looking
at the domains associated with an existing use counter for
this:
https://chromestatus.com/metrics/feature/timeline/popularity/4169.
I suspect that the majority of cases we would encounter
would be the cross-origin fetches that are already
blocked, though, matching the high percentage of these in
our metrics.
Making use-counter changes is certainly an option if the
consensus is that the upper bound still seems too risky
(even given that Firefox and Safari currently ship this
behavior and given the proposed mitigations).
Alternatively, we could enable this functionality in
Chrome Canary, Dev, and Beta for a few weeks and see if we
get any bug reports. WDYT?
> What does breakage look like? What do these sites see in
Safari today?
Blocking cross-partition fetches / subframe navigations is
implemented in both Firefox and Safari today, so for both
of those browsers the fetch / navigation fails and
DevTools shows a warning message. The partitioning scheme
is slightly different across browsers - Safari partitions
by top-level origin and Firefox partitions by top-level
site + whether there was a cross-site frame in the frame
tree, and the Chrome behavior will match the Firefox
behavior for this.
-Andrew
On Sun, Feb 9, 2025 at 11:21 PM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
Thanks for the compat analysis!
On Fri, Feb 7, 2025 at 6:48 PM Andrew Williams
<awil...@chromium.org> wrote:
Hey everyone,
From looking at use counters for these cases,
cross-top-level-site Blob URL navigations that
would have noopener set as part of this change are
seen on 0.0004% of page loads. Note that this is
calculated from data from pre-stable channels and
could change when looking at Stable data, but it
seems unlikely to change by orders of magnitude.
For cross-partition Blob URL fetches, these occur
on 0.21% of page loads, but from digging into this
more and from looking at UMA data, at least 83% of
those cross-partition Blob URL fetches are
guaranteed to be blocked today because they are
also cross-origin, and only ~21% of UMA-enabled
clients reported at least one cross-partition
fetch that wasn't guaranteed to be blocked. It's
likely that the remaining 17% of cross-partition
Blob URL fetches are cross-origin as well and
would already be blocked, but our current use
counter / metrics implementations don't provide a
way to gauge this. More details on this analysis
can be found at: https://crbug.com/387655548#comment2
So the upper bound for potential breakage is 0.04%?
If so, that's too high for comfort from my perspective.
Are there ways to tighten it? (e.g. through manual
sampling or use-counter changes)
What does breakage look like? What do these sites see
in Safari today?
Overall I think the use counter metrics +
supporting UMA data support moving forward with
this change, as does the fact that Firefox and
Safari have already implemented similar
functionality. If there is breakage as a result of
this, we do have an enterprise policy to disable
it, we'll have a chrome://flags entry so that
users can disable it, and we'll have a Finch
feature flag as a killswitch for any cases of
widespread, significant breakage.
Regarding formal signals from Gecko and Webkit, we
opened one from Gecko but haven't heard anything:
https://github.com/mozilla/standards-positions/issues/1151.
For WebKit, we reached out regarding whether we
should open one and they mentioned they didn't
think we needed to, given that we plan to
implement what the functionality they have
already, just using sites instead of origins.
-Andrew
On Thu, Dec 12, 2024 at 12:35 PM Andrew Williams
<awil...@chromium.org> wrote:
Thanks Domenic, we've landed a change to
remove .tentative from the test file names:
https://chromium-review.googlesource.com/c/chromium/src/+/5967596
Gregg, IIUC
"top-level->iframe(blob-from-top-level)" means
the top-level creates a blob URL and then
creates an iframe where the src is that blob
URL. Similarly,
"top-level->iframe(3rd-party)->iframe(blob-from-3rd-party)"
means that the 3rd-party iframe creates a blob
URL and then creates an iframe where the src
is that blob URL. Neither of those cases will
be affected by this change.
Daniel, thanks for the feedback. We will
collect use counts on this and report back
once the data is available (should be around
mid-February). In the meantime, we will
request formal signals from Gecko and WebKit
as you recommended.
On the topic of alignment across browsers, the
I2S mentions that all navigations will remain
partitioned only by frame origin, but I
learned recently that Safari and
Firefox partition subframe navigations (like
using a blob URL as the src of an iframe) by
storage key / the top-level as well (and this
is what was originally proposed in
https://github.com/w3c/FileAPI/issues/153).
It's only top-level navigations that remain
partitioned only by frame origin. Our
implementation will follow suit. I'll update
the Chrome Status description accordingly.
-Andrew
On Wed, Dec 11, 2024 at 11:38 AM Daniel
Bratell <bratel...@gmail.com> wrote:
After discussing this on the API OWNER
meeting I have a few questions and
suggestions.
My main concern is that we don't have full
understanding of the compatibility risk.
We believe this is rare, but do we have
any hard data to confirm that? If not,
would it be possible to add a targetted
use counter that counts the cases where a
page tries to use a broken blob?
I think you should also request formal
signals from Gecko and WebKit since this
is not exactly what they have done. It
seems from what you write that we're
getting something very slightly different
(which also means that what seems to work
for them might still break in Chromium).
/Daniel
On 2024-12-10 03:29, Domenic Denicola wrote:
LGTM1, nice work on all the spec changes
here!
Please send a web platform tests PR to
remove the .tentative.html from the test
filenames.
On Tue, Dec 10, 2024 at 10:49 AM Gregg
Tavares <g...@chromium.org> wrote:
Sorry if I'm not up on all of the
latest. I have several sites that use
blobs in iframes to implement user
code execution (think
JSFiddle/Codepen). Do I need to be
worried?
Some use
top-level->iframe(blob-from-top-level).
Others use
top-level->iframe(3rd-party)->iframe(blob-from-3rd-party)
They all currently work across
browsers so I'm guessing I don't need
to worry if Firefox and Safari
already implement this.
--
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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8377qyjY1fv99%2BnDhJZjWN8j9CdGFLsuwrZVyHJYwUMg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8377qyjY1fv99%2BnDhJZjWN8j9CdGFLsuwrZVyHJYwUMg%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 visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVgqdOa3MKSoUqvfdH3thYyqm3pM9Paib2frzALG3BhrQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEa0%2BkVgqdOa3MKSoUqvfdH3thYyqm3pM9Paib2frzALG3BhrQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
