Re: Comments on the EME opinion

On Thu, Oct 23, 2014 at 2:11 PM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Mark Watson [mailto:watsonm@netflix.com]
>
> > Well, obviously, it's not something anyone would be "for", if there was
> an alternative.​
>
> The existence of an alternative to these kind of one-by-one deals and
> coding setups is the entire idea the TAG feedback is driving at.
>

​Sure, and it is by no means a new idea.

I'm fairly sure that if such a solution was available we would be using it.
I don't think the absence of such solutions is for want of smart people
trying.​ If you have some ideas for overcoming the various obstacles I
mentioned, I'd love to hear them.


>
> > ​Large content providers are not all going to migrate to HTTPS overnight.
>
> Just thinking out loud, but have you considered a flag day? E.g., the spec
> says that after 2015-XX-XX, all implementations require secure origins.
> This should be encoded in implementations in a testable way out of the box,
> so that e.g. setting your system clock forward will trigger it. That would
> give enough time for content providers to migrate while avoiding the
> situation of shipping an insecure implementation forever.
>
> I imagine there are lots of holes to poke in this idea...
>
>
​A little more generally, w
​hen you talk about migrating large chunks of the web to HTTPS you ar​e
talking about asking industry to expend large sums of money. You're also
talking about a need to develop new technologies to handle HTTPS at scale -
at least we believe some new technology is needed. I think we need to
consider what strategies are most likely to be successful in getting
private businesses to spend that kind of money and to get the technologies
developed. It's the sort of thing where you need to build consensus around
a manageable and realistic plan and certainly such a plan could include
target dates. I would not expect any kind of unilateral
fiat
​from a ​
standards organization
​or anyone else ​
to be very well-received.

...Mark