Re: [MIX] Consider all CORS requests "active"

I've pushed
https://github.com/w3c/webappsec/commit/63b19a728191e74059c190d2769f7cf44e3a0fec
in an attempt to resolve the two items this thread raised. It drops the
'active'/'passive' distinction as we've previously discussed, and blocks
CORS-enabled mixed requests.

Does the current draft (https://w3c.github.io/webappsec/specs/mixedcontent/)
accurately capture the intent of those two proposals?

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)


On Tue, Jul 22, 2014 at 11:28 AM, Jake Archibald <jaffathecake@gmail.com>
wrote:

> On 22 July 2014 08:00, Brian Smith <brian@briansmith.org> wrote:
>
>> >n Fri, Jul 11, 2014 at 3:21 AM, Jake Archibald <jaffathecake@gmail.com>
>> wrote:
>> > Mixed content will be opaque (like all responses to no-cors requests),
>> it's
>> > down to the eventual consumer (<img>, <script>, @font-face etc) whether
>> to
>> > block or allow.
>>
>> Why? I think it is not worth supporting the edge case of a site that
>> has passive mixed content AND is progressive enough to be using
>> ServiceWorker AND is unwilling/unable to get rid of the passive mixed
>> content fixed. If nothing else, the security analysis of
>> ServiceWorkers is a lot clearer if mixed content doesn't have to be
>> considered.
>>
>
> ServiceWorker already has to deal with opaque responses for cross-origin
> no-cors responses. MIX already has to deal with blocking cors requests to
> http for <img crossorigin>, <link crossorigin> & XHR. Special-casing pages
> with a serviceworker is adding complication.
>
> An empty serviceworker should not alter page behaviour.
>