Intent to Ship: Shared Storage API

700 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Josh Karlin

ungelesen,
20.06.2023, 14:01:1920.06.23
an blink-dev, Yao Xiao, cam...@chromium.org, ale...@chromium.org, Asha Menon, Emily Keuthen

Contact emails

yao...@chromium.org, cam...@chromium.org, ale...@chromium.org, jka...@chromium.org



Explainer

https://github.com/WICG/shared-storage


Specification

https://wicg.github.io/shared-storage/


Summary

Shared Storage provides a general purpose privacy primitive for use cases where a small amount of cross-site data is required. It is comprised of a storage API (writes available from anywhere, reads only in isolated javascript environments called worklets) and a set of output gates which significantly limit the amount of cross-site information that can be read externally.


Blink component

Blink>Storage>SharedStorage


TAG review

TAG review


TAG review status

Open


Risks


Interoperability and Compatibility


Gecko: Negative


WebKit: Open, though concerns have been raised.


To reduce risk in the event that we later decide to replace this API with one that has more browser support, the API can be effectively disabled without breaking pages. That is, writing to shared storage can be a noop, selectURL can simply select the first URL, and run can be a noop.


Web developers


We have several developers testing the API in OT and initial feedback has been positive.


Other signals:


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

Shared Storage database contents for an origin can be viewed and modified within devtools. Support for debugging Shared Storage js worklets via devtools is planned for the near future.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

All but WebView


Is this feature fully tested by web-platform-tests?

Yes


Flag name

SharedStorageAPI


Requires code in //chrome?

No


Anticipated spec changes

  • We intend to limit the max worklet duration of the run() operation in the near future. This isn’t script breaking but for very slow operations the returned value may be sub-optimal.

  • We’re exploring new output gates (e.g., potentially a highly noised local differential privacy gate) but no solid plans as of yet. These would be backwards compatible.

  • Exploring new communication methods between origins within worklets. No expectation that this would cause compat issues.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6256348582903808


Links to previous Intent discussions

I2P | I2E

Ben Kelly

ungelesen,
21.06.2023, 10:35:0521.06.23
an Josh Karlin, blink-dev, Yao Xiao, cam...@chromium.org, ale...@chromium.org, Asha Menon, Emily Keuthen
I was the spec mentor for shared storage and worked with Cammie on the spec.  I'd just like to add my thoughts to provide the requested spec maturity summary.

Overall I think the spec process model has reached a high level of quality.  In particular, we paid special attention to make sure it integrates with the storage spec data model and resource timing's time source model.  Cammie has been very receptive to feedback and continues to make improvements to the spec.

Of course, it is a complex spec and there has not been a second implementation yet.  We should expect some corner cases or nuanced issues to be reported when that next implementation is done.  Pending that, however, I think the spec is as high quality as we can get at this stage.


--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaOmcaZAPAgOg97yDtW%2BuEPMXnKb3nnth8GHS28KBqSAWQ%40mail.gmail.com.

Yoav Weiss

ungelesen,
22.06.2023, 09:35:0422.06.23
an Ben Kelly, Josh Karlin, blink-dev, Yao Xiao, cam...@chromium.org, ale...@chromium.org, Asha Menon, Emily Keuthen
The explainer note about changes to the requirements around Fenced Frames also seems relevant. Can you elaborate on those changes?
 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6256348582903808


Links to previous Intent discussions

I2P | I2E

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaOmcaZAPAgOg97yDtW%2BuEPMXnKb3nnth8GHS28KBqSAWQ%40mail.gmail.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+...@chromium.org.

Josh Karlin

ungelesen,
22.06.2023, 11:24:2722.06.23
an Yoav Weiss, Ben Kelly, blink-dev, Yao Xiao, cam...@chromium.org, ale...@chromium.org, Asha Menon, Emily Keuthen
Yes, thanks for pointing that out as it's certainly relevant! The same will be true for Protected Audiences. We're gradually transitioning developers to a more private rendering environment (via fenced frames). Right now `selectURL` can either return a URN that is renderable in an iframe, or a fenced frame config which must be rendered in a fenced frame. Eventually, we'll transition to only returning fenced frame configs. This will require a deprecation of sorts, and lots of advanced notice. In our favor is the fact that while a very large fraction of page loads may be impacted, only a handful of companies are expected to call the API and they're more active/responsive than many sites. Also, we can make the deprecation non-breaking (for the page) by returning an empty URN rather than removing the interface. It may impact the page's monetization or functionality until they switch over however.
 
 

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6256348582903808


Links to previous Intent discussions

I2P | I2E

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaOmcaZAPAgOg97yDtW%2BuEPMXnKb3nnth8GHS28KBqSAWQ%40mail.gmail.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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMgNOyjRVpvaCSv9EkwoqmKaYv_ThXUOtHU%2BHtRr1T1AxA%40mail.gmail.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+...@chromium.org.

Rick Byers

ungelesen,
22.06.2023, 16:03:0222.06.23
an Josh Karlin, Yoav Weiss, Ben Kelly, blink-dev, Yao Xiao, cam...@chromium.org, ale...@chromium.org, Asha Menon, Emily Keuthen
Similar to my comments for Topics there's obviously a lot of interop risk around whether this sort of capability will be part of the web long-term or not, but I think shipping this in Chromium is the next logical step in moving the debate forward. Although I sympathize with the sentiment in Mozilla and Apple feedback about complexity, I'm personally inspired by the effort to go down this "isolated execution environment" path as I think it has the potential to open up a whole new class of techniques for improving privacy - someone should try! I appreciate the thought on mitigating future web compat risks and agree that reduces the need for concern significantly. I skimmed through the open spec issues and don't see anything that seems like it needs to block launch.

Overall I don't see anything that could reasonably be done to reduce future interop risk, so LGTM1 from me.

Is there a known issue for the tests failing on wpt.fyi with --enable-experimental-web-platform-features? I assume they're largely passing in chromium infrastructure?

Chris Harrelson

ungelesen,
22.06.2023, 16:13:5822.06.23
an Rick Byers, Josh Karlin, Yoav Weiss, Ben Kelly, blink-dev, Yao Xiao, cam...@chromium.org, ale...@chromium.org, Asha Menon, Emily Keuthen

Mike Taylor

ungelesen,
22.06.2023, 16:14:4422.06.23
an Chris Harrelson, Rick Byers, Josh Karlin, Yoav Weiss, Ben Kelly, blink-dev, Yao Xiao, cam...@chromium.org, ale...@chromium.org, Asha Menon, Emily Keuthen
Allen antworten
Antwort an Autor
Weiterleiten
0 neue Nachrichten