Similar to my comments for Topics <https://groups.google.com/a/chromium.org/g/blink-dev/c/PN_aE-X-f9U/m/uKG9txUtDgAJ> 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. On Thu, Jun 22, 2023 at 11:24 AM Josh Karlin <[email protected]> wrote: > > > On Thu, Jun 22, 2023 at 9:35 AM Yoav Weiss <[email protected]> wrote: > >> >> >> On Wed, Jun 21, 2023 at 4:35 PM Ben Kelly <[email protected]> >> wrote: >> >>> 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 >>> <https://www.chromium.org/blink/spec-mentors/#reviewing-the-specification> >>> . >>> >>> 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. >>> >>> >>> On Tue, Jun 20, 2023 at 2:01 PM Josh Karlin <[email protected]> >>> wrote: >>> >>>> Contact emails >>>> >>>> [email protected], [email protected], [email protected], >>>> [email protected] >>>> >>>> >>>> >>>> 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 >>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EStorage%3ESharedStorage&can=2> >>>> >>>> TAG review >>>> >>>> TAG review <https://github.com/w3ctag/design-reviews/issues/747> >>>> >>>> TAG review status >>>> >>>> Open >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> >>>> Gecko: Negative >>>> <https://github.com/mozilla/standards-positions/issues/646> >>>> >>>> >>>> WebKit: Open <https://github.com/WebKit/standards-positions/issues/10>, >>>> 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 >>>> <https://github.com/WICG/shared-storage/blob/main/shared-storage-tester-list.md> >>>> 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 >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? >>>> >>>> Yes >>>> <https://wpt.fyi/results/shared-storage?label=master&label=experimental&aligned=> >>>> . >>>> >>> 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? 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. >>>> >>>> >> The explainer note about changes to the requirements around Fenced Frames >> <https://github.com/WICG/shared-storage#fenced-frame-enforcement> also >> seems relevant. Can you elaborate on those changes? >> > > 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 discussionsI2P >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/_quChIvPzT8/m/0W7IxD_1AAAJ> >>>> | I2E >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaNn%3DOwqymhbTRPfcY6zW-S4Gs9JFummJhU%3Dx%2BcoydV%2BYw%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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaOmcaZAPAgOg97yDtW%2BuEPMXnKb3nnth8GHS28KBqSAWQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaOmcaZAPAgOg97yDtW%2BuEPMXnKb3nnth8GHS28KBqSAWQ%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/CAK7rkMgNOyjRVpvaCSv9EkwoqmKaYv_ThXUOtHU%2BHtRr1T1AxA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMgNOyjRVpvaCSv9EkwoqmKaYv_ThXUOtHU%2BHtRr1T1AxA%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/CAL5BFfXMXx-JzptBZtcst0-O903TguUdGy5bwmFR_1_xK%2B0yBQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXMXx-JzptBZtcst0-O903TguUdGy5bwmFR_1_xK%2B0yBQ%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/CAANMuaPUMrviJ4-46iSkR5i3L3vAvmx3umC9Bgx-KcTmmanypg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaPUMrviJ4-46iSkR5i3L3vAvmx3umC9Bgx-KcTmmanypg%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/CAFUtAY8AhjyuOXiOd9tZz%2BubQ7RdFCQoeXKPVdmOOEN22htBbg%40mail.gmail.com.
