W3C home > Mailing lists > Public > www-tag@w3.org > October 2014

Re: Comments on the EME opinion

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Wed, 29 Oct 2014 11:28:53 +0200
Message-ID: <CANXqsRLa1PnLk6ugMehM=TE2Kmu2cokEuZioinnTAMC3P2UEsA@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: David Dorwin <ddorwin@google.com>, Mark Watson <watsonm@netflix.com>, Domenic Denicola <domenic@domenicdenicola.com>, www-tag <www-tag@w3.org>
On Mon, Oct 27, 2014 at 4:45 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Oct 27, 2014 at 12:02 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
>> The obvious question that is whether it would be feasible to do
>> something that'd make XHR from https to http not blocked. For example,
>> could streaming services deliver hashes of the video segments to the
>> JS app over https and could https to http XHR be unblocked if the JS
>> app told XHR the expected MIME type and hash and those matched what
>> XHR actually received?
>
> Poking new holes in a system that's already fragile seems like a bad idea.

It's worth noting that most of the fragility would come from
preventing the application from obtaining information about the
resource before the hash has been computed (successfully). This
fragility already follows if the integrity policy "block" ends up
being implemented for XHR per Subresource Integrity:
http://w3c.github.io/webappsec/specs/subresourceintegrity/#xmlhttprequest-1

At this point, I'm not advocating anything--just exploring
possibilities, but it seems to me that if this is rejected on
fragility grounds (as opposed e.g. rejecting this due to there being
too much collateral damage from https pages being able to waive
confidentiality of XHR subsources), it seems to me that we should then
reject the XHR part of Subresource Integrity in general.

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/
Received on Wednesday, 29 October 2014 09:29:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:06 UTC