Skip to content

Commit 4fd923a

Browse files
domenicdomenic
authored
Add explainer for cross-origin iframe prerendering
1 parent b75b9f7 commit 4fd923a

File tree

3 files changed

+223
-8
lines changed

3 files changed

+223
-8
lines changed

‎opt-in.md

Lines changed: 5 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -34,6 +34,7 @@ This is an [HTTP structured header][http-structured-header] which lists tokens i
3434
* `uncredentialed-prefetch`
3535
* `uncredentialed-prerender`
3636
* `credentialed-prerender`
37+
* `prerender-cross-origin-iframes`
3738

3839
## Use cases
3940

@@ -67,6 +68,10 @@ _Note: as indicated previously, the first case here is not yet implemented in Ch
6768

6869
With this framework in place, by default, Bob's Star Wars Fan Site's attempt to prerender the List of Best Star Wars Movies document will fail and have no effect. And eventually, `https://docs.example.com/` might update their code to be prerendering aware, by not modifying the user's list of recently-viewed documents while prerendering. Once they've made such updates, `https://docs.example.com/` can add the `Supports-Loading-Mode: credentialed-prerender` header, and now the prerendering will work—giving a fast navigation from Bob's Star Wars Fan Site, with no unintended side effects.
6970

71+
### Prerendering cross-origin iframes
72+
73+
See [the dedicated explainer](./prerendering-cross-origin-iframes.md).
74+
7075
### Non-preloading cases
7176

7277
There are other contexts on the web platform where novel loading modes are introduced. One of these is [fenced frames](https://github.com/WICG/fenced-frame), which also will use the `Supports-Loading-Mode` opt-in.
@@ -86,14 +91,6 @@ This would be processed only if it appears within the `<head>` element and no `<
8691

8792
The main advantage here is that this may be easier to adopt. In order to make as much content as possible available for uncredentialed preloading, we would like to make it as easy as possible for authors to mark eligible content. We have heard from developers that many of them find it much easier to deploy changes that only affect content than changes which also require server behavior changes, even relatively straightforward ones. For example, these may be managed by different teams or not be possible at all. One example here is that GitHub Pages doesn't allow users to set response headers.
8893

89-
### Application to subframes while prerendering
90-
91-
Currently while prerendering, the loading of all cross-origin subframes are delayed. This prevents attacks similar to those described [above](#cross-origin-same-site-prerender). But of course, it has the cost that some of the benefits of prerendering are absent for such pages.
92-
93-
We could use `Supports-Loading-Mode` to allow subframes to indicate they are OK with being prerendered, using either the `credentialed-prerender` or `uncredentialed-prerender` variants.
94-
95-
It's not 100% clear this is necessary, because after [storage partitioning](https://github.com/privacycg/storage-partitioning/), the "attacks" on these cross-origin subframes would actually be on the subframe origin's partition within the top-level prerendered origin. Arguably, the top-level prerendered origin could be the one making decisions on behalf of its sub-partitions. If we want to start un-delaying cross-origin subframes in the future, we'll need to consider this question more carefully, and discuss it with the storage partitioning community.
96-
9794
## Redirect handling
9895

9996
This header only needs to be supplied by the final response in any redirect chain. For example, for the `credentialed-prerender` case, `https://example.com/` → `https://a.example.com/` without the header → `https://b.example.com/` with the header succeeds.

‎prerendering-cross-origin-iframes-security-privacy-questionnaire.md

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
# Security and Privacy Questionnaire: Prerendering cross-origin iframes
2+
3+
> 1. What information does this feature expose, and for what purposes?
4+
5+
None.
6+
7+
> 2. Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
8+
9+
Yes.
10+
11+
> 3. Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
12+
13+
No.
14+
15+
> 4. How do the features in your specification deal with sensitive information?
16+
17+
They do not.
18+
19+
> 5. Does data exposed by your specification carry related but distinct information that may not be obvious to users?
20+
21+
No.
22+
23+
> 6. Do the features in your specification introduce state that persists across browsing sessions?
24+
25+
No.
26+
27+
> 7. Do the features in your specification expose information about the underlying platform to origins?
28+
29+
No.
30+
31+
8. Does this specification allow an origin to send data to the underlying platform?
32+
33+
No.
34+
35+
> 9. Do features in this specification enable access to device sensors?
36+
37+
No.
38+
39+
> 10. Do features in this specification enable new script execution/loading mechanisms?
40+
41+
Not really; it allows existing mechanisms (i.e., iframes which contain script) to work in contexts where they were previously delayed from executing.
42+
43+
> 11. Do features in this specification allow an origin to access other devices?
44+
45+
No.
46+
47+
> 12. Do features in this specification allow an origin some measure of control over a user agent's native UI?
48+
49+
No.
50+
51+
> 13. What temporary identifiers do the features in this specification create or expose to the web?
52+
53+
None.
54+
55+
> 14. How does this specification distinguish between behavior in first-party and third-party contexts?
56+
57+
This feature can only be used by top-level pages, not by embedded third parties.
58+
59+
> 15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
60+
61+
The same as in normal mode.
62+
63+
> 16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
64+
65+
Yes, and the [explainer](./prerendering-cross-origin-iframes.md#privacy-considerations) has specific discussion.
66+
67+
> 17. Do features in your specification enable origins to downgrade default security protections?
68+
69+
No. (The delayed loading of cross-origin iframes while prerendering is not a security protection.)
70+
71+
> 18. What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
72+
73+
This isn't applicable, as prerendered pages cannot be kept in BFCache.
74+
75+
> 19. What happens when a document that uses your feature gets disconnected?
76+
77+
This isn't applicable, as prerendered pages cannot be included in iframes that get disconnected.
78+
79+
> 20. Does your spec define when and how new kinds of errors should be raised?
80+
81+
No new errors are raised.
82+
83+
> 21. Does your feature allow sites to learn about the user's use of assistive technology?
84+
85+
No.
86+
87+
> 22. What should this questionnaire have asked?
88+
89+
Probably something about "how does this all interact with storage partitioning".

0 commit comments

Comments
 (0)