Web Locks

[marcoscaceres]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Web Locks
• Specification or proposal URL: https://wicg.github.io/web-locks/
• Explainer: https://github.com/WICG/web-locks/blob/master/EXPLAINER.md
• Chrome Intent to implement

Other information

Google is proposing, "a new web platform API that allows script to asynchronously acquire a lock over a resource, hold it while work is performed, then release it. While held, no other script in the origin can acquire a lock over the same resource. This allows contexts (windows, workers) within a web application to coordinate the usage of resources."

[marcoscaceres]

Added link to Chrome's Intent to implement.

[dbaron]

We spent a good bit of time discussing this at the last TAG meeting, which is decently documented in w3ctag/design-reviews#217 (see Andrew's summary of the discussion, which I agree with).

[bzbarsky]

So this is not subject to deadlock in terms of blocking the world, right? Async functions can still get blocked, but that sort of thing is not going to block user interaction, at least, apart from the extent to which those async functions generate the content the user is expected to interact with...

It sounds like the scope of the lock is cross-process. What is the actual scope? I think it's expected to be cross-tabgroup; the explainer explicitly says so. Clearly it's not expected to be cross-browser. Is it expected to be cross-profile? Cross-container? What if we introduce more fine-grained privacy boundaries? At what point can these locks be effectively used for tracking across different privacy contexts?

[inexorabletash]

Not sure if it's appropriate for me to chime in or not; apologies if this is intended for folks within the org to discuss.

So this is not subject to deadlock in terms of blocking the world, right?

Correct.

What is the actual scope?

Since I'm coming from a storage API background (local storage, Indexed DB, cache API, etc), I would define it as having the same scope as storage APIs, i.e. if two bits of code see the same storage, they're same scope. So whatever name you give to that scope. A useful privacy context presumably includes separation of storage. This would manifest most interestingly today in Safari with it's dual-keyed storage, i.e. http://example.com in a cross-origin subframe does not have the same storage scope as http://example.com in a top-level window, so presumably it should also have a different lock scope.

I don't think we currently distinguish contexts more granular than "user agent" in spec language. If we do, I'd be very happy to add such text to clarify; I did attempt to describe this briefly in the security/privacy self assessment which would evolve into the Privacy section of an eventual spec.

[marcoscaceres]

@inexorabletash, you are absolutely invited to chime in. As the person proposing this, we won't be able to answer a lot of questions without your help! (so thanks already for jumping in!)

[dbaron]

I don't think we currently distinguish contexts more granular than "user agent" in spec language.

Spec language is just the language used in specs; you're welcome to add to it. I think the spec should describe that it should be tied to storage scope if that's the intent. If another spec (the Storage Standard might be a reasonable candidate) defines terms you can link to, great; if not, describe them as clearly as you think is reasonable.

[dbaron]

... though also, one of the reasons for consistency in language (and linking to definitions) is to avoid having things that are very similar, but slightly different for no good reason, since those differences introduce complexity. So if somebody else is trying to define the same things, please share.

[bzbarsky]

This would manifest most interestingly today in Safari

That is why we need to have this defined. Right now in Safari two things that have synchronous DOM access to each other may not have the same storage scope if I understand correctly. (Or am I wrong about how their setup works?) If so, is it expected that two pieces of code that can touch each other sync would have different web lock scope?

I don't think we currently distinguish contexts more granular than "user agent" in spec language.

Sure we do. There is https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-browsing-contexts and https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-similar-origin-browsing-contexts for example. But the web lock spec explicitly says it wants to cross those boundaries, again afaict.

Speaking of which, can service workers hold web locks? What happens on service worker restarts?

In general, I would assume that killing a process holding the web lock is expected to drop the lock, if the locks can cross process boundaries, right?

[inexorabletash]

(FYI, I'll be out of the office for about a week, so won't be able to spend much time on this.)

That is why we need to have this defined.

Agreed!

...in Safari two things that have synchronous DOM access to each other may not have the same storage scope...

That seems like it would be weird from a privacy perspective, but we need to test.

Sure we do...

Sorry, my bad. I meant from the "other direction" - I don't think we define separate user profiles or incognito/off-the-record/private/etc browsing sessions as anything different from "user agent", do we? i.e. we pretend those are separate user agents, from a spec perspective. (I'm probably wrong here...)

the web lock spec explicitly says it wants to cross those boundaries, again afaict

Yes, like storage visibility. (And since I haven't said it already: thanks for pointing out that this was implicit on my part and not called out! I'll make this explicit in the explainer as well.)

Another example of the same scope I'm envisioning that comes to mind is that used by BroadcastChannel so I can probably lift some wording from there. I note that it calls out e.g. "opened by the same user in the same user agent" which may be a place where we do distinguish profiles scope vs. user agent scope.

What happens on service worker restarts?

Yes they can hold them, and the lock would be lost. A process holding a lock would drop it. I attempted to explain that in Agent Integration but it seems like the cross-spec hooks are inadequate at the moment - tracking issue

[bzbarsky]

i.e. we pretend those are separate user agents, from a spec perspective

It depends. In Firefox, I think profiles are separate user agents. I think private browsing vs not are separate user agents, but confidence is about 90% on that. Separate containers are not separate user agents. For example, I believe they share a single "visited link" database, so that if I visit a page in one container links to it it will match :visited in all containers. They do have separate storages, though.

Another example of the same scope I'm envisioning that comes to mind is that used by BroadcastChannel

Good point. Even just defining that these things all have the same scope, whatever that scope is, would be useful, so implementors don't make different decisions for them when implementing new privacy/isolation primitives.

[inexorabletash]

FYI, I did some brief testing in Safari. Indentation indicates nested tabs/frames, letter (A,B) indicates origin, number (1, 2) is to distinguish in discussion

Case one:

• tab: A 1
  • iframe: B
    • iframe: A 2

A 1 and A 2 share storage

Case two:

• tab: A 1
  • iframe: B 1
• tab: B 2
  • iframe: A 2

A 1 and A 2 do not share storage (and neither do B 1 / B 2, of course).

[bzbarsky]

Case two:

In case 2, did "A 1" do the window.open to create the window that "B 2" was then loaded in?

[inexorabletash]

did "A 1" do the window.open to create the window that "B 2" was then loaded in?

(updates test...) Yes. B2 is opened by A1, A2 does not see the same storage as A1.

[bzbarsky]

So what happens when A2 pokes at the A1 storage via openedWindow.frames[0].localStorage or whatnot? It sees a separate storage?

[inexorabletash]

Apologies for letting this idle for a while. I'll get back to poking at storage APIs in Safari when I can.

I've started collapsing the README and proto-spec into an actual Bikeshed spec (using the WICG template for now), visible at: https://inexorabletash.github.io/web-locks/ - still very rough at a micro- and macro- level.

Otherwise... anything that I can answer about the proposal? Any support for moving the public discussion to WICG ? (No need indicate a position)

[asutherland]

I think we're ready to begin implementing this in 2019H2. The meta-issues about partitioning have been addressed by changes to the spec and the Gecko (internal) formalization of (effective) StoragePrincipal at https://searchfox.org/mozilla-central/source/toolkit/components/antitracking/StoragePrincipalHelper.h as an outgrowth of tracking protection.

The big problem is agent termination observability for ServiceWorkers. I've made a comment at w3c/web-locks#24 (comment) that proposes we break all locks/requests when the ServiceWorker becomes eligible for termination because there are no remaining pending events. For bfcache and windows, I think we just make windows ineligible for bfcache if they have an outstanding request or lock. If we implemented the page-lifecycle spec and document.onfreeze, that might change, but I'm not currently aware of any plans to implement page-lifecycle.

Are there any reasons to not go ahead?

[martinthomson]

It sounds as though you believe this is worth prototyping. In that case, perhaps you could open a pull request on this repository that records that conclusion.

In case it wasn't clear, this isn't the place to make decisions about implementation in Firefox. Talk to our product folks about that.

[annevk]

#64 (comment) appears unaddressed still.

I'm also a little worried about adding storage-like APIs to the web when we haven't fully retrofitted the existing storage APIs with better privacy guarantees in a standardized fashion. (Many of the APIs discussed above do not account for Safari's model or StoragePrincipal in the standard and those models are not fully interoperable either, though I believe there is some aspiration from both teams to get there.)

[asutherland]

#64 (comment) appears unaddressed still.

Do you mean in terms of what Safari does? Or what Gecko does? What Gecko does is theoretically well defined, but in practice we have a series of tracking/etc. lists that will entirely result in denied access to storage, not just double-keying.

I think that's a somewhat orthogonal issue, though. Web Locks spec text at https://wicg.github.io/web-locks/#lock-managers already effectively binds it to our StoragePrincipal model and can adapt to greater changes.

Also, Web Locks evolved from an attempt to add improved transaction handling to the ServiceWorkers' Cache API in w3c/ServiceWorker#823. I was concerned about having Cache API transactions be responsible for introducing such a powerful primitive (exposure of agent termination!), so having it extracted out from the ServiceWorkers spec seemed great. But we still need a coordinating transaction primitive for the Cache API. (And also practically speaking, Firefox can't have offline gmail until Firefox has Web Locks.)

[annevk]

To follow-up here, I think the overall assessment that this is worth prototyping is correct. @asutherland do you want to create a PR for that?

For our storage partitioning efforts, I've been wondering if we should aim to be more restrictive for communication channels such as shared workers and BroadcastChannel (e.g., restrict those to first-parties and third-parties with the storage access permission). That would also be applicable to Web Locks. To make such a transition easier perhaps we should restrict Web Locks to first parties initially, at least until we're more clear about where we want things to end up.