Re: [tor-talk] Towards a Torbutton for Thunderbird (torbutton-birdy)

[Bry8 Star]

Hi,
If below info are irrelevant or already discussed or old, then sorry to
post it here.

Are these being already done/added for "Torbutton-birdy" ?

"pref.js" file is inside below folder/directory :
PortableApps\ThunderbirdPortable\App\DefaultData\profile\

Before starting Thunderbird-Portable for first time,
these lines need to be added in "pref.js".

/* instead of sending/leaking your local ip-address, add a word like
"mailproxy" in helo/ehlo field */
user_pref("mail.smtpserver.default.hello_argument", "mailproxy");

/* when portable-thunderbird runs first time, then allow/partially-force
to go via Tor-proxy. The "Polipo" will be needed when using lines which
has port 8118, http or ssl. */
user_pref("dns.nameserver", "");
user_pref("network.proxy.http", "127.0.0.1");
user_pref("network.proxy.http_port", 8118);
user_pref("network.proxy.no_proxies_on", "localhost, 127.0.0.1");
user_pref("network.proxy.socks", "127.0.0.1");
user_pref("network.proxy.socks_port", 9050);
user_pref("network.proxy.socks_remote_dns", true);
user_pref("network.proxy.ssl", "127.0.0.1");
user_pref("network.proxy.ssl_port", 8118);
user_pref("network.proxy.type", 1);

/* To block auto connect to mozilla */
user_pref("app.update.auto", false);
user_pref("mail.shell.checkDefaultClient", false);

/* to block auto check for emails when startsup, or when started for
first-time */
user_pref("mail.startup.enabledMailCheckOnce", false);

Noticed, pressing "re-test" during adding new email account causes
Thunderbird to bypass Tor-proxy and use local network, thus leaking
ip-address & location of that email, even though Tor-proxy was
pre-specified or pre-configured.
But using the "Create Account" button located inside new email adding
window, did use Tor-proxy.

To avoid such local-net leak/use during email creation, few generic user
name based email accounts with major email service providers can be
pre-added into "pref.js". And then Tor-fied Thunderbird users themselves
can change "User1" in such "us...@gmail.com" pre-existing emails into
their actual email/user-name.
Pre-existing email accounts with tor-proxy pre-configured in TB, does
not leak dns or tcp.

I Noticed, in older Thunderbirds, the imap, smtp server is
"imap.gmail.com". In my test, that allows to receive emails, but not
sending. And when changed into "imap.googlemail.com", then succeeds in
both sending & receiving gmail emails.
receive: imaps, 993, SSL/TLS.
send : smtps, 587, STARTTLS.



On 5/7/2012 12:59 PM, Jacob Appelbaum wrote:
> On 05/07/2012 03:43 PM, anonym wrote:
>> 05/07/2012 05:33 PM, anonym:
>>> (Since the repo is huge (and there's no gitweb AFAIK) I also attached
>>> the commits as git patches. This were written for Thunderbird 8, but I
>>> know they apply cleanly to TB 10 as well.)
>>
> 
> ...
> 
>> Hm. I can see that the patches were attached in my outgoing email, but
>> that they didn't reach the mailing list for whatever reason (are
>> attachments disabled?). Here they are pasted inline instead:
>>
> 
> I'll comment in line.
> 
>>
>> From 0651e1f6e2c4f76fc444969f7fc6600670b302da Mon Sep 17 00:00:00 2001
>> From: Tails developers 
>> Date: Wed, 4 Jan 2012 14:48:02 +0100
>> Subject: [PATCH 1/7] Optionally skip probing for plaintext protocols.
>>
>> Setting mailnews.auto_config_ssl_only to True prevents detecting
>> plaintext protocols through autoconfiguration during account creation.
>> ---
>>  .../prefs/content/accountcreation/guessConfig.js   |   68
>> +---
>>  1 file changed, 44 insertions(+), 24 deletions(-)
>>
>> diff --git a/mailnews/base/prefs/content/accountcreation/guessConfig.js
>> b/mailnews/base/prefs/content/accountcreation/guessConfig.js
>> index 02acf3c..a183ad3 100644
>> --- a/mailnews/base/prefs/content/accountcreation/guessConfig.js
>> +++ b/mailnews/base/prefs/content/accountcreation/guessConfig.js
>> @@ -802,22 +802,32 @@ function getIncomingTryOrder(host, protocol, ssl,
>> port)
>>else if (protocol == UNKNOWN && !lowerCaseHost.indexOf("imap."))
>>  protocol = IMAP;
>>
>> +  var prefs = Cc["@mozilla.org/preferences-service;1"]
>> +  .getService(Ci.nsIPrefBranch);
>> +  var ssl_only = prefs.getBoolPref("mailnews.auto_config_ssl_only");
>> +
>>if (protocol != UNKNOWN) {
>> -if (ssl == UNKNOWN)
>> -  return [getHostEntry(protocol, TLS, port),
>> -  getHostEntry(protocol, SSL, port),
>> -  getHostEntry(protocol, NONE, port)];
>> -return [getHostEntry(protocol, ssl, port)];
>> -  }
>> -  if (ssl == UNKNOWN)
>> -return [getHostEntry(IMAP, TLS, port),
>> -getHostEntry(IMAP, SSL, port),
>> -getHostEntry(POP, TLS, port),
>> -getHostEntry(POP, SSL, port),
>> -getHostEntry(IMAP, NONE, port),
>> -getHostEntry(POP, NONE, port)];
>> -  return [getHostEntry(IMAP, ssl, port),
>> -  getHostEntry(POP, ssl, port)];
>> +if (ssl == UNKNOWN) {
>> +  var order = [getHostEntry(protocol, TLS, port),
>> + 

Re: [tor-talk] Cannot connect to Tor any more.

[Joe Btfsplk]

On 5/13/2012 11:57 AM, Aaron Whiteman wrote:

Hi,

Further to yesterday's e-mail, here are some detailed logs which explain my 
problem.

Is the problem circuit_build_times_set_timeout_worker(): and, if so, how to 
deal with it.

The logs below should a non-VPN connection (connection via a VPN does work).
This isn't a direct answer to your problem, but may help some less 
technical users.  Like in OLD Windows versions, often the solution to 
strange problems or apps / system hanging was just to reboot.  I found 
many times when Tor doesn't connect, in many cases, closing it (or 
closing TBB), making SURE that all processes of Tor -  Tor, Vidalia, Tor 
Browser are really stopped, then restart TBB / Tor solves the issue & 
saves lots of time in trying to troubleshoot.


(I still find occasionally that closing the Tor browser in usual way 
does NOT stop either / or the browser, Tor, Vidalia).

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Tor iOS repository is back online

[sid77]

Hi all,
I'd like to announce that the Tor iOS repository is back online!

TL;DR is just a two step solution:
1) If you still have the old repository installed, remove the "Sid77's Source"
package, otherwise skip to step 2
2) Use Cydia to add a new repository and write or paste this url:
http://sid77.slackware.it/ios/

