#629: Partitioning Storage, Service Workers, and Communication APIs
Discussions
2021-05-31
Thanks for bringing this to us for review. We're happy to see that engineers who work on all three engines are involved or are being consulted, and that there's a real effort to converge on one, interoperable partitioning model. Please do request another review in the future if your approach substantively changes!
Tess: concern with interop- they seem to have the right people in the loop. seems to be doing well. We should encourage them to keep at it.
[posted and clsoed
2021-05-31
Yves: we wanted to have coord between different efforts to partition things - so using the same key for example.
Yves: in 596 it was noted that they do use the same partitioning key.
Yves: so I'm fine with this.
Tess: I'm comfortable closing it. Folks from different implementers doing a good job. I'm inclined to just say. thumbs up.
Yves: porposed close and close at the plenary.
Dan: i'd like to see a closing comment from someone saying that.
Tess: I can draft a closing comment
2021-05-Arakeen
We're satisfied with this approach, would like to get Amy and Tess' feedback as well. Propose close satisfied.
We have a small concern with the carve-out for blob url's, but it looks like that's driven by a compat issues.
OpenedMay 3, 2021
Ya ya yawm TAG!
I'm requesting a TAG review of Partitioning Storage, Service Workers, and Communication APIs.
This effort proposes that a number of web platforms APIs used for storage and communication should be partitioned in 3rd party contexts. In this context "partitioned" means that in addition to being isolated by the same-origin policy, the affected APIs in 3rd party contexts would also be separated by the site of the top-level context.
Further details:
You should also know that...
[please tell us anything you think is relevant to this review]
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback