On 7 November 2010 18:04, Peter Eckersley <span dir="ltr"><<a href="mailto:pde@eff.org">pde@eff.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Sat, Nov 06, 2010 at 05:51:30AM -0400, Flamsmark wrote:<br>
<br>
> If a mature version of this sort of script is produced, is it possible that<br>
> (distant) future versions of the addon might do opportunistic https even for<br>
> sites where there isn't a rule?<br>
<br>
</div><snip><br>
Currently, I think these problems are too far-reaching to imagine HTTPS<br>
Everywhere autoprobing sites by default.  We could consider offering this kind<br>
of behaviour as an option that users can turn on if they want, of course.<br></blockquote><div><br>Many security or privacy oriented addons - like NoScript and RequestPolicy break sites by default. They typically come with a small whitelist of things that are known to safely fix some things, but leave the rest up to the user. I'm not saying that this is exactly the right approach for HTTPS Everywhere. It's possible, for instance, that the you'd prefer not to rely on users to make those sort of security assessments. However, I could certainly see the value of this approach, for the more sophisticated user at least. I know that I would appreciate that approach, even if I'm not the typical, or target user. Even still, most users are savvy enough to identify that a site is broken, and choose to switch to the other version.<br>

<br>Certainly consider the following hypothetical feature list:<br>- shipping HTTPS Everywhere with default rules for popular sites known to work, or not work,<br>- using HTTPS opportunistically according to such a script (though perhaps not with JS checks), and<br>

- giving the user a browser menu to over-ride the script's guess when a site breaks (and optionally save that choice).<br><br>Given that this is a popular paradigm for similar extensions, that would certainly be a feasible approach to take. It doesn't seem like to be outside the scope of possible development work. For the savvy user - at least - it would provide the potential for an addon that does roughly what the name says - HTTPS (almost) everywhere (that it's supported).<br>

<br>Is that a plausible development path?<br></div></div>