[Proposal] Media Feeds API

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.

This is an interesting proposal. What would be the interaction between this and the Media Session API? Would both make use of the same native UI mechanisms?

The Media Session API focuses on metadata for the currently playing audio/video on an open tab.

The Media Feeds API is a background fetch for recommendations that the user agent can present to a user. The user has to have visited the site before for the feed to be discovered but the site does not have to be open for the browser to do the fetch.

At the moment, we (Chrome) are planning to use something like this to collect data so that we can build native UI surfaces on top of that data in the future.

Interesting proposal @beccahughes, but I’m left wondering a couple of things that maybe you can help me understand a bit more:

• why surface this at the browser level, instead of just letting the web page handle it via fetch() or whatever?
• why do this at the web manifest level instead of, say, using a <link rel>?

For manifest inclusion, the timing might be a bit wonky for the request… like the user might not have logged in yet when the manifest is read, for instance… so this feels like it might be better suited to something inside a tag? … I don’t know tho, just speaking out loud here

Sure

1. This is at the browser level because the web page is never meant to fetch the feed. The browser will choose which feeds are relevant to fetch and fetch those. We do this in the background and the web page is unaware of it.

2. Using a web manifest provides a mechanism for the site to remove the feed in the future by removing it from the manifest

For the timing, if we see the feed before the user has logged in then the site should return a generic or empty feed. When the user logs in the browser will see the cookies have changed and re-fetch the feed.

Thanks for the clarifications. I’m bit worried about 2, to be honest, because we haven’t really worked out how updating web manifests works. I guess maybe this might force us to do that, but please be aware that updating the manifest is currently undefined behavior.

I’m not sure to understand the differences between having a new media_feed_url in the web manifest and a potential new link rel tag.

At first sight, it seems like the latter is better as it doesn’t force a website to define all other mandatory keys in a web manifest.

Moreover, “removing a media feed” could be configured as returning a 410 HTTP “Gone” error for instance.

When Becca and I talked about this, my suggestion was to go with Manifest only because my rule of thumb for Manifest vs link rel tag is whether the value would be expected to be the same on every page of a given website. In other word, is this a site-level information or a page-level information. In this case, it would be a site-level information.

How would this work for websites that allow users to have multiple profiles (Netflix for instance)?

Having one single media_feed_url in a web app manifest doesn’t seem to fit this use case. A link rel tag can be unique to a user profile and can be provided at a page-level.

From a content provider perspective, one the one hand, this API presents an opportunity to recommend content to users without them having to open our app. But, given users will typically have installed several content provider apps, how does the UA decide which providers’ content is given prominence in the UI? A concern we’d have is the risk is that this favours content from some providers and not others.

As the User Agent, hopefully the UA will pick content providers that the user is interested in based on available signals. The UA should have enough information to be able to make that call.

Can you explain more about how user authentication works with this API? Which cookies is the browser checking to detect when the user logs in? I didn’t see anything in the draft spec to describe this mechanism.

I switched the proposal to use the tag instead of the web manifest. There is a PR here: https://github.com/beccahughes/media-feeds/pull/8

Sure, when the browser fetches the feed it is a normal fetch request with cookies. Therefore, if we discover a media feed hosted at example.org/feed the cookies for example.org will be sent. The media feed must be in the same origin has the page where it was discovered.

The browser will also watch for changes to the cookies on example.org and we will re-fetch the feed if they change. This is because we don’t know if the user state has changed.

Thanks!

@marcosc would it be possible to spin up the repo now?

Really really sorry for the delay @beccahughes! Ok, let’s spin this up.

Up at https://github.com/WICG/media-feeds-api

I am writing in support of Mozilla’s classification of this API as harmful. YouTube has done extensive and well-documented damage already through its recommendation system, surfacing it in browser controls would only risk providing it with greater apparent authority.

I realise that there exist other recommendation systems. We must, however, deal with threats by volume and by that metric giving YouTube the appearance of greater authoritativeness is clearly harmful. If and when the major recommendation systems at work on the Web have adopted more responsible practices, it should be possible to revisit this question.

I would suggest that what is needed in the short term is the exact opposite of this proposal: we would benefit from markup that makes it easy for browsers to identify a section of a page as containing recommendations. Using this, it would be possible to eliminate recommenders known to be harmful, and possibly to replace them with ethical alternatives. It may be that a new role is all that this would require, but the benefits to the Web community would be clear.

@robin I like the proposal for markup in your last comment; I made a similar proposal a while back for markup around comments (which can also be harmful, and should be under user control).

Perhaps it would be interesting to spool up a CG about this topic generally (markup up pages to give users more control over what they consume)? To get adoption there might need to be a regulatory aspect, but that seems more possible recently.

I’m ambivalent on the Media Feeds API, as it seems like a very specialized use case, and seems to work more like an agent of the origin, rather than one which allows the user-agent to make good decisions in the user’s behalf.

But I feel all the arguments against this seem to be motivated by who stands to benefit the most, and the fact it is YouTube, a competitor to many of the parties here.

A better observation is that the API allows websites to optimize screen time on their sites, at the potential expense of other activities the user may value.

Instead of the somewhat arbitrary criteria presented so far, I think the criteria ought to very specifically include benefit to the user, with such metrics like:

• Does this railroad the user onto a single website, or is a decentralized web of links possible?
• Does this allow integration with existing media player functionality, so that playlists may be built from videos on multiple websites?

Both JSON-LD and schema.org have a history of mixed, if not poor, development.

These are very mature technologies. This is a hypermedia problem that deserves a hypermedia solution, and JSON-LD is probably the best developed hypermedia format in the Web stack behind HTML itself. That JSON-LD is a poor solution for other cases is irrelevant.

This is harmful to users because it appears to be designed to amplify or promote YouTube’s video recommendations feature, which has a significant history of promoting misinformation, conspiracies, and hateful content

How does a “significant history of promoting misinformation” by a single origin merely using the API, justify dismissing the entire API?

If you can argue this effect happens at scale for the majority of producers, there is a better argument.

YouTube has done extensive and well-documented damage already through its recommendation system

This is a content-neutral API for displaying information.

If we want to make the Web a fair and just place to interact with other people, we need to do a better job at examining the root causes of problems. The damage to society comes not from recommendations per se; it’s from the filter bubble. Almost everyone deploys some sort of filter bubble, including Firefox these days.

Some of this is, in turn, privacy related: notably, a heavy reliance on powerful scripting to provide customized content, optimized for maximizing screen time, instead of allowing the user-agent to decide what is in the user’s best interest.

For example, it is almost impossible to use YouTube with scripting disabled; even though there is no need for scripting whatsoever now that the <video> tag has been standard for almost a decade.

surfacing it in browser controls would only risk providing it with greater apparent authority.

Can you quantify this, or is this just speculation? How is a control in Firefox different than a control in the native YouTube Android app?

we would benefit from markup that makes it easy for browsers to identify a section of a page as containing recommendations.

This sounds like a different way of accomplishing the same goal; all you need to do is add some RDFa or JSON-LD markup to the page.