Downloading attachments with Tor - is this secure?

Scott Bennett bennett at
Tue Jun 22 08:48:08 UTC 2010

     On Tue, 22 Jun 2010 01:18:36 -0700 Seth David Schoen <schoen at>
>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.

     The OP, IIRC, asked for a way to force HTTPS usage for *all* sites.
>(2) NoScript only supports using HTTPS for an entire domain, but we

     Not true.  The NoScript configuration panel allows specification
of *sites* (i.e., host+domainnames).  However, it also allows the use
of wildcards, as I've previously noted on this list, so *
would force HTTPS for all connections to anything that matched that
pattern.  Similarly, a simple * should force HTTPS for everything.

>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.

     That does look like a nice feature, but it's not relevant to what
the OP requested.
>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 "" 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 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
>"" to something like ""
>or "".

     Again, URL rewriting beyond simple rewriting of the protocol
designator goes way beyond what the OP requested, but if it works
properly would still seem like a nice feature for the rest of us.
>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,, 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).

     The OP's request went still further in that he wanted not to
load *anything* by HTTP, even when HTTPS were not available.

>This policy would break some functionality on some pages, like
>preventing certain images from displaying.  Some users might

     Of course.  But that's the nature of browser security.  Leaving
Java and JavaScript disabled, as has to be done as part of securing
a browser, breaks a lot of supposed "functionality" (a.k.a., security
breaches).  Using NoScript breaks more functionality, and using
privoxy and/or AdBlock Plus and/or NoRedirect and/or Refresh Blocker
will break still more.  Disabling cookies does, too.  Likewise for
any pop-up blocker.  How is breaking such "functionality" relevant
if what one insists upon is a secure browser?

>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

     But only if a destination site both supports HTTPS and is
listed in your ruleset as supporting it.  Nevertheless, it probably
doesn't hurt to add it.  Nevertheless, NoScript should be considered
as an absolute necessity, regardless of whether one demands HTTPS.
I was very glad to see that it is now included in the tor bundles.

>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.

     Just out of curiosity, how does HTTPS-Everywhere interact with
NoRedirect and Refresh Blocker?  If it is usable with those two and
doesn't break any of the features of NoScript of Torbutton, then I
might install it and try it.

                                  Scott Bennett, Comm. ASMELG, CFIAG
* Internet:       bennett at                              *
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
To unsubscribe, send an e-mail to majordomo at with
unsubscribe or-talk    in the body.

More information about the tor-talk mailing list