@Ericlaw I think we should reset the sandboxing flags in a window when a user navigates via the address bar.

I’d have to think about what happens when the user navigates via clicking on links on the page, but I agree with you that the outcome is likely confusing.

@slightlyoff @dotproto @developers This change is one we could do without any web-facing changes. I agree that it would be lovely to give developers more granular request options, and `.request()` with a dictionary would be one reasonable approach to that problem.

I'm less convinced that we need to expose the temporary nature of a grant via `.query()`. "Yes, you have access to X right now." is true, but is never guaranteed to remain true (users can revoke permission just as UAs can).

@blinkygal @dbaron @AlesandroOrtiz I think security folks at various vendors can generally agree on things that we'd like to remove from the platform. Shifting from that conversation to agreement on the set of new features that we would tie to deprecations as part of a versioning system is more difficult. We don't have a culture of using additions to the platform as an incentive for change.

David mentioned Secure Context restrictions, which is the only example I can think of in the recent past.

@dbaron @blinkygal @AlesandroOrtiz We had a short conversation around the general topic of versioning in WebAppSec a ~month ago: https://github.com/w3c/webappsec/blob/main/meetings/2023/2023-03-15-minutes.md#linked-on-or-after. TL;DR: general versioning that bundles unrelated changes isn't something folks see as consistent with the web's philosophy.

Something opt-in like https://github.com/mikewest/baseline-header might be a reasonable (though low-reward) start. Ideally, we'll be able to harden `[SecureContext]` a la https://github.com/mikewest/securer-contexts, but that still requires long deprecations.