#477: Media Feeds API

Visit on Github.

Opened Feb 19, 2020

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.

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

Discussions

2020-06-15

Minutes

Tess: I raised two issues on their repo - one in March, one three weeks ago, and David also raised one three weeks ago. Looks like the spec was using rel=feed...

Tess: David raised issue about rel=feel, seems like weird anachronism; used to be a feed relation type, no longer implemented. Started discussion between Becca and Kevin Marks about figuring out what rel value to use and where to register it. Becca changed spec 6 days ago to change rel type to media-feed. What did you think of that?

David: Given that it's a weird thing, probably better?

Tess: Should we keep this issue open or close it?

Tess: Issue I filed 3 weeks ago: she replied, I need to read/process reply. Seemed odd that this was creating a new JSON feed format when there is one already. Some of the arbitrary design decisions differ between the 2. Why gratuitously be incompatible? I need to read/understand her reply.

Tess: So we should each look at responses to those issues and figure out next steps.

Tess: Should we close after that? Or generate more feedback? Propose to close at plenary

2020-07-20

Minutes

Peter: What is the browser meant to do with the feed?

David: there were some links... seems like it's to show e.g. recommended YouTubes?

Rossen: Interesting that audio-only feeds are explicitly a non-goal...

Peter: Are any other browsers interested in implementing this?

David: Mozilla is probably unlikely to be interested.

Peter: Who else is participating in WICG? Looks like Marcos has made a few comments..?

Alice: There was a comment from Chris Needham...

Peter: I would agree with that feedback... especially the comment about restricting a site to a single feed, not everyone has control over the site (?)

... Also, yet another feed format when we already have RSS, Atom etc.

Alice: I think that was the gist of the issue Tess filed.

... danbri commented that JSON would indeed be preferable, with lengthy reasoning.

... Intent to ship was sent, although not clear whether it will actually ship.

Peter: What should we do with this?

Dan: ... I should respond to this from Mozilla Standards Positions, but that's not a TAG thing...

Peter: A high-level concern with this being a whole new thing... pushback on "why not use X" where X already exists... would like to see a richer feed format which works for everything, if existing feed formats don't.

... I also share Chris Needham's concerns.

... Would be good to understand whether there has been significant participation outside of Chromium.

David: Does this affect privacy-related UI in browser? Browsers have UI to show users what's going on with their information, how does using cookie information in a context that's not obviously a web page influence that UI?

Rossen: What use case do you have in mind for this?

David: Browser goes and starts fetching the feed on its own, not associated with any particular tab. Browser making cookie requests outside the context of a tab feels a little weird to me.

Rossen: Could this be done for push instead?

David: (missed)

Rossen: The security and privacy questionnaire... what information is exposed? Answer is "no information exposed to the website", data flow is the other way around...

Peter: So, what do we want to do with this?

Rossen: Comments have been fairly reserved, no strong push-back. This is getting ready for shipping, seems like the shipping ship has sailed... only remaining question is whether this is truly a standard.

Peter: So, do we raise yet another issue about this being a one-off feed format?

Rossen: Doesn't hurt...

Peter: Is there an open issue for Chris' privacy concerns? I don't see one...

... I'll file an issue and ask Chris to share his concerns..

2020-08-03

Minutes

[we discussed the current status and requestor's latest changes in response to Mozilla feedback]

Hadley: Martin might have a point in terms of recommenders not being good for humanity. There might be something under ethical web principles relevant to this. On ther other hand it's already going on out there. Some people might think recommendations are useful for users. We can't stop people from doing this but we can help make it safer for users. Declaring a potential conflict of interest with schema.org. Should Schema.org not be approrpriate, the normal approach would be to spin up a w3c wg to define a vocab. Not the most expedient approach.

Dan: I also don't think it's accurate to say that Schema.org is a "existing Google data format". ... [for further discussion at plenary]

2020-08-03

Minutes

Peter: I think we should close this.

Unminuted discussion. Plan to draft a closing statemnt for the plenary.

2020-08-10

Minutes

Rossen: We drafted a response on the media feeds issue

[wordsmithing of the closing comment on this one...]

...closed and commented... [based on consensus view]

  • Breakout Rollupz

  • Issue Triage