Proposal: Transition 'sync-xhr' feature to Document Policy
clelland opened this issue · 13 comments
'sync-xhr' is currently implemented as a policy-controlled feature whose default allowlist is '*'. This means that it follows the model of "available in every frame until it disabled somewhere, and then disabled from there down". That is, disabling sync-xhr at one node in the frame tree means that it is necessarily disabled in all descendants of that node. (@martinthomson opines in #248 that "'sync-xhr' seems like its primary application is creating bustage in framed content.").
Moving this to Document Policy would provide a better model; the availability could be controlled per-document, without necessarily affecting framed content. (Required policies could be used to provide guarantees of non-usage in subframes if absolutely necessary, with their cooperation.) It establishes sync-xhr as following the 'document-sandboxing' model, as discussed in #296.
This would also support an eventual deprecation strategy: Switching the default value from true to false will disable synchronous XHR in documents, but would allow the same Document Policy mechanism to re-enable it where required. The additional configuration required should serve to discourage new uses of the API, and should help drive down existing usage, hopefully to the point where it can eventually be removed from the platform.
Not sure I like your chances of deprecating, but this is the right choice.
(@martinthomson opines in #248 that "'sync-xhr' seems like its primary application is creating bustage in framed content.").
That use case will no longer be enabled, right? That means that a top-level frame will no longer be able to make sure its 3P resources (or even devs from The Other Team™) are not using sync XHR. That seems like the use case for the policy.
What would be the use-case for the equivalent Document Policy? How do we foresee it being used?
You can still enforce it, but the framed document has to allow that restriction be imposed upon it. Meaning that the parent cannot alter its control flow in unexpected ways.
This seems right to me. We should likely move/copy document-domain as well.
A big +1 from me for both this change and for document-domain. In terms of the web's threat model, Document Policy seems like a better fit for these features because -- as Anne said -- it requires consent from an iframe to have its control flow affected by the embedder.
Not sure I like your chances of deprecating
It's completely possible that features like this end up as optional legacy features of the platform, that require a bit of configuration to enable, and stay like that for a long time. That's probably not a bad outcome, as long as we can provide better primitives so that new content doesn't need it by default.
I'm still hopeful, though :)