Re: [tor-dev] Distributing Tor developer keys via Fedora packages

[Andrew Clausen]

Hi Matt,

On Mon, 20 Jul 2020 at 22:37, Matthew Finkel  wrote:

> > I propose distributing the Tor developer keys inside the Fedora package
> > distribution-gpg-keys.[1]  This would give most Linux users a trustworthy
> > chain of signatures from their own distributor (e.g. CentOS or Fedora) to
> > Tor project downloads.
>
> (most? :) )
>

I suspect so.  I haven't checked if Debian/Ubuntu have keyrings for
Fedora.  (Vice versa is certainly true.)


> > I am happy to take care of this, although I am also happy if somebody who
> > is more involved with Tor than me takes this on.  I wrote a shell script
> > (attached) to acquire and organise the keys based on
> > https://2019.www.torproject.org/include/keys.txt.  My script would
> install
> > the following keys under /usr/share/distribution-gpg-keys/tor:
>
> Unfortuntately that file is very old and incorrect now.
>

That is unfortunate.  Is there any sensible way that users can currently
verify signatures of their downloads?  (Can I mimic that?)


> > The most obvious question is: how do I know that I am distributing
> > unadulterated keys?  I think the answer is that I don't!  But any attack
> > would have to affect a large group of people, and would be detected
> quickly
> > as long as many people are looking at the distribution-gpg-keys package.
> > If this solution is unsatisfactory, then perhaps someone who is more
> > involved with the Tor developers -- and hence able to directly check the
> > keys -- ought to take this on.
>
> Yeah, if a package like this exists and it has tor's name attached to
> it, then we should have a high degree of confidence that the package
> contains the correct keys.
>

I'm not sure I understood what you mean.  Are you worried about an attack?
Or just miscommunication?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Distributing Tor developer keys via Fedora packages

[Andrew Clausen]

Hi everyone,

I propose distributing the Tor developer keys inside the Fedora package
distribution-gpg-keys.[1]  This would give most Linux users a trustworthy
chain of signatures from their own distributor (e.g. CentOS or Fedora) to
Tor project downloads.

I am happy to take care of this, although I am also happy if somebody who
is more involved with Tor than me takes this on.  I wrote a shell script
(attached) to acquire and organise the keys based on
https://2019.www.torproject.org/include/keys.txt.  My script would install
the following keys under /usr/share/distribution-gpg-keys/tor:

Arm_releases/Damian_Johnson.gpg
Tails_live_system_releases/The_Tails_team.gpg
TorBirdy_releases/Sukhbir_Singh.gpg
Tor_Browser_releases/Arthur_Edelstein.gpg
Tor_Browser_releases/Georg_Koppen.gpg
Tor_Browser_releases/Mike_Perry.gpg
Tor_Browser_releases/Nicolas_Vigier.gpg
Tor_Browser_releases/The_Tor_Browser_Developers.gpg
Tor_source_tarballs/Nick_Mathewson.gpg
Tor_source_tarballs/Roger_Dingledine.gpg
Torsocks_releases/David_Goulet.gpg
deb.torproject.org_repositories_and_archives/Tor_Project_Archive.gpg
older_Tor_tarballs/Nick_Mathewson.gpg
other/Peter_Palfrader.gpg

Unless someone else volunteers (please do!), I will set up a weekly job to
run the script and alert me to any changes.

Can anyone see any potential problems with this plan?

The most obvious question is: how do I know that I am distributing
unadulterated keys?  I think the answer is that I don't!  But any attack
would have to affect a large group of people, and would be detected quickly
as long as many people are looking at the distribution-gpg-keys package.
If this solution is unsatisfactory, then perhaps someone who is more
involved with the Tor developers -- and hence able to directly check the
keys -- ought to take this on.

[1] See https://github.com/xsuchy/distribution-gpg-keys and
https://rpmfind.net/linux/RPM/fedora/updates/32/x86_64/Packages/d/distribution-gpg-keys-1.39-1.fc32.noarch.html


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

Re: [tor-dev] Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint

[Andrew F]

I think I like this idea.. Well done.

On Wednesday, February 11, 2015, Rohit Dua <8ohit@gmail.com> wrote:

> Hello
>
> I'm Rohit from India, aspiring for gsoc-2015(TOR). This will be my 2nd
> consecutive year for gsoc participation. Previous mediawiki. Project:BUB
> tool 
>
> I stumbled across Panopticlick related project
> 
> in tor project ideas. I would like to propose a project relating to this.
> Panopticlick obtains browser fingerprints mainly via javascript
> objects(navigator, screen, window etc.)  These objects are easy to fake in
> webkit browsers, without touching the underlying source code of browsers,
> eg.  using *__defineGetter__() *after every* javascriptObjectCleared.*
> If we could compile a large dataset of possible values of js object for
> several popular browsers, we could use that to randomize the fingerprint
> for each network request.
> The dataset could also contain random http header values etc.
>
> I am building a python library that does somewhat similar.
> https://github.com/rohit-dua/selkie (*in development*) It uses pyqt for
> headless browsing/scraping of webpages. It is a python library that mimics
> different browser fingerprints by faking(randomizing) the values of
> navigator, screen object, headers etc. I also intend to add biometric
> library that mimics humans mouse movements/ keypress statistics for
> clicking links and surfing pages.
>
> I propose to build a similar headless bot that mimics several browsers
> fingerprints and could be used for anonymous scraping of data and/or adding
> a feature of random fingerprint in awesome tor tools. Also to improve
> anonymity location based datasets could be provided(*supported in the
> above library*) as extra/feature.(maybe downloaded from statcounter.com)
>
> Thanks
> Rohit Dua
> IRC:rohit-dua
> github: rohit-dua 
> (8ohit@gmail.com 
> )
>
>
>
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Scaling tor for a global population

[Andrew Lewman]

I had a conversation with a vendor yesterday. They are
interested in including Tor as their "private browsing mode" and
basically shipping a re-branded tor browser which lets people toggle the
connectivity to the Tor network on and off.

They very much like Tor Browser and would like to ship it to their
customer base. Their product is 10-20% of the global market, this is of
roughly 2.8 billion global Internet users.

As Tor Browser is open source, they are already working on it. However
,their concern is scaling up to handling some percent of global users
with "tor mode" enabled. They're willing to entertain offering their
resources to help us solve the scalability challenges of handling
hundreds of millions of users and relays on Tor.

As this question keeps popping up by the business world looking at
privacy as the next "must have" feature in their products, I'm trying to
compile a list of tasks to solve to help us scale. The old 2008
three-year roadmap looks at performance,
https://www.torproject.org/press/2008-12-19-roadmap-press-release.html.en

I've been through the specs,
https://gitweb.torproject.org/torspec.git/tree/HEAD:/proposals to see if
there are proposals for scaling the network or directory authorities. I
didn't see anything directly related.

The last research paper I see directly addressing scalability is Torsk
(http://www.freehaven.net/anonbib/bibtex.html#ccs09-torsk) or PIR-Tor
(http://www.freehaven.net/anonbib/bibtex.html#usenix11-pirtor)

Is there a better list available for someone new to Tor to read up on
the scalability challenges?

-- 
Andrew
pgp 0x6B4D6475
https://www.torproject.org/
+1-781-948-1982
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Geolocating exit nodes.

[Andrew Lewman]

On 06/18/2014 04:38 AM, JP Wulf wrote:
> This geolocation could perhaps be used to validate the integrity of the
> nodes (how I dont know, maybe by establishing TOR honeypots that can only
> be compromised through traffic through a compromised (owned) exit node).

The Tor client does not trust the tor network by design. The user can
influence the client to use countries they think are safe. See
https://www.torproject.org/docs/faq.html.en#ChooseEntryExit


-- 
Andrew
pgp 0x6B4D6475
https://www.torproject.org/
+1-781-948-1982
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal for improving social incentives for relay operators

[Andrew Lewman]

On 06/09/2014 08:26 PM, Virgil Griffith wrote:
> For a while I've been seeking to grow the Tor network in both size and
> goodput.  Towards this end, I've explored various avenues such as
> increasing user-awareness via tor2web.  More recently, I've been exploring
> financial incentives like TorCoin.

This is great that you care about growing the Tor network. Thanks for
the thoughts.

However, can we please, please stop using Tor in the name of everything?
Our trademark lawyers love the business, but we'd rather spend money on
developers and improving tor; not defending our name to keep everyone
from being confused as to what is the real Tor or not. People, press,
and companies are already calling us at Tor thinking we wrote torcoin
and have approved it. We did not write torcoin nor do we approve of it
(as far as I know).

> The most relevant of these papers (Lacetera 2013) cites the major
> motivations for volunteer labor are: "pure altruism, warm glow, self-image,
> and reputation".  Upon reading this I realized TorCoin's technical
> interestingness had blinded me to much easier to leverage motivations of
> "warm glow" and "reputation".

Perhaps join the EFF's Tor Challenge? https://www.eff.org/torchallenge/
They would love the help.

-- 
Andrew
pgp 0x6B4D6475
https://www.torproject.org/
+1-781-948-1982
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Cloud - Issues/Maintainer/Next Steps

[Andrew Lewman]

On Sun, Apr 20, 2014 at 06:54:54AM -0700, s...@redteam.net wrote 0.6K bytes in 
0 lines about:
: I have created a ticket for Tor Cloud, I think I need access to the

Which ticket number?

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

Re: [tor-dev] Help hacking Mumble

[Andrew F]

Any movement on this?  anything new?



On Sun, Feb 9, 2014 at 9:52 PM, Matt  wrote:

> On Fri, 07 Feb 2014 09:54:35 +0400
> meejah  wrote:
>
> > What I would suggest:
> >
> > 1. change ConnectDialog so that it always uses not-yet-looked-up
> >QHostAddresses (perhaps only if a proxy is enabled). This still
> > won't help Tor, since they're sending UDP.
> >
> > 2. change Cert.cpp so it doesn't have to do a host-lookup. I sort-of
> >asked in my other email, but does this actually gain anything?
> > That is, does checking that the domain looks up "to something" really
> > accomplish anything useful? If the answer is "yes", then more
> > thinking; all I can think of is attempting a TCP/UDP connection
> > (again, with a not-yet-looked-up QHostAddress) to the server in
> > question (which will only work if there is a well-known port upon
> > which it should be listening to be considered valid).
> >
>
> I haven't actually confirmed that there is a DNS leak here. I've been
> focusing mostly on ConnectDialog, but mentioned Cert because it also
> had DNS-related code that I hadn't spent as much time with.
>
> > 3. suggest/document that Tor uses need to un-set the "show reachable"
> >(Settings::ShowReachable) option so that a server doesn't need a
> >valid ping-reply to show up in the list.
> >
> > Another option might be to factor out all the "ping" stuff to its own
> > class and simply not instatiate/use it when ShowReachable is off (or
> > have a separate option for pinging all the servers).
> >
> > Yet another different option might be to just have an option to turn
> > off the pinging of servers, leaving open the Cert.cpp question (which
> > one could also punt on by having an option). Then the game would be
> > to get Tor users to have the right options enabled ;)
> >
>
> I tried to do something like this in my branch; optionally turning off
> pings to Public and LAN servers was easy. Turning off pings to Favorite
> servers seemed a little trickier, especially if they are still to
> remain reachable.
>
> Thanks for all the pointers. A C++ developer volunteered to take a
> closer look at this issue. At this point, I think further discussion
> would most useful for all parties if it moved onto the bug ticket:
> https://github.com/mumble-voip/mumble/issues/1033
> ___
> 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

Re: [tor-dev] Help hacking Mumble

[Andrew F]

Matt,
What are you thinking about this?



On Thu, Feb 6, 2014 at 6:06 PM, Matt  wrote:

> On Thu, 30 Jan 2014 22:01:18 +
> Matt  wrote:
>
> Here is one of the Mumble developers' take on the issue:
>
>
> > I don't know where @zanethomas's post went, but I just want to clarify
> > what needs to be done here, and what's wrong.
> >
> > By default, Qt's proxy support can route hostname resolution through
> > the proxy if a hostname is used when creating the socket.
> >
> > However, in Mumble, we use QHostAddress to resolve addresses ahead of
> > time in a lot of places (for example, the server list), which causes
> > the DNS requests to not go through the proxy.
> >
> > We need some kind of abstraction on top of QHostAddress that allows us
> > to route the hostname lookups via the user's selected proxy. That, or
> > we need to upstream a Qt patch that allows QHostAddress to resolve
> > through the application's QNetworkProxy.
> >
> > ...Something along those lines.
>
> Source: https://github.com/mumble-voip/mumble/issues/1033
> ___
> 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

Re: [tor-dev] Help hacking Mumble

[Andrew F]

Matt, have you gotten any response?


On Thu, Jan 30, 2014 at 10:01 PM, Matt  wrote:

> If you're into C++ or Qt, we could use some help. Mumble[0] is a free
> software VoIP application that various people have had success
> using with Tor. One problem using Mumble with Tor is that Mumble
> doesn't abide by the native proxy settings when looking up Mumble
> servers[1]. When using a Tor router device or Torsocks, the DNS
> requests are just dropped. When using the native proxy settings, the
> DNS requests still get sent out to the local ISP, not through the
> proxy.
>
> The desired outcome is that if a SOCKS5 proxy is set, DNS requests get
> sent through the SOCKS5 proxy. The proxy is set as g.s.ptProxyType, and
> gets set when main.cpp calls NetworkConfig::SetupProxy(), which in turn
> uses QNetworkProxy::setApplicationProxy.
>
> The window that makes these DNS requests is ConnectDialog.cpp, but
> you'll want to look at Cert.cpp as well.
>
> I submitted a pull request[2] that allows users to completely turn off
> automatic UDP and DNS traffic sent out to the big list of public Mumble
> Servers. This does not stop the automatic DNS traffic that gets sent to
> servers on the Favorite servers list though, which is where any
> private servers you might want to connect to would be.
>
> Getting this fixed would be great for Tor because it would make VoIP
> over Tor easier and safer for people on all platforms. Please help!
>
>
> [0]: http://mumble.info
> [1]: https://github.com/mumble-voip/mumble/issues/1033
> [2]: https://github.com/mumble-voip/mumble/pull/1128
> ___
> 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

Re: [tor-dev] Tor Ecosystem Presentation

[andrew]

On Tue, Nov 26, 2013 at 09:42:42AM -0800, ata...@torproject.org wrote 0.8K 
bytes in 0 lines about:
: Hi all. A little over a week ago I gave a presentation at Seattle's
: TA3M at Ada's Books to give an overview of the projects within the Tor
: ecosystem. This is a revised version of a similar presentation Roger
: and Jake gave at 29c3...

Thanks Damian. I copied the video to the media server,
https://media.torproject.org/video/2013-11-t3am-damian-johnson.mp4.

And put your presentation in the svn presentation repo:
https://svn.torproject.org/svn/projects/presentations/2013-11-t3am-tor-ecosystem.odp
and .pdf.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] What happened to Tor Router?

[andrew]

On Mon, Nov 25, 2013 at 12:18:02PM +, and...@torproject.is wrote 1.6K bytes 
in 0 lines about:
: Much like the App Store[4] discussion, I think we're best suited to
: make Tor as portable and performant as possible, but leave hardware
: integration to others. We're the experts on Tor. We should stay focused
: on Tor and not get distracted with things that can run Tor. I'd rather
: see 3rd parties consulting with us to build "tor routers". We don't have
: the expertise nor resources to handle the hardware product lifecycle.

And another appears on the horizon,
http://www.indiegogo.com/projects/orp1-an-open-router-project

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] What happened to Tor Router?

[andrew]

On Sat, Nov 23, 2013 at 06:32:27AM -0800, s...@redteam.io wrote 1.3K bytes in 0 
lines about:
: I am trying to update myself on the status of Tor Router. I remember not
: too long ago it was a sexy project, funds were raised and people got paid
: to work on it. Has it been abandoned? How come we still don't have a Tor
: hardware router?

It's still a sexy project to some. Funds were never raised to do work on
it, at least not by Tor Project or anyone directly related to us. It's
been available to the community to take and build something. We've seen
the Access Labs work[0], OnionPi[1], and now Safeplug[2].

We did experiment with the Excito B3 platform[3] as well.

Much like the App Store[4] discussion, I think we're best suited to
make Tor as portable and performant as possible, but leave hardware
integration to others. We're the experts on Tor. We should stay focused
on Tor and not get distracted with things that can run Tor. I'd rather
see 3rd parties consulting with us to build "tor routers". We don't have
the expertise nor resources to handle the hardware product lifecycle.

This is a fine topic for discussion.

[0] https://trac.torproject.org/projects/tor/wiki/doc/OpenWRT
[1] http://learn.adafruit.com/onion-pi/overview
[2] https://pogoplug.com/safeplug
[3] http://www.excito.com
[4] https://lists.torproject.org/pipermail/tor-dev/2013-November/005773.html

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Apple App Store Redux

[andrew]

On Sun, Nov 10, 2013 at 08:30:23PM -0500, grif...@cryptolab.net wrote 1.7K 
bytes in 0 lines about:
:   - Submit Apple agreements to Wendy for review and
: rejection/acceptance. The last mention of this was a year ago on #6540.

We have corporate lawyers for The Tor Project. I haven't spent the
money to have them review the Apple agreements, because they will have to
review not just the Developer Agreement, but Terms and Conditions, Privacy
Policy, and other linked agreements to/from the Dev Agreement.  Wendy has
a very busy full-time job and doesn't have time to be Tor's
lawyer. Mostly, I haven't engaged our lawyers because of the answer to
the second point below.

:   - A volunteer who doesn't work for Tor maintaining the app store
: version of TBB. This would also free Tor as an organization from having
: to sign agreements. (Though this may contravene Apple's terms).

I agree with this method. I don't think The Tor Project should be the
one maintaining Tor-something in the App Store. I'd rather a trusted 3rd
party who signs a trademark licensing agreement with us be the person
who maintains an App Store presence. This is how we do it in the Android
world with Google Play and Amazon App Stores, and others. In the Android
world, we encourage people to get Tor on their device through f-droid
[0], rather than Google Play. I don't see why it should be different
for Apple, Microsoft, or whatever new mobile OS is the fad of the year.

In general, our code should be highly portable to any OS, and others
can go through the specifics of getting our highly portable code into
various app stores, because they understand the nuances and details of
their preferred OS.

[0] https://f-droid.org/

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] recreated website png diagrams as svg

[andrew]

On Sat, Nov 09, 2013 at 03:16:41AM -0700, jfind...@gmail.com wrote 263K bytes 
in 0 lines about:
: which look as if they're copied from some EFF presentation.  I've
: recreated them as svg.  Svg being a fairly standard vector markup, I
: supposed that it would be more amenable to automatic string
: replacement than a png (I'm not sure what wml is).  Please look them
: over and give me feedback.  If they are ultimately found acceptable,
: you are welcome to use them for the site.  Thanks.

Thanks! These look great. 

They weren't copied from an EFF presentation, they were
made by the EFF for us. You can find the originals inside
https://media.torproject.org/image/official-images/tor_design_archive.zip

I've added them to the site image directory for now.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] next globe update feedback

[andrew]

On Sun, Nov 03, 2013 at 11:23:18AM -0800, ata...@torproject.org wrote 0.5K 
bytes in 0 lines about:
: Damn this is awesome! I'm tempted to link to this from our front page
: (replacing Tor Browser in the project matrix on www.torproject.org,
: since TBB is already the featured item on the download page).
: 
: Mike, Roger, etc: Any objections?

TBB should stay where it is. Maybe feature this globe app from the
metrics page.

: Christian: Pity it doesn't have a valid cert. It would be nice if it
: defaulted to SSL.

Can we run the code somewhere rather than on a 3rd party server?

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Reminder: Attentive Otter IM Bundle Meeting in 1h

[Andrew F]

How about a specific time? with the time zone indicated.
thanks.



On Wed, Oct 9, 2013 at 10:11 AM, Jurre van Bergen
wrote:

> On 10/09/2013 06:04 PM, Tom Lowenthal wrote:
> > Hello hello,
> >
> > This is your roughly 60-minute reminder that we'll be comparing
> > proposals for the IM browser bundle on #tor-dev in about an hour. For
> > your reference, and to brush up on the research that everyone
> > valiantly did, the analyses are:
> >
> > *[Purple](
> https://lists.torproject.org/pipermail/tor-dev/2013-October/005544.html)
> > *[xmpp-client](
> https://lists.torproject.org/pipermail/tor-dev/2013-October/005546.html)
> > *[Instantbird](
> https://lists.torproject.org/pipermail/tor-dev/2013-October/00.html)
> >
> > That's all for now.
> > -Tom
> It's rescheduled and happening in one hour.
>
> Jurre
>
> --
> Developer at https://www.useotrproject.org/
>
> ___
> 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

Re: [tor-dev] OnionMail First Test

[Andrew F]

Josef,
Spot on.



On Wed, Sep 18, 2013 at 1:23 AM,  wrote:

> Why you guys use JAVA for such a security concerned email client?
>
> JAVA itself isn't secure and most relayable computers don't have
> a virtual machine. You know JavaSnoop and vm-hookers like that?
>
> Just rewrite it into plain C imho...
>
> /jo
>
> > Gesendet: Mittwoch, 18. September 2013 um 02:26 Uhr
> > Von: Liste 
> > An: tor-dev@lists.torproject.org
> > Betreff: Re: [tor-dev] OnionMail First Test
> >
> > Leo Unglaub ha scritto:
> > > Hey,
> > >
> > > On 2013-09-17 03:51, Liste wrote:
> > >
> > >> Work complete for the version 0.0.0Beta
> > >>
> > >> http://anopticon.ws/13c03c09/OnionMail-0.0.0.B.zip
> > >>
> > >
> > > please can you upload the source code as well, because no one is going
> > > to execute a .jar file without knowing the program code.
> > >
> > > Thanks and greetings
> > > Leo
> > >
> > >
> > I'm testing the program, removing unused code etc, I'm programming
> > the web site of the project... with source code and help...
> >
> > ___
> > 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 mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Retiring old user number estimates

[Andrew Lewman]

On Mon, 16 Sep 2013 20:28:21 +0200
Karsten Loesing  wrote:

> Why do I tell you this?
> 
> Because the old approach uses resources on our poor, already
> overloaded metrics machine, and I'm planning to shut down the old
> approach in the very near future.  Here's the plan:
> 
>  - Compute user numbers for 2012 and before; the current numbers start
> on January 1, 2013.  This is going to take at least until September
> 23.

What's stopping us from computing user numbers back to the beginning
of recorded data?

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Trac upgraded to 0.12.3

[Andrew Lewman]

On Mon, 26 Aug 2013 22:45:20 +0200
Erinn Clark  wrote:

> Hello everyone!
> 
> Weasel and I have upgraded https://trac.torproject.org to a newer
> version. 

Thank you Erinn and weasel!

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] how much havoc can a compromised baseband do to a Guardian ROM device?

[Andrew Lewman]

On Mon, 29 Jul 2013 15:00:05 +0200
Eugen Leitl  wrote:

> Anyone knows whether a Nexus 4 baseband processor has r/w
> access to system memory? 

How does this relate to tor development?

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle

[Andrew Lewman]

On Wed, 17 Jul 2013 22:10:26 +0400
User of Tor  wrote:

> I've installed Tor Browser Bundle for Windows
> (tor-browser-2.3.25-2_ru) I didn't change any settings. When I visit
> any html-page on which there is a flash video i can see it, flash
> works! Why? It must not work!
> 
> In settings(plugins) "Flash plugin" is disabled and it is inactive.
> In Tor Button settings Plugins are turned off. What happens? Is it a
> BUG?

This is a better message for h...@rt.torproject.org opening a bug,
https://bugs.torproject.org.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] License of TorDNSEL (was: Haskell packages?)

[Andrew Lewman]

On Sat, 08 Jun 2013 19:58:06 +0400
Nikita Karetnikov  wrote:

> I've found out that TorDNSEL is in the public domain (see [1]). 

The official Tordnsel will remain in the public domain. You're welcome
for fork it of course. However, if you want to commit back to us, please
don't change the licensing.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Chrome browser and sand boxing.

[Andrew F]

Thanks.



On Thu, May 23, 2013 at 5:00 PM, Andrew Lewman  wrote:

> On Thu, 23 May 2013 15:35:28 +
> Andrew F  wrote:
>
> > I have Googled and searched the Tor website, but I have not found any
> > information on chrome's sandbox feature and Tor.  Specifically with
> > flash. Is there any information out their on this?
>
> https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs
> that's all we've looked at so far.
>
> --
> Andrew
> http://tpo.is/contact
> pgp 0x6B4D6475
> ___
> 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

Re: [tor-dev] Chrome browser and sand boxing.

[Andrew Lewman]

On Thu, 23 May 2013 15:35:28 +
Andrew F  wrote:

> I have Googled and searched the Tor website, but I have not found any
> information on chrome's sandbox feature and Tor.  Specifically with
> flash. Is there any information out their on this?

https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs
that's all we've looked at so far.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Chrome browser and sand boxing.

[Andrew F]

I have Googled and searched the Tor website, but I have not found any
information on chrome's sandbox feature and Tor.  Specifically with flash.
Is there any information out their on this?

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

Re: [tor-dev] Discussion on the crypto migration plan of the identity keys of Hidden Services

[Andrew F]

George,
I would definitely create an extended transition time frame.   6 months or
a year where both keys will work.   just make it clear there  is a cut off
date.

And I think Adrelanos's concept is a valid one.   Since we may need to do
this again, why not put a structure in place that facilitates upgrades to
the system itself.







On Fri, May 17, 2013 at 3:09 PM, adrelanos  wrote:

> George Kadianakis:
> > Thoughts?
>
> Can you make .onion domains really long and therefor really safe against
> brute force?
>
> Or have an option for maximum key length and a weaker default if common
> CPU's are still too slow? I mean, if you want to make 2048 bit keys the
> default because you feel most hidden services have CPU's which are too
> slow for 4096 bit keys, then use 2048 bit as default with an option to
> use the max. of 4096 bit.
>
> Bonus point: Can you make the new implementation support less painful
> updates (anyone or everyone) when the next update will be required?
> (forward compatibility)
> ___
> 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

Re: [tor-dev] Tor Launcher settings UI feedback request

[Andrew Lewman]

On Fri, 3 May 2013 16:05:15 -0400
"Runa A. Sandvik"  wrote:

> I disagree. The Tor help desk sees a ton of requests from users saying
> that Tor is unable to connect, and the simple fix is to give them a
> bridge or two. Not all users know what they need to connect, and not
> all users will know the difference between bridge, obfs2, and obfs3.

One answer is the user shouldn't care. Tor Browser should automatically
loop through the various kinds of connectivity and just connect.
non-obfs bridges really should get wholly replaced with obfs bridges en
masse. 

Another thought is with flashproxy in the pluggable transports bundle,
what percent of flashproxies work by default with no user config needed?

I wonder if we could extrapolate that percentage to a larger "what if
we did relay by default?" for all bundles...

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Launcher settings UI feedback request

[Andrew F]

On the contrary, I think you should list them all under an menu item called
advanced connections.
Users who need these connections will have them and those that don't,
probably won't know what they are and thats ok.


On Fri, May 3, 2013 at 5:41 PM, Runa A. Sandvik wrote:

> On Fri, May 3, 2013 at 11:53 AM, Lunar  wrote:
> > Mark Smith:
> >>
> http://trial.pearlcrescent.com/tor/torlauncher/2013-05-03/SetupWizard/wizard-all.png
> >> (composite of all of the wizard panels).
> >
> > "If you are not sure how to answer this question, look at the Internet
> > settings in another browser to see whethever you are using a proxy":
> > I have a feeling this might not be the best advice. Asking users to open
> > another browser enhance the likelyhood of them making mistakes.
> > I remember Firefox being able to dig connection settings in other
> > browsers. Can't such piece of code reused to get a suggestion?
>
> It would be great if we could add some code to check whether or not
> the user is using a proxy. If this is not possible, we will have to
> think about some text for this screen that does not confuse anyone or
> lead to mistakes.
>
> > "Enter a comma-separated list of ports that are allowed by your
> > firewall": I find the "your firewall" pretty ironic for most cases
> > I know. One's university firewall will not be exactly theirs.
>
> I guess "the" might be a better fit.
>
> > Should pluggable transports be mentioned in any ways?
>
> I don't think we should confuse users too much by listing all the
> different options they have for connecting (no bridge, bridge, obfs2,
> obfs3).
>
> > Should the short user manual be added to this picture somewhere?
>
> We could link to it, just like we're linking to bridges.tpo and
> bridges@tpo. Other options might be to include it in the bundle or
> re-use the text as part of a help screen.
>
> --
> Runa A. Sandvik
> ___
> 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

Re: [tor-dev] Moving our website to git and splitting it in two

[Andrew Lewman]

On Fri, 5 Apr 2013 15:53:57 +0200
Peter Palfrader  wrote:

> Tom asked what was needed to get our website moved to git.
> Probably not much.  And while we're at it we could split the
> repository into two parts:
>  - things that are copied over verbatim, and
>  - things that build stuff that make our website.

Is now a fine time to talk about further splitting dist and media from
the content?

where dist is for moving to dist.torproject.org for all downloadable
software bundles, code, etc. (as in our packages). dist becomes a
mirrored dir on the webservers.

where media is for all videos, images, pdf, etc that are currently on
the site?  media.torproject.org becomes a mirrored dir on the
webservers.

This would make www.tpo content only, media.tpo images/video/pdfs only,
dist.tpo for "products"

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Obfs Links on dist are Suddenly Gone

[Andrew Lewman]

On Thu, 14 Mar 2013 20:39:51 -0400
Roger Dingledine  wr
> (We currently believe that phobos deleted them because they include
> older versions of Tor (aallai and dcf are working on updated versions,
> but those aren't ready quite yet), and because our dist/torbrowser/
> directory is huge and its size is knocking over Tor website mirrors.)

Yeah, we filled up the disk, and I purged anything with a non-current
Tor version.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Improving the HTTP interface of BridgeDB: bridges.torproject.org

[Andrew Lewman]

On Tue, 12 Mar 2013 16:14:41 +0100
Moritz Bartl  wrote:

> > 2. The correct email address is brid...@bridges.torproject.org
> 
> Huh? Why is that? I think it's a bad idea. Why would you need
> "bridges" in there two times? You can set up bridges@tpo to forward
> to the bridges host, done.
> 
> Same by the way for help/support. They should be help@tpo and
> support@tpo, and forward mails to the rt host. There is no reason to
> expose and require the mention of the used backend software.

We don't want to hide the systems and we want each system to manage
it's own mail queues. The main torproject mail server is not designed to
handle all mail for all tor services. Each system is independent of one
another and allows for better scaling and reachability than having one
massive mail hub.

rt, bridges and gettor are flooded with mail, no need to flood other
systems and back them up with unrelated email. We can scale each
individual system as needed based on usage.

People are just clicking links anyway, they might as well click the
most direct one that goes directly to the system. 


-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Improving the HTTP interface of BridgeDB: bridges.torproject.org

[Andrew Lewman]

On Mon, 11 Mar 2013 11:08:36 +0530
Sathyanarayanan Gunasekaran  wrote:


In general, these look great.
Some nitpicking items:

> Here are the .htmls -
> https://people.torproject.org/~gsathya/html/index.html

1. The majority of users aren't going to know which obfsproxy browser
they're using. I understand the difference, but to make a decision,
we should only ship one obfsTBB and assume everyone is using it as a
target for this site. I'm guessing we just call the
obfsproxy-flashproxy-tbb as obfsTBB and move forward with it.

2. The correct email address is brid...@bridges.torproject.org

3. I think we should scrap "normal bridges" and only promoted obfuscated
bridges. In the bigger picture, "normal bridges" are already subject to
DPI attack and blocked in many places in the world based on Tor's
network signature alone. All bridges should be obfsproxy bridges.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Fwd: [Wikitech-l] Can we help Tor users make legitimate edits?

[Andrew Lewman]

On Fri, 28 Dec 2012 15:26:25 -0800
Zack Weinberg  wrote:

> 3) Look at Nymble -
> http://freehaven.net/anonbib/#oakland11-formalizing and
> http://cgi.soic.indiana.edu/~kapadia/nymble/overview.php .  It would
> allow Wikimedia to distance itself from knowing people's identities,
> but still allow admins to revoke permissions if people acted up.  The
> user shows a real identity, gets a token, and exchanges that token
> over tor for an account.  If the user abuses the site, Wikimedia site
> admins can blacklist the user without ever being able to learn who
> they were or what other edits they did.  More:
> https://cs.uwaterloo.ca/~iang/ Ian Golberg's, Nick Hopper's, and Apu
> Kapadia's groups are all working on Nymble or its derivatives.  It's
> not ready for production yet, I bet, but if someone wanted a Big
> Project

I think nymble is superceded by blacr,
http://freehaven.net/anonbib/cache/blacr-ndss.pdf. It's model usecase
is Tor-using editors wishing to work with Wikipedia.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Xeronet's torrc

[Andrew Lewman]

On Thu, 27 Dec 2012 09:22:00 +0545
Nathan Freitas  wrote:

> How does it work ? Well, Tor works just great 'out-of-the-box',
> however, by tweaking settings and controlling how Tor connects to its
> own network we can improve on privacy and security.

...based on what evidence?

> (1) Block 'Bad' Exit Nodes using: ExcludeNodes

If the 'Bad' flag is assigned, then you already cannot exit from the
relay. No need to block it.

> Recommended: 'problem' internet countries Block List: Afghanistan,
> Algeria, Armenia, Argentina, Azerbaijan, Bangladesh, Belarus, Burma,
> China, Colombia, Cuba, Egypt, Eritrea, Ethiopia, Gambia, Georgia,
> Ghana, Guatemala, India, Indonesia, Iraq, Iran, Israel, Jordan,
> Kazakhstan, Kuwait, Kyrgyzstan, Laos, Lebanon, Libya, Macau, Malawi,
> Mali, Malaysia, Mauritania, Mexico, Moldova, Mongolia, Morocco,
> Nepal, Nigeria, North Korea, Oman, Pakistan, Palestinian Territories,
> Paraguay, Peru, Philippines, Qatar, Russia, Rwanda, Saudi Arabia,
> Somalia, South Africa, South Korea, Sudan, Sri Lanka, Syria, Taiwan,
> Tajikistan, Thailand, Tunisia, Turkey, Turkmenistan, UAE, Uganda,
> Uzbekistan, Venezuela, Vietnam, Yemen, Zimbabwe.

Why not just say 'block countries not full of white people'? Seriously,
wtf is up with that list.

This whole list is like alchemy and trying to turn water to wine. Using
the default torrc is probably far safer for 99.9% of users. I don't see
how this custom torrc is going to improve anything, other than an
attacker learning how unique you are in the tor network.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] More TBB usability challenges

[Andrew Lewman]

I was asked to meet with some people doing work in dangerous areas of
Latin America. In general, these people can get around and work with
Microsoft Windows competently. They are all fluent in English, Spanish,
and various dialects found in Latin American countries.  Most of them
had Spanish-language versions of Windows 7 on their laptops.

# Getting TBB

During the discussion, an informal usability study happened. I thought
having a discussion about this may be better than simply opening a trac
ticket.

Here's roughly the scenario. I asked people to download Tor Browser from
our website. All found Tor's website via Bing. Interestingly, some
searched for "tor", others for "tor browser", and one for "tor project".
They were all using Internet Explorer and Bing because that's the
default for Windows 7. Thankfully, our website is the top result for all
three queries at Bing.

They all found the big purple "Download Tor" button on the index page.

Issue #1: Running TBB from the website. When clicking the orange
"Download Tor Browser Bundle" button, IE prompts them to "Run", "Save",
or "Cancel". All of them chose "Run".

Issue #1A: When choosing "Run", a prompt appears, "The publisher of
tor-browser-2.2.39-5_en-US.exe couldn't be verified. Are you sure you
want to run the program?". All of them hit "Yes" and ignored the
warning.

Issue #1B: When the download completed, they were prompted with the
7zip self-extractor giving them a path similar to this:
"C:\Users\tor\AppData\Local\Microsoft\Windows\Temporary Internet
Files\Content.IE5\T868H68M\".  All of them pushed the "Extract" button
and let 7zip extract TBB into that temporary directory.

A few of them went to the Downloads folder to try to find TBB.
However, it's not there because it's extracted into a temporary folder.
This folder is not reachable by the user through File Explorer.

Issue #2: Downloading TBB. After some Q&A about what happened, I asked
them to "Save" rather than "Run". TBB then downloads. The user is
prompted with a warning box stating, "The publisher of
tor-browser-2.2.39-5_en-US.exe couldn't be verified." And the user is
left to choose between "Run" and "View downloads". When clicking "Run"
the user is prompted with the 7-zip self-extractor prompt and
"C:\Users\tor\Downloads\" is the default path. All of them hit the
"Extract" button. None of them were sure what just happened nor why TBB
needs to be extracted.

Issue #2A: The self-extract completes and the user is left looking at
their IE window with the TBB download page. Three of them went to their
Downloads folder to find Tor. The other few waited for something to
happen. When I asked the waiting few why they were waiting, they said
because they "ran TBB" and expected the extraction to automatically
start TBB for them.

Issue #3: In the Downloads folder there are two things called "tor
browser", one is an application the other is a file folder. See
https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11-28-tbb-downloads-default-icons.png
for an example. Most of the people had hundreds of files in the
Download folder, so it wasn't as clear as this example screenshot.

Some people wanted to run the application, because in their mind, you
run an application.

When asked to go into the Tor Browser folder, they all found "Start Tor
Browser" and ran it (some double-left click, some right click and
choose "Open"). See
https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11-28-tbb-downloads-default-icons-2.png
for what it looks like by default.

Issue #4: Once TBB was started, the users would alt-tab between
applications or choose various apps in their task bar at the bottom of
the screen. They kept clicking the onion icon because they thought it
was TBB, when it brings up the Vidalia control panel. This is what it
looks like,
https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11-28-tbb-downloads-default-icons-3.png

Issue #5: No one knew what "Startpage" was nor why it was in the top
bar. Just like IE, they all wanted to search from the awesome bar by
default. This does work, and they can search via startpage.com via the
awesome bar.

>From here on out, the normal TBB issues apply, as demonstrated by
Greg's HotPETS paper,
https://people.torproject.org/~andrew/hotpets12-1-usability.pdf

# Feedback

I asked how we can improve this entire process. The consensus is that
TBB needs to be a single application people can just run and get the
browser going. The extraction process was confusing and was sometimes
called an installation process. They felt that "running" it from the
tor download site was fine, so lon

[tor-dev] [PATCH 1/2] New option LocalOutboundBindAddress

[Andrew Cady]

This works just like OutboundBindAddress, but instead of excluding
connections to loopback addresses, it affects only connections to
loopback addresses.

The whitespace in this commit is a bit nutty, in order to put whitespace
changes into a separate commit.
---
 doc/tor.1.txt   |   11 +++
 src/or/config.c |   25 -
 src/or/connection.c |   17 ++---
 src/or/or.h |6 ++
 4 files changed, 43 insertions(+), 16 deletions(-)

diff --git a/doc/tor.1.txt b/doc/tor.1.txt
index 1e1ff1e..f25234d 100644
--- a/doc/tor.1.txt
+++ b/doc/tor.1.txt
@@ -477,6 +477,17 @@ GENERAL OPTIONS
 This setting will be ignored for connections to the loopback addresses
 (127.0.0.0/8 and ::1).
 
+**LocalOutboundBindAddress** __IP__::
+Like OutboundBindAddress, but _only_ for connections to loopback
+addresses (e.g., inbound connections to local hidden services).
+This is useful to distinguish Tor traffic from local traffic in
+the log files of your hidden services. +
+ +
+The IP should be in the 127.0.0.0/8 range for maximum compatibility.
+I recommend using 127.84.111.114, since 84.111.114 is the ASCII
+encoding of "Tor".  I also recommend adding \'127.84.111.114 tor' to
+your /etc/hosts file.
+
 **PidFile** __FILE__::
 On startup, write our PID to FILE. On clean shutdown, remove
 FILE.
diff --git a/src/or/config.c b/src/or/config.c
index 206ccc8..03e07f9 100644
--- a/src/or/config.c
+++ b/src/or/config.c
@@ -285,6 +285,7 @@ static config_var_t option_vars_[] = {
   OBSOLETE("IgnoreVersion"),
   V(KeepalivePeriod, INTERVAL, "5 minutes"),
   VAR("Log", LINELIST, Logs, NULL),
+  V(LocalOutboundBindAddress,LINELIST,   NULL),
   V(LogMessageDomains,   BOOL, "0"),
   OBSOLETE("LinkPadding"),
   OBSOLETE("LogLevel"),
@@ -5556,15 +5557,20 @@ getinfo_helper_config(control_connection_t *conn,
 static int
 parse_outbound_addresses(or_options_t *options, int validate_only, char **msg)
 {
-  const config_line_t *lines = options->OutboundBindAddress;
-  int found_v4 = 0, found_v6 = 0;
+ int i;
+ for (i=0; i<2; ++i) {
+
+  tor_addr_t *out4 = i ? &options->OutboundBindAddressIPv4_ : 
&options->LocalOutboundBindAddressIPv4_;
+  tor_addr_t *out6 = i ? &options->OutboundBindAddressIPv6_ : 
&options->LocalOutboundBindAddressIPv6_;
 
   if (!validate_only) {
-memset(&options->OutboundBindAddressIPv4_, 0,
-   sizeof(options->OutboundBindAddressIPv4_));
-memset(&options->OutboundBindAddressIPv6_, 0,
-   sizeof(options->OutboundBindAddressIPv6_));
+memset(out4, 0, sizeof(*out4));
+memset(out6, 0, sizeof(*out6));
   }
+
+  const config_line_t *lines = i ? options->OutboundBindAddress : 
options->LocalOutboundBindAddress;
+  int found_v4 = 0, found_v6 = 0;
+
   while (lines) {
 tor_addr_t addr, *dst_addr = NULL;
 int af = tor_addr_parse(&addr, lines->value);
@@ -5577,7 +5583,7 @@ parse_outbound_addresses(or_options_t *options, int 
validate_only, char **msg)
 return -1;
   }
   found_v4 = 1;
-  dst_addr = &options->OutboundBindAddressIPv4_;
+  dst_addr = out4;
   break;
 case AF_INET6:
   if (found_v6) {
@@ -5587,7 +5593,7 @@ parse_outbound_addresses(or_options_t *options, int 
validate_only, char **msg)
 return -1;
   }
   found_v6 = 1;
-  dst_addr = &options->OutboundBindAddressIPv6_;
+  dst_addr = out6;
   break;
 default:
   if (msg)
@@ -5599,7 +5605,8 @@ parse_outbound_addresses(or_options_t *options, int 
validate_only, char **msg)
   tor_addr_copy(dst_addr, &addr);
 lines = lines->next;
   }
-  return 0;
+ }
+ return 0;
 }
 
 /** Load one of the geoip files, family determining which
diff --git a/src/or/connection.c b/src/or/connection.c
index dbcfc41..397a2dc 100644
--- a/src/or/connection.c
+++ b/src/or/connection.c
@@ -1451,14 +1451,17 @@ connection_connect(connection_t *conn, const char 
*address,
 
   make_socket_reuseable(s);
 
-  if (!tor_addr_is_loopback(addr)) {
+  {
+const int is_local = tor_addr_is_loopback(addr);
 const tor_addr_t *ext_addr = NULL;
-if (protocol_family == AF_INET &&
-!tor_addr_is_null(&options->OutboundBindAddressIPv4_))
-  ext_addr = &options->OutboundBindAddressIPv4_;
-else if (protocol_family == AF_INET6 &&
- !tor_addr_is_null(&options->OutboundBindAddressIPv6_))
-  ext_addr = &options->OutboundBindAddressIPv6_;
+const tor_addr_t *maybe_ext_addr4 = is_local ? 
&options->LocalOutboundBindAddressIPv4_ : &options->OutboundBindAddressIPv4_;
+const tor_addr_t *maybe_ext_addr6 = is_local ? 
&options->LocalOutboundBindAddressIPv6_ : &options->OutboundBindAddressIPv6_;
+
+if (protocol_family == AF_INET && !tor_addr_is_null(maybe_ext_addr4))
+  ext_addr = maybe_ext_addr4;
+else if (protocol_family == AF_INET6 && !tor_addr_is_null(maybe_ext_addr6))
+  ext_addr = maybe_ext_addr6;

[tor-dev] [PATCH 2/2] New option LocalOutboundBindAddress: whitespace changes only

[Andrew Cady]

---
 src/or/config.c |   88 +--
 src/or/connection.c |   60 +--
 2 files changed, 73 insertions(+), 75 deletions(-)

diff --git a/src/or/config.c b/src/or/config.c
index 03e07f9..12f4f79 100644
--- a/src/or/config.c
+++ b/src/or/config.c
@@ -5557,55 +5557,55 @@ getinfo_helper_config(control_connection_t *conn,
 static int
 parse_outbound_addresses(or_options_t *options, int validate_only, char **msg)
 {
- int i;
- for (i=0; i<2; ++i) {
+  int i;
+  for (i=0; i<2; ++i) {
 
-  tor_addr_t *out4 = i ? &options->OutboundBindAddressIPv4_ : 
&options->LocalOutboundBindAddressIPv4_;
-  tor_addr_t *out6 = i ? &options->OutboundBindAddressIPv6_ : 
&options->LocalOutboundBindAddressIPv6_;
+tor_addr_t *out4 = i ? &options->OutboundBindAddressIPv4_ : 
&options->LocalOutboundBindAddressIPv4_;
+tor_addr_t *out6 = i ? &options->OutboundBindAddressIPv6_ : 
&options->LocalOutboundBindAddressIPv6_;
 
-  if (!validate_only) {
-memset(out4, 0, sizeof(*out4));
-memset(out6, 0, sizeof(*out6));
-  }
-
-  const config_line_t *lines = i ? options->OutboundBindAddress : 
options->LocalOutboundBindAddress;
-  int found_v4 = 0, found_v6 = 0;
-
-  while (lines) {
-tor_addr_t addr, *dst_addr = NULL;
-int af = tor_addr_parse(&addr, lines->value);
-switch (af) {
-case AF_INET:
-  if (found_v4) {
-if (msg)
-  tor_asprintf(msg, "Multiple IPv4 outbound bind addresses "
-   "configured: %s", lines->value);
-return -1;
-  }
-  found_v4 = 1;
-  dst_addr = out4;
-  break;
-case AF_INET6:
-  if (found_v6) {
-if (msg)
-  tor_asprintf(msg, "Multiple IPv6 outbound bind addresses "
-   "configured: %s", lines->value);
-return -1;
+if (!validate_only) {
+  memset(out4, 0, sizeof(*out4));
+  memset(out6, 0, sizeof(*out6));
+}
+
+const config_line_t *lines = i ? options->OutboundBindAddress : 
options->LocalOutboundBindAddress;
+int found_v4 = 0, found_v6 = 0;
+
+while (lines) {
+  tor_addr_t addr, *dst_addr = NULL;
+  int af = tor_addr_parse(&addr, lines->value);
+  switch (af) {
+  case AF_INET:
+   if (found_v4) {
+ if (msg)
+   tor_asprintf(msg, "Multiple IPv4 outbound bind addresses "
+"configured: %s", lines->value);
+ return -1;
+   }
+   found_v4 = 1;
+   dst_addr = out4;
+   break;
+  case AF_INET6:
+   if (found_v6) {
+ if (msg)
+   tor_asprintf(msg, "Multiple IPv6 outbound bind addresses "
+"configured: %s", lines->value);
+ return -1;
+   }
+   found_v6 = 1;
+   dst_addr = out6;
+   break;
+  default:
+   if (msg)
+ tor_asprintf(msg, "Outbound bind address '%s' didn't parse.",
+  lines->value);
+   return -1;
   }
-  found_v6 = 1;
-  dst_addr = out6;
-  break;
-default:
-  if (msg)
-tor_asprintf(msg, "Outbound bind address '%s' didn't parse.",
- lines->value);
-  return -1;
+  if (!validate_only)
+   tor_addr_copy(dst_addr, &addr);
+  lines = lines->next;
 }
-if (!validate_only)
-  tor_addr_copy(dst_addr, &addr);
-lines = lines->next;
   }
- }
  return 0;
 }
 
diff --git a/src/or/connection.c b/src/or/connection.c
index 397a2dc..021f7ab 100644
--- a/src/or/connection.c
+++ b/src/or/connection.c
@@ -1451,37 +1451,35 @@ connection_connect(connection_t *conn, const char 
*address,
 
   make_socket_reuseable(s);
 
-  {
-const int is_local = tor_addr_is_loopback(addr);
-const tor_addr_t *ext_addr = NULL;
-const tor_addr_t *maybe_ext_addr4 = is_local ? 
&options->LocalOutboundBindAddressIPv4_ : &options->OutboundBindAddressIPv4_;
-const tor_addr_t *maybe_ext_addr6 = is_local ? 
&options->LocalOutboundBindAddressIPv6_ : &options->OutboundBindAddressIPv6_;
-
-if (protocol_family == AF_INET && !tor_addr_is_null(maybe_ext_addr4))
-  ext_addr = maybe_ext_addr4;
-else if (protocol_family == AF_INET6 && !tor_addr_is_null(maybe_ext_addr6))
-  ext_addr = maybe_ext_addr6;
-
-if (ext_addr) {
-  struct sockaddr_storage ext_addr_sa;
-  socklen_t ext_addr_len = 0;
-  memset(&ext_addr_sa, 0, sizeof(ext_addr_sa));
-  ext_addr_len = tor_addr_to_sockaddr(ext_addr, 0,
-  (struct sockaddr *) &ext_addr_sa,
-  sizeof(ext_addr_sa));
-  if (ext_addr_len == 0) {
-log_warn(LD_NET,
- "Error converting OutboundBindAddress %s into sockaddr. "
- "Ignoring.", fmt_and_decorate_addr(ext_addr));
-  } else {
-if (bind(s, (struct sockaddr *) &ext_addr_sa, ext_addr_len) < 0) {
-  *socket_error = tor_socket_errno(s);
-  log_warn(LD_NET,"Error binding netw

Re: [tor-dev] RIAA v Verizon: 404

[Andrew Lewman]

On Mon, 26 Nov 2012 12:05:59 -0800 (PST)
Christian Kujau  wrote:
> the Tor DMCA response[0] has a link inside for the RIAA v. Verizon
> case:
> 
>https://www.eff.org/legal/cases/RIAA_v_Verizon/opinion-20031219.pdf
> 
> But this document is no longer available at this address, thus
> producing a 404. @EFF Webmaster, could you please fix this or provide
> the new address of this document? Is this perhaps the following:

Fixed on our website too.  Thanks!

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] resistance to rubberhose and UDP questions

[Andrew Lewman]

On Fri, 05 Oct 2012 12:07:39 +
Jacob Appelbaum  wrote:

> Huh. Wow. I just... Excuse me? Who suggests that no Tor developers
> haven't already had their arm twisted and stood their ground? Who
> suggests that those who run a Tor Directory Authority would comply
> with the "man" and what "they" say? On what evidence do they say these
> things? Do they understand the moral and ethical character of the
> people running those systems? No, they most certainly do not. Do they
> even know the history of harassment that Tor people have faced in
> various circumstances? No, they clearly do not know these things.

Towards this point, very few know who run the DirAuths, where they are,
and how we vetted these people. We've done a bad job of communicating
this info.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] IRC meeting to plan sponsor L milestones on Wed July 18, 15:00 UTC in #tor-dev

[Andrew Lewman]

On Tue, 14 Aug 2012 10:09:39 +0200
Karsten Loesing  wrote:
> Mike, Andrew, Roger, Runa: please update the wiki page with your
> feedback in this thread.  Please keep the developer feedback per
> deliverable as short as possible, ideally in a single paragraph.

We need a better way to have a conversation about these deliverables,
for SponsorL now, and in the future as more of these situations come
up. My only suggestion is to not use trac wiki and write endless
replies in text over or under previous text, maybe riseup etherpad, an
actual trac discussion plugin, gobby session, or something else similar.

As much as I dislike IRC as a decision medium, should we have another
IRC meeting to discuss current state?

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] IRC meeting to plan sponsor L milestones on Wed July 18, 15:00 UTC in #tor-dev

[Andrew Lewman]

On Thu, 19 Jul 2012 19:55:52 -0400
Roger Dingledine  wrote:


First off, let me welcome tor-dev and the world to the sausage factory
of open source projects.

> You should definitely put them somewhere. But be sure to retain the
> original text too, so we can go back and compare if we need to later.

Won't the past text and the diff be in the wiki history for the page?

> All of that said, I totally agree that for #1, we need to be sure
> Andrew and the funder both understand that we can't promise that
> we'll deploy any particular transport protocol -- the first step is
> research, and that means step two must stay flexible.

I expect the pushback to be along the lines of "this is a deployment
goal, not a research goal". If http/dns is bad, then we should figure
out some way to deploy two unique transports in the wild.

> Andrew is hoping to use this as an opportunity to explore "hire
> people who will do great work and not charge American prices".
> Apparently our current Farsi translator is one such person, and
> Andrew hopes we find more.

The language-specific support is part-time, at best. 

> 
> We have four separate directions in mind for this "community manager"
> notion (not all funded by SponsorL, mind you):
> 1) Relay operator coordinator. Somebody to keep relay operators happy
> and in touch with us, encourage people to set up new relays, organize
> recommended configurations, etc. Especially important in tandem with
> our "network diversity" work at #6232.
> 2) Volunteer-developer coordinator. Somebody to take incoming
> volunteers and help them find good existing projects to work on.
> Likely involves making our volunteer page more usable. Should also
> include knowing enough about every project to recognize and identify
> good low-hanging fruit, and knowing enough about our priorities to
> make smart decisions. 3) Blog/forum/mailinglist coordinator, to make
> sure our users have useful answers, and ultimately to manage and
> organize the volunteers who make sure our users have useful answers.
> 4) Social media person, to be our face on twitter, etc.
> 
> I believe the plan is for Runa to cover #4, and for us to contract
> somebody in our relay operator community part-time for #1 to start. I
> think there is no plan for #2 and #3 yet; but I'd love it if we could
> get somebody part-time for #2.

Actually, we have three roles. #4 is the same as #3. Whether it's
mailing list, forum, twitter, facebook, google+, whatever, the role is
the same. 

> >  Runa is wondering why we want
> > funding for languages no one has emailed us in (Spanish and French);
> > though nobody has emailed us in Arabic, either.

We have only told people we can handle English and Farsi at this point.
Once we announce others, they will come.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] IRC meeting to plan sponsor L milestones on Wed July 18, 15:00 UTC in #tor-dev

[Andrew Lewman]

On Thu, 19 Jul 2012 12:08:28 -0700
Mike Perry  wrote:

> Here's the job announcement page that needs to be updated to reflect a
> possible October start date:
> https://www.torproject.org/about/jobs-browserhacker.html.en
> 
> Action item 0 is to figure out how and where to announce that.

Action item pre-0 is to rework the content on that page. I'm
currently working with employment lawyers and HR people to sort out
what is "non-standard" from "illegal according to US labor laws". I'd
rather spend money on hiring a person than defending a lawsuit from a
bored person looking to sue Tor for labor law violations.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Thandy and what's next

[Andrew Lewman]

On Mon, 20 Jun 2011 21:40:07 +
Tomas Touceda  wrote:
> A couple of months ago, nickm and erinn worked in writing the package
> format spec (see [2] for more details), and now I'm going to start
> working as fast as I can (which may be slow) in implementing this last
> spec and get a working Thandy.

Hello Tomas,

Can you update us on thandy progress so far?  I've seen some work in
the alpha version of vidalia. Where do you need help?

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] First-time tails/tor user feedback

[Andrew Lewman]

On Sat, 21 Apr 2012 16:21:09 +
Robert Ransom  wrote:

> > # Third issue: green onion

> What should they have wanted to do with Vidalia?

Perhaps seeing the progress bar as tor bootstraps would have been
helpful. Perhaps knowing they do have some control over this blackbox
thing called tor browser would have been helpful.

Another thought is that using tor requires some education. Just
downloading it and running is probably dangerous for a subset of users.
One analogy is that tor is a race car. While many know how to
drive a car on the street, driving a race car takes some education and
practice to do safely. 

> That is exactly why I suggested the phrase “Congratulations. *This*
> browser is configured to use Tor.” (emphasis added) on
> https://bugs.torproject.org/2289 .  But when I explained on IRC that
> there is a big difference between “this browser” and “your browser”,
> no one believed that users would interpret them differently.

I agree with you.

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] First-time tails/tor user feedback

[Andrew Lewman]

wouldn't work (because there is no flash, java,
silverlight plugins installed) and their answer was 'then do not show
it at all'. Inside noscript, I unchecked the 'show placeholder..'
option and had them browse again. they were happy. It seems if the user
cannot do anything about the blocked apps, not showing them may be
preferred.

# Seventh issue: shutdown

I asked all 8 to shutdown tails and let me know when they thought their
data was safely no longer on the system. 1 of 8 figured out how to
shutdown tails by clicking the big red button in the upper right
corner. The rest hit the power button on the laptop.

After rebooting, i showed them all they could just pull the usb drive
to do it as well. As soon as tails started shutting down, they all
assumed everything was safe and tried to power off the laptop. 

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Alternatives to Tor Exit Enclaves

[Andrew Lewman]

On Wed, 18 Apr 2012 17:28:42 -0400
Arturo Filastò  wrote:

> The current stable version of Tor (0.2.2.x) still supports Exit
> enclaves. The new versions of Tor
> (> 0.2.3.x) use a new descriptor format (microdescriptors) allow
> relays to specify an Exit Enclave
> policy, but clients will not use it, therefore voiding the purpose of
> exit enclaving.

Is there a plan to re-enable clients to use exit enclaves?

-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Alternatives to Tor Exit Enclaves

[Andrew Clausen]

Hi Arturo,

On 18 April 2012 17:47, Arturo Filastò  wrote:
> On 4/18/12 5:33 PM, Andrew Clausen wrote:
>> Do .exit addresses already do what you had in mind?  For example, if
>> you add "AllowDotExit 1" to your torrc, you can type an address like
>> this
>
> No, .exit notation is a bad idea because it allows people
> to force you to exit through a particular exit node of their
> choosing.

I suppose this is true, according to the spec.  (When I tested this
out, the implementation seemed to match my proposal below rather than
the spec.  I haven't had a chance to look at it.)

However, it would be easy to change Tor slightly.  If Tor used four
ORs rather than three with .exit addresses, then there would be no
problem.  The only difference between using "http://myserver.exit";
rather than "https://myserver.com"; would be that the last hop would
use the Tor protocol rather than HTTP.

> For example I can place a  tag on a website
> and de-anonymize every user by getting them to go through my
> address.

The situation for http://myserver.exit";> would be no worse
than for http://myserver.com";>

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

Re: [tor-dev] Alternatives to Tor Exit Enclaves

[Andrew Clausen]

Hi Arturo,

Do .exit addresses already do what you had in mind?  For example, if
you add "AllowDotExit 1" to your torrc, you can type an address like
this

http://thewebserver.exit/index.html

into your web browser.

It would be nice if this particular usage of .exit were allowed by
default (but the more dangerous anotherserver.anexitnode.exit still
remain disabled by default).

Cheers,
Andrew

On 18 April 2012 17:28, Arturo Filastò  wrote:
> The purpose of Exit Enclaves was to allow people running a website to
> make Tor users
> access it without ever leaving the Tor network. This leads to the
> clients having end-to-end
> encryption with the target destination.
>
> Even in previous version this had some issues, one of which was the fact
> that at the first
> connection the user would not be accessing the destination over a Tor
> circuit if the destination
> was provided in a hostname format (and not IP).
>
> The current stable version of Tor (0.2.2.x) still supports Exit
> enclaves. The new versions of Tor
> (> 0.2.3.x) use a new descriptor format (microdescriptors) allow relays
> to specify an Exit Enclave
> policy, but clients will not use it, therefore voiding the purpose of
> exit enclaving.
>
> I believe there is the need for something similar to Tor Exit Enclaving
> and the closest thing I see
> fit these requirements are Tor Encrypted Services
> (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt).
>
> Encrypted Services (EC), are basically regular Tor Hidden Services, that
> do not provide anonymity
> for the server and gain a better performance because of this (they have
> a one-hop circuit
> to the RV and IP).
>
> The problem with making Encrypted services work to replace Exit Enclaves
> is that the client needs
> to have a way to understand that their destination is running also as an
> Encrypted Service.
>
> In this very high level overview I don't go into very much detail of how
> this system will actually
> work, but I hope it will prompt some discussion on the matter.
>
> I think this can be achieved mainly in 3 ways.
>
> 1) The client already knows all of the EC's
> 2) The client looks up if a destination is an EC when trying to connect
> to it
> 3) The final hop looks up if the destination is an EC
>
> These all have some drawbacks:
>
> In 1) the client needs to download the full list of EC's, therefore if
> the number of EC's get's
> very large it will take clients much more to bootstrap and they will
> need to store more data.
> The good thing of this though is that the speed of connections would be
> as fast as they
> are at the moment as it does not require any extra connections.
>
> In 2) the clients needs to complete an extra round-trip for every
> connection. I don't think
> this is a valid solution as it would degrade the quality of connections
> for every user.
>
> In 3) the final hop would do along side a normal A lookup for hostnames
> a CNAME lookup (
> or another special field). If it finds that such a lookup returns a
> .onion address instead of
> returning a RELAY_CONNECTED cell it will return a ENCRYPTED_SERVICE cell
> containing
> the .onion address of the target ES.
>
> The client will then cache this address and connect to it.
>
> This approach adds a little bit of overhead (since two DNS lookups need
> to be made),
> but it is still faster than 2).
>
> It suffers from the issue of the exit node could spoof the .onion
> address and redirect
> the user to a malicious .onion address. This is quite a tough problem
> that I am still
> unsure how it could be solved. If we have support for DNSSec this issue
> could be mitigated.
>
> I would love some feedback on this topic.
>
>
> - Art.
>
>
>
>
> ___
> 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

Re: [tor-dev] Tor for iOS via official channels

[Andrew Lewman]

On Sun, 18 Mar 2012 15:42:33 +0200
Linas Valiukas  wrote:
> I was thinking about a GSoC 2012 project I could propose, and I came
> to the question of why there's no Tor iOS (iPhone / iPad / iPod
> touch) application distributed on the official iTunes App Store?

People have tried in the past and been rejected for being a
'proxy/circumvention tool'. 


-- 
Andrew
http://tpo.is/contact
pgp 0x6B4D6475
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor download link

[andrew]

On Mon, Oct 10, 2011 at 10:23:00AM +, rransom.8...@gmail.com wrote 1.0K 
bytes in 24 lines about:
: Non-current Tor packages are somewhere on
: https://archive.torproject.org/ .  Current Tor packages may also be
: there.

In fact, current versions are there too.  Build systems should use
archive.torproject.org and not torproject.org/dist for their source code
needs.

/dist is for the current release only.

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] سلام برنامه تور فارسی برای ایران

[andrew]

On Fri, Sep 30, 2011 at 12:19:28PM -0700, mohammad_20101...@yahoo.com wrote 
2.7K bytes in 52 lines about:
: سلام برنامه تور فارسی برای ایران وسازگار با سرعت کم اینترنت داخلی می خاهم 
متشکرم

This has nothing to do with developing tor. Please email
community-supp...@lists.torproject.org.

I've unsubscribed you from the list.

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] MITM for TOR

[andrew]

On Fri, Sep 23, 2011 at 03:52:25PM +0200, robvanderhoe...@ziggo.nl wrote 0.5K 
bytes in 20 lines about:
: I build a small Monitor In The Middle (MITM) proxy that can be used to
: study the communication between TOR and the browser. Hope this can be
: used to improve TOR.
: 
: It's small but quite powerful. Wrote an article about it on my blog:
: 
: http://freedomboxblog.nl/mitm-for-tor/

It seems you responded to another thread with a new subject, perhaps
this has confused others.

How does this differ from the tamper data extension in Firefox?
https://addons.mozilla.org/en-US/firefox/addon/tamper-data/

In either case, did you find anything in the interaction between firefox
and the Tor socks proxy? From you blog post, it looks like Tor socks
interaction is quick, and the performance of everything else is
dependent on the active circuit.

And, it's Tor, not TOR.  See
https://www.torproject.org/docs/faq.html.en#WhyCalledTor for the
details.

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Sanitizing and publishing our web server logs

[Andrew Lewman]

On Friday, September 02, 2011 10:08:37 Brian Szymanski wrote:
> What exactly are we hoping to gain from the analysis of the (hopefully
> correctly) stripped logs?

Overall, all of our data collected can be analyzed to see if any of it can be 
used to discover users, sets of users, or other personally identifying info.  

It will also be helpful to know more about our websites, usage, referrers, 
etc.  If Tor is going to be transparent in its data collection practices, we 
should be able to publish our web server logs without issue.

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

Re: [tor-dev] Survey on Tor Trac usage and how you manage your tasks

[Andrew Lewman]

On Monday, September 12, 2011 11:27:51 Karsten Loesing wrote:
> Well, I don't know what to do here.  I think changing the component of
> 500+ tickets and adding, say, keywords for the category is a lot of work
> and will generate a lot of mail for people on tor-bugs.  Is it worth it?

Is there any way to automate the keyword creation for tickets?  

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

Re: [tor-dev] Survey on Tor Trac usage and how you manage your tasks

[Andrew Lewman]

On Monday, August 22, 2011 08:29:09 Karsten Loesing wrote:

> 1 Using Trac features
> 
> 1.1 Which of the reports (stored ticket queries) do you use most often?

All tickets, mine first

> 1.4 Are you subscribed to tor-bugs and/or tor-wiki-changes, and how do
> you use the mails sent to these lists?

tor-bugs, as review of all tickets with changes.

> 1.5 Which wiki pages do you read/edit most often?
> 1.6 How do you search for wiki pages?

index page.  trac search is useless for finding any information on the trac.  
ddg or google are better at finding info on our trac.
> 1.10 How relevant are the following ticket statuses for you?
> 1.10.1 accepted
> 1.10.4 needs_information
> 1.10.6 new

I use 'new' to mean 'haven't thought about it yet'.  I use 'accepted' to mean 
I've thought about it and have a plan. I use 'needs_information' to mean the 
user needs to provide info to me before further progress.

> 1.11 What other features do you use in Trac?

I use the timeline heavily to see what's changed.  I mostly subscribe to RSS 
feeds of tickets, wiki pages, and timeline to keep track of the various bits 
that are relevant to me.

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

Re: [tor-dev] Sanitizing and publishing our web server logs

[Andrew Lewman]

On Thursday, August 25, 2011 04:08:00 Karsten Loesing wrote:
> we have been discussing sanitizing and publishing our web server logs
> for quite a while now.  The idea is to remove all potentially sensitive
> parts from the logs, publish them in monthly tarballs on the metrics
> website, and analyze them for top visited pages, top downloaded
> packages, etc.  See the tickets #1641 and #2489 for details.

My concern is that we have the data at all.  We shouldn't have any
sensitive information logged on the webservers. Therefore sanitizing the
logs should not be necessary.  I would like to replace the current
0.0.0.0/0.0.0.1 scheme with a geoip lookup and just log the country code
in place of the IP address. Apache can do this on the fly between
request and the log entry.

> Is there still anything sensitive in that log file that we should
> remove?  For example:

Referrers and requested urls will be a nightmare to clean up. We
literally get thousands of probes a day per site trying to exploit
apache (or tomcat, or cgi, or a million other things). If we were the US
military, we'd claim each probe is a hostile attack and whine about
millions of attacks on our infrastructure a year. Clearly this is
cyberwar and we need $3 billion to stop it or retaliate.

On the other hand, seeing the referrer data has been interesting because
it tells us where our traffic originates. Our top referrers are google
and the wikipedia pages about tor in various languages. The search terms
are also valuable if we want to buy keywords for ads some day. We've had
two volunteers do this already through google adwords and the results
are surprising.

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

Re: [tor-dev] Instructions for building the Vidalia-bundle?

[Andrew Lewman]

On Tuesday, August 09, 2011 06:07:13 Robert Ransom wrote:
> On 2011-08-06, Andrew Lewman  wrote:
> > On Friday, August 05, 2011 13:02:46 Steve Snyder wrote:
> >> Is there documentation anywhere on how to build the Vidalia-bundle for
> >> Windows?  If so, where can I find it?
> > 
> > Build vidalia first,
> > https://svn.torproject.org/vidalia/vidalia/trunk/pkg/win32/build-vidalia-
> > installer.txt
> 
> Vidalia has moved to Git. 

Ok.  Can we purge the vidalia svn and put in a MOVED_TO_GIT notice?

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

Re: [tor-dev] Instructions for building the Vidalia-bundle?

[Andrew Lewman]

On Friday, August 05, 2011 13:02:46 Steve Snyder wrote:
> Is there documentation anywhere on how to build the Vidalia-bundle for
> Windows?  If so, where can I find it?

Build vidalia first, 
https://svn.torproject.org/vidalia/vidalia/trunk/pkg/win32/build-vidalia-
installer.txt

then build the bundle

https://svn.torproject.org/vidalia/vidalia/trunk/pkg/win32/build-bundle-
installer.txt

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

Re: [tor-dev] [PATCH] Allow tordnsel to build on Squeeze

[Andrew Lewman]

On Sun, 19 Jun 2011 23:35:42 +0200
Jérémy Bobbio  wrote:
>I give up on tordnsel, I'm unable to get git head to
> compile in squeeze
> 
> Attached are 3 patches that allow tordnsel to build on a Squeeze
> system. I unfortunately lack a test environment to ensure that the
> resulting binary works fine. Haskell has proven quite trusty, though.

Thanks!  I can only get patch 0001 to apply cleanly.  The other two
fail. I'll keep poking at it.

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

[tor-dev] Thoughts on simplified packaging

[Andrew Lewman]

As I talk to more and more people, they are confused by all of the
different software packages we offer.  From the simple, 

"I just want to be a relay, why is this so hard?"

to 

"I just want to safely get to the BBC, I don't care about configuration
and such. Can't you just make it a simple download and have it work by
default?"

I've written down my thoughts at
https://svn.torproject.org/svn/projects/roadmaps/proposed-package-roadmap.txt.

I'm looking for your thoughts and feedback.  The goal is to simplify
what we produce and make it easy for people to get the software and
configuration they want.

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

Re: [tor-dev] The Torouter and the DreamPlug

[andrew]

On Fri, Jun 10, 2011 at 04:15:43PM +, ja...@appelbaum.net wrote 15K bytes 
in 322 lines about:
: I think we should re-flash with an OS that makes hardening a priority. We
: should only harden the OS in the sense that we should strip out anything
: that we do not require for our uses. Debian and Ubuntu both have compiler
: hardening flags enabled by default but in general, I'd consider Ubuntu's
: userspace to be proactively improved and their kernel ships with quite a few
: security improvements. I'm not sure about the kernel status for Debian or
: who is proactively working on security in Debian.

Let's go back to the original point of the tor router.  It is to
provide a consumer-level Internet NAT/router that is a tor bridge.
This way, people have a functional Internet gateway, and also give
blocked users access to information via tor.  The target user is someone
who cannot configure tor themselves, but wants to help out with nearly
zero effort.  From what we're discussing, the excito is still that device.

We're only attracted to the dreamplug because it's cheaper.  If we're
going to ship a device that is only usable to 10 people in the world,
then we shouldn't waste our time and ship anything.  We can simply
document how to turn your dreamplug into a secure tor relay/bridge and
let those so interested do it. As it is, the dreamplug is already
difficult to use for 90% of the world because it's ssh only.  ssh and
vi only and consumer friendly generally do not go together.

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The Torouter and the DreamPlug

[andrew]

On Fri, Jun 10, 2011 at 07:12:25PM +, ja...@appelbaum.net wrote 1.7K bytes 
in 39 lines about:
: I did not suggest a backdoor! I suggested a method of remotely helping

This comes across as "it's not a backdoor, it's a highly secured front
door that only law enforcement will have access to in order to catch
criminals".   

: someday. It's a bad idea to just mail off a bunch of hardware and hope
: for the best. We should provide some kind of support and help for the
: device during the alpha testing phase of the project.

Then we shouldn't ship the hardware yet.  The hardware needs to stand on
its own, with real users, and not have a way we can remotely access
anything. 

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Too many cooks spoil the broth---or: how about we clean up the wiki?

[andrew]

On Sat, Jun 11, 2011 at 08:17:35AM +0200, karsten.loes...@gmx.net wrote 2.5K 
bytes in 34 lines about:
: > Do you plan to fix links in the mailing list archives as well?  How
: > about links in our e-mail inboxes?
: 
: Nope.  But we could add redirects for those pages linked from the
: mailing list archives and everyone's inbox.  Similar to how we added
: redirects when moving from
: https://wiki.torproject.org/noreply/TheOnionRouter/ to the current location.

Why this need to preserve old links forever?  Websites change. If we
migrate from trac to something else, I'm not going back and updating
every website that ever linked to trac.  When we changed from flyspray
to trac, google, yahoo, bing, etc search engines all update their
databases of links within 3 days.  

I'm fine with not putting in any redirects.  If the new structure is
sufficiently logical, people will figure it out. torproject.org is the
largest link farm to trac, we can update that.  Attached is the linking
domains, according to google, to trac.tpo.

-- 
Andrew
pgp key: 0x74ED336B
Domains,Links,Linked pages
torproject.org,"514,582","3,600"
seul.org,"11,250",304
mail-archive.com,"5,119",53
hermann-uwe.de,668,3
cybermirror.org,476,46
slyck.com,321,3
spline.de,278,18
hermetix.org,236,23
szb66.net,207,23
hacktivistas.net,190,2
vidalia-project.net,171,5
wordpress.com,146,16
neoturbine.net,145,3
blogspot.com,123,16
swik.net,111,4
bitchx.com,94,57
gmane.org,86,30
infosecurity.ch,78,3
thruhere.net,68,14
flossmanuals.net,60,2
ath.cx,58,7
marc.info,56,34
amorphis.eu,52,10
hak5.org,50,3
sesawe.net,42,2
wikipedia.org,34,6
slacknews.org,31,5
swfc.edu.cn,27,4
wilderssecurity.com,27,6
soup.io,24,6
ubuntuforums.org,23,9
boum.org,23,16
ngoinabox.org,21,1
pgpru.com,19,6
facebook.com,18,13
google.com,17,10
ubuntu.com,17,9
thaijobpost.com,16,12
zendfile.com,15,13
mozilla-russia.org,15,4
mozillazine.org,14,8
chinagfw.org,13,4
eff.org,13,5
gulli.com,13,5
ubuntuusers.de,12,4
osdir.com,12,4
sesawe.org,12,2
i2p2.de,12,2
newscn.org,11,9
torproject.org.in,11,4
fscked.org,11,11
ubuntu-fr.org,10,4
noirbizarre.info,10,1
linuxquestions.org,10,6
dslreports.com,9,1
linux-bg.org,9,3
zuo.la,9,3
ubuntu-it.org,9,3
appspot.com,8,4
baldric.net,8,2
bullog.org,8,4
jugem.jp,8,2
ethr.net,8,6
livejournal.com,8,5
debian.net,8,4
globalvoicesonline.org,8,1
guiguishow.info,7,1
launchpad.net,7,6
archlinux.org,7,4
wapedia.mobi,7,4
atagar.com,7,6
walkyr.fr,7,5
sensagent.com,7,2
slashdot.org,7,4
livelyblog.com,7,2
hispasec.com,6,6
antivirusgratis.com.ar,6,6
baidu.com,6,4
ncmilitia.org,6,4
utorrent.com,6,4
rakuten.co.jp,6,3
privacydigest.com,6,2
linux.org.ru,6,2
typepad.com,6,2
kairaven.de,6,5
haygus.fr,6,4
security-forums.com,6,3
indymedia.org.uk,6,1
guardianproject.info,6,1
boingboing.net,6,4
schneier.com,6,2
tor2web.org,6,4
derkeiler.com,6,5
metafilter.com,6,3
bodhizazen.net,6,3
seclists.org,5,5
twitter.com,5,4
bitcoin.org,5,2
gentoo.org,5,5
chzv.net,5,5
wiredwings.com,5,3
mobileactive.org,5,2
cousingirls.com,5,1
nerdbynature.de,5,2
beakkon.com,5,3
dbform.com,5,1
reddit.com,5,4
pczone.com.tw,5,3
rightpaths.com,5,5
txoof.com,5,3
pub.ne.jp,5,1
forsv.com,5,1
experts123.com,5,2
kirishimaya.com,5,1
html.it,5,3
v3-labs.info,5,1
taringa.net,5,2
koolfy.be,5,1
webhosting.pl,5,2
askapache.com,5,4
openwrt.org,5,1
hostingprod.com,5,1
sina.com.cn,4,2
opera.com,4,2
98.15.0.194,4,2
naver.com,4,2
dcluo.info,4,2
xmarks.com,4,2
pff.org,4,2
akarouche.com,4,2
frishit.com,4,1
ubuntu.org.cn,4,2
opennet.ru,4,1
fusselwurm.de,4,1
38.229.0.70,4,4
archetwist.com,4,1
altervista.org,4,1
uwaterloo.ca,4,2
korykirk.com,4,4
boards.ie,4,1
vuikhoe-vn.co.cc,4,2
cnnvd.org.cn,4,4
hermesblog.co.cc,4,1
kubieziel.de,4,3
bsdforen.de,4,4
canalblog.com,4,1
excito.net,4,3
anahuac.mx,4,1
linuxreviews.org,4,2
kriptopolis.org,4,2
pentbox.net,4,1
anarchopedia.org,4,2
headstrong.de,4,3
i2p.to,4,2
cnet.com,4,4
linuxmint.com,4,3
theonionrouter.com,4,2
meneame.net,4,2
over-blog.es,4,2
myners.net,4,2
thedarkrising.com,4,1
antichat.ru,4,1
sourceforge.net,4,4
gigaom.com,4,2
luna.com.tw,4,3
4pda.ru,4,1
bsdprojects.net,4,2
ndaru.net,4,2
linuxcenter.ru,3,3
as-ansar.com,3,2
vmware.com,3,2
dator.lv,3,1
myp2pforum.eu,3,2
ossblog.it,3,1
psycosismental.co.cc,3,3
mimizun.com,3,2
peio.org,3,3
fwolf.com,3,1
torproject.tk,3,2
swerat.com,3,1
filesharefreak.com,3,1
jovenescarmelitas.com,3,1
habrahabr.ru,3,1
libellug.org,3,3
protecus.de,3,3
blogfa.com,3,1
iteye.com,3,3
beme-it.de,3,2
noblogs.org,3,3
cpunk.de,3,3
thegeniusfiles.com,3,1
kicks-ass.net,3,3
pearltrees.com,3,2
bridges4tor.org,3,3
virus.org,3,3
unfix.org,3,1
esoeslodemenos.com,3,3
ubuntu.ru,3,2
heise.de,3,2
mail.ru,3,3
xda-developers.com,3,1
ubuntu-nl.org,3,3
es.tl,3,3
wired.com,3,1
transmissionbt.com,3,2
security-portal.cz,3,2
github.com,3,3
nabble.com,3,2
lightbluetouchpaper.org,3,3
dprox.org,3,1
experts-exchange.com,3,2
kak-gde.ru,3,3
dancersblogs.com,3,3
planetpeer.de,3,2
broadbandreports.com,3,2
answers.com,3,3
ebenben.com,3,1
osv

Re: [tor-dev] Too many cooks spoil the broth---or: how about we clean up the wiki?

[andrew]

On Fri, Jun 10, 2011 at 12:08:46PM +0200, karsten.loes...@gmx.net wrote 7.5K 
bytes in 279 lines about:
: I think the main problem is that there's no obvious structure in the
: wiki, so everyone just adds their stuff anywhere, maybe thinking that
: someone else will move it to the right place.  The other problem is that
: there's no such person cleaning up.

You're looking at the structure as created and migrated over 8 years.
Also see https://trac.torproject.org/projects/tor/ticket/1939 for
another option.  Our wiki is trying to be all things to all people, and
is clearly failing, or at least confusing everywhere. 

Trac search isn't very good.  Lots of people use
https://trac.torproject.org/projects/tor/wiki/TitleIndex to find their
way around the wiki.

Most of this is going to be a "do-acracy", he/she who does the work,
wins.  The only part to be careful with is the actual faq pages.  Those
are heavily linked from around the world.  I can pull up the view of our
trac according to google's webmaster tools if you're interested.

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The Torouter and the DreamPlug

[andrew]

On Mon, May 30, 2011 at 01:56:25PM +0100, runa.sand...@gmail.com wrote 2.9K 
bytes in 75 lines about:
: The whole point with the Torouter is to allow more people to run a
: bridge or a relay, so I see a web interface as something mandatory. So
: yeah, we'd have to make sure that the interface is secure.

Right, so we have two torouters, an expert model which is the dreamplug,
and a non-expert model which is the excito.

Experts use ssh and follow some instructions for configuring their
device.  Plus, they get some cheap hardware to do whatever else they
want to do with it.

Non-experts get the excito with the web interface: point, click,
configured, done.  

I have 10 dreamplugs with US power config arriving soon.  Once Excito
has their new version ready, we can get 10 of those.  Then we find 20
volunteers willing to test the default configs and provide feedback.  In
exchange, they get to help censored users and get free hardware.

Rather than arguing about web interfaces that do not exist, we should be
figuring out how to update the routers, make sure new tor packages are
updated timely, and how to handle support issues from the simple "it
doesn't work, at all" through "your router ate my cat and soured my
milk".

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The Torouter and the DreamPlug

[andrew]

On Thu, Jun 09, 2011 at 07:50:09PM +, ja...@appelbaum.net wrote 15K bytes 
in 359 lines about:
: What's the rational there? While we certainly need more bridges, I'd like to

Our funding for this project is to create more bridges to allow censored
users to access the less-censored Internet from somewhere else in the
world.  It is not to create more relays.

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The Torouter and the DreamPlug

[Andrew Lewman]

On Tue, 7 Jun 2011 15:36:45 -0700
Jacob Appelbaum  wrote:

> > We would also need a way for users to easily change the hashed
> > password. I can't remember if this is a feature that is already
> > present in Vidalia.
> Yes, we do need a way to change the password. We will also need a way
> to reset the password if the user is locked out of the control port. I
> generally think that this means we'll need a web UI... :-)

It's built into vidalia.  Just click Advanced and you can change the
password all you want.

> I think the best thing is to make an autoconfiguring device with a
> web UI; we can easily rate limit Tor to something reasonable and make
> it a middle node by default. In all cases it stands alone and simply
> plugging it into a wall (power/ethernet) will provide more capacity
> to the network if the OR port is reachable (ala tor-fw-helper + tor +
> init.d scripts to start Tor on boot).

Most of me wants to wait for the freedombox people to derive their web
interface, and then we can plug tor into it.  I realize this could be
years at the current rate of progress. If someone whips up a quick
interface that isn't a security nightmare, we could use that until
freedombox has something tangible.

I suggest we ship the dreamplug with cli access only for those who want
a cheap device to be a bridge or relay.  

I suggest we ship the excito with the web ui as the easy to use
option.  

In either case, we need to start testing, not keep thinking about what
we could do.  We're going to get a flood of feedback from actual people
testing the excito or dreamplug.

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

Re: [tor-dev] The Torouter and the DreamPlug

[Andrew Lewman]

On Tue, 7 Jun 2011 21:08:48 +0100
"Runa A. Sandvik"  wrote:
> > Vidalia is not designed to control or configure a Tor process that
> > it did not start.
> 
> I have tested this, and it works just fine. The question is; are we
> happy with something that works, even if it's being used in a way that
> it was not designed for?

Vidalia was designed to do this from the start, which is why it uses
tcp/ip instead of some ephermeral file descriptor locally.  The
connection between their vidalia and the tor process is in plaintext.
That should be the concern.

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

Re: [tor-dev] Tor meets real users

[Andrew Lewman]

On Fri, 13 May 2011 18:09:04 -0400
katmagic  wrote:
> As Torbutton has taught us, browsers send quite a bit of information
> with them. It seems like it would be helpful to automatically detect
> the user's language and operating system, via the User-Agent and
> Accept-Language headers.

For a long time, we at Tor have had a love/hate relationship with
javascript.  We want the website to work well without it, but at the
same time, having it would make our site more usable to those with it
enabled.  

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

Re: [tor-dev] Tor meets real users

[Andrew Lewman]

On Wed, 18 May 2011 00:39:03 -0700
Mike Perry  wrote:

> We should definitely translate Andrew's report and this commentary
> into tickets in the bug tracker, otherwise it will be forgotten..

On my todo list.

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

Re: [tor-dev] Tor meets real users

[Andrew Lewman]

On Fri, 13 May 2011 00:25:00 -0700
Lucky Green  wrote:
> Easily solved. A download page should be workflow based. You can lay
> it out as columns or successive pages. Example:

We have this, sort of, at
https://www.torproject.org/download/download-easy

> The first issue is the UE problem, meaning page design bug, of giving
> the user choices inside the default work flow of having to select a
> particular product, such as tpo/torbrowser. There should only be one
> default choice per OS.

If we used javascript to magically detect their preferred language,
then we could default the page to that, for their OS too.

> The other issue has too sub-issues. The first sub-issue is that users
> can be whiny, as they are here. How are those users with their shiny
> MacOS laptops getting OS updates? How large are those OS updates? How
> big was that last iTunes update? Oh, those updates are larger than 24
> MB?

Assume for this set of users, everything is possibly not legally
obtained. They swap cdroms and usb drives around.  They may not be able
to legally buy the software in their home country.  

> The second sub-issue (only useful to know after having figured out the
> first) is which download options to offer as part of the regular work
> flow. http/our download manager/BT are common, but that doesn't
> necessary make them the correct choices for Tor.

I was thinking of thandy/secure updater here.  They download one tiny
thandy-stub program, which then does the rest via https or bittorrent.

> > None of them had pgp installed, and therefore no way to verify
> > the .asc and zip file.
> That is to be expected. (And I am confident was expected by Andrew).

Yes, expected.

> > Most of them figured out to click inside the resulting folder and
> > start the 'start tor browser' program.  For all of the macs, the
> > tbb didn't start.  The people had to restart the system and then
> > clicking on 'start tor browser' worked as expected. 
> Bug of some sort. (Possibly in the installer not prompting the user
> for the required reboot).

It's a bug.  There is no installer for TBB by design.  It should just
unzip and work.

> You are striving for user notification of actions in 3/10th of a
> second. Anything more than that and the user will perceive lag. Note
> that 3/10 of a second is plenty of time to load a stub that reads
> "Please wait, Tor is loading". Take much longer after that notice is
> presented to the user for the final app to load and you'll want some
> visual indicator of progress, such as a spinning ball.

Something optional that loads the first time, with a check
box that says 'never load this message again' would also work.

> Again, multiple issues here. Clearly the browser is loading too
> slowly, which may be inherent to the browser. If so - and if it is
> not possible to make the browser load faster by stripping it down -
> you are using the wrong default browser. Obvious area to explore here
> is how fast the users' regular browsers are loading. Must be faster
> than tbb firefox or they wouldn't have been able to start their own
> browsers in the interim. Figure out why their default browsers are
> loading faster and go from there.

This is firefox, stripped down already.  I think the problem here isn't
that firefox was a dog on OSX, because it loaded fast on the window's
systems, but rather they didn't even know a browser was going to load.  

> UE design bug. The user should only be presented with UI elements that
> the user needs to interact with to complete the task. Anything else
> should be buried in a "Tools" (think Chrome) menu or Tray icon. If
> what you are loading is a new browser, there shouldn't even be a Tray
> icon, but an additional button or sub-menu in the browser.

I like what TAILS has done here.  They strip out all of the
configuration options from Vidalia, so you can't click to change any
settings.

> The Tor Project would do well to not ADHD its activities into fixing
> all security ills of this world, such as email encryption, full disk
> encryption, or how to secure data once it leaves the exit node. 

If not us, then who?  ;)  Yes, I agree, but users invariably ask us
about this stuff because we all use it daily.

> We do not
> know how to achieve this goal given the present state of the art in
> computer science.

Well, I look at TAILS and Haven as two anonymous OSes that make strides
towards this.  Anonymous and mostly-secure by default enforce the
'power of the defaults'. 

And yes, your comments are always welcome.

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

[tor-dev] Tor meets real users

[Andrew Lewman]

A short while ago, I did a training for some activists from a country
that is hostile to the Internet.  These people were some of the more
technical people from their community.  There was a mix of Windows and
OS X laptops in the session.  English was their third language, for
added fun.

I walked them through finding tor browser bundle, downloading it,
verifying it, unzipping it, and starting it.  Here was the first
problem.  They couldn't find tbb on the download page.  Their comments
were that all these files and releases on the page were confusing.
They wanted just one thing to look at, pick their operating system, and
go.  And they wanted the one thing to automatically detect their
language preferences for tbb.

I ended up pointing them at tpo/torbrowser, which they also thought was
confusing.  The aforementioned desires weren't satisfied on this page,
but at least they could find their preferred language.  They all
commented that back home, a 24MB file was too big, and can't they get
it via bittorrent or some other piecemeal way?  A 24mb file would take
hours to download.

Once they finally downloaded it, they all double clicked on their
resulting zip file.  In fact, all of the mac people ended up
downloading the windows tbb and unzipped it correctly.  In all cases,
their operating system handled the zip file correctly. After fixing the
mac people with mac tbb, we moved on to the next step.

None of them had pgp installed, and therefore no way to verify the .asc
and zip file.

Most of them figured out to click inside the resulting folder and start
the 'start tor browser' program.  For all of the macs, the tbb didn't
start.  The people had to restart the system and then clicking on
'start tor browser' worked as expected.  

As tbb was starting up, nearly all of them clicked on 'start tor
browser' one to three times more, because they didn't see anything
starting up.  In fact, it was starting, it just wasn't instantaneous.
I worry about forcing a splash screen that announces "I'm using Tor!"
on the screen, but at the same time, it would let users know that tbb
is starting.

Once vidalia started, no one waited for tbb firefox to start, but
rather started their own browser and tried to use it.  Once tbb firefox
started up, in some cases, minutes later, they were confused.  Why
didn't tbb firefox start right away instead of this useless vidalia
control panel?  

A few of them felt the need to explore the vidalia control panel since
we showed it to them.  As if to say, 'there are buttons you are showing
me, I just click and explore.'

Once tbb firefox started, they were ok with using firefox over tor just
fine.  The first thing many of them did was to login to facebook or
gmail over tor to see if it was different.  None of them verified the
ssl cert presented for facebook or gmail logins.  For those that did
login to gmail, gchat didn't work due to the lack of Flash in tbb
firefox.  

We then tried to configure their chat clients for tor.  Adium on the
mac was fairly easy.  The variety of clients on windows wasn't so
easy.  A few wondered about logging in over ssl, but never did because
the services didn't offer it (aol, msn, gchat).  I showed the windows
people pidgin, but they liked their native apps and didn't see why one
multi-protocol app was better.  

The experience continued through pidgin with OTR, installing pgp for
email and verifying files, and a general talk about openssl
certificates, what they mean, and what verification of a cert entails.

The relevant tor experience was what I wanted to communicate and for us
to start thinking through ways to address it.  Perhaps Mike's desire
for a anonymous browser is a correct path for usability and better
anonymity for the user.  I believe torfox and torora have both come to
the same conclusion (at different times) as well.

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

Re: [tor-dev] The Torouter project - where are we now?

[andrew]

On Thu, Apr 21, 2011 at 07:15:17PM +0100, runa.sand...@gmail.com wrote 7.4K 
bytes in 195 lines about:
: My mistake. I thought someone had a bridge running and that the only
: problem was disk space. I'll see if I can set up my router as a bridge
: this weekend and get things working.

I did, on the buffalo.  It worked fine with a 1gb usb drive stuck in the
router.

: Sure, that would work. I believe users will have to re-flash their
: routers to install a new image, though. Or maybe there's a nice way to
: handle upgrades in OpenWrt?

99% of users are not going to reflash their router.  If it isn't a point
and click automatic update, it won't happen.  I hate reflashing openwrt
on the buffalo. 

: > That's similar to what I said on IRC; it seems reasonable to keep the
: > Tor package updated in OpenWRT. We need to decide if we want to build
: > regular packages for installation and also if we want to host them. I
: > think this is mostly an Erinn question - helix?

We can barely keep up with the current build load, nevermind adding new
operating systems.  

Torouter based on openwrt is an experiment.  It seems it's going to cost
us more time, effort, and people than we have to spare.  The entire
torouter, or bridge/relay-by-default in hardware, is an experiment.  

I'd much rather see a debian-based torouter exist.  We can more easily
integrate debian packages of the necessary architecture, likely ARM,
into our build farm than we can an entirely new OS and build
environment. 

The openwrt-based torouter can be a community-run and maintained
project.  I'd rather Tor Project spend its time and effort on making tor
work on debian-compatible low-cost hardware, like a dreamplug or excito,
than trying to force tor into a new OS and platform.

-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The Torouter project - where are we now?

[Andrew Lewman]

On Tue, 19 Apr 2011 11:17:17 +0100
"Runa A. Sandvik"  wrote:
> I am trying to figure out how we can move the Torouter project
> forward. In this email, I will try to summarize the current status of
> this project.

My general thoughts are that we figure out the web ui, a config that is
a bridge by default, and start sending some out to users to get some
real feedback.

> #2334: Torouter on Buffalo breaks with large cached-descriptors[.new]
> files. The quick and easy solution here is to attach a USB stick to
> the router and use it as Tor's data directory. However, it would be
> great if someone could take a look at this and figure out a way to
> solve it.

Shipping a beta test router with a 1 gb disk stuck in it isn't so bad.
Fixing tor to handle such a constrained environment is better, but
clearly longer term.

> #2376: Torouter on OpenWrt shouldn't have its data directory in /tmp/.
> The problem with having Tor's data directory in /tmp is that whenever
> Torouter is rebooted, Tor generates new keys and gets a new
> fingerprint.

I don't see this as a real problem, actually.  

> #2370: Torouter basic Web UI for OpenWrt. I haven't tried the web
> interface myself, but development seems to be moving along nicely. I'm
> not sure what the remaining steps are, other than packaging it as
> tor-ui (or similar) for OpenWrt.

A tor-ui for openwrt sounds good.


> 1. How can we make sure that the version of Tor in OpenWrt is always
> up to date? Should we set up our own OpenWrt repository? Right now,
> the version of Tor in OpenWrt is 0.2.1.26. Also, should we offer
> packages for both stable and unstable?

A tor openwrt package sounds good.  

> 2. We want to collect statistics, which means that we need to ship a
> GeoIP file as well. I'm thinking we should create a tor-geoipdb
> package for OpenWrt. Thoughts?

A tor-geoipdb package sounds good.

> 3. Do we want one Tor process for bridging and one for the transparent
> wifi network? I think this sounds good, if the router can handle it.
> If not, then just running a bridge is ok too.

I think starting with a bridge config is good.  Starting with
transparent tor wifi may be too much to start.  The original goal of
the router was to provide automatically configured bridges and relays
for people who want to help.

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

Re: [tor-dev] Thoughts on https://trac.torproject.org/projects/tor/wiki/dev/SupportPolicy

[andrew]

On Sun, Feb 20, 2011 at 06:29:55PM -0800, shamr...@cypherpunks.to wrote 3.6K 
bytes in 74 lines about:
: Either way, even more core to my advice than which particular OS
: versions to support (the one area where any dichotomy between open
: source and the commercial world may or may not come in) was my point
: that Tor needs a written and published OS support policy, agreed-upon by
: the Tor team. Whichever version support policy the Tor team may arrive
: at and for whatever reasons. And whether or not the Tor team takes my
: advice as to which particular versions to support.

We attempted to have a discussion about this over the past few days. I
think our best option, for now, is to simply state what we can build
ourselves, make these OSes our supported OSes, and encourage others to
make their own builds if their favorite OS is not officially supported.


-- 
Andrew
pgp key: 0x74ED336B
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] or-dev mailing list migration February 19, 2011

[Andrew Lewman]

And this is complete.  Mail archive migration is coming soon.

On Sun, 13 Feb 2011 21:37:20 -0500
Andrew Lewman  wrote:

> A reminder that this migration occurs this weekend.
> 
> On Mon, 24 Jan 2011 15:28:30 -0500
> Andrew Lewman  wrote:
> 
> > Hello or-dev subscribers,
> > 
> > On February 19, 2011, we are migrating or-dev from or-...@seul.org
> > to tor-dev@lists.torproject.org.  We will migrate your e-mail
> > address's subscription to the new list. You will receive a
> > confirmation from the new mailing list software on the 19th.
> > 
> > Current or-dev archives will be migrated.  Roger plans to leave the
> > current archives in place at seul.org as well.
> > 
> > We're using this migration to spread administration out to Tor's
> > sysadmin team rather than making Roger do everything himself.  The
> > secondary benefits of having the lists on the torproject.org domain
> > include SSL-enabled login, archives, and easier account management.
> > 
> > You can subscribe to the new list at
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> > 
> > I will send out a reminder on the day of the migration.
> > 
> > Please e-mail tor-assista...@torproject.org with any questions.
> > 
> > Thank you.
> > 
> 
> 
> 



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