[HTTPS-Everywhere] Mixed Content Blocker

[Drake, Brian]

Firstly, the same issue would occur with mixed display content, if blocking
of mixed display content was turned on, right?

So the issue here is simply that, to the extent that the mixed content
blocker blocks _any_ requests, it does so before the requests are processed
by HSTS or extensions.

The first thing to do is to get some decent documentation on how things
work now – EFF and Mozilla, I’m looking at both of you! That means
documentation for users, extension developers and website developers.
Especially website developers, since the ultimate aim is to have the
websites fixed so there is no mixed content in the first place.

Then we can ask the browser publishers to change their designs. Yes, they
should change their designs. But I’m not sure that I agree with what the
change should be.

Firstly, whichever order the various components (mixed content blocker,
HSTS, extensions) process the request in, it should be clear to the user
what that order is. Especially when that user is an HTTPS Everywhere
ruleset author. :) [1]

I’m inclined to say that the mixed content blocker should block the
requests before they are processed by HSTS or extensions, but the user
should be able to override this. It should be possible, via the normal user
interface (not just something buried in about:config), to make this
override permanent. This seems like the way to get website developers’
attention while allowing users to get the same benefits that they did
before the mixed content blocker was introduced.

(Of course, the user should also be able to turn off the mixed content
blocker entirely, but that’s probably a separate issue.)

[1]
https://lists.eff.org/pipermail/https-everywhere/2014-January/001897.html

--
Brian Drake

All content created by me:
Copyright<http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html>©
2014 Brian Drake. All rights reserved.

On Tue, Jan 14, 2014 at 0910 (UTC), Jacob Hoffman-Andrews
<jsha at newview.org>wrote:

> Brian, you are correct: Currently in both Chrome and Firefox, neither HSTS
> nor HTTPS Everywhere can
> "fix up" active mixed content. The blocking happens before either
> mechanism has a chance to rewrite
> the URLs.
>
>
> Here are the relevant tickets to allow HTTPS Everywhere to do the rewrite,
> please star / vote for them:
>
>   https://code.google.com/p/chromium/issues/detail?id=122548
>   https://bugzilla.mozilla.org/show_bug.cgi?id=878890
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20140114/f40e073a/attachment.html>