On Friday, December 20, 2024 at 6:34:04 PM UTC+1 Josh Karlin wrote:
Contact emails yao...@chromium.org cam...@chromium.org jkar...@chromium.org rohitgu...@chromium.org ren...@google.com saraak...@google.com Explainer https://github.com/WICG/shared-storage/pull/199 Are there any explainer sections you can point at that won't require reading through PR diffs? Specification https://github.com/WICG/shared-storage/pull/209 https://github.com/WICG/shared-storage/pull/211 (anticipated) https://github.com/WICG/shared-storage/pull/213 (anticipated) Are the "anticipated" parts part of this intent? Are you planning to land those PRs before shipping? Summary Today, concurrent execution of shared storage worklets can lead to data inconsistencies due to race conditions. To address this issue, we propose integrating the Web Locks API into Shared Storage: 1. The navigator.locks.request() API is exposed to the shared storage worklet, to be able to request a lock and handle callback after the lock is granted. 2. All shared storage modifier methods now accept an optional { withLock: <lock name> } parameter. The modifier method will acquire the lock on the designated resource before executing. 3. A batchUpdate(methods, options) API is introduced in all applicable contexts. It first acquires a lock on the designated resource and then executes methods in order. 4. The 'Shared-Storage-Write' response header is now treated as a single batchUpdate(), and allows configuring a lock for the entire batch via: "options; with_lock=<lock name>". The shared storage locks' partition aligns with the shared storage data's partition -- locks are organized by the shared storage origin, and are independent from any locks used in Window or Worker context. Blink component Blink>Storage>SharedStorage <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EStorage%3ESharedStorage&can=2> TAG review FYI <https://github.com/w3ctag/design-reviews/issues/747#issuecomment-2557353877> TAG review status TAG is unsatisfied <https://github.com/w3ctag/design-reviews/issues/747> with the underlying API Risks Interoperability and Compatibility The changes are fully backward compatible. Gecko: No signal WebKit: No signal Web developers: Web locks were requested by developers for use with private aggregation. 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? - None Security / Privacy No concerns. Shared Storage web locks have their own partition which is not readable in normal js contexts. The scope and visibility of Shared Storage web locks aligns with the scope (i.e., per-origin) and visibility (i.e., only the worklet is allowed to read/wait on a lock) of shared storage data. Debuggability Shared Storage worklets can be inspected within DevTools: Debug Shared Storage worklets with DevTools <https://developers.google.com/privacy-sandbox/private-advertising/shared-storage/debugging#debug_shared_storage_worklets_with_devtools> We are working on adding the `withLock` parameter and a `batchUpdate()` event to the Application -> Shared Storage panel in DevTools. 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 Finch feature name SharedStorageWebLocks Requires code in //chrome? No Estimated milestones M133 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5133950203461632 -- 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/0d400b84-2794-4d67-a407-ed211e58ed8dn%40chromium.org.
