Downloading attachments with Tor - is this secure?
Seth David Schoen
schoen at eff.org
Tue Jun 22 08:18:36 UTC 2010
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
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
(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/"
In fact, we already have a similar case with Wikimedia services,
where the rewrite rules understand things like
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
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.
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
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
More information about the tor-talk