Prefetch request changes to improve privacy

[domfarolino]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Changes to prefetch requests + processing model to preserve privacy
• Specification URL: Add prefetch processing model, including double-key caching privacy protections whatwg/html#4115; Add a speculative flag to Request as well as related processing whatwg/fetch#881
• Explainer: A full explainer does not yet exist. The original motivation for these changes are currently logged in Prefetch and double-key caching w3c/resource-hints#82. Once an explainer has been created I'll update this thread.
• Tests: None at the moment
• Primary contacts (and their relationship to the specification): @domfarolino, @kinu, @yutakahirano (reviewers/implementers), @yoavweiss (spec PR author)

Further details:

• I have read and filled out the Self-Review Questionnare on Security and Privacy.
• I have reviewed the TAG's API Design Principles

You should also know that: Only early discussion has been going on regarding the changes to prefetch requests, and their processing model (HTML Standard PR above). We, Chrome, thought it would be best to request a TAG review early on as we're interested in making these changes in order to better-preserve privacy on the web platform. This is Blink's Intent thread. At the time of writing, the total compatibility effects of these changes are unknown, however we intend to experiment with an initial implementation. There has been some discussion from Apple regarding these changes as well.

We'd prefer the TAG provide feedback as:

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[FredKSchott]

Context: I was asked to comment here by @kenchris. I created and operate https://pika.dev/cdn.

Edit: Posted in the wrong place, moved to blink-dev

Context: I was asked to comment here by @kenchris. I created and operate https://pika.dev/cdn.

How are cross-origin CDNs considered in this change? My understanding is that this suggested change would kill the cache efficiency story of cross-origin CDNs, which is extremely troubling.

The ability to cache resources across domains is a huge benefit to using cross-origin CDNs at scale. The more use that they get, the more likely cache hits are, and the faster those websites become (potentially faster than if they'd served their own JS). Two examples:

1. "This month, July 2019, cdnjs served almost 190 billion requests ... Lodash (4.17.11) skyrocketed to the top of the list this month with 8.7 billion requests."[1]
I imagine the cache efficiency lost due to this change for this CDN alone (jQuery, lodash, etc) will be massive.

2. "Approximately 100% of the Fortune 500 already use npm to acquire approximately 97% of their JavaScript code." [2]
Pika is creating a CDN for modern npm packages that can run in the browser. The project is only a few months old today, but with ESM it becomes feasible for sites to load their npm dependencies from our CDN (or UNPKG, or another cross-origin CDN like it) in production. Basically, cdnjs for npm. In that world, every npm package would only be loaded once across all participating sites, and would then be cached and reused on future visits. Imagine if most sites never had to load React, ReactDOM, Preact, Vue, the 100 most popular npm packages, etc.

Obviously security is a huge concern, and I completely understand and appreciate the work being done here. But as others have pointed out the perceived threat (cached file detection) doesn't outweight the serious performance hit for CDNs.

As we moved towards bundling all of our JavaScript into custom site bundles over the last decade, cross-origin CDNs have gone out of fashion. But they clearly are still heavily used today (see cdnjs stats above), and we see them playing a big part in the future of the web once ESM becomes standard... as long as the current performance story isn't destroyed.

tldr: https://twitter.com/rektide/status/1156261839623401472

(PS: Please add that single explainer doc! I read through the different threads but there's a chance I could have misunderstood/missed something, in which case please let me know!).

[yutakahirano]

@FredKSchott, Is your comment for double-keyed HTTP caching in general, or for this change specifically?

[FredKSchott]

Double-keyed HTTP caching in general. I'd originally read the PRs to be addressing that generally, but in re-reading I see that you're talking exclusively about prefetching logic.

[domfarolino]

Yeah, so this issue and the Blink intent thread I posted. Concerns about Double-Key Cache in general should probably be brought up in Blink's intent thread for that change specifically, until a TAG review for it has been started. The thread's been pretty active so feel free to comment.

[FredKSchott]

Thanks all, I'll move my comment there instead 👍

[lknik]

Maybe relevant.

[domfarolino]

Quite. Thanks!

[lknik]

Is there any explainer in plan to get a better idea what's being done here? (maybe this document if of help).
Any view on finalising the pulls referenced above?
Are you filling a security/privacy questionnaire?

[lknik]

Might be useful context

Interoperability and Compatibility
We think the interoperability risk is low, because Apple has contributed to the spec discussion and started working on their implementation. Mozilla has also expressed interest. The final spec details are not resolved yet, but multiparty interest in this makes us confident that all vendors will work together to ship these changes.

[annevk]

@lknik I think it'll very much depend on usage data as per w3c/resource-hints#82 (comment). It's not entirely clear to me this feature is pulling its weight in a privacy-first world.

[domfarolino]

TLDR: I don't think this is ready for a deep review by the TAG, I just wanted to file this issue very early while Chrome and other vendors get their stance straight and proposing ideas in case TAG had any early input.

---

Is there any explainer in plan to get a better idea what's being done here? (maybe this document if of help).

Ah, yes I actually wrote that document. No explainer yet, as the ultimate direction is not entirely clear yet (sorry).

Any view on finalising the pulls referenced above?

RE spec: I'll defer to @yoavweiss, as he is currently authoring the spec changes relevant here. But as Anne mentioned, I agree a lot of that is blocked on how implementations decide to move forward.

To be clear: I think we'll likely not have any progress on this until after TPAC when vendors discuss this a bit more, so feel free to defer seriously at this looking until a meeting after 2019-09-04 (when the current label suggests this will be looked at closer). Just wanted to file an issue at the same time as I wrote Chromium's Intent-to-Implement to get his out earlier rather than later.

Are you filling a security/privacy questionnaire?

I will, however this won't be done until the direction is more clear (see above).

Might be useful context [...]

Ah, yes I wrote that too :)

[domfarolino]

It's not entirely clear to me this feature is pulling its weight in a privacy-first world.

@annevk Are you mentioning that it might not be worth keeping prefetch around at all, or specifically not worth supporting cross-origin prefetch in a privacy-first world?

[plinss]

Ok, we're going to close this issue for now. Feel free to ping us to re-open or file a new issue when it's ready for further review.