Quick FAQ:

+ What happenened?
Around the beginning of April, one of the machine of the slackware.it network
suffered an awful disaster. Both of its disks failed, and sid77.slackware.it
was hosted over there :(

+ There was a backup?
Obviously not. Well, to be honest, I *DID* a backup the day before the disaster 
but
I wasn't able to retrieve it in time. How lucky! :D

+ What does it mean?
Source code was mirrored on several places and on github.com so it wasn't a
big loss, however, the old GPG signing key with ID 0x6295C2FE is gone and
lost. Eventually, it will expires in 2015 but I am pretty ashamed of not
having a revoke certificate handy.

+ Why did it take you so long?
Me and the rest of slackware.it admins were all busy with Real Life(tm), we
tried to recover what we could from the disaster before rebuilding the missing
pieces from scratch.

+ Ok, now what? How can I have the repository back?
First, if you still have the old repository installed, remove the "Sid77's
Source" package, otherwise go on.
Open Cydia then go to Sources->Edit->Add and write or paste this url:
http://sid77.slackware.it/ios/ then tap "Add Source".
Once the repository is recognized tap, on "evelyn" (its name) and install or
upgrade "Tor Toggle".
Packages are signed with the new key with ID 0x09F4FCCE: Cydia will import it
as son you add the new source to your repositories.

+ Do you know there's a "Mobile Tor" package on Big Boss repository?
Yes I do. It's not mine nor I endorse it. It was uploaded by "W00t" and its
package ID is org.torproject.mobiletor but I do not think its an official
torproject.org package.
I downloaded the deb and, as far I can tell, it should be an all-in-one
version of every package I have released so far: it contains Tor, Polipo,
libevent and the startup scripts. I think it misses the SBSettings toggle but
I'm not that sure.
I have already released an updated "Mobile Tor" version 0.3-4 in my repository
which should be picked up by Cydia. In theory, the upgraded version was
useless as the two packages have different IDs but I'd like to be better safe
then sorry ;-) Well, it should be a good idea to remove BigBoss' "Mobile Tor"
before upgrading to my packages as both of them will try to write the same
files.

That's all, in the following days I will update the rest of the site with
package descriptions and everything else.

Ciao,
Marco
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] any issue with TBB extensions auto updating?

[Joe Btfsplk]

Is there any anonymity / fingerprinting issue(s) w/ extension shipped w/ 
TBB auto updating during a Tor session?


Default setting in TBB in Addons > Extension under drop box, "Update 
Add-ons Automatically" is checked.


Do No Script, HTTPS Everywhere, TorButton automatically update when the 
default update selection above is checked & does that pose any anonymity 
/ fingerprinting issues?


Thanks.
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Joe Btfsplk]

The most recent versions of TBB & No Script's default settings under 
Advanced>External filters, is not to block hulu.com, .youtube.com.  The 
content type (I think) refers to shockwave|futuresplash.  How - OR IF - 
No Script's blocking ability of "evercookies" w/ its settings as it 
ships w/ TBB & sites like * Hulu * that (at least in recent past) were * 
confirmed * by several privacy investigation projects to be using 
evercookie / Kissmetrics.com tracking cookie technology.  These cookies 
are NOT blocked by disabling all cookies / all 3rd party cookies in 
Firefox.  Even if they were, TBB ships w/ allow all cookies enabled.


One of the many ways / places (up to 12 - 15) that the js loaded 
evercookies can be placed is as an LSO / flash cookie.  There are many 
other traditional & non traditional places these cookies are stored.  
AFAICT from reading research, these cookies CAN transmit data that could 
compromise Tor users' anonymity - as they certainly can in Firefox.  
They are also very difficult to del & "stay" deleted (thus, sometimes 
called Zombie cookies).  Deleting cookies by "normal" means does NOT 
delete them.


Numerous research reports that I've read say one of the only ways to 
block these is disable js for most sites (as in, using No Script), but 
that supposedly makes users more susceptible to fingerprinting, by only 
allowing certain sites to load js content.  Yet Hulu was one of the 
worst offenders for using evercookies (I don't use Hulu, BTW), but is 
whitelisted in NoScript.


Have Tor devs looked into THESE special types of cookies & if they 
potentially compromising anonymity or even increasing chances of 
fingerprinting, due to information they transmit about every site you visit?

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Mike Perry]

The short answer is "Yes, we've looked into it. New Identity removes
evercookies."

The long answer is
https://www.torproject.org/projects/torbrowser/design/#new-identity and
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability

The footnote is "Please help us test this shit in new releases. We just
had a race condition on the cache that allowed cache cookies to persist
for up to a minute after clicking New Identity (though they did go away
after that)."
https://trac.torproject.org/projects/tor/ticket/3846
https://trac.torproject.org/projects/tor/ticket/5715

Thus spake Joe Btfsplk (joebtfs...@gmx.com):

> The most recent versions of TBB & No Script's default settings under
> Advanced>External filters, is not to block hulu.com, .youtube.com.
> The content type (I think) refers to shockwave|futuresplash.  How -
> OR IF - No Script's blocking ability of "evercookies" w/ its
> settings as it ships w/ TBB & sites like * Hulu * that (at least in
> recent past) were * confirmed * by several privacy investigation
> projects to be using evercookie / Kissmetrics.com tracking cookie
> technology.  These cookies are NOT blocked by disabling all cookies
> / all 3rd party cookies in Firefox.  Even if they were, TBB ships w/
> allow all cookies enabled.
> 
> One of the many ways / places (up to 12 - 15) that the js loaded
> evercookies can be placed is as an LSO / flash cookie.  There are
> many other traditional & non traditional places these cookies are
> stored.  AFAICT from reading research, these cookies CAN transmit
> data that could compromise Tor users' anonymity - as they certainly
> can in Firefox.  They are also very difficult to del & "stay"
> deleted (thus, sometimes called Zombie cookies).  Deleting cookies
> by "normal" means does NOT delete them.
> 
> Numerous research reports that I've read say one of the only ways to
> block these is disable js for most sites (as in, using No Script),
> but that supposedly makes users more susceptible to fingerprinting,
> by only allowing certain sites to load js content.  Yet Hulu was one
> of the worst offenders for using evercookies (I don't use Hulu,
> BTW), but is whitelisted in NoScript.
> 
> Have Tor devs looked into THESE special types of cookies & if they
> potentially compromising anonymity or even increasing chances of
> fingerprinting, due to information they transmit about every site
> you visit?
> ___
> tor-talk mailing list
> tor-talk@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Praedor Tempus]

OK, this sort of thing has me wondering if the only way to safely use tor is in 
a virtual machine.  Would this not seem to be the case?  Who cares if Hulu or 
Youtube gets your IP address if it is a bogus VM IP address rather than your 
real one?  They get to see either your tor IP or the IP of your VM and nothing 
else.  


Perhaps tor should move to a tor browser VM instead of just an app?




 From: Joe Btfsplk 
To: Tor-Talk  
Sent: Monday, May 14, 2012 2:15 PM
Subject: [tor-talk] Evercookies / supercookies tracking & No Script 
whitelisting tracking sites
 
The most recent versions of TBB & No Script's default settings under 
Advanced>External filters, is not to block hulu.com, .youtube.com.  The content 
type (I think) refers to shockwave|futuresplash.  How - OR IF - No Script's 
blocking ability of "evercookies" w/ its settings as it ships w/ TBB & sites 
like * Hulu * that (at least in recent past) were * confirmed * by several 
privacy investigation projects to be using evercookie / Kissmetrics.com 
tracking cookie technology.  These cookies are NOT blocked by disabling all 
cookies / all 3rd party cookies in Firefox.  Even if they were, TBB ships w/ 
allow all cookies enabled.

One of the many ways / places (up to 12 - 15) that the js loaded evercookies 
can be placed is as an LSO / flash cookie.  There are many other traditional & 
non traditional places these cookies are stored.  AFAICT from reading research, 
these cookies CAN transmit data that could compromise Tor users' anonymity - as 
they certainly can in Firefox.  They are also very difficult to del & "stay" 
deleted (thus, sometimes called Zombie cookies).  Deleting cookies by "normal" 
means does NOT delete them.

Numerous research reports that I've read say one of the only ways to block 
these is disable js for most sites (as in, using No Script), but that 
supposedly makes users more susceptible to fingerprinting, by only allowing 
certain sites to load js content.  Yet Hulu was one of the worst offenders for 
using evercookies (I don't use Hulu, BTW), but is whitelisted in NoScript.

Have Tor devs looked into THESE special types of cookies & if they potentially 
compromising anonymity or even increasing chances of fingerprinting, due to 
information they transmit about every site you visit?
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] any issue with TBB extensions auto updating?

