Intent to Prototype: Media Feeds

[Becca Hughes]

Contact emails becca...@chromium.org

mlam...@chromium.org

sgb...@google.com Explainer https://github.com/beccahughes/media-feeds/blob/master/explainer.md Summary We propose a new API to allow a user agent to discover a media feed provided by a website. When fetched by the user agent the site will return a feed of personalized media recommendations for the user. Motivation We would like to build features in the browser that use this data. Risks

Interoperability and Compatibility The risk here should be low since the media feed will be ignored on user agents that do not support it. Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: No signals

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? No. This is only supported on desktop (for now).

Is this feature fully tested by web-platform-tests? N/A Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5695114963845120

This intent message was generated by Chrome Platform Status.

[Daniel Vogelheim]

Hi Becca,

Could you explain a bit more how this is intended to be used?

This intent came up during privacy + security review, and I was having a hard time forming an opinion on it since most questions would require to know what happens with the data. These are the kind of questions I'd like to understand:

- When would a browser fetch the feed?

(Generally we've been very careful about any requests - especially personalized requests - that happen outside of users' browsing sessions,  since users typically expect that interaction with a site ceases once the tab is closed.)

- Would it ever fetch any of the media on this list? When? Are there previews?

- If a server attaches user-specific IDs to the media URLs listed in the feeds, would that allow the server to recognize the user in circumstances where it currently couldn't? (E.g., if cookies have been cleared between the feed fetch and the media fetch? What if the feed points to a media URL on a different origin than the feed?)

- How is incognito mode handled?

Does it use the same feed for both? (I.e., can it 'leak' between regular or incognito sessions?) Or separate feeds? (How/how long does it get stored?) Or is it disabled in incognito? (I.e., is it an Incognito distinguisher?)

A (somewhat unrelated) question, about complexity: Why would this be a browser feature in the first place? Could a website that wishes to make use of this implement the same thing using existing mechanisms, like a ServiceWorker + JavaScript-based parsing of the feed?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsEK1imxpN%2BC8kLBBXPsztnUj_2zbf_DEtoW7uVo0DzFM_Q%40mail.gmail.com.

[Becca Hughes]

Hi Daniel,

Thanks for the feedback. We are already working with the Chrome Privacy team internally on this feature.

Thanks,

Becca

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALG6KPORgCQDkqHcd4qvWR95FDNj_8ar7TmbGAy095nvEXPg7A%40mail.gmail.com.

[mme...@google.com]

Hi, I'm on the team addressing cross-site tracking.  Are same-site cookies used to fetch the feed?  What network isolation key will be used to fetch this information?  Using attacker-controlled URLs and the same NetworkIsolationKey allows for cross-site user identification, even without access to cookies.

e.g., site A sets first party cookie COOKIE_A uses the feed URL https://a.test/media_feed_url/user_id=COOKIE_A.  Site B sets first party cookie COOKIE_B and advertises a feed URL https://b.test/media_feed_url/user_id=COOKIE_B.

When the media code requests the feed at https://a.test/media_feed_url/user_id=COOKIE_A, the user is redirected to https://b.test/a_media_feed_url/user_id=COOKIE_A, and then redirected back to site a.test for the actual feed.  Then when https://b.test/media_feed_url/user_id=COOKIE_B is fetched, it will reuse the socket for the other request, so now a.test and b.test can identify the user across sites.  Note that there are other ways to do this even if redirects aren't followed (Like through shared reporting configurations between the two sites).

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFeLsEK1imxpN%2BC8kLBBXPsztnUj_2zbf_DEtoW7uVo0DzFM_Q%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Becca Hughes]

The Media Feed URL is required to be on the same origin as the site. I think based on this we can disable redirect=follow and therefore this shouldn't be an issue.

Thanks,

Becca

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f70cd91d-f36c-4661-8470-9d34d97f95e1%40chromium.org.

[Matt Menke]

That still leaves having a common reporting endpoint.  Actually, even just sharing an H2 certificate is enough for us to reuse an H2 connection and identify a user across sites.  So if we aren't sanitizing URLs, we need to use a per-site NetworkIsolationKey.  I'm not sure if using the same NIK as we use for normal loads of the site is sufficient - it would allow sites to identify which users are requesting the file from the manifest, but without feed URL sanitization, sites can collect that, anyways.

[Becca Hughes]

Ok, i'm sure we can do that.