Re: [tor-dev] Scheduled changes to Tor Metrics CSV files in the Performance and the Traffic category

[Griffin Boyce]

Thanks for the heads up 👍

On December 6, 2018 3:52:43 PM EST, Karsten Loesing  
wrote:
>Hi,
>
>if you're not pulling CSV files from the Tor Metrics website in an
>automated fashion, you can stop reading now.
>
>We just scheduled some changes to the Tor Metrics CSV files in the
>Performance and the Traffic category:
>
> - December 20, 2018 (scheduled): Remove source parameters and output
>rows with aggregates over all sources from Time to download files over
>Tor, Timeouts and failures of downloading files over Tor, Circuit build
>times, Circuit round-trip latencies graphs.
>
> - December 20, 2018 (scheduled): Remove two graphs Total relay
>bandwidth and Consumed bandwidth by Exit/Guard flag combination, and
>update the data format of the Advertised and consumed bandwidth by
>relay
>flag graph to cover all data previously contained in the first two
>graphs.
>
>For more details, see: https://metrics.torproject.org/stats.html
>
>I'm posting this note here, because some folks might pull these CSV
>files automatically, and they should have at least a two-weeks warning
>to update their scripts.
>
>All the best,
>Karsten

-- 
Transmitted via Minitel -- the New Wave in telephonics! ___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Flashproxy has been Deactivated by Stanford? Why?

[Griffin Boyce]

David Fifield wrote:

The reason I haven't asked people to stop running the flash proxy badge
is we're working on a new pluggable transport along the same lines but
without the usability challenges:
https://trac.torproject.org/projects/tor/wiki/doc/Snowflake. I was
thinking about adapting existing flash proxy badges to provide capacity
to Snowflake instead. This would go for Cupcake as well. The need to 
get

the badge running again hasn't been pressing because Snowflake isn't
deployed yet, but we're getting close.


  I'm working on incorporating Snowflake into Cupcake before Snowflake 
is added to Tor Browser.  Cupcake still has a flash proxy client (only), 
but obviously this is not particularly useful right now.  Not sure 
whether I'll just switch entirely to Snowflake or keep the legacy flash 
proxy support as an option in case it comes back into use.  The way it 
shook out, Cupcake users only wound up contributing ~6mb a day at most 
because there are many more Cupcake users than people who were using the 
flash proxy option on Tor Browser.  With Snowflake, the balance might 
shift a bit, so it will be interesting to see what happens there. =)


best,
Griffin

--
Accept what you cannot change, and change what you cannot accept.
PGP: 0x03cf4a0ab3c79a63
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Is it possible to leak huge load of data over onions?

[Griffin Boyce]

How do you transmit an elephant? One byte at a time...

But on a serious note, it's possible to transfer 2.6TB over Tor in small 
pieces (such as file by file or via torrent). Given the size, however, I'd 
suspect they mailed hard drives after establishing contact with 
journalists. Even on a fairly fast connection, 2.6TB would take quite a 
while...


~Griffin



--
On Sun, Apr 03, 2016 at 5:24 PM, Ivan Markin < t...@riseup.net 
[t...@riseup.net] > wrote:

Recently someone leaked enormous amount of docs (2.6 TiB) to the
journalists [1]. It's still hard to do such thing even over plain old
Internet. Highly possible that these docs were transfered on a physical
hard drive despite doing so is really *risky*.

Anyways, in the framework of anonymous whistleblowing, i.e. SecureDrop
and Tor specifically it's seems to be an interesting case. I'm wondering
about the following aspects:

o Even if we use exit mode/non-anonymous onions (RSOS)
is such leaking reliable? The primary issue here
is time of transmission. It's much longer than any
time period we have in Tor.

o What is going to happen with the connection after
the HS republishes its descriptor? Long after?
[This one is probably fine if we are not using
IPs, but...]

o Most importantly, is transferring data on >1 TiB
scale (or just transferring data for days) safe at
all? At least the source should not change their
location/RP/circuits. Or need to pack all this stuff
into chunks and send them separately. It's not
obvious how it can be done properly. So at what
point the source should stop the transmission
(size/time/etc)/change location or the guard/
pick new RP?

--
[1] http://panamapapers.sueddeutsche.de/articles/56febff0a1bb8d3c3495adf4/
--
Happy hacking,
Ivan Markin
___
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] Request for feedback/victims: cfc

[Griffin Boyce]

Yawning Angel wrote:

Inspired by https://trac.torproject.org/projects/tor/ticket/18361
I've been working on way to improve the situation.


  Neat. In the thread someone mentions that it's possible to derive the 
answer for the old-style street number captchas using tesseract [1]. 
Interestingly, there is a version of tesseract in javascript [2]. This 
is probably not especially useful for the current "select all boxes that 
contain one pixel of street sign" Recaptcha system, but if there were a 
way to trigger the old behavior, these techniques could be used 
together.


~Griffin

[1] https://trac.torproject.org/projects/tor/ticket/18361#comment:173
[2] http://tesseract.projectnaptha.com/

--
“Not having a clear goal leads to death by a thousand compromises.”
~ Mark Pincus
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] "Not our bug" bugs

[Griffin Boyce]

Hey all,

There have been quite a few bug reports that discuss incompatibility with
various Firefox extensions and with websites. In most cases, I can't 
replicate
these bugs -- either because the extension in question has been patched, 
the
website reported no longer exists, or the issue can't be replicated (which 
could

be due to site updates and past Firefox incompatibility).

