You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
With a security hat on, I'd prefer for the platform's defaults to assume the worst, and fail closed. It's worse, in my mind, for a developer's inaction to accidentally expose user data than for data to be less-sharable than the developer would prefer. I think that preference is justifiable as more user data becomes potentially web-exposed; truly public documents were the web when it began. I'm not sure they are today.
For those documents, though, you want your site to be frameable, embeddable, openable, and so on. I think it would be excellent to give you a clear path towards doing exactly that! Today, that path is simply a bit faster than I'd prefer. :)
Instead, I'd like for you to add something like X-Frame-Options: ALLOWALL to enable embedding (https://github.com/mikewest/embedding-requires-opt-in), and Cross-Origin-Opener-Policy: unsafe-none (or restrict-properties if we can get that defined and shipped) if you want to give cross-origin documents your window handle (https://github.com/mikewest/coop-by-default), and Cross-Origin-Resource-Policy: cross-origin if you want people to be able to make no-cors requests to your origin. The Baseline propsal doesn't even go that far, however. It simply suggests that developers should be able to opt-into a baseline for their site that's defensive by default, as opposed to the status quo baseline, which isn't.
If you opted into a more defensive baseline, and then opted-out of most/all of that baseline's protections for your public documents by declaring them public (maybe even with a fast-path like we've discussed in whatwg/html#8143), I promise not to tell you you're doing it wrong. :)
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.
The text was updated successfully, but these errors were encountered: