Re: "Mixed Content" draft up for review.

Right now Firefox will show the Mixed Content indicators if an HSTS site 
embeds and HTTP resource that will get converted to HTTPS before it hits 
the network.  We also show mixed content indicators if addons have 
rewritten the urls to use a secure connection (like HTTPS Everywhere).  
Because of implementation issues that are specific to Gecko, allowing 
the rewrites without showing warnings to the user is difficult.  We are 
working a project right now that will change that and allow these 
rewrites to happen before we trigger the Mixed Content Blocker, but it's 
going to take sometime 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1006868).

In the HSTS case, we have gone back and forth about whether we should 
warn users when no http network load has occurred 
(https://bugzilla.mozilla.org/show_bug.cgi?id=838395).  I personally 
could go either way on this.  Sometimes warning the user is the only way 
to convince a developer to fix a security issue.  I do worry about 
warning fatigue, but if the user warning allows the issue to be caught 
early and fixed quickly, then perhaps it is worth it.  The number of 
users that encounter this today is pretty miniscule, since HSTS isn't 
very common yet.  On the other hand, since more browsers are starting to 
support HSTS, the case to stop warning users grows stronger as more of 
the population will be protected despite developer mistakes 
(https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Browser_Support).

To answer Mike's question - I'm not sure if Mozilla will stop alerting 
users about potential mixed content on HSTS sites.  It is sort of a moot 
point until we finish Bug 1006868.

~Tanvi


On 6/2/14 8:26 AM, Mike West wrote:
>
> I defer to Ryan on this, but I'm curious about whether Mozilla is 
> going to push for the alternate interpretation. If not, then yes, both 
> Fetch and the mixed draft should change.
>
> Also: I think it's well in scope for the mixed spec to mandate UI in 
> broad strokes. It shouldn't mandate what shade of green the lock icon 
> should be, but forcing a distinction between mixed content and a 
> secure context seems eminently reasonable.
>
> -mike
>
> On Jun 2, 2014 5:19 PM, "Anne van Kesteren" <annevk@annevk.nl 
> <mailto:annevk@annevk.nl>> wrote:
>
>     On Mon, Jun 2, 2014 at 5:13 PM, Ryan Sleevi <rsleevi@chromium.org
>     <mailto:rsleevi@chromium.org>> wrote:
>     > While the UI treatment may be out of scope, it does seem
>     important to know
>     > what Fetch will return for an HTTP URL within an HTTPS document,
>     for which
>     > an HSTS policy exists.
>     >
>     > My view is "default secure" and "consistency is king", and to
>     block/taint
>     > the fetch as Mixed.
>     >
>     > HSTS from a site operator is a clear indicator that all
>     resources should be
>     > HTTPS, and thus failures to adhere to that policy are bugs by
>     the author
>     > that UAs should not try to cover up.
>
>     I think this makes sense actually. For resources not controlled by the
>     document it might depend on HSTS caching (did we visit that domain at
>     some point) whether or not we would block/taint which seems extra
>     weird.
>
>     Mike, should we update Fetch / Mixed Content so that blocking happens
>     before any HSTS updates to the URL? What about CSP?
>
>
>     --
>     http://annevankesteren.nl/
>