Re: Testing W3C's HTTPS setup

I'm a little confused as to the barrier here -- like Mike said, it's never
been the case that HSTS would fix mixed-content warnings, even with CSP
upgrade-insecure-requests. There have been some proposals to this effect,
but nothing is finalized in any browser, and only Mozilla has indicated
clear interest.

As an outsider, I can say that it looks pretty weird for the W3C to not
have HTTPS figured out yet. Are there ways for outsiders to help identify
or fix mixed content issues? I'll run some sed commands on a folder full of
flat text files to help the W3C any time. :)

-- Eric

On Mon, Sep 21, 2015 at 8:06 AM, Mike West <mkwst@google.com> wrote:

> On Mon, Sep 21, 2015 at 1:48 PM, Jose Kahan <jose.kahan@w3.org> wrote:
>
>> We need a solution that will allow to assume all content is https,
>> in perpetuity, without needing to upgrade all legacy content.
>>
>
> That seems like an unfortunate design decision. I hope you'll change your
> mind over time. :)
>
>
>> > I guess it's not clear to me why you're fine with the current setup for
>> > browsers like Safari, but aren't fine with it for Firefox? Wouldn't you
>> > just treat Firefox like every other browser that doesn't support the
>> > upgrade directive? That is:
>> >
>> > * If you don't see an `upgrade-insecure-requests` header in the
>> navigation
>> > to `http://w3.org/` <http://w3.org/>, don't redirect to HTTPS.
>>
>> That's how we set it up.
>>
>
> Great! In that case, I still don't understand the problem. If
> Firefox/Safari/Edge don't support the features that you need, and you're
> not redirecting them, what is the problem that would cause you to roll back
> the change?
>
> > * If you don't see an `upgrade-insecure-requests` header in a navigation
>> to
>> > `https://w3.org`, downgrade to HTTP (and don't serve HSTS)?
>> >
>> > This use case is why we added the signaling header. :)
>>
>> That doesn't make sense. When browsing protected resources, you need
>> HTTP, you cannot downgrade it to HTTP systematically. What I think
>> you mean to say is that for public resources, apply the rule you said.
>> I may be missing some of the context in your statement.
>>
>
> I'm sure the setup you're working with will have some special cases (like
> resources behind the login wall being HTTPS-only). Those special cases
> shouldn't see any change in behavior from today, however, right? Firefox
> still works correctly on those pages.
>
> I suppose I should have been more specific. If you don't see an
> `upgrade-insecure-requests` header in a request for a page which requires
> `upgrade-insecure-requests` to function correctly, then you should
> downgrade that request from HTTPS to HTTP. Does that make sense?
>
> -mike
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>