[HTTPS-Everywhere] In Google.xml, why "[^/@:]"?

[Drake, Brian]

Oh, I didn’t realise that the pattern you object to is being used, in some
places, to match top-level domains. In those places, yes, that is bad, as it
could (in theory, at least) match domains that aren’t even controlled by
Google.

While we’re talking about narrowing down the rules, why use clients[0-9]
when the <target> elements only go from 1 to 5? Isn’t this inefficient (by
creating more work for the regex engine)?

On Fri, Dec 24, 2010 at 0154 (UTC-8), Drake, Brian <brian2 at drakefamily.tk>wrote:

> Such misspelled URLs are going to be accessed anyway, whether or not we
> catch them. Even the request or response for a misspelled URL can contain
> information that you would not want others to see. Everything should be over
> HTTPS, unless there’s a good reason for it not to be.
> [snip]
>
> On Thu, Dec 23, 2010 at 2327 (UTC-8), Osama Khalid <osamak at gnu.org> wrote:
>
>> In Google.xml and GoogleServices.xml, "[^/@:]" is used to match
>> language codes. Language codes[0] consists of two letters. Numbers and
>> other spacial characters are not included.
>>
>> I wonder if we should use the standard '[a-zA-Z]' to match all
>> letters and to avoid catching misspelled URLs.
>>
>> [0]: http://en.wikipedia.org/wiki/List_of_ISO_639-2_codes
>>
>> --Osama Khalid
>> [snip] <https://mail1.eff.org/mailman/listinfo/https-everywhere>
>>
>
> --
> Brian Drake
> [snip]
> All content created by me Copyright © 2010 Brian Drake. All rights
> reserved.
>

--
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 © 2010 Brian Drake. All rights reserved.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.eff.org/pipermail/https-everywhere/attachments/20101230/2fc5db2f/attachment.html>