[Mike Perry]

We're not aware of any fingerprinting or anonymity issues, so long as
you keep the same set of addons in TBB and do not install extras.

The updates are authenticated over SSL.

However, we want to ween ourselves off of our dependence upon the CA
model for authenticating these updates:
https://trac.torproject.org/projects/tor/ticket/5092

Thus spake Joe Btfsplk (joebtfs...@gmx.com):

> Is there any anonymity / fingerprinting issue(s) w/ extension
> shipped w/ TBB auto updating during a Tor session?
> 
> Default setting in TBB in Addons > Extension under drop box, "Update
> Add-ons Automatically" is checked.
> 
> Do No Script, HTTPS Everywhere, TorButton automatically update when
> the default update selection above is checked & does that pose any
> anonymity / fingerprinting issues?
> 
> Thanks.
> ___
> tor-talk mailing list
> tor-talk@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Towards a Torbutton for Thunderbird (torbutton-birdy)

[Sukhbir Singh]

Hi,

> /* instead of sending/leaking your local ip-address, add a word like
> "mailproxy" in helo/ehlo field */
> user_pref("mail.smtpserver.default.hello_argument", "mailproxy");

Done.

> /* when portable-thunderbird runs first time, then allow/partially-force
> to go via Tor-proxy. The "Polipo" will be needed when using lines which
> has port 8118, http or ssl. */
> user_pref("dns.nameserver", "");
> [...]
> user_pref("network.proxy.type", 1);

Done.

> /* To block auto connect to mozilla */
> user_pref("app.update.auto", false);

Done.

> user_pref("mail.shell.checkDefaultClient", false);

Not done. Please explain why do you think this is useful, that is,
what type of information can be leaked? :)

> /* to block auto check for emails when startsup, or when started for
> first-time */
> user_pref("mail.startup.enabledMailCheckOnce", false);

There is no concept of 'toggle' in the Torbutton for Thunderbird --
the only way to enable/ disable it will be by restarting Thunderbird.
So IMO this is not required.

> Noticed, pressing "re-test" during adding new email account causes
> Thunderbird to bypass Tor-proxy and use local network, thus leaking
> ip-address & location of that email, even though Tor-proxy was
> pre-specified or pre-configured.
> But using the "Create Account" button located inside new email adding
> window, did use Tor-proxy.
>
> To avoid such local-net leak/use during email creation, few generic user
> name based email accounts with major email service providers can be
> pre-added into "pref.js". And then Tor-fied Thunderbird users themselves
> can change "User1" in such "us...@gmail.com" pre-existing emails into
> their actual email/user-name.
> Pre-existing email accounts with tor-proxy pre-configured in TB, does
> not leak dns or tcp.

We are aware of this issue (tagnaq's paper [0], Section 3.6.5 explains
this in detail). Because there seems to be no way to disable this from
within Thunderbird, we are currently working to skip the auto
configuration wizard by forcing the use of the manual account
configuration. I think we should have something ready soon.

> I Noticed, in older Thunderbirds, the imap, smtp server is
> "imap.gmail.com". In my test, that allows to receive emails, but not
> sending. And when changed into "imap.googlemail.com", then succeeds in
> both sending & receiving gmail emails.
> receive: imaps, 993, SSL/TLS.
> send : smtps, 587, STARTTLS.

[1].

Thanks for helping us test this out.

[0] - 
https://trac.torproject.org/projects/tor/attachment/wiki/doc/TorifyHOWTO/EMail/Thunderbird/Thunderbird%2BTor.pdf
[1] - https://support.google.com/mail/bin/answer.py?hl=en&answer=78799

-- 
Sukhbir
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Joe Btfsplk]

On 5/14/2012 1:58 PM, Praedor Tempus wrote:
OK, this sort of thing has me wondering if the only way to safely use tor is in a virtual machine.  Would this not seem to be the case?  Who cares if Hulu or Youtube gets your IP address if it is a bogus VM IP address rather than your real one?  They get to see either your tor IP or the IP of your VM and nothing else. 



Perhaps tor should move to a tor browser VM instead of just an app?
I think one of the issue (may) be that even though evercookies wouldn't 
see you "real" IP address, they would be able to track you across 
multiple websites, incl. all URLs, pages / links you click on, what you 
d/l, etc.  They are able to transmit that data back to the mother ship.  
I'll leave it to Tor "experts" EXACTLY how that could be used by either 
the companies gathering the info, the sites (where the evercookie was 
set) that were paying them to gather data, or adversaries trying to 
fingerprint Tor users (if that's possible using evercookie data).


I would think - certainly in countries hostile to Tor (or ones that 
aren't) - they could set up fake websites in order to set evercookies 
just for tracking purposes.  That might or might not lead them directly 
to a person (again, experts can weigh in), but it would give them info 
on how many users are accessing certain sites & what they're looking 
at.  There may be other things I haven't thought of.


___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Joe Btfsplk]

On 5/14/2012 1:56 PM, Mike Perry wrote:

The short answer is "Yes, we've looked into it. New Identity removes
evercookies."

The long answer is
https://www.torproject.org/projects/torbrowser/design/#new-identity and
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability

The footnote is "Please help us test this shit in new releases. We just
had a race condition on the cache that allowed cache cookies to persist
for up to a minute after clicking New Identity (though they did go away
after that)."
https://trac.torproject.org/projects/tor/ticket/3846
https://trac.torproject.org/projects/tor/ticket/5715
How, pray tell, does clicking New Identity remove evercookies from 12 - 
15 possible locations?  The cache isn't the only place evercookies can 
be stored.  How does it remove ANY cookies at all?  Does that 
necessarily clear LSOs, clear different locations HTML5 data can be 
stored - like delete webappstore.sqlite - (even if you've not viewed 
HTML5 media, the cookies can still be place there), or all other known 
locations evercookies can be placed (so far)?  I never heard or read 
that feature when using New Identity.  Was I absent that day or were we 
waiting for just the right time for a big announcement?


Thus spake Joe Btfsplk (joebtfs...@gmx.com):


The most recent versions of TBB&  No Script's default settings under
Advanced>External filters, is not to block hulu.com, .youtube.com.
The content type (I think) refers to shockwave|futuresplash.  How -
OR IF - No Script's blocking ability of "evercookies" w/ its
settings as it ships w/ TBB&  sites like * Hulu * that (at least in
recent past) were * confirmed * by several privacy investigation
projects to be using evercookie / Kissmetrics.com tracking cookie
technology.  These cookies are NOT blocked by disabling all cookies
/ all 3rd party cookies in Firefox.  Even if they were, TBB ships w/
allow all cookies enabled.

One of the many ways / places (up to 12 - 15) that the js loaded
evercookies can be placed is as an LSO / flash cookie.  There are
many other traditional&  non traditional places these cookies are
stored.  AFAICT from reading research, these cookies CAN transmit
data that could compromise Tor users' anonymity - as they certainly
can in Firefox.  They are also very difficult to del&  "stay"
deleted (thus, sometimes called Zombie cookies).  Deleting cookies
by "normal" means does NOT delete them.

Numerous research reports that I've read say one of the only ways to
block these is disable js for most sites (as in, using No Script),
but that supposedly makes users more susceptible to fingerprinting,
by only allowing certain sites to load js content.  Yet Hulu was one
of the worst offenders for using evercookies (I don't use Hulu,
BTW), but is whitelisted in NoScript.

Have Tor devs looked into THESE special types of cookies&  if they
potentially compromising anonymity or even increasing chances of
fingerprinting, due to information they transmit about every site
you visit?
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk



___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] any issue with TBB extensions auto updating?

[tagnaq]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

> Is there any anonymity / fingerprinting issue(s) w/ extension
> shipped w/ TBB auto updating during a Tor session?
> 
> Default setting in TBB in Addons > Extension under drop box,
> "Update Add-ons Automatically" is checked.
> 
> Do No Script, HTTPS Everywhere, TorButton automatically update when
> the default update selection above is checked & does that pose any
> anonymity / fingerprinting issues?

You might be interested in this discussion:
https://lists.torproject.org/pipermail/tor-talk/2011-June/020755.html
https://lists.torproject.org/pipermail/tor-talk/2011-July/020784.html

short version: the exit sees what you are updating (http request) but
can't modify it without being detected.

regarding the prevention of SSL MITM (compromised CAs and the such)
during the update process, you might want to have a look at:
https://trac.torproject.org/projects/tor/ticket/3555

the future of key pinning via HTTP headers
http://tools.ietf.org/rfcmarkup?doc=draft-ietf-websec-key-pinning-01
-BEGIN PGP SIGNATURE-

iF4EAREKAAYFAk+xbEkACgkQyM26BSNOM7aJ3AEAnWiVA4+And1x/ThB07dH/p6M
Y8KBT51eNVCFKg8GCsgA/AjaTuAsE2tuGhky25py9KCZtqAQsIbKdXQsjAE9U9iD
=dlXp
-END PGP SIGNATURE-
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Matthew Kaufman]

Hi Joe,

Great questions.  I was also wondering how these claims on the New Identity
button works in this case.

If it is the case, which it may be, this seems to or would seem to exceed
my expectations just as it may yours.



On Monday, May 14, 2012, Joe Btfsplk wrote:

> On 5/14/2012 1:56 PM, Mike Perry wrote:
>
>> The short answer is "Yes, we've looked into it. New Identity removes
>> evercookies."
>>
>> The long answer is
>> https://www.torproject.org/**projects/torbrowser/design/#**new-identityand
>> https://www.torproject.org/**projects/torbrowser/design/#**
>> identifier-linkability
>>
>> The footnote is "Please help us test this shit in new releases. We just
>> had a race condition on the cache that allowed cache cookies to persist
>> for up to a minute after clicking New Identity (though they did go away
>> after that)."
>> https://trac.torproject.org/**projects/tor/ticket/3846
>> https://trac.torproject.org/**projects/tor/ticket/5715
>>
> How, pray tell, does clicking New Identity remove evercookies from 12 - 15
> possible locations?  The cache isn't the only place evercookies can be
> stored.  How does it remove ANY cookies at all?  Does that necessarily
> clear LSOs, clear different locations HTML5 data can be stored - like
> delete webappstore.sqlite - (even if you've not viewed HTML5 media, the
> cookies can still be place there), or all other known locations evercookies
> can be placed (so far)?  I never heard or read that feature when using New
> Identity.  Was I absent that day or were we waiting for just the right time
> for a big announcement?
>
>>
>> Thus spake Joe Btfsplk (joebtfs...@gmx.com):
>>
>>  The most recent versions of TBB&  No Script's default settings under
>>> Advanced>External filters, is not to block hulu.com, .youtube.com.
>>> The content type (I think) refers to shockwave|futuresplash.  How -
>>> OR IF - No Script's blocking ability of "evercookies" w/ its
>>> settings as it ships w/ TBB&  sites like * Hulu * that (at least in
>>> recent past) were * confirmed * by several privacy investigation
>>> projects to be using evercookie / Kissmetrics.com tracking cookie
>>> technology.  These cookies are NOT blocked by disabling all cookies
>>> / all 3rd party cookies in Firefox.  Even if they were, TBB ships w/
>>> allow all cookies enabled.
>>>
>>> One of the many ways / places (up to 12 - 15) that the js loaded
>>> evercookies can be placed is as an LSO / flash cookie.  There are
>>> many other traditional&  non traditional places these cookies are
>>> stored.  AFAICT from reading research, these cookies CAN transmit
>>> data that could compromise Tor users' anonymity - as they certainly
>>> can in Firefox.  They are also very difficult to del&  "stay"
>>> deleted (thus, sometimes called Zombie cookies).  Deleting cookies
>>> by "normal" means does NOT delete them.
>>>
>>> Numerous research reports that I've read say one of the only ways to
>>> block these is disable js for most sites (as in, using No Script),
>>> but that supposedly makes users more susceptible to fingerprinting,
>>> by only allowing certain sites to load js content.  Yet Hulu was one
>>> of the worst offenders for using evercookies (I don't use Hulu,
>>> BTW), but is whitelisted in NoScript.
>>>
>>> Have Tor devs looked into THESE special types of cookies&  if they
>>> potentially compromising anonymity or even increasing chances of
>>> fingerprinting, due to information they transmit about every site
>>> you visit?
>>> __**_
>>> tor-talk mailing list
>>> tor-talk@lists.torproject.org
>>> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk
>>>
>>
>>
>> __**_
>> tor-talk mailing list
>> tor-talk@lists.torproject.org
>> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk
>>
> __**_
> tor-talk mailing list
> tor-talk@lists.torproject.org
> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk
>
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Joe Btfsplk]

On 5/14/2012 1:56 PM, Mike Perry wrote:

The short answer is "Yes, we've looked into it. New Identity removes
evercookies."...

The footnote is "Please help us test this shit in new releases. We just
had a race condition on the cache that allowed cache cookies to persist
for up to a minute after clicking New Identity (though they did go away
after that)."...
Maybe there should be more discussion about these types of cookies (most 
aren't even aware of them or their capabilities), how to PREVENT them - 
to extent possible & how to clean them up.  They are NOT easy to get rid 
of if they've been placed in many / most of the known locations they can 
hide.


Also, FAQ on them.  I read the design links for New Identity &  the bug 
links, but I didn't see how that handles ALL the known locations where 
evercookies can be placed.
Another view is, "An ounce of prevention is worth a pound of cure."  I 
think educating users how to avoid them, to the extent possible, would 
be good.  They're often easier to avoid than eradicate.


I can't vouch for these clean up utilities effectiveness on 
evercookies.  I use them, but haven't tested much on evercookies.

BleachBit claims it will clean evercookies (recent versions).
CCleaner (some forum moderators) claim it will clean them, but I 
couldn't squeeze out of anyone at Piriform, that CCleaner officially 
claims to handle evercookies (meaning, all known "hiding places.")


___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Mike Perry]

Let's continue speculating instead of reading any documentation.
That's totally a productive use of everyone's time.

https://www.torproject.org/projects/torbrowser/design/#new-identity
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability

Thus spake Matthew Kaufman (mkfmn...@gmail.com):

> Hi Joe,
> 
> Great questions.  I was also wondering how these claims on the New Identity
> button works in this case.
> 
> If it is the case, which it may be, this seems to or would seem to exceed
> my expectations just as it may yours.
> 
> 
> 
> On Monday, May 14, 2012, Joe Btfsplk wrote:
> 
> > On 5/14/2012 1:56 PM, Mike Perry wrote:
> >
> >> The short answer is "Yes, we've looked into it. New Identity removes
> >> evercookies."
> >>
> >> The long answer is
> >> https://www.torproject.org/**projects/torbrowser/design/#**new-identityand
> >> https://www.torproject.org/**projects/torbrowser/design/#**
> >> identifier-linkability
> >>
> >> The footnote is "Please help us test this shit in new releases. We just
> >> had a race condition on the cache that allowed cache cookies to persist
> >> for up to a minute after clicking New Identity (though they did go away
> >> after that)."
> >> https://trac.torproject.org/**projects/tor/ticket/3846
> >> https://trac.torproject.org/**projects/tor/ticket/5715
> >>
> > How, pray tell, does clicking New Identity remove evercookies from 12 - 15
> > possible locations?  The cache isn't the only place evercookies can be
> > stored.  How does it remove ANY cookies at all?  Does that necessarily
> > clear LSOs, clear different locations HTML5 data can be stored - like
> > delete webappstore.sqlite - (even if you've not viewed HTML5 media, the
> > cookies can still be place there), or all other known locations evercookies
> > can be placed (so far)?  I never heard or read that feature when using New
> > Identity.  Was I absent that day or were we waiting for just the right time
> > for a big announcement?
> >
> >>
> >> Thus spake Joe Btfsplk (joebtfs...@gmx.com):
> >>
> >>  The most recent versions of TBB&  No Script's default settings under
> >>> Advanced>External filters, is not to block hulu.com, .youtube.com.
> >>> The content type (I think) refers to shockwave|futuresplash.  How -
> >>> OR IF - No Script's blocking ability of "evercookies" w/ its
> >>> settings as it ships w/ TBB&  sites like * Hulu * that (at least in
> >>> recent past) were * confirmed * by several privacy investigation
> >>> projects to be using evercookie / Kissmetrics.com tracking cookie
> >>> technology.  These cookies are NOT blocked by disabling all cookies
> >>> / all 3rd party cookies in Firefox.  Even if they were, TBB ships w/
> >>> allow all cookies enabled.
> >>>
> >>> One of the many ways / places (up to 12 - 15) that the js loaded
> >>> evercookies can be placed is as an LSO / flash cookie.  There are
> >>> many other traditional&  non traditional places these cookies are
> >>> stored.  AFAICT from reading research, these cookies CAN transmit
> >>> data that could compromise Tor users' anonymity - as they certainly
> >>> can in Firefox.  They are also very difficult to del&  "stay"
> >>> deleted (thus, sometimes called Zombie cookies).  Deleting cookies
> >>> by "normal" means does NOT delete them.
> >>>
> >>> Numerous research reports that I've read say one of the only ways to
> >>> block these is disable js for most sites (as in, using No Script),
> >>> but that supposedly makes users more susceptible to fingerprinting,
> >>> by only allowing certain sites to load js content.  Yet Hulu was one
> >>> of the worst offenders for using evercookies (I don't use Hulu,
> >>> BTW), but is whitelisted in NoScript.
> >>>
> >>> Have Tor devs looked into THESE special types of cookies&  if they
> >>> potentially compromising anonymity or even increasing chances of
> >>> fingerprinting, due to information they transmit about every site
> >>> you visit?
> >>> __**_
> >>> tor-talk mailing list
> >>> tor-talk@lists.torproject.org
> >>> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk
> >>>
> >>
> >>
> >> __**_
> >> tor-talk mailing list
> >> tor-talk@lists.torproject.org
> >> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk
> >>
> > __**_
> > tor-talk mailing list
> > tor-talk@lists.torproject.org
> > https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk
> >
> __

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Mike Perry]

Thus spake Joe Btfsplk (joebtfs...@gmx.com):

> How, pray tell, does clicking New Identity remove evercookies from
> 12 - 15 possible locations?  The cache isn't the only place
> evercookies can be stored.  How does it remove ANY cookies at all?
> Does that necessarily clear LSOs, clear different locations HTML5
> data can be stored - like delete webappstore.sqlite - (even if
> you've not viewed HTML5 media, the cookies can still be place
> there), or all other known locations evercookies can be placed (so
> far)?  I never heard or read that feature when using New Identity.
> Was I absent that day or were we waiting for just the right time for
> a big announcement?

Oh, sorry, you did ask how. Well:
https://gitweb.torproject.org/torbutton.git/blob/master:/src/chrome/content/torbutton.js#l1387

For the other stuff, I refer you to about a half dozen blog posts on the
topic, several tor-talk posts, and probably a few dozen mailinglist
threads, may of which you yourself participated in.



-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Mike Perry]

Thus spake Mike Perry (mikepe...@torproject.org):

> Thus spake Joe Btfsplk (joebtfs...@gmx.com):
> 
> > How, pray tell, does clicking New Identity remove evercookies from
> > 12 - 15 possible locations?  The cache isn't the only place
> > evercookies can be stored.  How does it remove ANY cookies at all?
> > Does that necessarily clear LSOs, clear different locations HTML5
> > data can be stored - like delete webappstore.sqlite - (even if
> > you've not viewed HTML5 media, the cookies can still be place
> > there), or all other known locations evercookies can be placed (so
> > far)?  I never heard or read that feature when using New Identity.
> > Was I absent that day or were we waiting for just the right time for
> > a big announcement?
> 
> Oh, sorry, you did ask how. Well:
> https://gitweb.torproject.org/torbutton.git/blob/master:/src/chrome/content/torbutton.js#l1387

Here's a better link direct to the comment above the implementation,
which describes it.
https://gitweb.torproject.org/torbutton.git/blob/master:/src/chrome/content/torbutton.js#l1370



-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Mike Perry]

Thus spake Joe Btfsplk (joebtfs...@gmx.com):

> On 5/14/2012 1:56 PM, Mike Perry wrote:
> >The short answer is "Yes, we've looked into it. New Identity removes
> >evercookies."...
> >
> >The footnote is "Please help us test this shit in new releases. We just
> >had a race condition on the cache that allowed cache cookies to persist
> >for up to a minute after clicking New Identity (though they did go away
> >after that)."...
> Maybe there should be more discussion about these types of cookies
> (most aren't even aware of them or their capabilities), how to
> PREVENT them - to extent possible & how to clean them up.  They are
> NOT easy to get rid of if they've been placed in many / most of the
> known locations they can hide.

https://trac.torproject.org/projects/tor/ticket/5294

We want to keep it short and sweet, though. Normal people don't care
about enumerating evercookie locations, only mentats do.

Mentats are encouraged to read the design doc, suggest improvements, and
review the source code.

> Also, FAQ on them.  I read the design links for New Identity &  the
> bug links, but I didn't see how that handles ALL the known locations
> where evercookies can be placed.
> Another view is, "An ounce of prevention is worth a pound of cure."
> I think educating users how to avoid them, to the extent possible,
> would be good.  They're often easier to avoid than eradicate.

Word. The design does come from a thorough understanding of all the
places browsers can store state about your browsing experience, in what
cases it gets transmitted and/or side channeled, and how
to deal with it.

The design is documented so others with this understanding can verify
we've done our jobs, though perhaps we could make the "New Identity"
section itself more legible, somehow.

Keeping TBB relatively simple (only three addons, no plugins) makes this
a whole lot easier than for vanilla Firefox. That's one of the reasons
why New Identity is disabled there.

> I can't vouch for these clean up utilities effectiveness on
> evercookies.  I use them, but haven't tested much on evercookies.
> BleachBit claims it will clean evercookies (recent versions).
> CCleaner (some forum moderators) claim it will clean them, but I
> couldn't squeeze out of anyone at Piriform, that CCleaner officially
> claims to handle evercookies (meaning, all known "hiding places.")

To be fair, the EverCookie problem does grow exponentially more
complicated once you add in third party plugins and addons, AV software,
etc. That's why we try to keep TBB simple, and keep other addons and
plugins out of it.


-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Infographics about Iranian Internet

[ix4svs]

On 10 May 2012 02:38,   wrote:
> I thought this was more accessible to the non-technical crowd.
>
> http://www.this-is-maral.com/the-iranian-internet/-info-graphic

A script-free version would be great.
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] please unsubscribe me to your mailing loist thanks!

[ix4svs]

On 30 April 2012 12:11,   wrote:
> On Mon, Apr 30, 2012 at 02:01:36AM +, crowma...@tormail.org wrote 1.8K 
> bytes in 49 lines about:
> : i don't wan't these messages anymore thank you
>
> Then unsubscribe, the link is at the bottom of every single message to the 
> list.

Apparently the gobbledygook in the footer doesn't mean anything to
people who haven't spent years on mailing lists.

Perhaps there should be something more explicit like "To unsubscribe,
click here: https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk";?

Cheers

Alex
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Evercookies / supercookies tracking & No Script whitelisting tracking sites

[Joe Btfsplk]

On 5/14/2012 3:52 PM, Mike Perry wrote:

Let's continue speculating instead of reading any documentation.
That's totally a productive use of everyone's time.

https://www.torproject.org/projects/torbrowser/design/#new-identity
https://www.torproject.org/projects/torbrowser/design/#identifier-linkability
I'm not speculating at all.  As I said, I read the info on new identity 
design (as best as I can understand - regarding both limited amount & 
complexity of info).  I didn't get anything from them that explained (to 
me, a non expert) how New Identity, or anything else in TBB, deletes 
evercookies in every documented storage location (if they exist in many 
/ all of those locations).

Sorry if I'm dense, but I didn't get that.

The original developer of the evercookie concept, Samy Kamkar, listed 
the places they can be hidden (below).  I just didn't get that using New 
Identity would deal w/ all these locations.  Maybe it does, but it 
didn't read like that to me.


Standard HTTP cookies
Local Shared Objects (Flash cookies)
Silverlight Isolated Storage
Storing cookies in RGB values of auto-generated, force-cached PNGs 
using HTML5 Canvas tag to read pixels (cookies) back out

Storing cookies in Web history
Storing cookies in HTTP ETags
Storing cookies in Web cache
window.name caching
Internet Explorer userData storage
HTML5 Session Storage
HTML5 Local Storage
HTML5 Global Storage
HTML5 Database Storage via SQLite

The developer is looking to add the following features:

Caching in HTTP Authentication
Using Java to produce a unique key based on NIC information.

___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Towards a Torbutton for Thunderbird (torbutton-birdy)

[Mike Perry]

Thus spake Sukhbir Singh (sukhbir...@gmail.com):

> > /* To block auto connect to mozilla */
> > user_pref("app.update.auto", false);
> 
> Done.

Yikes! Don't disable Thunderbird autoupdate like this without a damn
good reason, analysis, *and* alternatives. 

Otherwise, you're condemning the user to get owned as their client
gradually gets more and more exploitable from the date they install
Torbirdy.
 

-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk