Added privacy & security section #40
Conversation
|
LGTM, but @sleevi would probably have comments |
| omitted, preload defaults to same security and privacy processing as a | ||
| call to `fetch()` - i.e. subject to `connect-src`.</li> | ||
| </ul> | ||
| <p>The site authors are encouraged to take the necessary precautions and |
There was a problem hiding this comment.
Should there also be a call to user-agents to respect user's preferences for the context of fetching resources?
That is, for example, if a user has image loading disabled, then so too should a preload relevant to images be ignored.
It may be worth mentioning the passive tracking privacy effect; for example, if a page (such as a search engine results page) indicates preload directives for resources on the subsequent search result pages, then EVEN IF that search result page was served over HTTPS, it may leak context about the nature of the query based on the resources and domains that were preloaded (even if they TOO were delivered over HTTPS). This would not be true in the no-preload case, since the only traffic analysis the attacker could conduct would be in response to actual loads by the user, which would not be anything new.
This is not documenting a new attack surface, but merely highlighting for authors and spec reviewers the awareness of the risks of traffic analysis, such that any future solutions that try to mitigate such risks are also aware of the need to find a solution for this spec and not just the 'naive' case.
WDYT?
There was a problem hiding this comment.
Speculative fetches for next session should be <link rel=prefetch>, not preload, so I don't think this belongs here, but rather in the Resource Hints' privacy & security section. Looking at that section, seems like it already is.
There was a problem hiding this comment.
Wouldn't preload still apply in the case of say, an email inbox preloading subresources (such as email images) before the email is loaded? Or for displaying previews and such in-page?
I think the overall goal being that preloading resources - whether through the existing methods (like XHR or Fetch or CSS) or this declaration - ends up revealing more information about the overall 'activity' than just the page load. This has been admittedly true for over a decade, but perhaps just worth highlighting. Of course, the fact that it is so universally true may be reason enough not to mention it.
There was a problem hiding this comment.
I see what you're saying, but unless the user bails early from the page, preload is not supposed to download any resources that wouldn't have been downloaded anyway later on.
We could highlight the information leakage that resource download creates here, but as you say, it is true for pretty much any resource fetch.
There was a problem hiding this comment.
I'm inclined to omit this for Preload, exactly because the same can be said for any resource fetch that the page is already making -- preload is just initiating the request earlier.
That said, we do highlight this within Resource Hints.. and I think it does make sense to do so there as we're talking about fetching resources that are required by some other page.
|
LGTM |
|
Merged via 0bf8a6f. |
Closes #34.