Media Feeds API

[beccahughes]

Hello TAG!

I'm requesting a TAG review of Media Feeds API.

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.

• Explainer¹ (minimally containing user needs and example code): https://github.com/wicg/media-feeds/blob/master/explainer.md
• Security and Privacy self-review²: https://github.com/wicg/media-feeds/blob/master/security-privacy-questionnaire.md
• GitHub repo (if you prefer feedback filed there): https://github.com/wicg/media-feeds
• Primary contacts (and their relationship to the specification):
  • Becca Hughes (@beccahughes), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):

https://chromestatus.com/features/5695114963845120

Further details:

• [ X ] I have reviewed the TAG's API Design Principles
• The group where the work on this design is being done (or is intended to be done in the future): WICG
• Existing major pieces of multi-stakeholder review or discussion of this design:
• Major unresolved issues with or opposition to this design:
• This work is being funded by:

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[hober]

Talked about this in Wellington; filed beccahughes/media-feeds#10; marking this pending external feedback.

[beccahughes]

We have updated beccahughes/media-feeds#10

[beccahughes]

@hober since we responded to the issue should this not be marked as "pending external feedback" anymore?

[chrisn]

Prompted by seeing the recent intent to ship come through, I want to raise a couple of architectural questions about this proposal.

One of the goals for Media Feeds is to provide personalised media recommendations. To do this, the browser makes an authenticated request to the server, using the website's session cookies. The use of a website's session cookies for what is really a native application feature seems strange to me. Is there precedent in other web platform features here?

Related to this, the spec says there's very low impact on security and privacy, but the proposal exposes personal information to the UA (information about the currently logged in user), makes direct use of session cookies to make authenticated requests, and provides the UA (and its host platform) with media recommendation data which is valuable user insight. Sites would have to limit the scope of any cookie used to fetch the media feed to prevent potential misuse.

Another concern we have with the current design is that there is a limit of one media feed per origin. I raised this here, but as this is an architectural consideration, I'm interested in the TAG's perspective on this.

[torgo]

https://github.com/mozilla/standards-positions/issues/370#issuecomment-664537275

[atanassov]

Hi,

First of all, thank you for bearing with us while we've been working on this review.

Thank you for switching away from rel=feed, which had been dropped from HTML over a decade ago. Also, thank you for jumping through both IANA and Microformats hoops to ensure your new rel value is registered in all the right places.

We're also happy to see you've addressed @chrisn's security & privacy concerns.

@dbaron and others raised a concern about allowing Media Feeds to be processed as either JSON-LD or as JSON. Specs that enshrine polyglot processing like this have frequently been a source of interoperability problems on the web, and we're very happy to see that Media Feeds has moved away from this approach. (We intend to update our Web Platform Design Principles doc to capture this, to help others in the future with similar issues.)

Adding new formats to the web is a significant undertaking, and when it can be avoided, it probably should be. We suggested that an existing feed format like Atom or RSS could be used. You countered that browsers don't natively support Atom or RSS, but do natively support JSON. But this proposal is also incompatible with the existing JSON Feeds format. We're glad to see you reached out to the JSON Feeds community. We agree with @manton, who replied:

I don't think another feed format is needed. Although the focus with Media Feeds is a little different, building off of JSON Feed (or RSS for that matter) seems preferable. Especially for media, RSS is used everywhere for podcasts already.

[…] now that JSON Feed and other feed formats are here and widely adopted, I think there is a very high bar to meet to introduce another format.

It seems like the reluctance to re-use a pre-existing, standardized format is primarily driven by a desire to be compatible with existing YouTube tooling.

The restriction of the Media Feeds format to video appears to have no technical justification. The use case (surfacing media recommendations) is just as compelling for audio as it is for video, and in the wild, we see the popularity of both audio and video podcasts to be strong evidence of user interest. This limitation appears to be motiviated solely by YouTube. Given this, the restriction should probably not be encoded into the spec itself, but instead be a Chrome/YouTube implementation detail.

On a more fundemental level, we share the concern expressed by our colleagues at Mozilla that Media Feeds is "designed to amplify or promote YouTube's video recommendations feature, which has a significant history of promoting misinformation, conspiracies, and hateful content." See these W3C TAG Ethical Web Principles:

• The web should not cause harm to society
• The web must support healthy community and debate
• The web must make it possible for people to verify the information they see
• The web must enhance individuals' control and power

We're especially concerned because "the reason for doing this appears to be for some form of integration of YouTube recommendations into the Chrome media controls," which would place the contents of YouTube recommendations directly into trusted browser UI.

At the present time, Chrome appears to be the only implementer which has expressed interest. Based on the implementer feedback we've observed so far (Mozilla's and WebKit's), it apears that most of the concerns we expressed here are also concerns of theirs. Our preference is for collaboration and consensus on features that are exposed to the web and we'd ideally like to see interest and support of this proposal from multiple media properties and browser vendors.

Thank you again for bringing Media Feeds to us for an early review. We know this isn't the answer you wanted to receive. If there is a future proposal that resolves these concerns, please don't hesitate to open another review.