Transition Level 1 to CR

[igrigorik]

• Known / outstanding spec issues
  • https://github.com/w3c/preload/milestone/1
• Web platform tests
  • upstream Blink tests
• Privacy and security
  • http://w3c.github.io/preload/#privacy
• Implementations
  • Chrome: M50+
  • Firefox: M56
  • Edge: under consideration
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=158720
• Public signals: adoption, feedback...
  • https://www.chromestatus.com/metrics/feature/timeline/popularity/1124

[igrigorik]

@yoavweiss any chance you could help with the web-platform-tests for this one? Also, any pointers for Safari discussions/bugs we can link to?

[yoavweiss]

@igrigorik - on my TODO list. If I'm realistic, it probably won't happen before Velocity AMS, but I'll carve out the time to get it done not long after.

Master WebKit issue is https://bugs.webkit.org/show_bug.cgi?id=158720

[igrigorik]

@yoavweiss sounds great, thanks!

[toddreifsteck]

I know it is already in progress but I want to ensure that we are clear that the tests are super critical for this spec given its "background" nature. I assert that we MUST get tests into Web Platform Tests before moving this to the next phase.

[yoavweiss]

Later than I thought, but first batch of tests is at web-platform-tests/wpt#4316

[yoavweiss]

@toddreifsteck @igrigorik - I'd appreciate your review of the tests and mostly a list of scenarios which are not currently covered.

[addyosmani]

web-platform-tests/wpt#4316 (which was great to see land) noted that this was an incomplete set of tests. @yoavweiss do you know if there are additional tests that need to be landed beyond #92?

[siusin]

@yoavweiss @igrigorik
do you think this spec needs a TAG review? I know a few TAG members are involved in the design of this spec, but can't find the record of a formal review.

[toddreifsteck]

@siusin @yoavweiss @igrigorik I believe a TAG review is supposed to be part of every new spec's publishing process. We should get this spec on the list, but I don't believe that needs to block the request to publish.

[yoavweiss]

With 2.5 shipping implementations and presence in 0.9% of page views, I think it's a bit late for that :/ While we can go through the motions, I don't think we'd be able to act on any recommendations that'd result in breaking changes.

[siusin]

I'd suggest we at least formally ask the TAG if they wish to review this, also the Web Plat WG. It won't take long...

[igrigorik]

Hmm, I'm surprised we missed the formal TAG bit here -- I'll take the blame for that, should have caught it earlier! Pinging TAG for formal review sgtm, with an explicit note that this has already shipped and has a good ramp on adoption. Yoav, would you be willing to drive that?

[siusin]

[Draft] Call for Review --

TAG Review:

I'm requesting a TAG review of:

• Name: Preload
• Specification URL: https://www.w3.org/TR/preload/
• Explainer, Requirements Doc, or Example code: https://www.w3.org/TR/preload/#introduction
• Tests: https://w3c-test.org/preload/
• Primary contacts: @igrigorik @yoavweiss
• Relevant time constraints or deadlines: N/A

Further details (optional):

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

You should also know that...

The Preload spec has already got 2.5 shipping implementations and presence in 0.9% of page views.

We'd prefer the TAG provide feedback as (please select one):

• open a single issue in our Github repo for the entire review

Self-Review Questionnare on Security and Privacy:

• Does this specification deal with personally-identifiable information?
  No.
• Does this specification deal with high-value data?
  No.
• Does this specification introduce new state for an origin that persists across browsing sessions?
  No.
• Does this specification expose persistent, cross-origin state to the web?
  No.
• Does this specification expose any other data to an origin that it doesn’t currently have access to?
  No.
• Does this specification enable new script execution/loading mechanisms?
  Yes.
  This specification defines the preload keyword that may be used with link elements, it provides a declarative fetch primitive that initiates an early fetch and separates fetching from resource execution.
• Does this specification allow an origin access to a user’s location?
  No.
• Does this specification allow an origin access to sensors on a user’s device?
  No.
• Does this specification allow an origin access to aspects of a user’s local computing environment?
  No.
• Does this specification allow an origin access to other devices?
  No.
• Does this specification allow an origin some measure of control over a user agent’s native UI?
  No.
• Does this specification expose temporary identifiers to the web?
  No.
• Does this specification distinguish between behavior in first-party and third-party contexts?
  No.
• How should this specification work in the context of a user agent’s "incognito" mode?
  The feature would work in such a way that the website would not be able to determine that the user was in "incognito".
• Does this specification persist data to a user’s local device?
  No.
• Does this specification have a "Security Considerations" and "Privacy Considerations" section?
  Yes.
  https://w3c.github.io/preload/#privacy.
• Does this specification allow downgrading default security characteristics?
  Yes.
  Preload links for CORS enabled resources, such as fonts or images with a crossorigin attribute, must also include a crossorigin attribute, in order for the resource to be properly used.

@igrigorik @yoavweiss could you give a quick check of the above review details before we send out the wide review requests?

[igrigorik]

@siusin thanks for drafting this! GH formatting was broken in a few places --> updated. LGTM.

[Krinkle]

@siusin For what it's worth, it seems two of the test suites fail over HTTP (in Chrome at least). Might want to link w3c-test.org over HTTPS instead.

[siusin]

Done.

Thanks @Krinkle !

[yoavweiss]

Opened a TAG review request at w3ctag/design-reviews#202

[siusin]

CR Published on 26-Oct.

Thanks all for getting this done.

[yoavweiss]

@siusin Thank you for publishing! :)

[igrigorik]

Yay! Thanks all.