w3c / tvcontrol-api

TV Control API specification - https://w3c.github.io/tvcontrol-api/
10 stars 11 forks source link

More flexible presentation restrictions requirement? #13

Open tidoust opened 7 years ago

tidoust commented 7 years ago

I obviously do not qualify as content publisher but I wonder whether the Presentation restrictions use case could be loosened a bit. As described, it suggests that an arbitrary Web app may not be able to see any channel at all.

A possible rephrasing: "In order to ensure a consistent user experience, as a content publisher I want to allow TV content to be rendered on any web application but only allow access and manipulation of content on web domains that are authorised to do so."

The resulting requirement would then be slightly different: "The API allows presentation of audio and video media on all web domains. However, the API only allows access to and modification of the content of media tracks to some web domains."

Isolated Media Streams, defined in WebRTC, would typically match the first part of the requirement, allowing arbitrary web applications to render a MediaStream in a video or audio tag without having access to any of its internals (essentially, the MediaStream is considered CORS cross-origin content)

The peerIdentity concept would need to be adjusted to the tuner case to meet the second part of the requirement, of course. I'm not sure a whitelisting mechanism is possible on the Web, but if there's a way to associate an origin with a MediaStream coming from a tuner, the usual same-origin policy could work (e.g. if the MediaStream is identified as "bbc.co.uk", then "bbc.co.uk" web applications fully can manipulate it, while others can only render the stream.

chrisn commented 7 years ago

I think the underlying concerns from our point of view are around the display of advertisements alongside the media, and misrepresentation of the content or the metadata.

I wonder whether these concerns may be better addressed through non-technical means rather than changes to the spec? A more open API without such restrictions may encourage greater use from application developers. I'd like to hear other points of view, e.g., from other content providers on this issue.

JPEvain commented 7 years ago

This is a very sensitive subject. In short, I believe a solution meeting broadcasters (private or public) or other content providers/publishers, is a solution that would not facilitate there services to be tampered with.

There are already growing concerns about broadcaster content being re-edited and associated to third party stories, out of the original intended context.

This is even worth with advertising for many business, editorial and branding reasons.