W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2018

Re: To Stream or not to Stream (payload encryption use cases)

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 15 Jun 2018 14:04:09 -0700
Message-ID: <CAJrXDUHvSJu68KxYFWOaDs5e=zBnZKadqggfnkOnTP4Rax4zcg@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: youenn fablet <yfablet@apple.com>, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Jun 15, 2018 at 5:39 AM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Youenn said:
>
> "The dual encryption use case is also interesting to study."
>
> [BA] It appears that there may be multiple of these, with different
> security requirements.
>
> One of them is the "secure conferencing" use case.
>
> In this use case, the goal is to have end-to-end payload encryption, where
> the service itself is untrusted and must not have access to unprotected
> media (raw or encoded).
>
> As a result in such a use case JS access to raw or encoded cleartext
> frames is an anti-requirement - this must be prevented to implement the use
> case properly.
>
> The other use case relates to entertainment - namely content protection.
>
>
Such a deep rabbit hole.  Can we just stay far away and not think about
this use case?


> In that use case, the service is trusted, but the goal is to disable
> aspects of browser functionality such as media recorder.
>
> So performance is not the only issue here - we need to understand exactly
> what use case we are attempting to implement and what the resulting
> security requirements are.
>
> Yoenn also said:
>
> "As of the streaming of media content, I agree there might be some
> convergence, especially with live content.
> That said, access to raw decodable content/raw decoded frames goes against
> EME-based solutions."
>
> [BA] Indeed.  That is why it is critical that we are clear on the use case
> and *all* of the requirements necessary to make them work.
>
Received on Friday, 15 June 2018 21:04:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC