[tor-dev] Panopticlick summer project

[Gunes Acar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear All,

My name is Gunes Acar, a 2nd year PhD student at Computer Security and
Industrial Cryptography (COSIC) group of University of Leuven.

I work with Prof. Claudia Diaz and study online tracking and browser
fingerprinting. I'd like to work on "Panopticlick"
(https://www.torproject.org/getinvolved/volunteer.html.en#panopticlick)
summer
project and other fingerprinting related issues which I tried to
outline below:

1) Collaborate with Peter@EFF to port/open-source Panopticlick:
https://trac.torproject.org/projects/tor/ticket/6119#comment:4
a) implement necessary modifications - e.g. we won't be having cookies
or real IP addresses to match returning visitors.
b) consider security implications of storing fingerprints (e.g. what
happens if someone gets access to fingerprint database?)

2) Add machine-readability support outlined in Tor Automation
proposals:
https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint
a) which one(s) should we implement? JSON, YAML, XML?

3) Survey the literature for fingerprinting attacks published since
Panopticlick. Implement those that may apply to TBB:
a) Canvas & WebGL fingerprinting (Mowery et al.) - make sure the patch
at #6253 works
b) JS engine fingerprinting (Mulazzani et al.)
c) CSS & rendering engine fingerprinting, (Unger et al.)
...

4) Check with realworld fingerprinting scripts to see if they collect
anything that is not considered before. Check if TBB's FP
countermeasures work against them. (We can use data from FPDetective
study to find sites with fingerprinting scripts)

5) Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in case
they consider an update.

6) Convert fixed FP-related bugs into regression tests.
https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting&status=closed

7) Build test cases to check the severity of fingerprinting related
open tickets, e.g.:
https://trac.torproject.org/projects/tor/ticket/8770
https://trac.torproject.org/projects/tor/ticket/10299

8) Work on potential fingerprinting bugs that ESR31 may bring.

9) ESR transitions seem to create a lot of FP-related issues that need
to be checked manually (e.g. #9608). Consider developing a tool that
iterates over the host objects of two browsers to compare them
automatically (e.g. to pinpoint new objects, new methods, updated
default values, etc.). Similar to "diff tool" mentioned here:
https://people.torproject.org/~boklm/automation/tor-automation-proposals.html#helper-fingerprint

10) Evaluate the font-limits of TBB by checking the average # of fonts
Top 1 Million sites use. We can either collect fresh data with
FPDetective or use the existing (~1 year old) data.


More on my background relevant to fingerprinting and TBB code base:

We recently published a paper called "FPDetective: Dusting the Web for
Fingerprinters" (CCS'13) to measure the prevalence of browser
fingerprinting on the Internet. As a part of this study, we built
instrumented browsers from Chromium and PhantomJS source code and
developed a framework to detect fingerprinting
(https://github.com/fpdetective/).

I also got my hands dirty with the TBB source code to seek
vulnerabilities in FP countermeasures. Two ways I found to circumvent
existing font limits were as follows:
https://trac.torproject.org/projects/tor/ticket/8270#comment:2
https://trac.torproject.org/projects/tor/ticket/5798#comment:13

Other pointers:
My website: http://www.esat.kuleuven.be/cosic/?page_id=126
FPDetective website: https://www.cosic.esat.kuleuven.be/fpdetective/
My (first & only) Tor patch:
https://trac.torproject.org/projects/tor/ticket/10472
My Tor FAQ profile: http://tor.stackexchange.com/users/731/gacar

Looking for your comments,
Cheers,
Gunes

N.B.: I won't be applying to GSoC.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTJmUiAAoJEPb7JcMmVt4g4jAH/2JLUKPGo52JpfsHeMtLZgQm
JVoEELKuNVjwJ5KqgO4OhIqpS6yl/cggLsUe19fNrC5I++5w5lGWM3JRqCU/T5OV
PLwRrs1lc1wU2zWkcKN/uvZyFys1xAsA2NzyYRZdKOjoGiDI8a3wgYM/o8a5PSt0
+wTJ6OdtRpFuXk9CrxUScx6kbLEYCoQeGcAmQe+ZIUWo6CzeQr/3yP8Jz7B3Uyqq
ccSJACFuif2naQFiCDqyuQLIZu/9jMFGbYMg81OhZeeOWhmq4FwCjZOR8bzj8zqV
i3N8hFXTRSYLjOg5AWVX+JMsCWJAX3rTrYe6X5GKA/tIm1gMJhwtedfaE38eHOM=
=2stA
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] GsoC - Interested in "Revamp GetTor"

[Israel Leiva]

Hi!

My name is Israel Leiva, I'm a computer science student at University of
Santiago, Chile. More info about me in [1]. I'm interested in the 'Revamp
GetTor' project for the Google summer of code. I think that GetTor has a
huge impact on how to avoid censorship, and therefore it could be expanded
to do a lot more of what it does now. Here is my idea:

i) A modular design, with a core module in charge of transmitting data to
the others modules, each one of them would represent a different "service"
(e.g. SMTP)

ii) The core module will be in charge of receiving requests from the other
modules and answer them. For example, the SMTP module will say "Give me the
URL links for TBB in this language" and the core module will answer with
the desired links. These links could be retrieved from several locations,
my proposal is that the links could be stored in a private git repository
available only to trusted Tor developers, so the links and other data could
vary with time according to the different censorship behaviours.

iii) As I said, the other modules will each represent a different
"service". I propose the following three for starting:

   * SMTP: Enhance the current bot. I tried it a couple of days ago and it
didn't work as I expected (sent me a windows link when I asked for linux).

   * Twitter: this module will answer requests via twitter, either via
mentions or via direct messages. It will ask for the corresponding links to
the core module. There are lots of bots implemented out there, no need to
reinvent the wheel.

   * Skype: this module will listen for calls or chats and will answer with
a file transfer or message with the links. I believe this can be done using
the sevabot [2] in Python or the Skype::Any [3] in Perl.

The main idea is that this new design would allow for new services to be
implemented in the future.


** OTHER IDEAS **

Here are some minor ideas that could also be considered:

a) Most OS bring tools to make DNS requests, and an (experimented) user
could make custom requests for TXT records that contain links. I know this
isn't the case for most people, but it could be helpful.

b) Users could send formatted mails with their public PGP keys to the SMTP
service, and the bot will answer them with encrypted content.

c) Users could notify services with censored links, this means that if, for
example, a user requests the links via SMTP and one of them has been
blocked, he/she could send a message notifying this to the SMTP service.
This info along with stats about which services are more popular will be
saved in a log file (I think this is how is working now) and/or a database.
The purpose of this data will be to enhance GetTor, no info about users
will be recorded.

d) Other option to storage could be Github (as you may know, repos can be
downloaded as ZIP files).

e) For all the above, GetTor will need official twitter/github accounts.

f) Comunication between modules could be done via system commands, but I'm
open to any other suggestions. This communication will involve sending
links (trusted servers, github repo, dropbox accounts) or local uris
(~/tbb/latest.tgz).

A basic diagram representing what I've tried to explain can be found on [4].

I think the best way to achieve this is to rewrite GetTor, but if you
choose extend the current code to do it I'm okay with it. If you choose the
former, I could do it in Python, eventhough I have a lot more experience in
Perl (I've coded a module to automate the grading of programming tasks [5]).

This is just a draft, please let me know if you find this is the way to go
and I'll work in the details and a possible timeline to see how much can be
done in 4 months.


[1] http://ileiva.github.io
[2] https://github.com/opensourcehacker/sevabot
[3] http://search.cpan.org/~akiym/Skype-Any-0.06/lib/Skype/Any.pm
[4] https://raw.github.com/ileiva/Tor/master/revamp-gettor-simplediagram.txt
[5] https://metacpan.org/author/ILV

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

Re: [tor-dev] GSoC - Search Engine for Hidden services

[Giovanni `evilaliv3` Pellerano]

Hi George,

i answer for the two tor2web related questions:
1) where are the stats of Tor2web?
in collaboration with Ahmia i've decided to implement some stats, but
due to the fact that we don't to want to provide I) realtime data
useful for tracking II) so much information we decided to implement
the following:

tor2web logs, only in RAM and using a two days window, a cumulative
counter for hidden services and make it available for access only to
the yesterday stats in order to not provide this data in realtime so
that the data provided is simply:
hidden service 1: #22
hidden service 2: #333
...

here is the example: https://antani.tor2web.org/antanistaticmap/stats/yesterday

2) what about list of blocked hs?
tor2web also provides the configuration for blocked hs by simply using
MD5 of resources so that the url of the blocked page is not available
since the configuration time.
due to this simple implementation we make always a check for the MD5
of the hidden service and an MD5 of the full resource, if that matchs
it means that the page must be blocked.

tor2web also does currently fetch ahmia list in order to get automatic
updates of this hashed blocklist.

this is the list provided by ahmia: https://ahmia.fi/bannedMD5.txt
(numes it currently list only an entry why?)


George if you or anybody else have good suggestion for better
improval, you are welcome :)

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

Re: [tor-dev] GSoC - Search Engine for Hidden services

[Fabio Pietrosanti (naif)]

2014-03-16 20:13 GMT+01:00 George Kadianakis mailto:desnac...@riseup.net>>:


> API development
>
> In addition, ahmia.fi  provides RESTful API to
integrate other services
to use hidden service description information (see
https://ahmia.fi/documentation/ ).
Hidden services can integrate their
descriptions directly to the hidden service list (see
https://ahmia.fi/documentation/descriptionProposal/
).


I just added manually all the known globaleaks sites
(http://en.wikipedia.org/wiki/GlobaLeaks#GlobaLeaks_uses) to the Ahmia
Directory, so we can test the experimental feature of GlobaLeaks that
generate a Description.json documented at
https://ahmia.fi/documentation/descriptionProposal/
 
 

> Integration with Tor2web
> Thanks to our suggestion recently, Tor2web has implemented a feature
that provides secure and anonymous statistics within a day. I want to
implement to implement an automatic fetch and handling of this data.
> Ahmia.fi should fetch these and add each new .onion page


The experimental statistics documented here:
https://github.com/globaleaks/Tor2web-3.0/wiki/OpenData

Fabio


-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - http://globaleaks.org - http://tor2web.org

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

Re: [tor-dev] GSoC - Search Engine for Hidden services

[George Kadianakis]

Juha Nurmi  writes:

>> And what would you like to do over the summer so that: a) Something
>> useful and concrete comes out of only 3 months of work. b) Your
>> work will also be useful after the summer ends.
>>
>> I would be interested to see some areas that you would like to work
>> on over the summer, and how that would change the ahmia.fi user
>> experience.
>
> I have drafted a timetable for the possible new features to ahmia.fi:
>
> https://docs.google.com/document/d/1XB42HM4uESYBAnoHHRuaqKMP64VFDI91Qa-CtIuye2E/edit?usp=sharing
>

Hello Juha,

here are some comments on your proposal:

> Search development
>
> Full text search development
> Popularity tracking (catch users clicks and tell YaCy the popular
pages): development of a popularity tracking feature for ahmia.fi
and Integration of that feature with YaCy API (providing stats for  
  popular pages and suggestions for relevant results)
> 1-3 workdays
>

Yes, this is definitely useful.

I would also like you to check out how backlinks work, and whether
your crawler can start counting HS backlinks too. Mainly because
popularity tracking is easily gameable, whereas backlinks might be
harder to game (still definitely gameable though; SEO is crazy).

To make sure that this section is done properly, I would suggest to
compile a list of well-known HSes and verify that they all appear
on/near the top of the ahmia search results by the end of development
of these features.

I would suggest using more than 1-3 workdays for this.

> Use an another crawler to search .onion pages from the public Internet
> Search new .onion domains from different online sources
> This is an excellent case to test open source crawlers like Heritrix and
Apache Nutch
> 1 workweeks
>

Yes, this is very useful.

> Public open YaCy back-end for everyone
> let’s make our YaCy network open so anyone can join to it with their
YaCy nodes
> This way we could get real P2P decentralization
> Share installation configuration package that joins a YaCy node to
ahmia.fi’s nodes
> 1 workweek
>

I guess this is also useful.

> Better edited HS descriptions
> Design and development of a more useful and complete UI including more  
  comple and exaustive descriptions and details (e.g., show the whole   
 history of descriptions and let the users edit it better)
> 1 workweek
>

Yes this seems like a good idea. Improving the UX is very important.

Because of the security nature of ahmia, the UX should be security
conscious too. For example, you shouldn't give your users too much
confidence on the ordering of the search results since a motivated
adversary can probably influence it.