Occasionally, the issue is real and still in effect, but isn't really a Tor 
bug
(such as #7279, where a forum restricts logins by Tor users). We've all 
worked

very hard to reduce overly-restrictive blacklist policies, but can't be
everything for everyone.

In these cases, I'd propose rejecting these bugs as either invalid or `not 
a
bug`. These are all varying degrees of "not our bug" or "actually not a bug 
at

all." Open to more thoughts on this.

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

Re: [tor-dev] Introducing Snowflake (webrtc pt)

[Griffin Boyce]

Serene wrote:

Q: Why is it called Snowflake?
There's a bunch of "ICE" negotiation happening for WebRTC, and it also
involves a great abundance of ephemeral and short-lived (and special!)
volunteer proxies...

Anyhow, if Snowflake seems like it would be useful / desired here, it
would be awesome if we had more help getting it stable, polished,
audited, deployable, etc...
Plenty of work to do!


  This is really great work, Serene ^_^  Once it is a bit more stable 
(and perhaps audited!), I'd be happy to incorporate Snowflake into 
Cupcake if that's useful.


  I am curious why you chose CoffeeScript for the proxy, rather than 
JavaScript.


woot,
Griffin

--
“I did then what I knew then, & when I knew better, I did better.”
― Maya Angelou
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] UX tag

[Griffin Boyce]

Georg Koppen wrote:

Nima Fatemi:

Lunar:

Tor Browser folks have been tagging tickets with tbb-usability:
https://trac.torproject.org/projects/tor/tags/tbb-usability

Do you want an extra tag for those?


This is a good question. I'm aware of tbb-usability tag and have 
already

added it to my filters; but I'm treating tbb team special and am not
sure if that's the right path to take with every component we have.


I don't know either but I'd prefer to have just the tbb-usability*
keywords for Tor Browser. As the asterisk already indicates we have a
more fine-grained keyword system tracking various areas where we need 
to

improve Tor Browser's usability and just using "UX" would blur lines


  I agree with this.  Keep in mind also that looking up "usability" as a 
keyword aggregates all of these tickets.  So if you wanted to make sure 
that UX-related tickets for the website get seen, making the keywords 
more granular but including usability wouldn't be a bad approach.


best,
Griffin

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

[tor-dev] Finding location metadata in large "dark market" datasets

[Griffin Boyce]

Hello all,

  I came across a blog post that might interest you all.  @techdad did a 
quick analysis of public images from online black markets (such as Silk 
Road et al)[2] from 2011-2015, and came to the following conclusion:


"After parsing hundreds of thousands of images, I came across about 37 
unique images that were not properly sanitized."[1]


  That's surprisingly low -- 0.00037% if one assumes 100k images 
analyzed.  Given the number of high-profile cases [4] where this 
location information led to arrests, it's not very surprising that some 
people likely took the time to remove the EXIF data, but I'm curious 
whether a given website may have stripped the metadata for uploaded 
images.  The images that tested positive are shown on the blog post, and 
8/37 were clearly from the same individual.


  When mapped out, the location data is primarily in the US (5 
locations), along with 1 location in France and Australia.


  Incidentally, the full 1.6TB dataset from 2011-2015 is available on 
the Internet Archive [3], just in case the Hacking Team disclosures 
haven't used up all your hard drive space. ;-)  This data on its own is 
a rather interesting look into the workings of black markets -- many of 
which no longer exist.  Curious to see what you all think and what 
analyses you'd like to see from this kind of data.


best,
Griffin


[1] http://atechdad.com/Deanonymizing-Darknet-Data/
[2] http://www.gwern.net/Black-market%20archives
[3] https://archive.org/details/dnmarchives
[4] 
https://www.eff.org/deeplinks/2012/04/picture-worth-thousand-words-including-your-location



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

[tor-dev] Stormy update

[Griffin Boyce]

Hey all,

  It seems like time to give the tor-dev list an update on Stormy's 
development.  Right now, the scripts are undergoing third-party testing 
to identify any obvious bugs before sending them to security auditors.  
Testing should be finished imminently, any bugs found will be fixed this 
week, and then sent to auditors (along with the GUI).  The security 
audit may take about two to three weeks [1].


  Currently, Stormy's functions include installing typical onion service 
dependencies (webserver+tor), setting up a Ghost-based content 
management system, creating a personal cloud server to handle files/rss 
feeds/calendars/tasks, installing an XMPP/jabber server for private 
communications, and installing an IRC server for group communications.


Shortcomings and future work:
  Like all software projects, Stormy has some shortcomings.  Users can't 
configure multiple onion services on the same machine as Stormy doesn't 
account for virtual hosts.  For users to run more than one onion 
service, they must be on separate physical or virtual machines.  Stormy 
also doesn't detect the currently-running clearnet service, so users who 
seek to make their existing service also an onion service may need to 
adjust their configuration manually.  Currently, Stormy lives on my 
github page [2], though once it passes a security audit, the goal is for 
it to live within Tor's git repositories.


best,
Griffin

[1] Cupcake's audit took about two weeks, so that's really my only real 
data point for audit timing.

[2] https://github.com/glamrock/stormy

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] The future of GetTor

[Griffin Boyce]

ilv wrote:

With this in mind, we have been discussing about the idea of having a
signed and verified distributor app (desktop), available on official
channels (OSX app store, Google Chrome store, etc), which could ease 
the

process of downloading and verifying the integrity of Tor Browser. In
other words, a user should be able to download and make sure it has the
right file with just a few clicks.


  While I don't necessarily want to discourage you from working on 
GetTor, it's worth noting the duplicated effort in terms of distribution 
apps.  My primary project makes downloading Tor (and other privacy 
software) from un-censored sources easy, verifying sha256 hashes easy, 
along with distributing tutorials and bridges [1][2].


  The project is called Satori -- it's under heavy development, but has 
traction, particularly in Iran and China [3].  Satori comes partly from 
the fact that I don't scale -- 1-to-1 distribution is important but 
takes a lot of time and a handful of trainers can't help everyone.  So I 
can write applications and increase my positive impact (particularly 
once guides are included and translations are finished).  Downloads are 
via accessible CDNs and torrents.


  To answer your questions:  1) distributors are important IMO (see 
above).  2) I've always liked the idea of email autoresponders for 
software, but as the size of the Tor Browser increases, I'm not sure how 
viable it will be.  It may be worthwhile to experiment with sending 
unblocked CDN links and torrent files.  3) I considered an API but don't 
think it would work as it just recreates the single point of failure 
that one is trying to avoid with this kind of project.  At least for me, 
the focus on CDN and bittorrent-based software distribution make the 
most sense.


best,
Griffin

[1] http://imgur.com/a/EIR80
[2] https://github.com/glamrock/satori
[3] [the Chrome version's been out for more than a year]

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Summary of meek's costs, April 2015

[Griffin Boyce]

Mike Perry wrote:

David Fifield:

Here's the summary of meek's CDN fees for April 2015.

total by CDN  $3292.25 + $3792.79 + $0.00 = $7085.04 grand total
https://metrics.torproject.org/userstats-bridge-transport.html?graph=userstats-bridge-transport&start=2015-02-01&end=2015-04-30&transport=meek


Yikes! Are these costs covered by a grant or anything? Should we be
running a donations campaign?


If you want to help reduce costs, you can
 1. Use meek-azure; it's still covered through a grant for the next 
four

months.
 2. Set up your own App Engine or CDN account. Then you can pay for 
your

own usage (it might even be free depending on how much you use).
Here are instructions on how to set up your own:
  
https://gitweb.torproject.org/pluggable-transports/meek.git/tree/appengine/README
  
https://trac.torproject.org/projects/tor/wiki/doc/meek#AmazonCloudFront
  
https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure

Then you will have to enter a bridge line manually. Follow the
instructions at
  
https://trac.torproject.org/projects/tor/wiki/doc/meek#Howtochangethefrontdomain

but instead of changing the "front=" part, change the "url=" part.
For example,
  bridge meek 0.0.2.0:1 url=https://.appspot.com/ 
front=www.google.com


Please let me know if anyone takes you up on this!

I am happy to add the meek bridges of anyone who does this as an option
in Tor Browser. We can add logic to round robin or randomly select
between the set of meek providers for a given meek type upon first
install, or even for every browser startup.


  If there were some randomization logic included, I'd be happy to 
contribute an App Engine or Amazon meek access point.  If a few people 
did that, the costs might be more manageable.  But also the stats might 
be a bit harder to aggregate (which might be important if David is 
writing a thesis/paper/etc).


  Either way, way to go =)

best,
Griffin

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Urdu & Hindi translations of Tor browser ?

[Griffin Boyce]

Sukhbir Singh wrote:

I am sure other users
from India/Pakistan can back this up, but personally, even though my
native language is Punjabi and Hindi, I have always selected "English"
when installing Debian. Similary, I have almost never seen a copy of
Windows in any of the local languages, anywhere in India.

The English precedence is slowly changing though, with more and more
technology products being shipped in local languages so that they can
reach populations that don't speak English (which is more in number 
than

the population that can.)


  These are great points, and the perspective is critical.  It's worth 
noting I only speak English and by necessity only interact with people 
who also speak English.  So frequently I have to wonder how that shapes 
my perspective and whether various users might have unmet needs.  
Whereas in your case, you've lived in some of these areas and speak 
Hindi so have a more realistic idea of what might be useful in India.



So while my experience with this has been different from Griffin's in
that no Tor user in India has asked me for a translation in their local
language, I think the simple reason may be that English-speaking
population doesn't feel the need and right now, they are the ones that
dominate the online market. Not that this is an excuse for not having
local translations, but I am stating the probable reasons for the lack
of translations.


  Those who've approached me about Urdu have been trainers from 
Pakistan, and I'd imagine that as you say they are hoping to reach more 
users who don't speak English.  But I'm not actually sure how to really 
measure need based on these individual interactions.


best,
Griffin

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Urdu & Hindi translations of Tor browser ?

[Griffin Boyce]

David Fifield wrote:

Griffin Boyce wrote:
  Both populations also have a large number of speakers: ~300M for 
Hindi

and ~66M for Urdu.


I was really surprised; Hindi is the third-most spoken language in the
world, trailing only Mandarin and English. Of the top 10 languages in
this Wikipedia list, Tor Browser is missing localizations only for
Hindi, Bengali, and Malay. (Urdu is #11.)


  Yes, and Firefox has localized versions for Bengali(bn-IN), Bahasa 
Indonesia, Malay, Hindi, and Urdu.  So the strings to translate would be 
only for the Tor-specific interfaces.


  I guess what I'm really asking is what's the process for supporting 
additional languages?  Would adding additional languages add too much 
overhead to release cycles?


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

[tor-dev] Urdu & Hindi translations of Tor browser ?

[Griffin Boyce]

Hello all,

  Whenever I attend events with a large Pakistani or Indian contingent, 
I'm asked why there isn't an Urdu or Hindi translation of Tor Browser.  
And I'm not totally sure what to say.  There's clearly a large need, 
given Pakistan's history internet censorship.  At a recent event in DC, 
an activist from Pakistan spoke with me about increased surveillance in 
recent years, as well as the shocking trend of targeting activists with 
charges of blasphemy for criticizing the government.  (Blasphemy is 
punishable by death, and those accused frequently do not survive until 
trial due to mob violence).


  The situation in India is a bit different, but their need for online 
privacy much the same as like Pakistan they are subject to mass 
surveillance.


  Both populations also have a large number of speakers: ~300M for Hindi 
and ~66M for Urdu.


  What do you think?

~Griffin

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Please vote on times for the Pluggable Transports, Bridges, and BridgeDB Meeting!

[Griffin Boyce]

So, just to clarify, this would be 10pm EST on Tuesday or Wednesday 
night, correct?


~Griffin


On 2015-04-06 16:31, Brandon Wiley wrote:

I can't do 0200 UTC on Wednesdays. I could potentially do 0200 on some
Thursdays.

On Mon, Apr 6, 2015 at 3:06 PM, isis  wrote:


Last chance. http://doodle.com/tn28wgzw8iydpznp [1]

We're currently leaning towards 0200 UTC on Wednesdays. If this
doesn't work
for you, now's your chance to Rock The Vote™ or whatever.

I should mention that Yawning and I are both entirely willing to
switch to a
different day; please let either of us know if this would help with
scheduling
in any way.

isis transcribed 2.6K bytes:


Hello!

Did you have an interest in attending the Pluggable Transports

Meeting v1.0?

Well then, you will certainly be excited to here about the *BRAND

NEW*

Pluggable Transports Meeting v2.0

*NOW INCLUDING DEVELOPMENT DISCUSSION OF BRIDGEDB AND BRIDGES IN

GENERAL*


That's 3 meetings for the price of 1!! Wow!!!

Please take a moment away from your undeniable shock and ecstatic

joy at this

great news to vote for a new time for this combined meeting:
http://doodle.com/tn28wgzw8iydpznp [1]

Thanks!


--
♥Ⓐ isis agora lovecruft
_
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt [2]

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




Links:
--
[1] http://doodle.com/tn28wgzw8iydpznp
[2] https://blog.patternsinthevoid.net/isis.txt
[3] 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


--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] #15060: Decide the fate of MyFamily / prop242 better families

[Griffin Boyce]

So, what do we think?  I'd say that MyFamily is likely to continue to


MyFamily is also critical for people who are running a lot of relays.  
It's ideal to list keys, but in a scenario where I run two dozen relays 
or more, having a good shorthand for them would make it easier to group 
them.


~Griffin

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] thanks redditt

[Griffin Boyce]

Tyrano Sauro wrote:

This is funny


  Oh, I agree :D  There was an outtake where Karen (development 
director) was walking around with a tiny orange tree saying "Orange 
Routing! Orange Routing!" It was pretty great ^_^


~Griffin

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tor Browser sha256 checksums for old versions?

[Griffin Boyce]

David Fifield wrote:

I don't know if there's a place where they're all in a single file, but
you can get them for historical releases here:

https://archive.torproject.org/tor-package-archive/torbrowser/


  Thanks!  That's perfect :D  Satori's new version will detect version 
based on the hash.  I'm only looking to go back to v3.5 (Dec 2013) right 
now, but might add more back to Jan 2012.  The version numbers get kind 
of annoying if you go back to v2.2.35-4, and people are less likely to 
be using those old versions, but it would be good to trigger a warning 
to download the new Tor Browser.


best,
Griffin

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tor Browser sha256 checksums for old versions?

[Griffin Boyce]

Hey all,

  I was just wondering if it's possible to get a gpg-signed list of 
sha256 checksums for the Tor Browser.  The website only shows the 
current version's list of hashes.  Which is really useful, but it would 
be great to have them all if possible.


thanks,
Griffin

--
“Sometimes the questions are complicated and the answers are simple.”
― Dr. Seuss
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Research repository [was: Master's Thesis]

[Griffin Boyce]

grarpamp wrote:
Is there a project to collect, index and archive all the relevant 
papers

from all the various internet sites, homepages, anonbib, etc... into
one central, easily mirrored and referenced repository? git would
seem more useful for this than the various disparate http resouces
of uncommon design. If the fame of the original site is needed that
would be included in the commit or a per paper paired metadata file.
This model could be extended to multimedia formats of papers via
rsync, with the index being git'd. The index itself could of course
be stored in git in html format to point browser at locally, or even
remotely over gitweb as the possible internet frontend.

There may be volnteers on tor-talk if fwd there.


  I whipped up this github repository, based on anonbib.  Anonbib is the 
most in-depth project for cataloging these kinds of papers, so 
contributing new entries there is probably your best bet.  However, if 
people submit issues or pull requests to my repo, I'll send a bibtex 
entry to anonbib.


  The readme probably still has some errant formatting errors: 
https://github.com/glamrock/anonbib


that was a fun distraction,
Griffin

--
"Cypherpunks write code, not flamewars."
~Jurre van Bergen

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

Re: [tor-dev] Distributing TBB and Tails via Torrents

[Griffin Boyce]

SiNA Rabbani wrote:

We can also use S3's bit-torrent feature:
http://docs.aws.amazon.com/AmazonS3/latest/dev/S3Torrent.html It's
relatively painless. Tor has its own Amazon account, I am also more
than happy to provide my own S3 for to mirror Tor's binaries.


Hi Sina,

  Thanks for this - I actually did not know about this feature.  I have 
a long list of trackers that I want added, so this might not be an ideal 
long-term solution.  Though right now I'm distributing via S3 directly.


~Griffin

--
"The apparent safety of modern life is just a shallow skin atop
an ocean of blood, guts and bricked devices."
~Pearce Delphin

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

Re: [tor-dev] Distributing TBB and Tails via Torrents

[Griffin Boyce]

Fabio Pietrosanti (naif) - lists wrote:

On 12/10/14 7:53 PM, Chuck Peters wrote:
The torrent files are available through https with a valid 
certificate.

We would love to distribute Tor Browser Bundle via Tor2web, useful for
specific use-cases:

https://github.com/globaleaks/Tor2web-3.0/issues/168


  It's on the roadmap for the next Satori release.  I've distributed Tor 
Browser and Thunderbird via torrents in the past few months, but am keen 
to automate torrent creation since there are 60 separate TBB files (plus 
GPG signatures) for each release.  Right this moment, don't have the 
time to keep up with that.  January there should be a semi-automated 
system in place to release updates as torrents.


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

Re: [tor-dev] Stormy - request for feedback

[Griffin Boyce]

Hey all,

  Sorry for the delay in responding -- comments inline.

Fabio Pietrosanti - lists wrote:
I would suggest to add a Tor2web policy that, looking at X-Tor2web: 
HTTP

header, enable or disable access to the Blog trough he internet:


  What is your reasoning for disabling access via tor2web?


You may also consider adding support for Ahmia directory index


  This seems reasonable =)  Added as a task.

Nicolas Vigier wrote:

So I am thinking that an other way to do it could be to write a few
ansible modules (or modules for your favorite configuration management
tool) for the various tasks currently done by the script (installing
nginx, installing a blog software, setup a hidden service, configure
the firewall, etc ...), or take existing modules if they do what is
needed.


  I've been considering creating ansible modules to make it easier to 
deploy for some people.  An organization reached out who wants to offer 
it in-house as some kind of enterprise service, which has reignited the 
discussion.



Then write a GUI program that will ask some questions, and when
you click on the "setup" button generate an ansible variables file
containing the answers to those questions (variables which are used by
the ansible modules), and run ansible to apply the changes on the 
system.


  Lots of people would like a GUI, which would make it much easier to 
deploy, but I always recommend that people segregate their hidden 
services (and websites) from their personal machine.  I might be slowly 
changing my mind on GUIs for a number of reasons.  It's still not a good 
idea to run on one's personal machine if there is a large risk 
associated with being personally linked to running a particular hidden 
service (eg, Muslims in Myanmar should host in a VM or a dedicated 
machine). But this may be a case where more users would be better served 
by having a gui than the fairly mild risk of someone running a service 
on their personal machine.


  And a GUI would be great for people who want to run a hidden service 
using Tails.  =)


Patrick Schleizer wrote:

I think it's non-ideal to modify config files using cat/sed/echo. That
breaks sooner or later. And if later settings are supposed to be 
changed

in the same file, things get messy. Some suggestions...

It would be better to put the config files into (debian) packages.


  While this is true for popcon, this is not possible for most config 
files being edited.  The most critical edits require the onionsite 
address, which of course has to be generated by each user on their own.


  It's possible for debian and ubuntu packages to list package 
conflicts, which would be much better than rolling up custom packages 
that only exist to remove another.


Please consider to set timezone to UTC. Perhaps use the timezone-utc 
[2]

package?


  Tor requires an accurate clock to work properly.


You're sure you're not inventing a new linux distribution here? :)


  Quite sure ;-)  There's a real risk in trying to be everything to 
everyone.  Not only does everything have to be created and documented, 
but maintained long-term.  Bash scripts are straightforward for these 
tasks, as is ansible, VMs much less so, and GUIs very difficult.


best,
Griffin


--
"The apparent safety of modern life is just a shallow skin atop
an ocean of blood, guts and bricked devices."
~Pearce Delphin

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

[tor-dev] Stormy - request for feedback

[Griffin Boyce]

Hello all,

  So as some of you know, I've been working on installers for hidden 
services, to ideally make very common services (such as blogs and plain 
websites) easy to deploy and automatically update.  This is a very rough 
version of the one-click hidden service installer, but I'd love to get 
feedback on places where it breaks and where it could use a major 
structural change.


Script is here, please feel free to flag bugs or tell me how I'm doing 
it wrong:

https://github.com/glamrock/Stormy/blob/master/one-click-blog.sh

Q: Can I use this right now to set up a hidden service?
A: Please don't use this in production until firewall settings are in 
place.


Q: Are there firewall settings in place?
A: Not yet - the current setup is entirely for development and should 
not be used as-is.


best,
Griffin

--
"I believe that usability is a security concern; systems that do
not pay close attention to the human interaction factors involved
risk failing to provide security by failing to attract users."
~Len Sassaman
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Of CA-signed certs and .onion URIs

[Griffin Boyce]

Fair. What are your thoughts about possible trade-offs with anonymity when 
using a CA-signed cert?


On November 14, 2014 9:38:02 PM EST, Jacob Appelbaum  
wrote:
>On 11/15/14, Griffin Boyce  wrote:
>> Lee wrote:
>>>> c) Get .onion IANA reserved
>>>
>>> It doesn't look like that's going to happen.
>>
>>Yeah. Though the biggest use-case for cert+onion is when trying to
>> match a clearnet service to a hidden service -- such as Facebook or
>> Erowid.
>>
>
>That is false. Using TLS has many use-cases - one that is critically
>important is stronger defense in depth.
>
>All the best,
>Jacob
>___
>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] Of CA-signed certs and .onion URIs

[Griffin Boyce]

Lee wrote:

c) Get .onion IANA reserved


It doesn't look like that's going to happen.


  Yeah. Though the biggest use-case for cert+onion is when trying to 
match a clearnet service to a hidden service -- such as Facebook or 
Erowid.


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

Re: [tor-dev] Hidden Service authorization UI

[Griffin Boyce]

On 2014-11-09 15:30, Fabio Pietrosanti - lists wrote:

On 11/9/14 8:58 PM, Jacob Appelbaum wrote:

For example, it would be interesting if TBB would allow people to
input a password/pubkey upon visiting a protected HS. Protected HSes
can be recognized by looking at the "authentication-required" field 
of

the HS descriptor. Typing your password on the browser is much more
useable than editing a config file.

That sounds interesting.


Also i love this idea but i would suggest to preserve the copy&paste
self-authenticated URL property of TorHS, also in presence of 
authorization.


  I'm conflicted about this idea.  Much better for usability ~but~ there 
should be an option for authenticated hidden services that want to *not* 
prompt and instead fail silently if the key isn't in the torrc (or 
x.y.onion url, depending on the design).


  Use case: if someone finds my hidden service url written in my planner 
while traveling across the border, they might visit it to see what it 
contains. If it offers a prompt, then they know it exists and can press 
me for the auth key (perhaps with an M4 carbine).  If there's no prompt 
and the request fails, then perhaps it "used to exist" a long time ago, 
or I wrote down an example URL.


best,
Griffin

--
"I believe that usability is a security concern; systems that do
not pay close attention to the human interaction factors involved
risk failing to provide security by failing to attract users."
~Len Sassaman
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hidden Service authorization UI

[Griffin Boyce]

So most of my work over the next three days is writing and editing 
documentation on hidden services. 

I'm in Boston and the purpose of this trip is to rewrite existing documentation 
to be more useful, but with authenticated hidden services, what's available is 
extremely sparse. GlobaLeaks and SecureDrop have good authenticated hidden 
service setups (and good use cases for them). A friend of mine uses an 
authenticated HS for his personal cloud.  More secure for him than logging into 
DropBox, etc. So they're also useful for mere mortals like us. ;-) 

Is there something you need/want in terms of documentation.

best,
Griffin

PS: yes I'm aware of the hilarious timing of this trip.


On November 9, 2014 7:50:00 AM EST, George Kadianakis  
wrote:
>Hidden Service authorization is a pretty obscure feature of HSes, that
>can be quite useful for small-to-medium HSes.
>
>Basically, it allows client access control during the introduction
>step. If the client doesn't prove itself, the Hidden Service will not
>poroceed to the rendezvous step.
>
>This allows HS operators to block access in a lower level than the
>application-layer. It also prevents guard discovery attacks since the
>HS will not show up in the rendezvous. It's also a way for current
>HSes to hide their address and list of IPs from the HSDirs (we get
>this for free in rend-spec-ng.txt).
>
>In the current HS implementation there are two ways to do
>authorization:
>https://gitweb.torproject.org/torspec.git/blob/HEAD:/rend-spec.txt#l768
>both have different threat models.
>
>In the future "Next Generation Hidden Services" specification there
>are again two ways to do authorization:
>https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/224-rend-spec-ng.txt#l1446
>One way is with a password and the other is with a public key.
>
>I suspect that HS authorization is very rare in the current network,
>and if we believe it's a useful tool, it might be worthwhile to make
>it more useable by people.
>
>For example, it would be interesting if TBB would allow people to
>input a password/pubkey upon visiting a protected HS. Protected HSes
>can be recognized by looking at the "authentication-required" field of
>the HS descriptor. Typing your password on the browser is much more
>useable than editing a config file.
>
>Furthermore on the server-side, like meejah recently suggested [0], it
>would be nice if there was a way for HSes to be able to dynamically
>add/remove authorized clients using the control port.
>
>[0]:
>https://lists.torproject.org/pipermail/tor-dev/2014-October/007693.html
>___
>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] Potential projects for SponsorR (Hidden Services)

[Griffin Boyce]

Roger Dingledine wrote:

h) Back to the community again. There have recently appeared a few
   messaging protocols that are inherently using HSes to provide link
   layer confidentiality and anonymity [1]. Examples include Pond,
   Ricochet and TorChat.


  There are also a fair few IRC and XMPP servers floating around 
onionland (and soon to be many more via Stormy).  I'm also really 
curious what the impact that Pond would have on the HS landscape if it 
become popular.  Right now, there are probably only a handful of people 
who run their own independent Pond HS, but that could change.


  There's also onionshare, which creates hidden services as-needed -- 
which are typically discarded after sharing a single file one time.



   It might be worth researching these use cases to see how well Tor
   supports them and how they can be supported better (or whether they
   are a bad idea entirely).


Yes. My guess is that it's lightweight to establish a circuit with each
of your friends, and then when it goes away you try to reestablish it
and if you fail then your friend is probably gone. And my guess is that
it's heavyweight to try rendezvousing with each of your friends every
5 minutes to see if they're still there.

We should put up some guidelines for eco-friendly use of hidden 
services

in this situation.


  Scott Ainslie and I came to the conclusion that two one-way video 
conversations over hidden services is a pretty decent replacement for 
Skype etc[2].  At a really crude level, this can be achieved using 
gstreamer (maybe with FreeNote[1]) and then sharing the hidden service 
addresses with each other.  Some assembly required, obviously.  It's my 
undying wish that someone create a proof-of-concept app for this using 
gtk or kivy or something.



== Opt-in HS indexing service ==

The question of whether this has to be built-in is a fine one to
explore. I bet we'd get more people doing it if it were just a torrc
option that you can uncomment. But it also seems inherently less safe,
since it might mean more publishings by your Tor than the human would 
do.


  It would definitely get more opt-ins than if there were additional 
steps.  There's a measure of informed consent there, because if you are 
opting in intentionally, then you are saying that you want your hidden 
service publicized.  Any given person running a library or art project 
might think "Oh nobody cares about my hidden service" and not bother 
going through additional steps, but would be perfectly happy to have 
more people look at their work.


  The question, to me, is how to frame the torrc option so as to make 
sure people know it's optional.



- #8902 	Rumors that hidden services have trouble scaling to 100 
concurrent connections


  I've been curious about this ticket for a while, and happy to 
structure&run a follow-up test on a controlled server.  Since the 
original problem was with an IRC server, it makes sense to set one up 
for the purposes of a test, and then set up a secondary machine for 
'user' connections and an extra monitoring point.


  I suspect that there are other factors that might have influenced that 
report.  Could it be an issue with one of the intermediary points?  
There certainly *seem* to be tons of people using the OFTC hidden 
service, but that could be perception (ie, still <100 concurrent users).




What useful projects/tickets did I forget here?


1) We should identify and describe the great use cases of hidden 
services,

especially the ones that are not of the form "I want to run a website
that the man wants to shut down."


  One thing that is interesting: in practice, onionshare (RetroShare et 
al) winds up being easier than trying to share a file with a friend 
using third-party services.  Particularly for large-ish files or 
something where you want some measure of privacy (ohai dropbox), sending 
it to a third-party and then making it available to your friend and then 
deleting/hiding it again is a little annoying.  (And there are of course 
privacy and cost tradeoffs with this as well).


  People like to set up private IRC & Jabber chats to chat without 
attracting trolls and spambots, and get an extra layer of encryption 
from Tor.


What sorts of hidden service examples are we missing from the world 
that

we'd really like to see, and that would help everybody understand the
value and flexibility of hidden services?

Along these lines would be fleshing out the "hidden service challenge"
idea I've been kicking around, where as a follow-up to the EFF relay
challenge, we challenge everybody to set up a novel hidden service. We
would somehow need to make it so people didn't just stick their current
website behind a hidden service -- or maybe that would be an excellent
outcome?


  This could be fun. =)  We could put out a blog post when Stormy 
reaches 1.0 about this too.



there is a lot of, shall we call it, dark matter in hidden service
space. What are some safe ways we can improve 

Re: [tor-dev] Scaling tor for a global population

[Griffin Boyce]

  I'd say that the idea to 'downgrade' people into being bridges is a 
good one, if done without requiring user input.  'Everyone run a relay' 
might only be useful because so many of the people we say it to have 
fast connections.  It seems reasonable to filter out persistently low 
connections (and allow them back in if their connection speed improves). 
 That is not to say that every potential bridge should actually be 
accepted as a bridge.  The 28B/s bridge is nuts - either it's on an 
embedded device or their torrc is misconfigured.


  What I usually recommend is to users is based on their bandwidth and 
how frequently their IP changes.  If their connection is fast and their 
IP never changes (eg, a desktop or server), then run a non-exit relay 
[2].  For a laptop that moves to-from work, then a relay or bridge.  If 
it moves a *lot*, use Cupcake (which is a wrapper for flashproxy).  
Running a relay on a raspi or a router (?!) is not a great idea -- 
though people attempt both.  If things could gracefully switch from 
being a relay to a bridge based on their speed, then that would actually 
make it more straightforward for users because they don't have to worry 
about whether they should be a bridge or relay.


  People can't really estimate their own bandwidth without something 
like NDT, but they have an idea of how fast it is. eg, this connection 
is 21Mb/s up, 6mb/s down, but that's mostly irrelevant because my 
perception of it is that it's Fast.  That perception would be the same 
if I were getting 2Mbp/s up/down.  So maybe one non-technical change we 
can make is to user education and website documentation -- run a relay 
if you have a Fast connection.


  Filtering people out based on advertised bandwidth is tricky - 
advertised bandwidth is only useful if it's based on reality.  250kb/s 
seems like a reasonable floor for both relays and bridges.  100kb/s is 
kind of the sanity check for a distributed bridge - if it's below that, 
it's not useful enough IMO.


  The real questions for me are: how much of a gain is possible? and 
what is the right balance between number of relays and speed of those 
relays?  and I suspect that until something is tried, it may just be 
speculation.


best,
Griffin

[2] No one should be running an exit from home, and no one who is asking 
me about this at an event should be running an exit.



--
"I believe that usability is a security concern; systems that do
not pay close attention to the human interaction factors involved
risk failing to provide security by failing to attract users."
~Len Sassaman
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Making and distributing custom TBB with a new "home-page"

[Griffin Boyce]

On 2014-09-21 11:32, Fabio Pietrosanti (naif) wrote:
Have you considered just distributing Tails USB sticks along with the 
.onion

address on a piece of paper?


We've considered it, but it was outside the logistically doable
opportunity, as far as i understood.

Sounds like the most "apparently obvious" solution for our community,
are not so easily applicable in that context of use by speaking with 
the

end-users.


  Yeah, even if you distributed DVDs with the .onion address written on 
it, there's still a trail leading from them to you (however tangential). 
 Better for press organizations to provide potential whistleblowers with 
easily-understood documentation and try to be as pervasive an option as 
possible.


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

[tor-dev] Debian popcon as a vulnerability?

[Griffin Boyce]

Hello all!

  I am wondering whether to force-uninstall Debian's popularity-contest 
package as part of Stormy's installation process. It would be good to 
have an idea how popular Stormy is, but on the other hand, I'm not sure 
how anonymous the reporting is on Debian's end.


  This is also relevant for users of the tor package, who might also be 
at mild risk (though far less so because the number of users is so high, 
and doesn't reveal location of location-hidden services).


  Anyone have opinions on this? I'm leaning towards checking if 
popularity-contest is installed and then asking if the user would like 
it to be removed.  If y'all have other recommendations, please comment 
here or on the ticket.


Ticket: https://trac.torproject.org/projects/tor/ticket/13154

thanks!
Griffin

--
"I believe that usability is a security concern; systems that do
not pay close attention to the human interaction factors involved
risk failing to provide security by failing to attract users."
~Len Sassaman
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Decentralized VOIP (or video chat) over Tor

[Griffin Boyce]

  This is similar, though not *quite* the same.  A while back ioerror 
released FreeNote[1], which makes it easier to broadcast audio and video 
on a hidden service.  This is a pretty cool idea and works pretty well.  
AND it should be pointed out that two one-way conversations can be a 
two-way conversation by virtue of just sharing the links over OTR [2].


  Scott Ainslie and I discussed the possibility of taking that basic 
two-way conversation hidden service concept and making a GUI for it with 
Glade+GTK.  Unfortunately, neither of us really have the time or 
expertise for this endeavor.  I got as far as wireframing some ideas 
before going face-first into developing a more time-sensitive project 
[3].  I'd love it if someone actually did this and released their 
prototype as free software.  There are way too many issues with 
centralized services like Skype and Google Hangouts.[4]


best,
Griffin


[1] https://github.com/ioerror/freenote
[2] Of course, if someone shares the links further, there can be privacy 
issues.

[3] Satori: https://github.com/glamrock/Satori
[4] and jitsi never recognizes my fucking microphones =/

On 2014-08-15 21:43, Jordan wrote:

Hi, terryz,

Thanks for the idea! Today I was actually wondering if *video* were 
possible,

too. :-D

Guardian project has [Ostel](https://guardianproject.info/apps/ostel/). 
Is
that what you're wanting? If not, was there a feature you were wanting 
from

Ostel or another application that has features that Ostel doesn't?

As for "decentralized," I think the whole point of tor is that tor 
itself is

decentralized. Check out [Running a relay]
(https://www.torproject.org/docs/tor-doc-relay.html.en) to see how this 
works.


Again, thanks for the input! :-D

On Friday, August 15, 2014 05:53:44 PM ter...@safe-mail.net wrote:

Hi,

I'm interested an anonymous decentralized VOIP network on Tor. All 
traffic

routed through Tor. Every Tor user being an optional server for PTT or
Continuous Speech.

How feasible does this sound?


--TZ
___
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] Email Bridge Distributor Interactive Commands

[Griffin Boyce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Lunar wrote:
> We can't just make Tor Browser stop accepting obfs2 because some
> people are using obfs2 bridges right now. But we shouldn't add more
> people to the set of users of a broken protocol.

  We should really be reaching out to those running obfs2 nodes and
convincing them to move to obfs3 if at all possible.

  Related question: are there geographic areas where standard bridges
are being blocked, where obfs2 are still usable?  If so, maybe in the
future it would be possible to restrict distribution of remaining
obfs2 bridges to those areas.  But on the whole I agree that giving
those out is problematic.  Unless they comprise a large portion of
bridges, maybe it's time to phase them out of bridgeDB (not
necessarily TBB).

best,
Griffin

- -- 
Wherever truth, love and laughter abide, I am there in spirit.
- -Bill Hicks
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJT0f/jAAoJEAPPSgqzx5pjSn0IAIpa7EY0si58vgM61Zqzt3Fi
qCICh7CMpLBWJqWJVF+1kv09L+28ZEsGkrvR+9nzjmd2lOAUJZvtgvOMgv81YTUc
jPF+ZhvAwh0vdyvk0ANmncO3uI7yBN6Xsxam6iIjERksLRwgPfxJNLwdGYC2235J
eKVVWmlQpvLW1oTsnUU1Gw/5rChIYMnsJisUDeVoz/yJ3HAl5hCqjdSwXVAmzdjJ
P0cR7034iLfhnYotVfeDpyxUwrNp6yFeE2b8QcZVlLjW0pTPUMXMmwJ73GQ9egIp
KLqKq0RcUPijoNLI0AIt8aZGm40FV0gixGbxWl2AvSr1wIWqt2jIB7nBGvZdHfg=
=0jn8
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Email Bridge Distributor Interactive Commands

[Griffin Boyce]

isis wrote:

Do you have a better suggestion for what to call "vanilla bridges"?


  I keep calling them standard bridges (as opposed to fancy, 
monocle-wearing bridges).  People seem to understand immediately that 
other types of bridges are special somehow if I call 
regular/vanilla/non-obfs bridges Standard.  And then I explain how obfs 
bridges and flashproxy are used in different circumstances.


  Also, I vote that we ditch the 'obfs' name from obfs5 and beyond in 
favor of 'crypto-voltron.'  This will also make user education 40% more 
awesome.


  As an aside, I'm happy that 'huggable transports' [1] is a thing now 
:D


best,
Griffin

[1] https://twitter.com/abditum/status/431665969627672576
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Torspec proposal for adding new X- fields to relay descriptor

[Griffin Boyce]

In addition to explicitly forbidding newlines, perhaps it would be a good idea 
to either strip them entirely or ignore any value with a newline.
-- 
Sent from my tracking device. Please excuse brevity and cat photos.___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Cute Otter == Tahoe-LAFS + Tor?

[Griffin Boyce]

Leif Ryge wrote:

I think the idea would be to have a web publishing app which doesn't
necessarily expose Tahoe-LAFS to users directly, but rather just has a
"Publish" button which uploads to it.


  That would be really cool =)  The URL problem is still a problem, but 
for use cases where url memorability isn't a factor, it would probably 
be fine.  (Such as Crabgrass instances where people are organizing 
rather than sharing files, or where visitors are mostly following links 
from the front page.



What properties does stormy provide? Can I read about it somewhere?


  The original roadmap/code repo is Github[1].  The project has expanded 
rather a lot, and I'm happy to talk about it off-list sometime. =)


  The basics: a command line wizard that guides users through the 
install process, adds keys, performs critical server hardening (that 
most users currently don't do), sets up unattended security updates, 
sets up their platform of choice[2], sets up the Tor portion & torrc, 
sets up regular backups, sets up all of the init files and cron jobs, 
then backs up all config files and keys to a zip for easy retrieval by 
the user.


  I'd love to have guides translated across Tor's 15 supported 
languages, but that's wishing for too much ;-)  Maybe if I write *one* 
guide, the community will help with the rest.  The wizard itself detects 
language, but because environments tend to be in en_US, that's not as 
helpful as just giving an option to select language.


best,
Griffin

[1] https://github.com/glamrock/stormy
[2] There are several good options here that I've used in the past.  
With an eye toward avoiding Apache, the current roster includes Ghost, 
Crabgrass, MoinMoin, ejabberd, just a basic webserver, and just 
hardening. GlobaLeaks and SecureDrop would be perfect for this, but 
development on both is moving really fast right now.


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

Re: [tor-dev] Cute Otter == Tahoe-LAFS + Tor?

[Griffin Boyce]

  I'm working on a project with the same goals (Stormy), but not sure 
what the status is for formalized Torstuff.


  For me at least I'm not interested in using Tahoe because it adds 
unnecessary complexity.  My work with users typically shows that people 
have learned or been taught how to use PGP/OTR, but don't have 
experience as sysadmins and don't have consistent access to advanced 
technical help.  It's also far beyond what most sysops actually need.  
For WikiLeaks, it might make sense.  But for The Dubai Times, it might 
not and the complexity is more likely to confuse/demoralize people.


~Griffin

On 2014-05-16 01:56, David Stainton wrote:
Hi, What is going on with that cute otter hidden service publishing 
project?


What do people think about having it use the Tahoe-LAFS Onion Grid and
lafs-rpg instead of telling users to run their own webservers?
Tahoe-LAFS could help to greatly increase the security and censorship
resistance of the data being published.

If the people involved with this were interested in using Tahoe-LAFS
as the data store then I would be more than happy to help out with
this. (I don't do any web development at all)


Sincerely,

David
___
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] GSoC: Pluggable Transports Combiner

[Griffin Boyce]

quinn jarrell wrote:

Hi everyone,

My name is Quinn Jarrell and I'm a student University of Illinois at
Urbana Champaign. I'm excited to join GSoC and I'll be working on
building a pluggable transporter this summer for Google summer of
code. The pluggable transports combiner will allow transports to be
chained together to form more varieties of transports and make them
harder to detect and block. You can read more about it here: [0].


That's *awesome* ^_^  Please keep us all in the loop! Very excited to 
see how your project progresses.


best,
Griffin

(monchichi on IRC)
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Python Only Tor Client?

[Griffin Boyce]

Hey Naif,

  Have you considered making something with STEM? Granted, it probably 
isn't *quite* what you're looking for, but might get you closer: 
https://stem.torproject.org


best,
Griffin

On 2014-04-21 04:46, Fabio Pietrosanti (naif) wrote:

Hi all,

does anyone know of any work to make a Python Only Tor Client, that 
just

enable to expose a Tor Hidden Service?

It would be very cool if it would be possible to avoid "Tor binary" as 
a

dependency for Globaleaks, making it pure Python application code.

The questions are:

- Are there projects that foresee to do something like that?

- From a Tor Project perspective, does it make sense?

- From a Security perspective, are there strong security implications 
in

doing so?

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

[tor-dev] [Flashproxy] Some sites filtering users?

[Griffin Boyce]

Hey all,

  Got a report from a friend* who noticed that twitch.tv stops letting 
him watch broadcasts while flashproxy is in an active state.  He uses 
Cupcake, which shows flashproxy's status in the icon bar, and he only 
has an issue when the cupcake icon has a mustache.


  Has anyone noticed similar behavior when using flashproxy?

~Griffin

* who is a hacker
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Moving ownership to TheTorProject

[Griffin Boyce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  In your git config, you can define a pushurl that is different from
url.  Which effectively means that you can pull from github but push
to tor.

  So in .git/config, your entry would look something like this
(double-check pushurl syntax):


[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = g...@github.com:zackw/stegotorus.git
fetch = +refs/heads/*:refs/remotes/origin/*
pushurl = za...@gitweb.torproject.org/stegotorus.git
[branch "master"]
remote = origin
merge = refs/heads/master


  You could also clone to new directory, change the origin to tor,
then push each branch.  Unless there are just tons of branches, this
should only take a couple of minutes =)

best,
Griffin


On 04/01/2014 11:01 AM, Zack Weinberg wrote:
> On 02/20/2014 10:48 AM, vmonmoonsh...@gmail.com wrote:
>> Hey Zack,
>> 
>> I want to put up Stegotorus up for GSoC this summer. I was
>> wondering if you mind transfering the ownership of your
>> Stegotorus repo:
>> 
>> https://github.com/zackw/stegotorus
>> 
>> To "TheTorProject" on github:
>> 
>> https://github.com/TheTorProject
>> 
>> ? (https://github.com/zackw/stegotorus/settings then Transfer)
>> 
>> If you don't feel comfortable, we can fork it as well.
> 
> [ Background for tor-dev: I am no longer involved in Stegotorus 
> development.  vmon and at least one other person are continuing to
> work on it; this is currently happening in non-default branches of
> the copy on my github account.  There is also a copy of the repo
> on gitweb.torproject.org but it has not been updated in quite some
> time. ]
> 
> I discussed this with Roger on IRC yesterday and we came to the 
> conclusion that instead of transferring my Stegotorus repo to the 
> "TheTorProject" organizational account, 
> gitweb.torproject.org/stegotorus.git should be promoted to the
> master copy.  I think right now I am the only person with write
> access to that copy, and I am not sure what the right procedure is
> for granting you access.  I'm also not good enough at Git to know
> how to copy all branches of remote A into remote B (short of
> tedious manual actions and/or shell loops).
> 
> I think this would also entail using Tor's Trac for issues instead
> of Github's issue tracker.
> 
> zw
> 
> 
> 
> ___ tor-dev mailing
> list tor-dev@lists.torproject.org 
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTOtnhAAoJEAPPSgqzx5pjlKgH/AmLj3tHAOPg3VvJaDHAt/Nh
ZesH9vJrF2ZdipJhK0QTXnOHsdk5nIxNlnNC/VRLv09At7mzu4X5l9ZvECLlj64f
JeQVhHJ4lFj141mc1LabBnGoppYHOssBMS2HZH0ef8pEGyOJwhacYILDuzIfmn1A
Zs21V9EKd6WIIyyLtnA5BNNZmMHWSCqVSxbXDMM3Sk8lRupYzD2FF4D6xkdlqW3A
WKMBLTA0MTOVDkmJVYv0e65A05hFOv6Fxh/YF41HrgIhjulv6fdK50Y5pFqaKuv6
BU1hU3n80rWPnLjezUj8a/cd2ZliXUVMElAnyoVd41Nprfem2XuJMT3UmgShydQ=
=Kdkg
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] TBB for Chromebooks?

[Griffin Boyce]

Hello all,

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

Re: [tor-dev] Novel distribution mechanisms (was: "s3 alternatives" on libtech)

[Griffin Boyce]

David Fifield wrote:
> GitHub is how Chinese users download GoAgent. It's a little weird, but
> they keep the binary right there in their source tree (goagent.exe).
>   https://github.com/goagent/goagent/tree/3.0/local
> GitHub is great because it's HTTPS only, projects are subdirectories
> rather than subdomains (so no DNS poisoning), and it's important
> infrastructure that's difficult to block.
> 
> David Fifield

  It would also be fairly trivial to create and maintain a repo just for
newest TBB release and signatures.  Not the fastest thing to `git clone`
as a dev, but makes it possible for a user to visit the page and
download a zip file for their language and the signature to verify it.

  Of course, if every project did this, it would change the equation a
bit for censors, but we won't know until we try ;-)

~Griffin

[0] this is a project that is *so* easy that someone could just go ahead
and do it, but of course it's far better to have an official repo
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Novel distribution mechanisms (was: "s3 alternatives" on libtech)

[Griffin Boyce]

Nathan Freitas wrote:
> Have you looked into BitTorrent Sync? You can do semi-private (I
> believe) Dropbox-like Torrent shares, that could be provisioned based on
> emails or other requests from users.
>
> There is a really nice mobile BitTorrent Sync app, so I have
> particularly been interested in this as a means to distribute apps to
> Iran and China.
>
> +n

  I haven't looked into BitTorrent Sync, actually.  But that sounds like
it could be an improvement on torrent distribution (or at least an
additional approach).  I'm not sure to what extent user downloads are
tracked via mobile phones in the target areas, but my assumption is
100%.  Having said that, I'd like to know more -- and it makes absolute
sense for something like Orbot to be distributed friend-to-friend via
BlueTooth or something like BitTorrent Sync.

~Griffin
gpg: 879B DA5B F6B2 7B61 2745  0A25 03CF 4A0A B3C7 9A63
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Novel distribution mechanisms (was: "s3 alternatives" on libtech)

[Griffin Boyce]

Nathan of Guardian wrote:
> Github? Maybe not whole sites, but specific files.

  I've been working with users who have networks in censored countries
to expand access to specific software bundles (not just Tor).  My two
approaches right now are Google Web Store and torrents attached to a
stable offsite seedbox.  Both are fairly accessible, but both have
pros/cons.  With torrents, someone can sit as a seeder and try to tally
information on downloaders. Google Web Store downloads are tracked in
unknown (legally requestable?) ways by Google and of course it requires
downloading/installing Google Chrome to gain access.[1]

  It's not perfect, but at least for the user groups I talk to, they are
realistic solutions to a really tricky problem.

~Griffin

[0] cross-posted upon recommendation of David Fifield
[1] most users can't figure out how to download extensions manually
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Weekly Tor dev meeting: Tuesday 25 Feb, 20:00 UTC

[Griffin Boyce]

On 2014-02-24 12:59, Roger Dingledine wrote:

I see this was answered on irc, but to answer it here for completeness:
it is my understanding that the Tuesday dev meeting will be held on
Tuesday this week. :)


  Is this for little-t tor, or more user-facing projects like TBB?

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

[tor-dev] Fwd: [OpenITP Dev] Python & Javascript volunteer?

[Griffin Boyce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OpenITP & TA3M have had a python dev ask if STEM or txtorcon need
assistance =)  For more details, talk to Sandy (sandraordo...@openitp.org).

~Griffin

-  Original Message 
Subject: [OpenITP Dev] Do u needa Python & Javascript volunteer?
Date: Wed, 29 Jan 2014 10:45:46 -0500
From: Sandra 
Organization: OpenITP
To: d...@lists.openitp.org



I've started asking at TA3M if people are interested in volunteering
to shot me an email with qualifications. Do any of your projects need
someone like this

"You said I should shoot you an email since I was one of the women
in New York and also to get involved volunteering. I would like to
help with development for one of the projects - I am currently
programming in Python and JavaScript - I do Django development, and I
have some background in security. I saw on the site that stem and
txtorcon are in Python - do either of those groups need assistance?
Also feel free to ask if you guys need help with set up or organizing
local events.

Let me know, I'll make intros :)






___
Dev mailing list
d...@lists.openitp.org
https://lists.openitp.org/mailman/listinfo/dev



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

iQEcBAEBAgAGBQJS6SLCAAoJEAPPSgqzx5pjUUEH/1ybIOkHrUxnkBs0Sjmu4TP9
O/zsPLFFnGFOvDFrQCsv8nErNTgeSivpTT9I2+4FeIpDu4VEEdwnyCOe7qpAZE63
sef/zX2oZaMPAlM8Fbyjz1jUCUXgo1SsSFGpEGK35WiQi1O3Xa5kbBRn05oc7jvU
Qspjd9wf/C6A23usK2Jq3XA7/sJf8oCXl+f6zBXTb+yhXJX+ZqunwYb6Xks2De3U
pzTaOuVChcmlfFGTwPKND1io4Bhx/coi3+ANg2fNvHkyTLZRLHly7TkjRhc34lPs
9hCeMsfjoPHqFNu1zUSZ+qTmcmMtSiY/SaG8Kmkpz5UeCgkCWJR23VksTiXAiP4=
=PWtb
-END PGP SIGNATURE-

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

Re: [tor-dev] Projects to combat/defeat data correlation

[Griffin Boyce]

Ximin Luo wrote:
In my understanding, the anonymity set doesn't apply to use of PTs 
since this is only at the entry side. The exit side does not know[1] 
what PT the originator is using, so is unable to use that information 
to de-anonymise.


[1] at least, in theory should not know, perhaps someone can check 
there are no side-channels? would be pretty scary if exit could work 
out that originator is using PTs.


  Anonymity is still a consideration, even if it's highly unlikely to 
be impinged upon by pluggable transports.  For example, if a network 
notices someone connect to a known obfsproxy bridge, then they can make 
an educated guess that the person is using both Tor and obfsproxy.  With 
flashproxy, this is of much less concern given address diversity.  With 
bananaphone, it wouldn't really apply at all as far as I can see.


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

Re: [tor-dev] exit-node block bypassing

[Griffin Boyce]

Hey Ximin,

  I don't think it's been discussed in-depth before (at least not 
on-list), but I've thought a fair bit about it. While it's an 
interesting idea, I don't think that the risks for deploying it far 
outweigh any minor reward that could come of it.  This idea has come up 
several times in the context of Cupcake "wouldn't it be great if we 
could" sort of thing.  It really wouldn't.


  Exit node operators take on some pretty serious legal and security 
risks if they operate their exit from home. (NEVER DO THIS).  More than 
one person has been raided by police who didn't do their due diligence 
beforehand.  Expanding that into the territory of people who aren't 
fully aware of their risks would have terrible repercussions.


  It also becomes trivial to flood the Tor network with bad ephemeral 
exits, which disappear before people catch on.  Speed would be an issue 
also.


  While I really believe that expanding Flashproxy and Fog and Bridges 
is extremely important, I don't that's plausible for exit points.  
Educating groups of website owners about censorship would help us a lot. 
 Circumvention isn't something that's thought a lot about in the US, 
which unfortunately is where a lot of large websites are based.  
Unblocking all or portions of [big website] can be extremely helpful to 
at-risk groups of people, and that's not always obvious to sysops.


~Griffin


Il 31.12.2013 06:07 Ximin Luo ha scritto:

Hey all,

Flashproxy[1] helps to bypass entry-node blocks. But we could apply
the general idea to exit-nodes as well - have the exit-node connect to
the destination via an ephemeral proxy. The actual technology probably
needs to be different since we can't assume the destination has a
flashproxy (websocket/webrtc) PT server running, but we could probably
find a technical solution to that.

However, I talked this over with a few people and there might be legal
and security issues. A few points:

- running an exit node carries a great risk, it would be bad/unethical
to let ephemeral proxy runners take this risk
- (for security reasons we don't fully understand) there is a process
for trusting exit nodes and/or detecting misbehaviour (I see badexit
emails from time to time). this would be made much harder if exits
were ephemeral.
- someone could create a massive number of ephemeral exit nodes and
capture a lot of exit traffic, giving them extra data to de-anonymise
people.

I was wondering if any of these have been discussed in depth before
already, or if the general topic of exit-node block bypassing is
something to be explored.

X

[1] http://crypto.stanford.edu/flashproxy

___
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?

[Griffin Boyce]

Fabio Pietrosanti (naif) wrote:
> I mean supporting many hardware devices, rather than going with a custom
> hardware?

Hey Naif,

  Access Labs' openwrt-based torouter firmware is still the best and
most stable.  It worked pretty well for me back in August on a TP-Link
N750, and earlier on a Buffalo router, so it's worth looking at.  PORTAL
is also a cool project, but tbh I don't know much about it.

  This is the sort of project that someone should pitch to RFA when the
next Open Tech Fund round opens in January.  In my mind, the ability to
make your own torouter out of inexpensive (and ubiquitous) routers
somewhat trumps having open-hardware torouters available for purchase. 
But all work in this area is a true labor of love, and it makes sense
for people to pool their efforts where they feel the greatest impact can
be made.

~Griffin

(unsurprisingly, I speak only for myself and not my employer)

-- 
Be kind, for everyone you meet is fighting a hard battle.

PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97
OTR: sa...@jabber.ccc.de

___
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

[Griffin Boyce]

Sorry for taking so long to respond to this thread.  Responses are
(mostly) inline below.

  At a training event a couple of days ago, a user was sketched out by
the warning her Mac gave her -- in spite of the advance notice she'd
been given by the trainers.

Erinn Clark wrote:
> Please see Ralf's reply to me elsewhere in the thread -- do you still
> think this while taking into account what we know about US companies'
> cooperation the NSA/USG with regards to turning over user data?

  This is an extremely important point, and I don't want to minimize
user risk in this regard. But I think that it needs to be weighed
against the probability that it will expand availability to censored
users. (Especially if the bundle uploaded is the pluggable transport
bundle, hint hint hint).

  The situation is similar to Orbot's deployment (as Nathan points out).
Censor X would have to block the app store in order to block access to
Orbot, but the trade-off is that Google gets a list of people interested
in anonymity.

  Part of me feels that if a user is using an Apple device, they're on
the hook to do their homework -- responsibility and informed consent and
definitely in play there. AFAIK, the last bug submitted was #6540.

  However, having said all of that, it turns out that Tor doesn't need
to distribute it via app store to distribute a signed app [1] (there are
two types of certificates). Though the signing situation itself is
complicated (eg, Apple would still likely know that you've downloaded Tor).


and...@torproject.is wrote:
> 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.

  I really like this idea. My only real concerns are about licensing and
whether Apple would consider a Tor-licensing dev to be effectively a
proxy of the Tor Project Inc.  Also, the tpo site right now indicates
that someone could just submit TBB to an app store without a licensing
agreement, so that could use clarifying.

  Other than that, agree with Naif :D  To Nathan's point, Macs and
Chromebooks subscribe highly to the "walled garden" model of app
accessibility, and more users look to Apple's blessed apps than for
independent solutions.  This is either a good thing or a bad thing,
depending on your outlook (broader userbase vs. better-educated users).

abusing his parenthetical privileges,
Griffin

[1] Page 11 of:
https://developer.apple.com/library/mac/documentation/security/conceptual/CodeSigningGuide/CodeSigningGuide.pdf

-- 
Be kind, for everyone you meet is fighting a hard battle.

PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97
OTR: sa...@jabber.ccc.de
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Finalizing translation strings

[Griffin Boyce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nima Fatemi wrote:
> I didn't find it on torproject page. but anyways here it is:
>
> https://www.transifex.com/projects/p/cupcake/language/fa/
>
> Please donate the /whatever amount of/ money you had in mind for this
> translation to Tor Project.
>
> My small contribution. Only for David's great job.
>
> Bests,Nima

  Thanks so much!  Tor's Persian page is at:
https://www.transifex.com/projects/p/torproject/language/fa/  I will
donate that money to the tor project.

  David does amazing work and I am incredibly honored to be using
flashproxy as the basis for this project.

thanks again,
Griffin

- -- 
Be kind, for everyone you meet is fighting a hard battle.

PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97
OTR: sa...@jabber.ccc.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJSgtnJAAoJEOMx/SmueSyX0+gQAKqYO/LuVLM6XPZmCCjAbCLf
uWoLFZEqrMMTD6b2FA/GRzEgCC2tsQ78lUDUY2xVrcVS4uunzhzP8OIUwDeNGyH9
lmmp4LqGTC8uFHXxuS4SPqFAdcIWZG2U83SGZrEYKfbWV+77WmS9bgCuF0qiEV7G
7YoHA/b2oh2VkvMM6Q+C9MNKolJyA7nm1KxzCRHmR9pT5eyvsbAk2OrZXYOtNxVB
1HQxjoryOeXWd7mraj+YpCT1AR95Erb4hF6JE+hkplgmULHAZdTK2+QeeXxKxYm2
m7CS4Va2FxJoPW6fd/As0LMODnbyODDyLqpNjZMaIo0abGvEmkoetyfjT/TUPAhd
HPss+u/O3JAc1wXrOOwcgjIW765blUXqIDH+RO4vbvlH6ITv9z2GwqQFGKgxTfdX
isaGChIkM3vIvEHhw8p/2gq7gYNPprTnHbkD9O/cuaMxwhbczLVLhTygf8ENGJQ7
K3Oua3cvRYPpH0wCBu+4UNV9ZYO7MpiSd3HJHxyWuVrtcP5YqTzT+B0hdo6DCbOH
KR82lOqblDfwT/kD6T5D/m61QLXGhBzZvmyTIZAZTrRSP+Y+wjXx4kfBFOoxqhqM
M/jBD94LMr4pZJNDUvgO9kWpWiHLL2DVcINVqpew8Hv9zEIh5vATXDuuAOgQyZvZ
CvomcyL8+q55jRpzA6Sl
=lbE7
-END PGP SIGNATURE-

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

Re: [tor-dev] Finalizing translation strings

[Griffin Boyce]

Nima Fatemi wrote:
> Griffin Boyce:
>>   After chatting with Runa, decided to go ahead and post this to the
>> list.  If strings could be updated/finalized by early December, that
>> would help the process a lot. =)
> Planing to post it on Transifex? or link me if you already did?

Both are currently on Transifex:

Tor (separated into projects):
https://www.transifex.com/projects/p/torproject/
Cupcake (which is only about 400 words):
https://www.transifex.com/projects/p/cupcake/

  I typically only add languages when there is a translator interested,
but if you think of any others that stick out, please let me know.

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

[tor-dev] Finalizing translation strings

[Griffin Boyce]

  So I'm hiring translators for Cupcake, for Persian and
Urdu translations.  As it turns out, this is surprisingly inexpensive.
Because I'm hiring translators anyway, I want to go ahead and donate
translations of Tor project strings.  (Especially Urdu, which is
inexpensive, but difficult to find volunteers for).

  After looking at Transifex for a few projects, there
seem to be some extraneous strings. Torbutton and TorBirdy both
have a lot of single-character strings which don't make sense (or lack
context).

  After chatting with Runa, decided to go ahead and post this to the
list.  If strings could be updated/finalized by early December, that
would help the process a lot. =)

best,
Griffin

-- 
Be kind, for everyone you meet is fighting a hard battle.

PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97
OTR: sa...@jabber.ccc.de

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

[tor-dev] Apple App Store Redux

[Griffin Boyce]

  It's been a while since there's been a discussion on-list about
getting the TBB into Apple's app store [1].  Interest hasn't really gone
away in the intervening 13 months, so I just want to open up discussion
about it.

Here are the issues as I see them:
  - Apple has traditionally been at odds with GPL-licensed stuff [3],
though of late it seems to have relaxed a bit with dual-licensed
material [2].
  - If the TBB is added to the app store by Tor, it requires review of
and agreement to Apple's terms and also agreeing not to reveal DRM
sekrits [4].
  - It requires time and energy to keep the app store listing maintained.

Here are some possible solutions:
  - Submit Apple agreements to Wendy for review and
rejection/acceptance. The last mention of this was a year ago on #6540.
Status?
  - 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).
  - Actively decide to continue without being blessed by Apple, but
focusing instead on educating Mac users about their application security
options.

Thoughts?

~Griffin


[1] https://trac.torproject.org/projects/tor/ticket/6540
[2] https://www.opensource.apple.com/license/gpl-with-exception/
[3] http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/
[4]
https://www.eff.org/deeplinks/2012/05/apples-crystal-prison-and-future-open-platforms#gatekeeper-update

-- 
Be kind, for everyone you meet is fighting a hard battle.

PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97
OTR: sa...@jabber.ccc.de

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

Re: [tor-dev] [tor-assistants] Please help me plan and run meetings in ways that you'll find most helpful

[Griffin Boyce]

On 11/08/2013 12:14 PM, Ximin Luo wrote:
> Tom, we also have Pluggable Transport meetings every other Friday, including 
> today, at 17:00 UTC;
could you add that to the calendar too? (For some reason in my personal
calendar it's every week, but other people told me it's every 2 weeks.)

  Ahhh, I was just asking if these were still going on =)  Last time I
was in one, they were weekly, but things might have changed in the past
month.

  I'd just like to point out that this calendar is a great way to avoid
having to schedule with Doodle every day.  Scientists are currently
researching how I managed to be the only person to show up to the Otter
IM meeting.  You don't want to be more tardy than me =P

  But if there are times that work better for people, let Tom know or
post on the list in some sort of obvious way.

forever tardy,
Griffin

-- 
Be kind, for everyone you meet is fighting a hard battle.

PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97
OTR: sa...@jabber.ccc.de

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

Re: [tor-dev] Registering special-use domain names of peer-to-peer name systems with IETF

[Griffin Boyce]

Nick Mathewson wrote:
> establishing the precedent that if you make a P2P network that uses a
> new virtual TLD, you can officially own that TLD forever for free 

  Well, if the barrier-to-entry is ten(ish) years of hardcore
development, a robust research community, and hundreds of thousands of
daily users, then that might be an acceptable precedent to set :-D

  Though I am slightly saddened that I'll never own "notatrap.onion" ;-)

~Griffin

PS: thanks for doing this, Christian!

-- 
Be kind, for everyone you meet is fighting a hard battle.

PGP: 0xD9D4CADEE3B67E7AB2C05717E331FD29AE792C97
OTR: sa...@jabber.ccc.de

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

Re: [tor-dev] Help me guague how full your plate is via regular check-in conversations

[Griffin Boyce]

On 10/29/2013 07:30 PM, Tom Lowenthal wrote:
> Any questions or suggestions?
>
> -Tom

  Is this a "tor dev" thing, or a "devs who work on tor-related projects
but who are not part of tor" thing?

~Griffin

-- 
"Cypherpunks write code not flame wars." --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de

My posts are my own, not my employer's.

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

[tor-dev] Browser extension identification/fingerprinting mitigation?

[Griffin Boyce]

Hi all,

  I'm looking at possibly replacing the images used by Cupcake with
inline SVG XML, to reduce the possibility of fingerprinting/identifying
Cupcake users who use Chrome [1].  One of the more talked-about methods
of identifying a user's browser extensions is to look for images used by
the extension (in Chrome at least), so this seems to make some amount of
sense. [2]

Does anyone have any thoughts on this?

~Griffin

[1]
https://chrome.google.com/webstore/detail/cupcake/dajjbehmbnbppjkcnpdkaniapgdppdnc
[2] http://blog.kotowicz.net/2012/02/intro-to-chrome-addons-hacking.html

-- 
"Cypherpunks write code not flame wars." --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de

My posts are my own, not my employer's.

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

Re: [tor-dev] Attentive Otter: Analysis of Instantbird/Thunderbird

[Griffin Boyce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

  So the lack of OTR support in Instantbird is nearly a dealbreaker for
me, as it makes it a bit more likely than a rogue exit could intercept a
user's communications. Though this depends in part on SSL/TLS support
and whether a user *actually enables* it in their settings.

  Would the plan be to create and test a reliable OTR patch for Instantbird?

  Pidgin's big issue before was DNS leaks. How is this addressed by
Instantbird? (okay, there are a few big issues with Pidgin but...)

  I like Instantbird's UI, but we should come up with a plan to set
proper defaults.

~Griffin


Mike Perry & Sukhbir Singh wrote:
>   - No OTR support yet
> + OTR support tickets:
>   https://bugzilla.instantbird.org/show_bug.cgi?id=877
>   https://bugzilla.mozilla.org/show_bug.cgi?id=779052
> + For a stopgap/prototype: We can use the js-ctypes wrapper of libotr
>   along with the message observer API
>   + Example observer API use w/ rot13:
> http://hg.instantbird.org/addons/file/tip/rot13
>   + JS-Ctypes wrapper for native libotr:
>
http://gitorious.org/fireotr/fireotr/blobs/master/chrome/content/otr_wrapper.js
> + The ctypes wrapper can be converted to an XPCOM wrapper later.
> + According to sshagarwal #maildev on irc.mozilla.org, Mozilla is
>   also working towards implementing all of the primitives needed
for OTR (and OTR
>   itself) in NSS. These are listed in this comment:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=779052#c17
>   + We could also rely on the ctypes wrapper until native support is
> available, and possibly skip an XPCOM libotr wrapper entirely.


- -- 
"Cypherpunks write code not flame wars." --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de

My posts are my own, not my employer's.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJSVcVCAAoJEOMx/SmueSyX/T4QALZ3WzbxxNtOj/FbDciYb3t5
B793kSDIrezwZ/lhYtfgAxP9TKGZ2K5yCBf5CtAPWoBSp4vXmscdfkI+1jE2aU6E
rBCTgjDpw+r27hrmU6rm78awhzrg6jpTrBpiMFuEKmCT0ZREdt/1xj9cJCLYjUId
50fmz7uv6/8MeLvy+yUJTYMbxwLfTbLRMWY7OzipJTozuot3+13I6qh4zh9N5qnq
qahxu2cpE+oe8MuWSHdGv14pHziKs+r9ebIh4WKcrP4dRq4hixagSRbS078XN9fR
BEV+JFsHrtLXLjvfaxxBZor4lhoK3Zt1GmgPFOB+LiMZh5X9LdsVlLSha04+084z
JmMkYVruPYAJo0uaxOQU0pTTKJmzSwxzB3xebw+oGBzrLP5rdO85oOOv6ND+mOFv
EymTo6exsbQiFg7bmFuT2pF9npJsqpKuNEM+Pinrxx1JZrzPTBBD0wDMZs6jh7Z3
vE7cyFYI5qIfv5uAyDQyF1UENX8L7HIQIf9N4TmagksdEsM/wAn9w8ZswSsUwUHO
xOzaJwC/4NnUQODlI/YYzI+9E6vaXJ2RxWtiCeCGHSbDkXiAdUTPps6se4I/jdGW
t2G6DPFM+k9BZDA8Wz+ulH10rlaYOPuhTmBHvuf+cXZpZRyLpse4bTqCcSOAfL8p
PZbvZukOi83RQ4ThJv0C
=5/Gh
-END PGP SIGNATURE-

___
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

[Griffin Boyce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/16/2013 09:51 PM, Liste wrote:
> Work complete for the version 0.0.0Beta

  Any chance you could upload your project to github, or a similar site
so that people can review it before downloading?  Github also uses SSL,
which does offer some amount of protection when downloading random bits
of code.

~Griffin

- -- 
"Cypherpunks write code not flame wars." --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de

My posts are my own, not my employer's.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJSN96VAAoJEOMx/SmueSyXifoQAI25y1We6gjHuQ/fyfIiJg5S
sawObqso6Qb01IqID+h5PBczUhS/O+tNAne0DqGjaVtiOMATtJUAJdBuU/MEWYFO
jKuqA7+5SlCzDKM706XUoZj3hstK5fM3IPgFUnhgPCxh61L3uX4iz1gvXLDYjuws
WEcUInOfnWgFc9BvaESC37+evZhf+FFG8m8we50cJ1q9t+BVuMF19owAfwxDBbQX
h5E9Cihy5ZpTf/pfH3mk3jYlIat/asVRfDaKTLiAU1nywpjUJRtA4MxdQ7cJlDDI
td7bbNbXP+m0VjPH8+DaYDhmztjg0b1/RUQ9v3dX130QiyFxsrXyfQ9tZldo7Orn
ivc1CYFtKvGlCZsn+4O+VgdyvPR0CYxAjbBuGdTe5SZaB79aFfDDpCQf0riTnCly
e94WflbQnjeWn16fMLqGWcpMJeOUlKTfS10zrdyNYPrW5s+uR/pZEOKm+dsLvlf3
Q+w8deviF/r17oQjaRFz6v2f2mqWN7ti1yWvl3JUP9ndAqgLp3Zgnc5F7o8cVUw3
2j+627D+pQjzg099R8g/pHyQ2EuXqwywE9xKNoZIMYc45avG4uh/bqqSPam+MwDs
BbCcIHPRpMeIIrGZwHAA8H+B+pkftDTd70sfxJni56oWWeeXF7OiaV7mg3I+N8j6
+3DeRztvCt64sl9PWQ3o
=oPlE
-END PGP SIGNATURE-

___
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

[Griffin Boyce]

  I would actually really appreciate the old numbers (from ~2007-8/2013)
being kept online.  Estimating growth over time and mapping spikes is
kind of a big deal to me. =)

~Griffin


On 09/16/2013 02:28 PM, Karsten Loesing wrote:
> Hi everyone,
>
> some of you may already know our new approach to estimating daily Tor users:
>
> https://metrics.torproject.org/users.html#userstats
>
> This new approach is in beta since April, and I'm quite happy with it.
> I trust the new numbers more than the old ones, both for direct users
> and bridge users.  The new code for direct users is quite similar to the
> old one, but much cleaner.  The approach for bridge users is a much
> better idea than the old hack.  Today I added the missing features like
> the top-10 lists and the censorship detector.
>
> 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.
>
>  - Take out the "BETA" labels and throw out everything above "New
> approach to estimating daily Tor users (BETA)".  This could happen on
> October 1.
>
> Thoughts?  Did I miss anything that's worth keeping?  Anyone want to
> create an archive of their favorite graphs before I pull the plug?
>
> All the best,
> Karsten
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>


-- 
"Cypherpunks write code not flame wars." --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de

My posts are my own, not my employer's.

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

Re: [tor-dev] Pluggable transport weekly meeting

[Griffin Boyce]

  I thought we were having it at noon EST tomorrow.  If no one else
shows up, maybe we can have a discussion about cats or something. (Or
just show up in #tor-dev and start talking about pluggable transports
until it turns into a meeting ;-) )

~Griffin


Kevin P Dyer wrote:
> Hi all,
>
> Will we be having the first Pluggable Transport Weekly tomorrow?
>
> I'm working towards getting a build environment setup for the PTTBB
> and would like to chat about it, to ensure I'm not duplicating
> previous efforts.
>
> Thanks,
> Kevin
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Pluggable transport weekly meeting

[Griffin Boyce]

That day and time work well for me -- thanks for setting this up! =)

~Griffin

On 09/06/2013 04:58 AM, Vmon wrote:
> I sent this email quite a while ago and I was surprised that nobody
> was interested/replied. Today I found out that I had sent it to a
> wrong address. But here we are, so I'm sending it again. So please
> reply so we can kick this off soon.
>
> Thanks,
> Vmon
>
> -- Forwarded message --
> From: mailto:vmonmoonsh...@gmail.com>>
> Date: Wed, Aug 21, 2013 at 6:46 AM
> Subject: Pluggable transport weekly meeting
> To: tor-dev-requ...@lists.torproject.org
> 
>
>
> Hello Tor devs,
>
> Following up on what we came up with in the dev summit
> (https://trac.torproject.org/projects/tor/wiki/org/meetings/2013SummerDevMeeting/PluggableTransports1),
> we are going to have weekly 30-minute IRC meeting focusing on pluggable
> transports. The format (I think) will be scrum-esque that every
> developer who is working on a pluggable transport will update everybody
> else about the work they did/are doing on their transport during the
> week and ask questions if they have any, for example if they got stuck
> somewhere and they think somebody can help.
>
> Preliminary, we decided to have the meeting on Fridays, cause why not,
> but if you have serious problem with Fridays then we might be able to
> pick a better day.
>
> For the time of the meeting, considering the geographical positions
> of the current transport developers, we'll probably end up having a CEST
> evening and PST morning meeting. Having that in mind I suggest:
>
> CEST: 18:00
> BST (Summer GMT): 17:00
> EST: 12:00
> MNT: 10:00
> PST: 9:00
>
> So if this doesn't work for you, please reply to this email with your
> alternative proposal.
>
> Thanks,
> Vmon
>
>
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


-- 
"Cypherpunks write code not flame wars." --Jurre van Bergen
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de

My posts are my own, not my employer's.

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

Re: [tor-dev] New flash proxy facilitator domain fp-facilitator.org

[Griffin Boyce]

I've updated the Cupcake extension already.  Thanks for the heads up. :)

~ Griffin

-- 
Sent from a phone, please excuse fatfingers and grammatical errors.
On Jun 30, 2013 5:55 PM, "David Fifield"  wrote:

> On Thu, Apr 25, 2013 at 01:32:08AM -0700, David Fifield wrote:
> > I moved the flash proxy facilitator to a new domain, fp-facilitator.org.
> > This is to get it away from bamsoftware.com, which also has a lot of
> > unrelated stuff. The old facilitator name
> tor-facilitator.bamsoftware.com
> > will continue to work (the DNS for both points to the same place).
> > https://trac.torproject.org/projects/tor/ticket/7160 is the ticket.
>
> The SSL certificate for the old tor-facilitator.bamsoftware.com will
> expire on 14 August. I'm planning to let it expire, unless someone
> critically needs it. Public flash proxies should all be using the new
> fp-facilitator.org domain.
>
> David Fifield
> ___
> 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] XMPP Pluggable Transport

[Griffin Boyce]

Alex Eftimiades  wrote:

>
> I have been working on creating an XMPP pluggable 
> transport for
> Tor for a couple of weeks now, and someone suggested I send an email to
> this mailing list for suggestions.
>

I can't really help out with development, but am happy to help test. =)
Is all of this in a git repo somewhere?

best,
Griffin

-- 
Just another hacker in the City of Spies.
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de

My posts, while frequently amusing, are not representative of the thoughts
of my employer.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Memorable onion addresses (was Discussion on the crypto migration plan of the identity keys of Hidden Services)

[Griffin Boyce]

Matthew Finkel  wrote:

> So I think we should make some terms clear (just for the sake of
> clarity). We have, I guess, three different naming-system ideas
> floating here: petnames, (distibuted) namecoin-ish, and centralized
> consensus-based - rough summary.
>
> Some months ago, the petname system interested me enough that I started
> to write a proposal for it. At this point, it's wound up in bitrot.
> Though I'd spent a bit of time working on it, there was no comprehensive
> way to accomplish it.


  I too started writing a petname proposal only to have it wind up on the
backburner.

  In a nutshell, there would be a sort of pseudo-DNS that allow a given
.onion to define a petname through a file on their site.  For example,
somename.onion/petname.txt could shorten the address to bettername.pet.
 The pseudo-DNS would check if a hidden service is alive once every few
days, and if the onion is down for thirty days, the petname is freed up for
someone else to use.  This has the side effect of promoting good onion
upkeep.

  I like the idea of federating hidden services and eepsites into one
petname system, but not sure how possible/practical that would be.  Of
course, there's really nothing keeping an independent actor from making
this and offering it as a firefox plugin for those who might want to use it.

Thoughts?

~Griffin
-- 
Technical Program Associate, Open Technology Institute
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Status of Torouter project

[Griffin Boyce]

Jacob Appelbaum  wrote:

> Yes, it is. I'm working on it and so are a number of other people.
>
> All the best,
> Jacob


 Good to hear.  Is there a tentative date for a beta release?

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

Re: [tor-dev] Status of Torouter project

[Griffin Boyce]

adrelanos  wrote:

> Accesslabs: no visible progress. No saying there is none or they are not
> working on it, but I never found a public mailing list, git repository,
> trac timeline is empty. Happy to be proven wrong. Perhaps mail them.
>

  I haven't heard of any substantial movement on torouter in maybe a year
or so.  Some assume that development was ongoing because the idea of
torouter is so appealing, but from a developer perspective, that is not the
best place to be.


> Not sure it's good to base a Tor Router and WRT 
> Not very good for a security sensitive project.
>

  I only sort-of agree. Installing/updating with opkg is problematic for
the reasons you mention, but I work on an OpenWRT-based project, and we
manually install/update rather than use opkg.  (But we're also working with
a model where people may not have realistic internet access). [1]

~Griffin
[1] https://github.com/opentechinstitute

-- 
Technical Program Associate, Open Technology Institute
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Status of Torouter project

[Griffin Boyce]

Hello all,

  So I'm part of a team working on wireless mesh, and Torouter has come up
a few times this week.  Is it actively being developed?  Given the state of
the roadmap [1], I'd sort of assumed it was inactive or on hiatus, but
others had heard differently.

thanks,
Griffin Boyce

-- 
Technical Program Associate, Open Technology Institute
#Foucault / PGP: 0xAE792C97 / OTR: sa...@jabber.ccc.de
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] New flash proxy facilitator domain fp-facilitator.org

[Griffin Boyce]

David Fifield  wrote:

> I moved the flash proxy facilitator to a new domain, fp-facilitator.org.
> This is to get it away from bamsoftware.com, which also has a lot of
> unrelated stuff. The old facilitator name tor-facilitator.bamsoftware.com
> will continue to work (the DNS for both points to the same place).
> https://trac.torproject.org/projects/tor/ticket/7160 is the ticket.
>
> David Fifield


I'll push an update to Cupcake [1] that has permissions on the new domain.

~Griffin

[1]
https://chrome.google.com/webstore/detail/cupcake/dajjbehmbnbppjkcnpdkaniapgdppdnc

-- 
Please note that I do not have PGP access at this time.
OTR: sa...@jabber.ccc.de / fonta...@jabber.ccc.de
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Human factors of security software

[Griffin Boyce]

  While I'm not quite sure it's what you're looking for, cross-cultural
factors come into play a lot and seriously affect trust.  I work with an
organization that (in turn) works with Chinese activists & organizers.
 It's a bit of a catch-22 that tools and guides in Chinese dialects are
critically important, but tools made in China aren't necessarily trusted.
 (Though this is probably owing to the extreme levels of infiltration in
activist communities there).  But tools that aren't trusted might be used
more often than non-translated alternatives.

...It's problematic.

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

Re: [tor-dev] Hidden service access without TOR

[Griffin Boyce]

Rather than going through a large process to reach hidden services without
the Tor bundle, I'd suggest instead using Tor2Web or Onion.to.  Tor2Web is
also open-source, but both are fairly reliable.

Example: DuckDuckGo
Tor only: http://3g2upl4pq6kufc4m.onion
http://3g2upl4pq6kufc4m.tor2web.org
http://3g2upl4pq6kufc4m.onion.to

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

Re: [tor-dev] Tor Exit Images

[Griffin Boyce]

Fabio Pietrosanti (naif)  wrote:

> To fix that need it would be nice to make a sort of "hosting provider"
> (using existing tool for customer management, payments,
> server/application deployment & maintenance) to host Tor Exit.


This would definitely be cool, though honestly I was thinking more
pre-configured bundles for common ISP(s).

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

[tor-dev] Tor Exit Images

[Griffin Boyce]

Hey all,

  After talking to Wendy Seltzer, I decided to bring this up on the list.
 I frequently talk to people who would like to run an exit node, but who
aren't as good a sysadmin as they'd like to be.  It would be great if there
were server images that could be fairly easily installed and then
configured.  All of these people so far have had the means to spend $150ish
a month on the required hosting, they just felt that getting it running was
a stumbling block.

  Thoughts?

~Griffin

-- 
"What do you think Indians are supposed to look like?
What's the real difference between an eagle feather fan
and a pink necktie? Not much."
~Sherman Alexie

PGP Key etc: https://www.noisebridge.net/wiki/User:Fontaine
___
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

[Griffin Boyce]

SiNA Rabbani  wrote:

> Are we also interested in translating this to other languages? Perhaps
> we can get the Farsi done ASAP, since we now have a country obfsproxy
> users coming to this page soon :)
>
> All the best,
> SiNA


If everyone's open to interface ideas, a rough number of bridges per day in
the past  would be great, in addition to the graph now.  I know
it's likely an estimate, but it would help outsiders like me make
calculations. =)

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

Re: [tor-dev] Cupcake: browser extension for flash proxies

[Griffin Boyce]

On Fri, Jan 4, 2013 at 5:42 PM, David Fifield  wrote:

>
> Thank you for doing this. Would you please add this information to the
> ticket at https://trac.torproject.org/projects/tor/ticket/7721? This is
> the ticket for creating a browser addon. You can create an account or
> use the anonymous account cypherpunks:writecode. There are people
> watching the ticket who will be interested in helping you test.
>

No sweat - didn't realize that there was a thread about it already.
https://trac.torproject.org/projects/tor/ticket/7721#comment:5


> We will probably be moving to an all-opt-in model for flash proxy. Your
> addon should send the flashproxy-allow=1 cookie, if it doesn't already


It doesn't, but I'll make that update


> At this point, it will help if you can keep it pointing to the same
> embed page. As we are on the verge of deployment, we may need to make
> changes to the proxy program quickly.
>
> David Fifield
>

Sounds good to me. I don't think it would be too difficult to get a couple
thousand users through the Chrome Web Store.

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

[tor-dev] Cupcake: browser extension for flash proxies

[Griffin Boyce]

Hi all,

  Made this extension for Google Chrome to extend the concept of the Flash
Proxy, and make it easy for users to create bridges.  (and as a result
cause a bunch of fairly robust bridges to be made).  The concept could be
used in addons for FireFox, Opera, or Safari as well, since they all allow
processes to run in the background.

Benefits:
* Allows people to opt-in to becoming flash proxies, rather than current
opt-out model
* Works in Chrome OS
* Takes all guesswork out of making a bridge
* Flash proxies made with Cupcake have a substantially longer uptime than
those using site visitors
* Uses less memory than either Tor BB or Vidalia

Source code: https://github.com/glamrock/cupcake

Now that I've tested it and it seems to work well, I'd love to get input
and suggestions on it. If it's useful, I'll submit it to the Chrome Web
Store. Right now it uses the Stanford project site's embed page. If there's
much interest in this, I'll switch to a dedicated site since it's maybe not
fair to send that many requests to them ^_^;

Input, ideas, and tomatoes welcome =)

Best,
Griffin Boyce

-- 
"What do you think Indians are supposed to look like?
What's the real difference between an eagle feather fan
and a pink necktie? Not much."
~Sherman Alexie

PGP Key etc: https://www.noisebridge.net/wiki/User:Fontaine
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev