[HTTPS-Everywhere] The context menu has landed

Drake, Brian brian2 at drakefamily.tk
Fri Jul 1 06:07:08 PDT 2011


It’s true that my optimisation example does not provide an encryption
advantage. But rules like [0], do not provide an encryption advantage either
(in the absence of certificate errors, anyway), compared to the simplest
form [1], yet we still use them.

If, right now, we are taking an HTTP URL and adding “www.” to the start,
then I am suggesting that we take the corresponding HTTPS URL and do the
same thing. Be consistent!

As for the other types of rules, I was not suggesting that we accept them,
only that the software should support them. There are other people, like me,
who have the knowledge and willingness to write such rules for themselves
and for other people who know what they are doing.

In the end, I was simply asking that the software continue to support
redirects for all types of URLs, particularly HTTPS ones, even if (by some
miracle) all these certificate errors were resolved. And, like I asked last
time, wouldn’t that be easier anyway?

[0] http://(www.)?example.com/ → https://www.example.com/
[1] http://example.com/https://example.com/; http://www.example.com/https://www.example.com/

On Sat, Jun 25, 2011 at 1219 (UTC-8), Osama Khalid <osamak at gnu.org> wrote:

> On Sat, Jun 25, 2011 at 005612 (UTC-8), Drake, Brian wrote:
> >    - optimisation (https?://(www.)?example.com/ →
> >    https://www.example.com/, where https://example.com/ would have
> >    redirected to https://www.example.com/ anyway);
>
> I don't think this kind of rules should be accepted because it does
> not provide a known encryption advantage, but I may support it if
> https://example.com/ results in a certificate warning.
>
> >    - controlling content from untrusted domains
> >    (https?://apps.facebook.com/→ https://example.com/fbAppGateway/).
>
> This kind of rules shouldn't be accepted at all since it redirects
> users to a provider other than the one they choose, which could be
> even more dangerous than insecurely connecting the original website.
>
> --Osama Khalid
>

--
Brian Drake

Alternate (slightly less secure) e-mail: brian at drakefamily.tk
Alternate (old) e-mail: brianriab at gmail.com

Facebook profile: Profile ID
100001669405117<https://ssl.facebook.com/profile.php?id=100001669405117>
Twitter username: BrianJDrake <https://twitter.com/BrianJDrake>
Wikimedia project username:
Brianjd<https://secure.wikimedia.org/wikipedia/meta/wiki/User:Brianjd>(been
inactive for a while)

All content created by me
Copyright<http://www.wipo.int/treaties/en/ip/berne/trtdocs_wo001.html>©
2010–2011 Brian Drake. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20110701/917c5b77/attachment.html>


More information about the HTTPS-everywhere mailing list