Maybe you could also expose some of your popularity/backlinks
information to users, in case that lets them pick results more safely.

> Comment and vote about the content (safe/unsafe)
> Ahmia.fi needs a commenting and rating systems for hidden services
> It is useful to gather a user's knowledge about the sites
> 1 workweek
>

I think that this needs more thinking.

The rating idea is trivially gameable. Do we assume that all users are
good citizens?

Given that there are shitloads of phising websites registered to
ahmia, we take it that there are bad people out there who know of
ahmia. How will the rating system interact with bad people? What about
the comming system? Is this also an argument against popularity
tracking? How do we use this technologies usefully in the face of bad
people?

> Tor browser friendly version of the ahmia.fi
> Development of a JavaScript free version of ahmia.fi
> 1 workweek
>

TBB has javascript enabled these days. I would probably spend this one
week on other stuff.

> Search API
> 1 workweek
>

What do you mean by this? Do other search engines provide this sort of API?

This would need more than one week to design and deploy properly, no?

> Automated statistics and visualizations about hidden services and their
content
> Development of an Analytics feature
> As the result of the indexing Tor network's content ahmia.fi can produce
an authoritative and exact quantitative research data about what is
published through the Tor network.
> 2 workweeks
>
> Automated visualizations
> It is very practical to visualize the data
> 2 workweeks
>

Both of the above items are statistics and they seem to require 1
month of development. Are there really that many stats that we
can/should produce?

What kind of stats are you thinking of, other than the "number of HSes
added per month", "number of ahmia visitors", etc.? BTW, we should be
very careful that stats are privacy preserving.

> Show cached text versions of the pages
> 1 workweek
>

Useful. I thought you had this feature in the past though; no?

> API development
>
> In addition, ahmia.fi provides RESTful API to integrate other services
to use hidden service description information (see
https://ahmia.fi/documentation/). Hidden services can integrate their
descriptions directly to the hidden service list (see
https://ahmia.f

Re: [tor-dev] Torbirdy

[Sukhbir Singh]

Hi mujnabed,

> I wanted to clarify my understanding of the current status of the project.
> The project requires resolving two issues related to location anonymity
> weakening due to local timestamp leakage specifically in the MessageID &
> Date header fields.

Thanks for your interest in Tor and TorBirdy!

> From reading issues #6314, #6315 mentioned and the patch requests submitted
> for bugs #902573 and #902580 at bugzilla.mozilla.org, It seems that the
> current hold up by Mozilla to accepting the patch request are:
> 1. Establishing how well Thunderbird & other mail clients handle the date
> not being inserted by the sender in the mail header
> 2. Finding which MTA/MSA's automatically insert date headers on their own
> and if most/all don't, finding a workaround to that. Gmai, Mail.com, Gmx,
> Yandex and the now dead Lavabit had been tested successfully for automatic
> date header insertion

This was the idea when the patches were submitted but in later
discussions, we decided that removing the date header completely was not
a good idea and would break things, not only in Thunderbird but in other
MUAs. Also, convincing Mozilla to get such a patch accepted is  likely
going to be difficult.

The exact specifics can be discussed later, but as mentioned in #902573,
this option looks most suitable:

  Keep the Date header and ensure it is in UTC (eg: allow some clock
disclosure but not time zone to network)

> 3. And using extension hooks with explicit calls instead of checking user
> set configurations flags for removing timestamp data from header. This it's
> suggested will allow better handling of messages received/sent in the
> background by Thunderbird.

Yes, that's correct. Figuring out how to do this and doing it properly
is the only blocker. We already have code ready for generating random
message-IDs (which could also use some work but that is for later) which
is called using the preferences system, which is what you are going to
be replacing.

Let me know if you have any more questions. It would also be helpful to
read https://bugzilla.mozilla.org/show_bug.cgi?id=776397, which was the
original ticket we submitted.

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

Re: [tor-dev] TBB for Chromebooks?

[Alexander Kyte]

This is entirely unnecessary. Allow me a proof by enumeration.

1) Chromeos doesn't allow an end-user to set a proxy on the version of
chrome shipped with the chromebook.
2) If the end user is running some other browser they had to install it via
crouton or by installing another distro on their chromebook.
2a) In either case, the user can simply install TBB.
3) There is no need to make a chromebook-specific package. In fact, I don't
think it is possible to make one.


On Sun, Mar 16, 2014 at 8:11 AM, Griffin Boyce wrote:

> Hello all,
>
>   Is there a plan to port TBB for chromebooks?
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] TBB for Chromebooks?

[Griffin Boyce]

Hello all,

  Is there a plan to port TBB for chromebooks? 
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Torbirdy

[mujnabed sol]

Hello everyone,

I'm in my final year of B.E in Electronics & Instrumentation Engineer and
M.Sc in Mathematics from BITS Pilani, India.
I was hoping to get a chance to work with the Tor community through this
years GSOC. I was reading the projects list and was interested in
contributing to the Torbirdy project as I have some experience in coding in
Javascript.

I wanted to clarify my understanding of the current status of the project.
The project requires resolving two issues related to location anonymity
weakening due to local timestamp leakage specifically in the MessageID &
Date header fields.

>From reading issues #6314, #6315 mentioned and the patch requests submitted
for bugs #902573 and #902580 at bugzilla.mozilla.org, It seems that the
current hold up by Mozilla to accepting the patch request are:
1. Establishing how well Thunderbird & other mail clients handle the date
not being inserted by the sender in the mail header
2. Finding which MTA/MSA's automatically insert date headers on their own
and if most/all don't, finding a workaround to that. Gmai, Mail.com, Gmx,
Yandex and the now dead Lavabit had been tested successfully for automatic
date header insertion
3. And using extension hooks with explicit calls instead of checking user
set configurations flags for removing timestamp data from header. This it's
suggested will allow better handling of messages received/sent in the
background by Thunderbird.

If someone can let me know if this is the current status of the project or
if there are some details I'm missing or even if I've completely missed the
point it would be great.

Thanks and sorry for the longish mail

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

Re: [tor-dev] HTTP-requesting browser extension WIP (works in Firefox, not in Tor Browser)

[David Fifield]

On Tue, Mar 11, 2014 at 10:31:16PM -0700, David Fifield wrote:
> On Tue, Mar 11, 2014 at 05:22:37PM -0400, Mark Smith wrote:
> > On 3/10/14, 11:23 PM, David Fifield wrote:
> > >I started trying to write a Firefox extension that makes HTTP requests
> > >outside of the proxy settings. I have one that works in Iceweasel 24.3
> > >and does the Host header trick used by the transport. However it doesn't
> > >work in Tor Browser, and I'm looking for some insight as to why it might
> > >be so.
> > >
> > >The source code of the extension is in the "firefox" directory of
> > >   git clone -b extension https://www.bamsoftware.com/git/meek.git
> > >Instructions on how to try it are: 
> > >https://developer.mozilla.org/en-US/docs/Building_an_Extension#Test.
> > >I also pasted the important JavaScript code at the end of this message.
> > 
> > I looked at this for a few minutes but ran out of time for today.
> > 
> > When I dump aStatus in your onStopRequest function, I get 2152398890
> > which is 0x804B002A which is NS_ERROR_UNKNOWN_PROXY_HOST (see
> > https://developer.mozilla.org/en-US/docs/Table_Of_Errors).
> > 
> > I am not sure what that means but it sounds interesting.
> 
> Thanks for finding this clue. It appears to me that the critical
> difference is in the network.proxy.socks_remote_dns setting. My
> Iceweasel had it false and Tor Browser had it true. If it make it true
> in Iceweasel, the extension fails; if I make it false in Tor Browser,
> the extension succeeds. I'll see if there's a way to make it work with
> socks_remote_dns=true.

I made a mistake when I said this. The issue turns out not to be the
socks_remote_dns setting. The extension works in Iceweasel whether
socks_remote_dns is true or false, but works in Tor Browser only when it
is false. Mike traced the cause to this patch in Tor Browser, which
guard against DNS leaks by prohibiting name lookups when
socks_remote_dns=true, which is its default setting.

https://gitweb.torproject.org/tor-browser.git/commitdiff/5069a3ee8fa51546a8ad582e6004be66bc9748aa
If I undo that patch, the extension works in Tor Browser with no other
changes.

I wrote a summary of the situation here:
https://trac.torproject.org/projects/tor/ticket/11183#comment:6

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