Intent to Ship: Web Locks API

> scoped <https://inexorabletash.github.io/web-locks/#security-scope> to
I believe the Firefox status at the moment is that we're not clear on
exactly what the proposed scoping is in various important cases, which
is making it hard to evaluate whether it makes sense, which is making it
hard to decide what we think about the proposal. Which is why there's
been no followup on our standards position; we don't have enough
information to evaluate.

I will say that I personally am extremely concerned about too-broad
scoping getting baked into the implementation and consumers and hence
making it difficult to ship other features in the future, change process
models, improve user privacy via efforts like Firefox's containers, etc.

-Boris

To give a simple example,
https://inexorabletash.github.io/web-locks/#security-scope seems to
assume that the set of partitions is the same for all "storage
facilities" and "communication channels", which may well not be true in
general, depending on a UA's actual goals.

-Boris

The main concern I personally have is that the proposal assumes that
there is only one partitioning. This is demonstrably false for cookies
(e.g. they ignore scheme and nothing else does) and might become false
for other things in a world in which (some) things are double-keyed.

I don't have a clear list of cases; this is an area of active research
and experimentation.
Possibly.

Based on a conversation earlier today with, it seems that my concern
boils down to this. The proposal is for abstract locks which are not
tied to particular features. This has obvious desirable qualities, but
requires that the lock scope match the scope of whatever you're locking.
And since you don't know what you're locking, the scopes of all the
things need to match.

So it's possible that the right answer is to be more explicit about what
you plan to lock with a given lock so that it can be scoped appropriately.

It's also possible that the right answer is to make browsers only have
one scope. Again, it's not clear to me that this interacts well with
some desirable privacy features[1].
Except cookies, right?

But that's my point: this seems to be assuming details about how Chrome
works today. And these details may not be true for other browsers
today, much less other browsers in the future...
You are correct. We have not. But if we're proposing to give people a
tool that makes it look like that scoping is defined (by explicitly
giving them guarantees that a lock held will lock out other things
within the relevant scope), then we should attempt to define these things.

Ben Kelly pointed out that BroadcastChannel already has this problem to
some extent, in that you could try to build a synchronization setup on
top of it. Which is true, but it's a lot easier to write off failures
of that to correspond to storage scoping as "yeah, we don't guarantee
that" than it would be with web locks, which are explicitly meant to
guarantee things work right.

-Boris

[1] Let me give a concrete example. Say a page at foo.com includes an
iframe from bar.com. bar.com is attempting to track users. A browser
could try to prevent this by giving that iframe its own storage
partition that's separate from other bar.com storage. This is
sufficient to deal with the "user opens a new tab, loads foo.com" case.

Now say user loads bar.com and bar.com then window.open()s foo.com. In
this case the original page and the subframe can communicate with each
other. Synchronously, even. The question is what the storage
partitions should look like.

In an ideal world, the answer might be "well, actually, in the
window.open case they can't communicate", but I suspect that's not
web-compatible. Another answer might be "the storage used for the
bar.com subframe depends on whether there's a toplevel bar.com page in
the same unit of related browsing contexts" or some such. That, too,
could have web compat issues. For example, the storage the subframe
sees would randomly depend on whether you load foo.com in a new tab
yourself or follow a link from a search engine or whatnot.

Note that the threat model here is not "bar.com toplevel should never be
able to access the storage of the bar.com subframe". It clearly can in
the window.open case. The threat model is that if the user opens a tab
that is otherwise entirely unrelated to bar.com then the bar.com in that
tab should not share storage with bar.com in other such tabs. Arguably
shouldn't share BroadcastChannel either.... But if you come from
bar.com itself, then it already knows you're doing that, so all bets are
kind of off.

This is all a bit fuzzy, but the point is that it's not clear so far
what the right model is here, and I am worried about foreclosing options
by shipping an API that makes strong and very exposed assumptions about
what that model is.

For existing things, sure. I was talking about people creating new
sites that try to rely on that guarantee and discovering it does not hold.
That seems OK to me if we're very certain that all non-cookie storage is
scoped in a consistent-with-each-other way in browsers. Which seems
like a reasonable thing to want, though I very much doubt any specs
actually come out and say it.

This spec would definitely want to explicitly say that's what the
scoping is.

-Boris

As long as you don't equate shared memory here with SharedArrayBuffer,
which has a very different scope. 😊

(Another issue here is that some browsers double key third-party
(<iframe>) storage.)


--
https://annevankesteren.nl/