On Thu, Apr 16, 2015 at 8:10 AM, Mark Watson <watsonm@netflix.com> wrote:
>
>
> On Thu, Apr 16, 2015 at 7:53 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>
>>
>> Did you agree with my assertion nevertheless? That we might want to
>> put less effort into enabling this particular MSE use case?
>>
>
> That's up to you. For our part it's not something we would find useful,
> but maybe others would. Also, the mixed content user interface is not
> ideal: the user is led, though typing https, or possibly first seeing the
> green padlock or whatever, to expect security and then it is taken away. I
> doubt most users have much idea what this means. It would be better if an
> HTTP site could somehow cause HTTPS to be used for most of the resources
> without any indication to the user (i.e. the indication is the same as an
> HTTP site, whatever that becomes).
>
> ...Mark
>
Hi Anne,
We think this is still an important issue that needs solving if we're to
offer a viable migration path from existing plugin-based solutions, and for
content providers that may not have teams of engineers like Mark mentioned
that can focus on the organization-specific challenges in getting to a
secure default.
As it stands, the absence of this solution makes several much less secure
or interoperable options more desirable, both from a technological
perspective and a user-experience. While I'm happy to hear that Netflix was
able to solve their challenges much sooner than anticipated, and am
appreciative that they focused resources to solving the problem, I think as
we look to provide a compelling story for EME over wholly-proprietary (...
rather than partially-proprietary) solutions, or look to improve the user
experience in streaming video with MSE vs the <video> tag, this is still
very much needed.