From milan.boran at gmail.com Wed Sep 1 10:00:13 2010 From: milan.boran at gmail.com (Milan Boran) Date: Wed, 1 Sep 2010 18:00:13 +0100 Subject: [HTTPS-Everywhere] https-everywhere --- problem with OptimizeGoogle and/or GoogleEnhancer Message-ID: Hi, please double check that there is no problem with either of the above referenced extensions, especially with autoscolling & more/new search results. Just what I've observed, but it could be another extension. Thank you, Milan -- ---------- Legal Note This message, incl. potential attachments, is of confidential or privileged nature and intended solely for individual/organization addressed. If received in error, please notify sender at once and destroy. Unintended use of message is forbidden/potentially illegal. Salvatory and severance apply, estoppel is void, e.g. in that any message or any part thereof shall be valid in their own context. ---------- From dexgeh at gmail.com Thu Sep 9 03:26:34 2010 From: dexgeh at gmail.com (First name Last name) Date: Thu, 9 Sep 2010 12:26:34 +0200 Subject: [HTTPS-Everywhere] ruleset for ansa.it Message-ID: From jeroen at blijbol.nl Sat Sep 11 08:05:02 2010 From: jeroen at blijbol.nl (Jeroen van der Gun) Date: Sat, 11 Sep 2010 17:05:02 +0200 Subject: [HTTPS-Everywhere] Updated and new rulesets Message-ID: <4C8B9A9E.6010201@blijbol.nl> Hello, I've made some minor modifications to the rules for Mozilla and the Netherlands Government: * Mozilla now includes the domain mozillamessaging.com (Mozilla's site for Thunderbird) * Nederland now includes the domain govcert.nl I also created two new rulesets: * Inschrijven.nl is a Dutch site to sign up for a large number of sport events in the Netherlands. Very useful rule since registration for such events includes entering your bank account number. * Security.NL is a small Dutch news site about computer security and privacy All rulesets are attached. I hope they are useful! -- http://www.jeroenvandergun.nl/pki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SecurityNL.xml Type: text/xml Size: 123 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Nederland.xml Type: text/xml Size: 1032 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Mozilla.xml Type: text/xml Size: 664 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Inschrijven.xml Type: text/xml Size: 129 bytes Desc: not available URL: From alexandros.papadopoulos at gmail.com Tue Sep 14 02:44:36 2010 From: alexandros.papadopoulos at gmail.com (Alexandros Papadopoulos) Date: Tue, 14 Sep 2010 11:44:36 +0200 Subject: [HTTPS-Everywhere] ruleset update suggestion: exclude wiktionary Message-ID: Hello Thank you for a great plugin! (I'm using version 0.2.2.development.3 on Firefox) For the next release, I'd suggest updating the wikipedia ruleset to exclude wiktionary, because right now requesting http://www.wiktionary.org takes people to https://secure.wikimedia.org/wiktionary/www/wiki/ which is just a landing page. Wiktionary should be excluded, as there apparently is no SSL version yet. Thanks! Alex From jeroen at blijbol.nl Fri Sep 17 11:24:47 2010 From: jeroen at blijbol.nl (Jeroen van der Gun) Date: Fri, 17 Sep 2010 20:24:47 +0200 Subject: [HTTPS-Everywhere] Updated and new rulesets In-Reply-To: <4C8B9A9E.6010201@blijbol.nl> References: <4C8B9A9E.6010201@blijbol.nl> Message-ID: <4C93B26F.1030704@blijbol.nl> I just created another ruleset, this time for URL shortener bit.ly. See attachment! Op 11-9-2010 17:05, Jeroen van der Gun schreef: > Hello, > > I've made some minor modifications to the rules for Mozilla and the > Netherlands Government: > > * Mozilla now includes the domain mozillamessaging.com (Mozilla's > site for Thunderbird) > * Nederland now includes the domain govcert.nl > > I also created two new rulesets: > > * Inschrijven.nl is a Dutch site to sign up for a large number of > sport events in the Netherlands. Very useful rule since > registration for such events includes entering your bank account > number. > * Security.NL is a small Dutch news site about computer security > and privacy > > All rulesets are attached. I hope they are useful! > > -- > http://www.jeroenvandergun.nl/pki -- http://www.jeroenvandergun.nl/pki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Bitly.xml Type: text/xml Size: 101 bytes Desc: not available URL: From marti at juffo.org Fri Sep 17 16:45:43 2010 From: marti at juffo.org (Marti Raudsepp) Date: Sat, 18 Sep 2010 02:45:43 +0300 Subject: [HTTPS-Everywhere] ruleset update suggestion: exclude wiktionary In-Reply-To: References: Message-ID: On Tue, Sep 14, 2010 at 12:44, Alexandros Papadopoulos wrote: > http://www.wiktionary.org takes people to > https://secure.wikimedia.org/wiktionary/www/wiki/ Try http://en.wiktionary.org/, works for me... Looks like the 'www' subdomain is just an exception that the ruleset should handle differently. Regards, Marti From schoen at eff.org Fri Sep 17 17:00:33 2010 From: schoen at eff.org (Seth David Schoen) Date: Fri, 17 Sep 2010 17:00:33 -0700 Subject: [HTTPS-Everywhere] ruleset update suggestion: exclude wiktionary In-Reply-To: References: Message-ID: <20100918000032.GE10267@sescenties> Marti Raudsepp writes: > On Tue, Sep 14, 2010 at 12:44, Alexandros Papadopoulos > wrote: > > http://www.wiktionary.org takes people to > > https://secure.wikimedia.org/wiktionary/www/wiki/ > > Try http://en.wiktionary.org/, works for me... > Looks like the 'www' subdomain is just an exception that the ruleset > should handle differently. You're both right. There is an HTTPS version of Wiktionary if you specify the language, but the current behavior if you use www.wiktionary.org is a bug because the treatment isn't parallel to the other Wikimedia Foundation wikis. We can add an exclusion for that. But if you're already familiar with the Wikimedia project you want, you should normally specify the language in the URL, like pt.wikipedia.org, de.wiktionary.org, es.wikisource.org, and so on. HTTPS Everywhere does handle all of those cases correctly, as far as we know. -- Seth Schoen Senior Staff Technologist schoen at eff.org Electronic Frontier Foundation https://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 From greased_lightning at lavabit.com Fri Sep 17 16:26:22 2010 From: greased_lightning at lavabit.com (g) Date: Fri, 17 Sep 2010 18:26:22 -0500 Subject: [HTTPS-Everywhere] Ruleset for NetFlix Message-ID: <4C93F91E.2080705@lavabit.com> From alexandros.papadopoulos at gmail.com Sat Sep 18 04:29:56 2010 From: alexandros.papadopoulos at gmail.com (Alexandros Papadopoulos) Date: Sat, 18 Sep 2010 12:29:56 +0100 Subject: [HTTPS-Everywhere] ruleset update suggestion: exclude wiktionary In-Reply-To: <20100918000032.GE10267@sescenties> References: <20100918000032.GE10267@sescenties> Message-ID: Thank you for the replies - yes, specifying the language does the job, but adding an exception would make the extension more user-friendly. Cheers! Alex On Sat, Sep 18, 2010 at 1:00 AM, Seth David Schoen wrote: > Marti Raudsepp writes: > >> On Tue, Sep 14, 2010 at 12:44, Alexandros Papadopoulos >> wrote: >> > http://www.wiktionary.org takes people to >> > https://secure.wikimedia.org/wiktionary/www/wiki/ >> >> Try http://en.wiktionary.org/, works for me... >> Looks like the 'www' subdomain is just an exception that the ruleset >> should handle differently. > > You're both right. ?There is an HTTPS version of Wiktionary if > you specify the language, but the current behavior if you use > www.wiktionary.org is a bug because the treatment isn't > parallel to the other Wikimedia Foundation wikis. ?We can add > an exclusion for that. > > But if you're already familiar with the Wikimedia project you > want, you should normally specify the language in the URL, > like pt.wikipedia.org, de.wiktionary.org, es.wikisource.org, > and so on. ?HTTPS Everywhere does handle all of those > cases correctly, as far as we know. > > -- > Seth Schoen > Senior Staff Technologist ? ? ? ? ? ? ? ? ? ? ? ? schoen at eff.org > Electronic Frontier Foundation ? ? ? ? ? ? ? ? ? ?https://www.eff.org/ > 454 Shotwell Street, San Francisco, CA ?94110 ? ? +1 415 436 9333 x107 > From vegan at riseup.net Sat Sep 18 07:42:23 2010 From: vegan at riseup.net (Vegan) Date: Sat, 18 Sep 2010 07:42:23 -0700 Subject: [HTTPS-Everywhere] Feedback on HTTPS Everywhere Message-ID: EFF HTTPS EVERYWHERE Firefox XPI Plug-in Performance using FACEBOOK! FEEDBACK After downloading from the EFF website and having installed the Firefox XPI Plug-in called ?HTTPS Everywhere? version 0.2.2 in the Firefox version 3.6.10, running on a Windows XP Pro SP3 operating system the following condition was experienced. When I select the option from the HTTPS EVERYWHERE application to use SSL on FACEBOOK, it does NOT redirect the ?active web content? that Facebook makes use of. In fact, there is NO warning in Firefox, that ?active web content? isn?t using SSL on a SSL encrypted website, unlike Microsoft Internet Explorer, tested in v6 and v7, which does pop up a security warning asking the browser user if they want to display non secure items! 2010 09 18 0010.jpg So is the EFF HTTPS EVERYWHERE Firefox Plug-in looking like a big bank vault for customers (Firefox users) with a gapping hole in the back side? Sure enough, when one checks the ?html code? on the Facebook web pages, there is plenty of non secure URL?s and non secure active web content! 2010 09 18 0032.jpg An additional issue when using the EFF HTTPS Everywhere was when attempting to view any FACEBOOK photo album, which either doesn?t display completely or takes a rather long time to display all of the photos (thumbnail views) with additional F5 webpage refreshes required. Just for the sake of testing, I tried using Facebook on different PC?s by switching between ?http? and ?https? to see what happens. In all cases, when Facebook was using SSL it had problems displaying photos, whereas non secure ?http? was blazing fast, without needing the web page to be refreshed. How does using SSL prevent loading (displaying) photos that are sent encrypted using SSL? I?m NOT a web designer, just take a look here below? 2010 09 18 0033.jpg As you see in the picture above inline, it shows some of the SSL traffic, showing those photos to be encrypted, so why does using SSL only on Facebook, delay and prevent (missing) photos from displaying. Let, me make this more clear, in that some of the photos begin to load and display on the Facebook photo album webpage, but many do NOT and some take a very long time, from seconds to minutes, to half an hour, just for thumbnails to appear! Even when refreshing the web page, which helps to display more photos, it still acts like something freezes for the behavior of using SSL with Facebook. As soon as SSL isn?t used, then those same thumbnail photos load and display almost instantly, even a hundred of them at a time. So somehow those photos are loaded in a manner that the active web content which isn?t SSL traffic produces a delay? I don?t understand, but the PC is working good, other websites don?t have this issue, when using SSL traffic. The same problem happens on multiple different computers regarding FACEBOOK when using the SSL method. So it?s NOT an issue with the PC, or the operating system, not the browsers, as different ones were used on different computers and all demonstrated the same repeating issue no matter. How to secure Facebook? So that Facebook is using full SSL/TLS using 256 bit in Firefox, including active web content? When does a social website for which millions are using, get serious with privacy security? Thanks for reading! Sincerely, V -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 40194 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 424328 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 273771 bytes Desc: not available URL: From https at whizzmo.com Sun Sep 19 23:00:58 2010 From: https at whizzmo.com (Whizz Mo) Date: Sun, 19 Sep 2010 23:00:58 -0700 Subject: [HTTPS-Everywhere] Feedback on HTTPS Everywhere In-Reply-To: References: Message-ID: I'll bite. Some ISPs (e.g. Comcast) use transparent caching servers to speed up access to frequently-requested URLs. Using SSL for these connections precludes transparent caching, as your ISP (should) never see the full URL for an SSL request. Instead of responding quickly with a ready-to-go image from a server on their network, they have to pass the request on up to the original site. The original site may be considerably farther away (ping-wise) than the caching server. The original site may also experience considerably more load than your ISPs caching server (serving one batch of clients vs. the rest of the internet). SSL connections take longer to set up and tear down than normal TCP connections (handshaking, key exchange, etc). All of these factors add up to a client experience that is slower, but more resistant to logging and malicious packet injection. You trade some lost performance for some gained security. Side note 1: "http" DTD references and "http-equiv" headers are not necessarily insecure URLs. Please be careful where you point your highlighter. Side note 2: If I remember correctly,* even if a page or HTML document contains insecure http:// references*, those references will be fetched over and SSL connection if HTTPS Everywhere has a rule that matches the reference. (Example: If http://www.cnn.com calls for an image from http://timewarnercdn.net/images/blahblahblah/omgwtfbbqsauce.jpg and HTTPS Everywhere has a rule for http://timewarnercdn.net -> https://timewarnercdn.net, the image *should *be fetched over an SSL connection. ) In other words, even "insecure" Facebook pictures can fetched over an SSL connection, albeit at a slower speed (see above). On Sat, Sep 18, 2010 at 7:42 AM, Vegan wrote: > EFF HTTPS EVERYWHERE Firefox XPI Plug-in Performance using FACEBOOK! > > * * > > *FEEDBACK* > > After downloading from the EFF website and having installed the Firefox XPI > Plug-in called ?HTTPS Everywhere? version 0.2.2 in the Firefox version > 3.6.10, running on a Windows XP Pro SP3 operating system the following > condition was experienced. > > > > When I select the option from the HTTPS EVERYWHERE application to use SSL > on FACEBOOK, it does NOT redirect the ?active web content? that Facebook > makes use of. In fact, there is NO warning in Firefox, that ?active web > content? isn?t using SSL on a SSL encrypted website, unlike Microsoft > Internet Explorer, tested in v6 and v7, which does pop up a security warning > asking the browser user if they want to display non secure items! > > > > > > > So is the EFF HTTPS EVERYWHERE Firefox Plug-in looking like a big bank > vault for customers (Firefox users) with a gapping hole in the back side? > > > > Sure enough, when one checks the ?html code? on the Facebook web pages, > there is plenty of non secure URL?s and non secure active web content! > > > > > > > An additional issue when using the EFF HTTPS Everywhere was when attempting > to view any FACEBOOK photo album, which either doesn?t display completely or > takes a rather long time to display all of the photos (thumbnail views) with > additional F5 webpage refreshes required. > > > > Just for the sake of testing, I tried using Facebook on different PC?s by > switching between ?http? and ?https? to see what happens. In all cases, when > Facebook was using SSL it had problems displaying photos, whereas non secure > ?http? was blazing fast, without needing the web page to be refreshed. > > > > How does using SSL prevent loading (displaying) photos that are sent > encrypted using SSL? I?m NOT a web designer, just take a look here below? > > > > > > > As you see in the picture above inline, it shows some of the SSL traffic, > showing those photos to be encrypted, so why does using SSL only on > Facebook, delay and prevent (missing) photos from displaying. Let, me make > this more clear, in that some of the photos begin to load and display on the > Facebook photo album webpage, but many do NOT and some take a very long > time, from seconds to minutes, to half an hour, just for thumbnails to > appear! Even when refreshing the web page, which helps to display more > photos, it still acts like something freezes for the behavior of using SSL > with Facebook. > > > > As soon as SSL isn?t used, then those same thumbnail photos load and > display almost instantly, even a hundred of them at a time. So somehow those > photos are loaded in a manner that the active web content which isn?t SSL > traffic produces a delay? I don?t understand, but the PC is working good, > other websites don?t have this issue, when using SSL traffic. The same > problem happens on multiple different computers regarding FACEBOOK when > using the SSL method. So it?s NOT an issue with the PC, or the operating > system, not the browsers, as different ones were used on different computers > and all demonstrated the same repeating issue no matter. > > > > *How to secure Facebook?* So that Facebook is using full SSL/TLS using 256 > bit in Firefox, including active web content? When does a social website for > which millions are using, get serious with privacy security? > > > > Thanks for reading! > > > > Sincerely, > > V > > > > > > _______________________________________________ > HTTPS-everywhere mailing list > HTTPS-everywhere at mail1.eff.org > https://mail1.eff.org/mailman/listinfo/https-everywhere > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pebosi at gmail.com Sun Sep 19 23:28:17 2010 From: pebosi at gmail.com (pebosi) Date: Mon, 20 Sep 2010 08:28:17 +0200 Subject: [HTTPS-Everywhere] Firefox 4 Message-ID: Hi, i would love to see your addon working with firefox 4 beta releases as its going to be finished soon... Currently the settings arent working. Regards Peter From email at franciscorrigan.com Mon Sep 20 04:44:31 2010 From: email at franciscorrigan.com (Frank Corrigan) Date: Mon, 20 Sep 2010 12:44:31 +0100 Subject: [HTTPS-Everywhere] Fwd: HTTPS? Message-ID: <1284983071.25606.1395899065@webmail.messagingengine.com> FYI ----- Original message ----- From: "franciscorrigan at aol.com" To: support at tumblr.com Date: Mon, 20 Sep 2010 12:24:36 +0100 Subject: HTTPS? Dear Tumblr, Can you advise why you do not advertise the fact that it is possible to login and sign up to Tumblr via HTTPS encrypted urls? Plus could I request that when using the Dashboard it would also be via HTTPS on a persistent basis, these options are available on most other popular blogging platforms and as you have enabled HTTPS for login and Dashboard Tumblr seem to have technically arranged for it to be impossible to enable HTTPS once logged on. Plus I do think it would be nice to have HTTPS functions enabled when accessing anyones Tumblr blog and when they are using mapped domain names, whilst this may invoke a SSL Cert error response, having such choice is important to protect users privacy and security. Services like GMAIL, Google, Facebook and Wordpress all offer persistent HTTPS connections. If Tumblr was to do as I suggest your Privacy Policy would have more credibility: "Tumblr, Inc. (?Tumblr?) takes the private nature of your personal information very seriously." http://www.tumblr.com/privacy_policy An example of the growing trend toward persistent HTTPS being enabled is HTTPS everywhere: https://www.eff.org/https-everywhere Yours faithfully Francis Corrigan From graffatcolmingov at gmail.com Mon Sep 20 10:09:25 2010 From: graffatcolmingov at gmail.com (Colonel Graff) Date: Mon, 20 Sep 2010 13:09:25 -0400 Subject: [HTTPS-Everywhere] Fwd: Firefox 4 In-Reply-To: References: Message-ID: Forgot to Reply to All ---------- Forwarded message ---------- From: Colonel Graff Date: Mon, Sep 20, 2010 at 1:09 PM Subject: Re: [HTTPS-Everywhere] Firefox 4 To: pebosi Hey Peter, I don't work on HTTPS but I know that Ffx 4beta7 has broken a lot of plugins with a regression. It has to do with the CDATA tag in the plugin source. This may or may not be the issue, but it's my guess. For the record, I found out about it here https://code.google.com/p/vimperator-labs/issues/detail?id=421 On Mon, Sep 20, 2010 at 2:28 AM, pebosi wrote: > Hi, > > i would love to see your addon working with firefox 4 beta releases as > its going to be finished soon... > > Currently the settings arent working. > > Regards Peter > _______________________________________________ > HTTPS-everywhere mailing list > HTTPS-everywhere at mail1.eff.org > https://mail1.eff.org/mailman/listinfo/https-everywhere > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at eharrishome.com Mon Sep 20 14:21:53 2010 From: erik at eharrishome.com (Erik Harris) Date: Mon, 20 Sep 2010 17:21:53 -0400 Subject: [HTTPS-Everywhere] Fwd: Firefox 4 In-Reply-To: References:

Message-ID: <4C97D071.8030107@eharrishome.com> On 9/20/2010 1:09 PM, Colonel Graff wrote: > I don't work on HTTPS but I know that Ffx 4beta7 has broken a lot of > plugins with a regression. It has to do with the CDATA tag in the plugin > source. This may or may not be the issue, but it's my guess. For the > record, I found out about it here HTTPS Everywhere has been broken since 4.0 beta 2. 4.0 beta 7 hasn't been released yet, so a regression affecting extensions isn't really an issue unless they fail to fix it prior to release. The current beta is beta 6, released on Sept 14th. check that... according to the URL you posted, the regression you mention has already been fixed, so it will not affect any Firefox beta, and it's not what caused HTTPS-Everywhere to break in beta 2. This is actually more of a problem than simply "oh, the extension doesn't work with a beta version, we'll fix it when 4.0 comes out." HTTPS-Everywhere 0.2.2 *claims* to work with the Firefox 4.0 betas and doesn't, whereas plenty of other extensions do not claim to be compatible but actually do work (using the Add-on Compatibility Reporter extension, or using one of the various manual hacks to make Firefox activate old extensions). If an extension claims not to be compatible, it's no big deal when it doesn't work. When it claims to be compatible, though, it should work. I reported this problem in late July on this list, and I've seen a couple of other people mention it since then, too. Peter said that he or Mike would fix it the following week, but if they've had time to fix it, it hasn't made it into a new release yet. :( -- Erik Harris http://www.eHarrisHome.com - AIM: KngFuJoe - Yahoo IM: kungfujoe7 - "The beliefs that you hold the most dear are the ones you should question the most." - Jay Novella From graffatcolmingov at gmail.com Mon Sep 20 16:54:30 2010 From: graffatcolmingov at gmail.com (Colonel Graff) Date: Mon, 20 Sep 2010 19:54:30 -0400 Subject: [HTTPS-Everywhere] Fwd: Firefox 4 In-Reply-To: <4C97D071.8030107@eharrishome.com> References:

<4C97D071.8030107@eharrishome.com> Message-ID: On Mon, Sep 20, 2010 at 5:21 PM, Erik Harris wrote: > On 9/20/2010 1:09 PM, Colonel Graff wrote: > >> I don't work on HTTPS but I know that Ffx 4beta7 has broken a lot of >> plugins with a regression. It has to do with the CDATA tag in the plugin >> source. This may or may not be the issue, but it's my guess. For the >> record, I found out about it here >> > > HTTPS Everywhere has been broken since 4.0 beta 2. 4.0 beta 7 hasn't been > released yet, so a regression affecting extensions isn't really an issue > unless they fail to fix it prior to release. The current beta is beta 6, > released on Sept 14th. > > My bad. I don't keep up with the Firefox betas but I do keep up with Vimperator. I was working off the information there. > check that... according to the URL you posted, the regression you mention > has already been fixed, so it will not affect any Firefox beta, and it's not > what caused HTTPS-Everywhere to break in beta 2. > > This is actually more of a problem than simply "oh, the extension doesn't > work with a beta version, we'll fix it when 4.0 comes out." HTTPS-Everywhere > 0.2.2 *claims* to work with the Firefox 4.0 betas and doesn't, whereas > plenty of other extensions do not claim to be compatible but actually do > work (using the Add-on Compatibility Reporter extension, or using one of the > various manual hacks to make Firefox activate old extensions). If an > extension claims not to be compatible, it's no big deal when it doesn't > work. When it claims to be compatible, though, it should work. > > I reported this problem in late July on this list, and I've seen a couple > of other people mention it since then, too. Peter said that he or Mike would > fix it the following week, but if they've had time to fix it, it hasn't made > it into a new release yet. :( > > -- > > Erik Harris http://www.eHarrisHome.com > - AIM: KngFuJoe - Yahoo IM: kungfujoe7 - > > "The beliefs that you hold the most dear are the ones you should question > the most." - Jay Novella > A big problem with HTTPS Everywhere, in my honest opinion is that it doesn't allow for those of us who want to contribute to do so. I'm certain by now that someone would have come up with a patch to fix it. I apologize for my own confusion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nitrox202 at gmail.com Wed Sep 22 02:30:57 2010 From: nitrox202 at gmail.com (Nitrox) Date: Wed, 22 Sep 2010 10:30:57 +0100 Subject: [HTTPS-Everywhere] Google Dictionary Issue and Google Code suggestions Message-ID: Hi, Thanks for the wonderfull addon. I just wanted to make some suggestions. When i try to visit google.com/dictionary i am being forwarded to https://encrypted.google.com/ After looking at the guide to write rules i wrote a simple redirection and it works. I just wanted to share it with you guys so you can fix it. Everything on that page loads in SSL except this one - http://www.google.com/images/nav_logo.png If i force it to https then it loads in https version. One more suggestion How about adding ssl to projectname.googlecode.com/svn/ and projectname.googlecode.com/hg/ examples: https://simpleinvoices.googlecode.com/svn/ https://ontowiki.googlecode.com/hg/ Thank you - Nitrox -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Thu Sep 23 09:28:27 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 Sep 2010 12:28:27 -0400 Subject: [HTTPS-Everywhere] upstream source for https-everywhere? Message-ID: <4C9B802B.8030100@fifthhorseman.net> hey folks-- i'm looking at the https-everywhere plugin, and considering packaging it for debian (or helping out with the packaging at least). (see http://bugs.debian.org/591579, where the debian packaging should be tracked) i'd like to know if there's an upstream source that i can follow more directly than just the published xpis. So far i've found git://git.torproject.org/https-everywhere , which appears to be a git clone of some svn repo (i don't know where that svn repo is, if it's published). unfortunately, it doesn't include any tags (e.g. of the 0.2.2 release), and the re-merges from stable to unstable (or vice versa) aren't explicitly represented (probably because svn doesn't represent them). Should i just treat the xpi as the "upstream source"? (it's not quite "the preferred form of modification" promised in the GPL, since it doesn't include the build scripts). Do you publish tarballs or release tags someplace? Also, i note that the git repo has a pkg/ directory that appears to contain .xpi files themselves, but those files are out of sync with the material in src/ (at least, the already-built xpis don't contain anything in Changelog more recent than 0.2.0). why include them in the upstream repo at all, since one should be able to generate an xpi from the src/ ? i'm happy working with git, btw -- if i was to contribute changes, i'd rather do it via git than via svn, if possible. Thanks for offering https-everywhere! sorry for the nit-picky questions... --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From schoen at eff.org Thu Sep 23 10:27:48 2010 From: schoen at eff.org (Seth David Schoen) Date: Thu, 23 Sep 2010 10:27:48 -0700 Subject: [HTTPS-Everywhere] upstream source for https-everywhere? In-Reply-To: <4C9B802B.8030100@fifthhorseman.net> References: <4C9B802B.8030100@fifthhorseman.net> Message-ID: <20100923172748.GA8725@sescenties> Daniel Kahn Gillmor writes: > hey folks-- > > i'm looking at the https-everywhere plugin, and considering packaging it > for debian (or helping out with the packaging at least). (see > http://bugs.debian.org/591579, where the debian packaging should be tracked) > > i'd like to know if there's an upstream source that i can follow more > directly than just the published xpis. Hi dkg, We're in the process of switching from SVN to that git repository, which is why it doesn't look very upstreamy or very used yet. If you can wait a little longer, the git repository should be the "real" upstream source location. -- Seth Schoen Senior Staff Technologist schoen at eff.org Electronic Frontier Foundation https://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 From dkg at fifthhorseman.net Thu Sep 23 15:03:42 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 23 Sep 2010 18:03:42 -0400 Subject: [HTTPS-Everywhere] upstream source for https-everywhere? In-Reply-To: <20100923172748.GA8725@sescenties> References: <4C9B802B.8030100@fifthhorseman.net> <20100923172748.GA8725@sescenties> Message-ID: <4C9BCEBE.70700@fifthhorseman.net> On 09/23/2010 01:27 PM, Seth David Schoen wrote: > We're in the process of switching from SVN to that git repository, > which is why it doesn't look very upstreamy or very used yet. If > you can wait a little longer, the git repository should be the > "real" upstream source location. Cool, thanks, Seth. This is good news. Does this mean that the eventual "real upstream" repo will grow out of what's currently there? or will there be rebasing going on that will cause the current branches there to be invalid in the future? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 892 bytes Desc: OpenPGP digital signature URL: From pde at eff.org Thu Sep 23 15:12:56 2010 From: pde at eff.org (Peter Eckersley) Date: Thu, 23 Sep 2010 15:12:56 -0700 Subject: [HTTPS-Everywhere] upstream source for https-everywhere? In-Reply-To: <4C9BCEBE.70700@fifthhorseman.net> References: <4C9B802B.8030100@fifthhorseman.net> <20100923172748.GA8725@sescenties> <4C9BCEBE.70700@fifthhorseman.net> Message-ID: <20100923221256.GA6366@tapdance> We created the git repo from our SVN history, and have refrained from committing anything while we move over to git (which should hopefully be done in the next week). On Thu, Sep 23, 2010 at 06:03:42PM -0400, Daniel Kahn Gillmor wrote: > On 09/23/2010 01:27 PM, Seth David Schoen wrote: > > We're in the process of switching from SVN to that git repository, > > which is why it doesn't look very upstreamy or very used yet. If > > you can wait a little longer, the git repository should be the > > "real" upstream source location. > > Cool, thanks, Seth. This is good news. Does this mean that the > eventual "real upstream" repo will grow out of what's currently there? > or will there be rebasing going on that will cause the current branches > there to be invalid in the future? > > --dkg > > _______________________________________________ > HTTPS-everywhere mailing list > HTTPS-everywhere at mail1.eff.org > https://mail1.eff.org/mailman/listinfo/https-everywhere -- Peter Eckersley pde at eff.org Senior Staff Technologist Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993 From joe at xoskins.com Mon Sep 20 09:12:16 2010 From: joe at xoskins.com (joe at xoskins.com) Date: Mon, 20 Sep 2010 09:12:16 -0700 Subject: [HTTPS-Everywhere] https ruleset for xoskins.com Message-ID: I have added and tested the xml ruleset for xoskins.com and it does work. Please add this. Thank you From mezzanine at Safe-mail.net Wed Sep 22 20:23:34 2010 From: mezzanine at Safe-mail.net (mezzanine at Safe-mail.net) Date: Wed, 22 Sep 2010 23:23:34 -0400 Subject: [HTTPS-Everywhere] Rulesets - Epson.com (partial) and LensRentals.com Message-ID: Attached to this message is a ruleset for the LensRentals.com site and a partial ruleset for a few *.epson.com domains (was.epson.com, pos.epson.com, and www.epson.com.) -------------- next part -------------- A non-text attachment was scrubbed... Name: Epson.xml Type: text/xml Size: 646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: LensRentals.xml Type: text/xml Size: 125 bytes Desc: not available URL: From manuel.flury at gmail.com Thu Sep 23 02:11:22 2010 From: manuel.flury at gmail.com (Manuel FLURY) Date: Thu, 23 Sep 2010 11:11:22 +0200 Subject: [HTTPS-Everywhere] Bad behaviour with google image Message-ID: Hi, It seems that Google Images can't be accessed through HTTPS. what needs to be done in order to have an easy access to Google Images ? Manuel FLURY -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasil at ludost.net Thu Sep 23 07:12:45 2010 From: vasil at ludost.net (Vasil Kolev) Date: Thu, 23 Sep 2010 17:12:45 +0300 Subject: [HTTPS-Everywhere] hotfile.com https-anywhere rules Message-ID: <1285251165.2059.44.camel@shrike.home.ludost.net> -- Regards, Vasil Kolev -------------- next part -------------- A non-text attachment was scrubbed... Name: hotfile.xml Type: application/xml Size: 253 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: ???? ? ??????? ????????? ???? ?? ??????? URL: From James.R.Anderson at utah.edu Thu Sep 23 15:26:38 2010 From: James.R.Anderson at utah.edu (James Anderson) Date: Thu, 23 Sep 2010 16:26:38 -0600 Subject: [HTTPS-Everywhere] Bug with Amazon color selection Message-ID: <61A710E22C550E48A5F665507D69BCFD6086B87579@C5V1.xds.umail.utah.edu> Thanks for creating this plugin. I've noticed that when the HTTPS-Everywhere plugin is enabled in Firefox I can no longer switch product colors on Amazon's site: For example, Amazon.com defaults to the graphite version of the kindle: http://www.amazon.com/Kindle-Wireless-Reader-3G-Wifi-Graphite/dp/B002FQJT3Q/ref=amb_link_354009242_5?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-1&pf_rd_r=04PJ3H60HETN73EZ59SF&pf_rd_t=101&pf_rd_p=1275406862&pf_rd_i=507846 If I want to add a white Kindle to the shopping cart I should be able to select the white color button which opens the page for the white version of the product. Instead portions of the page (ex. Price) are greyed out. You can still add the Kindle to the shopping cart, but the graphite version and not the white version is added. Without the plugin a white image of the Kindle is shown and if added to the shopping cart it lists the white Kindle. Not sure if this is your issue or Amazon's, but someone will be upset by this eventually. Sorry if this is a known issue. No response needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From patf at well.com Sun Sep 26 13:47:05 2010 From: patf at well.com (pat flaherty) Date: Sun, 26 Sep 2010 13:47:05 -0700 Subject: [HTTPS-Everywhere] Https-everywhere support for FF 4 Beta Message-ID: <4C9FB149.2020608@well.com> Hi - I'm a programmer in the SF Bay Area. I'd been using Https-everywhere for some time with FF 3 and appreciate what the addon is able to do. Upgraded recently to FF 4 Beta which seems to be a noticeable win in both speed and (lower) memory use, but Https-everywhere no longer does its stuff. Do you know what Https-everywhere's issues are with FF 4 and are there plans to upgrade it to FF 4? Is it open-sourced? I haven't worked on a FF addon in some time but wouldn't mind turning my hand that direction again. Esp for something as worthy as Https-everywhere. thanx - pat From dkg at fifthhorseman.net Mon Sep 27 10:00:40 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 27 Sep 2010 13:00:40 -0400 Subject: [HTTPS-Everywhere] loose rulesets (hostname termination) Message-ID: <4CA0CDB8.40502@fifthhorseman.net> hey folks-- this might be nit-picking, but i'm a bit concerned that some of the rulesets i see in the git repo are too loose. For example, NYTimes.xml contains: > > > which matches things like http://nytimes.commerce.com/, afaict. Now, i don't care for commerce.com's web site specifically, but it seems that it's important that rules indicate the end of the host name explicitly somehow, or else they end up covering a very broad range of systems. i'm having some trouble seeing how to resolve the issue, though. i think that the "from" should be rewritten to: from="^http://(www\.)?nytimes\.com($|/)" but i'm not entirely sure that covers the right cases (and excludes the others). i welcome verification/double-checking. Other rulesets in git that seem to be affected include: EFF.xml DuckDuckGo.xml Ixquick.xml Torproject.xml GMX.xml WashingtonPost.xml Apple.xml PayPal.xml Microsoft.xml zNoisebridge.xml Mozilla.xml Facebook.xml zGentooBugzilla.xml If the above change makes sense, i can publish a git changeset that corrects these rulesets. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From schoen at eff.org Mon Sep 27 10:15:21 2010 From: schoen at eff.org (Seth David Schoen) Date: Mon, 27 Sep 2010 10:15:21 -0700 Subject: [HTTPS-Everywhere] loose rulesets (hostname termination) In-Reply-To: <4CA0CDB8.40502@fifthhorseman.net> References: <4CA0CDB8.40502@fifthhorseman.net> Message-ID: <20100927171521.GB20313@sescenties> Daniel Kahn Gillmor writes: > hey folks-- > > this might be nit-picking, but i'm a bit concerned that some of the > rulesets i see in the git repo are too loose. > > For example, NYTimes.xml contains: > > > > > > > > > which matches things like http://nytimes.commerce.com/, afaict. This is what we discussed earlier as the "trailing slash issue". There is a bug in our bug tracker about it and my conclusion is that every rule should include a trailing slash; the ones that don't are buggy for exactly the reason you mention. I think I have a longer discussion of this somewhere in the mailing list archives. :-) -- Seth Schoen Senior Staff Technologist schoen at eff.org Electronic Frontier Foundation https://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 From dkg at fifthhorseman.net Mon Sep 27 10:31:58 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 27 Sep 2010 13:31:58 -0400 Subject: [HTTPS-Everywhere] loose rulesets (hostname termination) In-Reply-To: <20100927171521.GB20313@sescenties> References: <4CA0CDB8.40502@fifthhorseman.net> <20100927171521.GB20313@sescenties> Message-ID: <4CA0D50E.9050009@fifthhorseman.net> On 09/27/2010 01:15 PM, Seth David Schoen wrote: > Daniel Kahn Gillmor writes: > >> hey folks-- >> >> this might be nit-picking, but i'm a bit concerned that some of the >> rulesets i see in the git repo are too loose. >> >> For example, NYTimes.xml contains: >> >>> >>> >>> >> >> which matches things like http://nytimes.commerce.com/, afaict. > > This is what we discussed earlier as the "trailing slash issue". There > is a bug in our bug tracker about it and my conclusion is that every > rule should include a trailing slash; the ones that don't are buggy for > exactly the reason you mention. I think I have a longer discussion of > this somewhere in the mailing list archives. :-) ah, thanks. sorry for the repeat -- i just joined the list. fwiw, here's the link to the mailing list discussion, which contains a link to the ticket: https://mail1.eff.org/pipermail/https-everywhere/2010-July/000098.html Can i offer a changeset that adds the trailing slash to all the missing rulesets? (i'd opted for ($|/) instead of just / because i wasn't sure that http://whatever.com would get translated properly, but if you've tested it, i agree that the simplicity of / is better.) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Mon Sep 27 13:33:54 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 27 Sep 2010 16:33:54 -0400 Subject: [HTTPS-Everywhere] loose rulesets (hostname termination) In-Reply-To: <4CA0D50E.9050009@fifthhorseman.net> References: <4CA0CDB8.40502@fifthhorseman.net> <20100927171521.GB20313@sescenties> <4CA0D50E.9050009@fifthhorseman.net> Message-ID: <4CA0FFB2.9000309@fifthhorseman.net> On 09/27/2010 01:31 PM, Daniel Kahn Gillmor wrote: > Can i offer a changeset that adds the trailing slash to all the missing > rulesets? I've made such a change. it's 344dd in my git repo at: git://lair.fifthhorseman.net/~dkg/https-everywhere the repository also contains (as separate changesets) a minor fix for the exclusion rules for wordpress, an rulesets for chillingeffects.org and Riseup Networks. hope they're useful, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From home at miguelduarte.net Tue Sep 28 06:48:17 2010 From: home at miguelduarte.net (Miguel Duarte) Date: Tue, 28 Sep 2010 14:48:17 +0100 Subject: [HTTPS-Everywhere] Portuguese Government Ruleset Message-ID: Hi, Attached please find a simple ruleset to use with the 3 main Portuguese government pages. I'm however having a "bug" with the exclusion rule for mobile pages (which doesn't work properly with https): The main mobile page is: http://www.portugal.gov.pt/PortalMovel/Pages/Menu.aspx Where am I failing? Besides this, on all my tests everything seemed to be working ok. Regards, Miguel Duarte ---- Mobile: +351 966075978 Office: +351 217242590 Fax: +351 211531507 iNum: +883 510004607597 SIP: 607597 at voxalot.com Skype: mcduarte2000 -------------- next part -------------- A non-text attachment was scrubbed... Name: governoportugues.xml Type: text/xml Size: 614 bytes Desc: not available URL: From trevor.eckhart at gmail.com Thu Sep 30 19:08:10 2010 From: trevor.eckhart at gmail.com (Trevor Eckhart) Date: Thu, 30 Sep 2010 22:08:10 -0400 Subject: [HTTPS-Everywhere] rulesets Message-ID: HTTPS everywhere is great. Been using it for awhile now. Have a question on google services though, it appears that google profiles is not encrypted - http://www.google.com/profiles This is there "new" social networking, HTTPS seems to work fine and im sure would have some value. Also the following sites i have added with basic rules, someone else might get some use out of. Why not make a user submitted XML page? =========================== ========================== -------------- next part -------------- An HTML attachment was scrubbed... URL: