Scott Bennett writes: > While HTTPS-Everywhere may be a nice programming exercise for its > author(s), it appears wholly unnecessary for Firefox users because Firefox > users should *ALREADY* be using NoScript, which allows one to accomplish > the same thing, but also provides mountains of other protective measures. > Don't be fooled into thinking that HTTPS-Everywhere can protect your > anonymity or your privacy. If you and/or the OP continue to refuse to > use NoScript, then sooner or later you and/or the OP will get burned and > will thus be taught the hard way the lesson you should have understood by > now.
NoScript provides important protections for Firefox users that HTTPS Everywhere doesn't, but there are two kinds of gaps where HTTPS Everywhere provides functionality that NoScript doesn't. (HTTPS Everywhere is also partly based on code from NoScript.) (1) HTTPS Everywhere bundles a specific, and growing, list of sites that support HTTPS, so you don't (necessarily) have to find those sites yourself. (2) NoScript only supports using HTTPS for an entire domain, but we have several examples where sites support HTTPS only on parts of the site, or even using a different hostname, requiring a more specific translation rule and not just a hostname list. For example, the Google support in the current HTTPS Everywhere tree is currently _fifteen_ different substitution rules, and we are already aware of several parts of Google's services that it still handles slightly incorrectly and that will require additional rules and exclusions. Just adding "www.google.com" to your NoScript configuration will provide quite a bit less correct functionality; to use a simple example, Google Language Tools currently breaks if you try to access it in HTTPS. Google has also suggested that they may move HTTPS support off of www.google.com entirely in order to help schools censor access to Google services; if they do that, there will be an even more conspicuous need for HTTPS Everywhere to rewrite URLs beginning with "http://www.google.com/"; to something like "https://secure.google.com/"; or "https://ssl.google.com/";. In fact, we already have a similar case with Wikimedia services, where the rewrite rules understand things like http://pt.wikipedia.org/wiki/Tiradentes --> https://secure.wikimedia.org/wikipedia/pt/wiki/Tiradentes http://la.wikisource.org/wiki/Carmina_(Catullus)/1 --> https://secure.wikimedia.org/wikisource/la/wiki/Carmina_(Catullus)/1 Again, NoScript currently can't do that kind of substitution. If you tried to force HTTPS access on, say, en.wikipedia.org, it would just break because there is no HTTPS support on that host. On the other hand, some users might definitely prioritize confidentiality over availability and argue that the browser should never load an HTTP resource from an HTTPS page (which I understand was actually a common browser default in the past). This policy would break some functionality on some pages, like preventing certain images from displaying. Some users might think that's an appropriate trade-off because of the risks of unencrypted access. Currently HTTPS Everywhere doesn't include any rules which deliberately do this when it would break some of the page's functionality. It's possible to implement that behavior on your own machine with either NoScript or HTTPS Everywhere if you know all of the relevant domain names (for example, for Wikimedia you might block access to "http://upload.wikimedia.org/";). For Tor users, HTTPS Everywhere particularly provides protection against exit node operators and their ISPs, while NoScript particularly provides protection against sites trying to recognize or track users. (Of course, NoScript is also helpful for defending against other kinds of threats.) In this sense, the protections provided by the two programs can be complementary. -- Seth Schoen Senior Staff Technologist [email protected] Electronic Frontier Foundation https://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
