Re: [w3ctag/design-reviews] Media Feeds API (#477)

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](https://github.com/WICG/media-feeds/issues/30#issuecomment-647583339), 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](https://github.com/WICG/media-feeds/issues/41).

@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](https://github.com/w3ctag/design-principles/issues/128) our [Web Platform Design Principles doc](https://w3ctag.github.io/design-principles/) 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](https://github.com/beccahughes/media-feeds/issues/10) 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](https://github.com/WICG/media-feeds/issues/29). We're glad to see you [reached out to the JSON Feeds community](https://github.com/manton/JSONFeed/issues/140). We agree with @manton, who [replied](https://github.com/manton/JSONFeed/issues/140#issuecomment-670593953):

> 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](https://github.com/mozilla/standards-positions/issues/370#issuecomment-662754454) 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](https://w3ctag.github.io/ethical-web-principles/):

* [The web should not cause harm to society](https://w3ctag.github.io/ethical-web-principles/#noharm)
* [The web must support healthy community and debate](https://w3ctag.github.io/ethical-web-principles/#community)
* [The web must make it possible for people to verify the information they see](https://w3ctag.github.io/ethical-web-principles/#verify)
* [The web must enhance individuals' control and power](https://w3ctag.github.io/ethical-web-principles/#control)

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](https://w3ctag.github.io/design-principles/#trusted-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](https://github.com/mozilla/standards-positions/issues/370) and [WebKit's](https://lists.webkit.org/pipermail/webkit-dev/2020-June/031235.html)), 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/477#issuecomment-672613700