mikewest / baseline-header Goto Github PK

Developing extensions where the default behaviour of an API is not the requirement will be helpful.

We have numerous means to sandbox a browsing context, no universal means to unset some or all of the default behaviours, even in extensions.

For example, MV3 has implemented chrome.offscreen.createDocument(). We can use Notification API to create a notification, await navigator.permissions.request({name: 'clipboard-write'}) state is "granted", however, when we call await navigator.clipboard.writeText(location.href) we get a DOMException document is not focused error. That is baked in to the specification, however, we want to be able to disable that without necessarily filing a bug to do so; a header is one option to do that, since in MV3 extensions we have control over the reponse with respondWith().

It would be much simpler if we could set document level permissions, and disable focus requirement of a document in a header.

Another useful header that would be useful is setting the opener of a window. That would alleviate a lot of intermediary steps to communicate directly from a ServiceWorker to an arbitrary Web page, for example use Transferable objects to transfer files, folders, etc. from extensions to Web pages the user decides default security features should be exempt from.

I think we should have the capability to undo any and all of the secuirty measures that wind up eventually becoming baked in to default vendor products - thus extension authors have to undo each hardened feature individually, instead of utilizing a single object or set of headers that can handle all default security features that the developer and user decide declaratively or programmatically they do not want to be enabled by default.

Thanks for your effort in these matters.

I've struggled in the past with the idea that browser vendors "think we should be using" certain headers, but those headers are counterproductive for some static sites I maintain. (E.g., https://html.spec.whatwg.org/, or https://blog.domenic.me/.) Namely, I want my static sites to be frameable, embeddable, openable in a window which the opener controls, etc.

I'd encourage any work in this area to keep such cases in mind. Both from a technical design level, and also from a marketing and social angle. It doesn't feel great to be told by security engineers that I'm doing things wrong. I myself might be able to realize "but really they mean this to apply to dynamic, credentialed sites and applications", but others might not be.