W3C home > Mailing lists > Public > public-web-and-tv@w3.org > March 2016

RE: [GGIE] Future web standards question

From: Kilroy Hughes <Kilroy.Hughes@microsoft.com>
Date: Thu, 10 Mar 2016 01:24:28 +0000
To: "Deen, Glenn (NBCUniversal)" <glenn.deen@nbcuni.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Message-ID: <CY1PR0301MB1289A5108EF8F3E41AC2EAEDE1B40@CY1PR0301MB1289.namprd03.prod.outlook.com>
A common problem in several TV consortia specifying DASH to HTML5 for TV services is secure advertising behavior.

That includes:

1.      Authenticating trusted players before authorizing them to play ad supported content.

2.      Inserting and playing ads; including the player requesting ad decisions when signaled, downloading/decoding/displaying each ad.

3.      Reporting play progress to a measurement server with appropriate tokens to authenticate the response, sending protected user info for targeting and reporting purposes.

4.      Enforcing different ad play rules, such as disabling user operations during ad playback, disabling skipping ahead over ads, disabling fast forward above a particular speed, and/or until a minimum play time has been exceeded, replay behavior when rewinding, play once, play again, decision again, first ad in a pod, etc.

The general issue is that script and markup are hard to secure, and a large number of browsers have ad blockers installed today, so ad blockers for internet TV should be expected.  Security solutions that may work for signed binaries don't work for dynamic ECMAScript and distributed web pages.  If a user agent is going to enforce any behavior ad play behavior, it needs to be standardized and supported across browsers.

A consistent method for discovering user preferences.
It would be nice if applications could inspect the properties on an object or in a browser independent file or similar.

*        User preferences include audio language, subtitles on/off, subtitle language (browser display language isn't the same thing).

*        Video accessibility preferences, e.g. for descriptive audio for visually impaired, descriptive subtitles for hearing impaired, etc.

*        Multichannel or stereo sound, where the device has no idea how many speakers the audio signal connects to.

A consistent method of system capability discovery.
In particular media decoders for audio, video, and subtitles; and content decryption module SystemIDs and version numbers.

Current methods that involve querying a MIME type are usually inconclusive and insufficient to determine decode and decrypt capability.  Content is becoming well described by manifests, such as DASH; but determining decoding capability is mostly based on trial and error or external knowledge about a browser and device.  I would be useful if a browser could expose list codecs, profiles, levels, sample formats, containers, encryption schemes, registered media profile 4CC codes, etc. that it and the underlying device support so an application can easily select compatible content.


Kilroy Hughes | Senior Digital Media Architect |Windows Azure Media Services | Microsoft Corporation
[cid:image001.png@01CDABBA.71FD8800]<http://www.windowsazure.com/media>

From: Deen, Glenn (NBCUniversal) [mailto:glenn.deen@nbcuni.com]
Sent: Wednesday, March 9, 2016 10:30 AM
To: public-web-and-tv@w3.org
Subject: [GGIE] Future web standards question

I'm looking for input from the GGIE participants, and anyone else who wants to chime In,  from a GGIE perspective on Mark Watson's request for comment on future web standards for the entertainment industry.

The two initial things that came to my mind, based on what we've worked on in GGIE are:

1.   New user identity standards beyond the simplistic   USER@EXAMPLE.COM<mailto:USER@EXAMPLE.COM> email based, or  NAME that only works in the context of a service  (e.g. a Facebook account name).        These new identity standards would support privacy protection features such as pseudonyms and the ability to abandon an identity which has had It's anonymity veil broken, but without loosing all the assets tied to the that identity.     GGIE has been working on both use cases ) for this, and a requirements document. ((https://www.w3.org/2011/webtv/wiki/GGIE_TF/UseCases/Identit<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2f2011%2fwebtv%2fwiki%2fGGIE_TF%2fUseCases%2fIdentity&data=01%7c01%7ckilroy.hughes%40microsoft.com%7c03142a2f35a649631e9008d348496b42%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=lu%2bsnNCQX3R1%2fOt0olkiza6%2f%2fkd4OdN9ILfHTTiKQ3w%3d>   , https://github.com/w3c/tv-ggie/blob/master/GGIE.Identity.UC.Requirements.md)

2.  A standard API that would permit web applications to identify content.    This API would permit the application to query and obtain a URI that includes at least an identifier that uniquely identifies the content.   This could be an AD-ID or EIDR for professional content, or some other id for content from other sources.      The API would present a standard way to ask the question, and behind the scenes could employ extraction from any of  metadata, fingerprinting, or watermarking as the means to identify the content and find the associated identifier.        GGIE has a series of use cases that depend on an applications ability to know what the content is. (https://www.w3.org/2011/webtv/wiki/GGIE_TF/UseCases/Content_Identification and https://www.w3.org/2011/webtv/wiki/GGIE_TF/UseCases/Streaming<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2f2011%2fwebtv%2fwiki%2fGGIE_TF%2fUseCases%2fStreaming&data=01%7c01%7ckilroy.hughes%40microsoft.com%7c03142a2f35a649631e9008d348496b42%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=HlOWZFge7WbXUbS5TXSt8ugdI%2bhnRialIUpbtVzG6C8%3d>)


I know there are a number of non-Web Standards that have been discussed in the GGIE scope, including content addressing in caches, but Mark specificially asked for Web Standards, so we should focus in that context I thing.

Are there other Web Standards that we should include in responding to Mark?

regards
Glenn Deen (Chair GGIE taskforce)



image001.png
(image/png attachment: image001.png)

Received on Thursday, 10 March 2016 01:25:12 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 10 March 2016 01:25:13 UTC