Re: [spec-reviews] Strawman spec review for upgrade insecure requests (#54)

> +navigational requests will be upgraded if they are in the "upgrade insecure
> +navigations set" for a context.
> +
> +### CLARIFICATION: Violation Reports for Inherited Policy
> +
> +As mentioned in 6.2, there is a security issue if a document is able to get
> +violation reports for cross-origin nested documents (iframes, etc.) which
> +inherit upgrade policy. So if a nested document does not specify its reporting
> +endpoint, do all reports from the nested document get blocked?
> +
> +### IDEA: Cache/Pin Successful Upgrades
> +
> +Thinking about the broader goal of encrypting the web, it would be nice if
> +user agents could remember which subresources have been successfully upgraded
> +through this mechanism. That way, on a page that has not set the CSP header,
> +the known-upgradeable subresources could be upgraded anyway.

CSP pinning is scoped to a host (modulo include-subdomains), right? I was actually thinking that a resource could always be upgraded on any website once the UA knows that it is upgradeable.

Use case:
https://example.com sends the upgrade header and embeds `<script src="http://jquery.com/jquery.js">`. The UA notes that `jquery.com` has been upgraded successfully. In the future, the user visits https://not-example.com which also embeds `<script src="http://jquery.com/jquery.js">`. not-example.com does not send the CSP header, but the UA tries to upgrade jquery anyway. 

This mechanism seems kind of clumsy though; I'm more a fan of letting hosts signal that they should be upgraded regardless of where they are subresourced. (as described below)

---
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/pull/54/files#r29079571