- tor-project - lists.torproject.org

Belated thanks to George and David
by Allen Gunn 29 Nov '16

29 Nov '16

Hello all, With both general gratitude and a spirit of shouting out folks who do great ambassador work for Tor, I wanted to thank George R and David F for contributing so much about two weeks back at our Nonprofit Software Development Summit. George explained Tor architecture to a bunch of participants who say they are now inspired to run relays and set up onion sites, and also had a number of how-to side conversations. David explained pluggable transports and a number of other Tor features during our demo fest and contributed richly to other sessions. We are grateful to have this type of super-valuable sharing take place at the Dev Summit, and I just wanted to state that publicly. Thanks you two, you both rock. peace, gunner -- Allen Gunn Executive Director, Aspiration +1.415.216.7252 www.aspirationtech.org Aspiration: "Better Tools for a Better World" Read our Manifesto: http://aspirationtech.org/publications/manifesto Follow us: Facebook: www.facebook.com/aspirationtech Twitter: www.twitter.com/aspirationtech --

1 0

Turning on timing obfuscation (iat-mode=1) for some default bridges
by David Fifield 29 Nov '16

29 Nov '16

I propose that we turn on the obfs4's optional packet size and timing obfuscation on some of the default Tor Browser bridges. The packet size and timing obfuscation can be off (iat-mode=0) or on (iat-mode=1). Currently, all of the default bridges, and probably ≈100% of BridgeDB bridges, have it turned off (iat-mode=0). As far as I know, iat-mode=1 has never really been tried in practice. The reason I propose trying it is the current blocking situation in Kazakhstan. According to reports, obfs4 (along with meek and vanilla Tor) are blocked there--not only the built-in default bridges, but also secret bridges from BridgeDB. A user on IRC has been experimenting with the Kazakh firewall; the blocking seems to be some sort of probabilistic traffic analysis--it doesn't always block and the rate of blocking depends on the network load. That user would like to have iat-mode=1 set on some of the default bridges to see if it gets through the firewall. Here are details on the Kazakhstan situation: https://bugs.torproject.org/20348 So I'm thinking it's a good idea to turn on iat-mode=1 on, say, 20% of the default bridges. That'll also be a good hedge against potential future blocking, as we can see if the bridges that use size and timing obfuscation are more resistant. It is safe for the server to turn on iat-mode=1 while the client still has iat-mode=0; the obfuscation will only apply in one direction but the connection will still work. ---- Addendum on how to activate iat-mode=1 on the server If you built obfs4proxy from source, and you are using commit a7a2575cab or later, you just need to add one line to your torrc: ServerTransportOptions obfs4 iat-mode=1 Unfortunately this commit is not yet in a released version. If you are using a released version, such as obfs4proxy-0.0.6, then you need to specify every other possible parameter in addition to iat-mode. Find the file <datadir>/pt_state/obfs4_state.json, and convert the JSON syntax into key=value syntax in a ServerTransportOptions, for example if obfs4_state.json contains {"node-id":"0af6c84b644856255dd858b2b189725db6ded51a","private-key":"d04e61ea38757ef67131a3032709e26bbf77a370aadf3950180fbf797973b365","public-key":"fedde584dc36265f9071ab6f7d845a9ae9e3cea5b9c956b252c1c7849aa2d006","drbg-seed":"5bb4dd59f507a89660c4d313f598ed56f4e9e0a620e129af","iat-mode":0} then add this to torrc: ServerTransportOptions obfs4 node-id=0af6c84b644856255dd858b2b189725db6ded51a private-key=d04e61ea38757ef67131a3032709e26bbf77a370aadf3950180fbf797973b365 public-key=fedde584dc36265f9071ab6f7d845a9ae9e3cea5b9c956b252c1c7849aa2d006 drbg-seed=5bb4dd59f507a89660c4d313f598ed56f4e9e0a620e129af iat-mode=1 You will know you need to do this if, when you try to set iat-mode=1 by itself, you get the tor.log error: [warn] Server managed proxy encountered a method error. (obfs4 missing argument 'private-key')

4 6

Cross-team OONI and Tor Browser project: default bridge checking
by Roger Dingledine 29 Nov '16

29 Nov '16

Hi folks, It looks like two of the default obfs3 bridges in Tor Browser have been broken for a while -- maybe for many months. I only noticed by accident today. I was about to open a ticket for the Tor Browser team to automate checking them, so they can proactively notice and fix things if they break. But then I thought, hey, OONI should be doing that testing from all over the world, right? There are these tickets from the past: https://trac.torproject.org/projects/tor/ticket/12544 https://trac.torproject.org/projects/tor/ticket/6414 Maybe this is a great collaboration point between the Tor Browser team and the OONI team? (For best collaboration, we might want to find a way to have it be more than the tor browser team saying "hey ooni, can you do this for us, thanks". :) --Roger

6 10

Fwd: [Netfreedom] IFF Call for Proposals--final submission deadline Nov. 28!
by Shari Steele 24 Nov '16

24 Nov '16

> Begin forwarded message: > > From: Sarah Bushman <sbushman(a)irex.org> > Subject: [Netfreedom] IFF Call for Proposals--final submission deadline Nov. 28! > Date: November 17, 2016 at 7:54:15 AM PST > To: netfreedom(a)lists.cymru.com > > Dear colleagues, > > *IFF Call for Proposals - Final Stretch until November 28th!* > > We're just TWO WEEKS out from the November 28th deadline to submit your session and workshop proposals for the 2017 IFF. > > IFF is by you and for you, so we need your voices in the agenda. Diverse and inclusive discussion means stronger support and solutions for the challenges we, as a community, face. Submit your ideas here: https://internetfreedomfestival.org/host-a-session/ <https://internetfreedomfestival.org/host-a-session/> > > Contact us at team(a)internetfreedomfestival.org <mailto:team@internetfreedomfestival.org> for questions. We look forward to seeing you in Valencia in March! > -- > > > Sarah E. Bushman > > Program Officer > > IREX/USA > > 1275 K Street, NW, Ste. 600 > > Washington, DC 20005 > > 202-628-8188 <tel:202-628-8188> x129 > > Skype: sarahbushman > > > > _______________________________________________ > Netfreedom mailing list > Netfreedom(a)lists.cymru.com > https://lists.cymru.com/mailman/listinfo/netfreedom

2 1

Tor Project Job Opening - Core Developer
by Erin Wyatt 23 Nov '16

23 Nov '16

Hello Everyone, We are looking to hire a Core Developer for the network team. We did recently hire a core developer who will start in February, this opening is in addition to that position. This is an open call and the application deadline is December 31, 2016. Please help us spread the word! If you have someone in mind, refer them to the job posting link on our website (below). If not, you can still help by posting, forwarding, and/or retweeting links to the position! Tor Project website: https://www.torproject.org/about/jobs-coredev.html.en <https://www.torproject.org/about/jobs-coredev.html.en> Twitter: https://twitter.com/torproject/status/801515058131931136 <https://twitter.com/torproject/status/801515058131931136> Thank you! Have a great week. Cheers, Erin Wyatt HR Manager ewyatt(a)torproject.org GPG Fingerprint: 35E7 2A9F 6655 45F9 2CB6 6624 BA0C 9400 F80F 91CE ricochet:65mmrt6kp6qgvpgm

1 0

Blog spam hygiene and a plan for the future
by Roger Dingledine 21 Nov '16

21 Nov '16

tl;dr: if you do a blog post and you enable comments (great), please disable comments when you're done paying attention to your post. Hi folks, If you do blog posts, please help us figure out a better plan going forward. My hobby this past weekend was cleaning up spam comments from the blog. The spam is now gone, and there remain approximately 740 (!) non-spam comments that are in the 'unpublished' state, across dozens of blog posts. In the medium to long term, our infrastructure for handling spam comments will get better, since Mike's friends are working on migrating the blog to a newer Drupal and hosting it in a place that will get updates more consistently. In the mean time though: (and probably these plans will serve us well post-migration too) A) I think our #1 problem is when people do a blog post, allow comments, maybe process and respond to comments for a while, but then forget about the post and let the spam comments pile up. The spam comments then make it harder for other people to find real comments, and things spiral out of control. A2) So if you're doing a blog post, and you want to interact with users, please do enable comments! Just be sure to deal with comments as they show up, and switch the post back to 'read only' when you're no longer planning to deal with them. A3) I don't want to force all people who write blog posts to be the ones who will handle the comments. What a great role for our teams! Maybe each team should self-organize to have a plan for responding to comments on their posts? The small teams can ask the larger ones for help; it will work best if people (1) communicate and (2) give advance warning for posts that will need extra attention. B) During this spam purge I turned off new comments on posts from: ailanthus alison arma art asn boklm gk isabela isis karsten mikeperry nickm phoul sukhbir weasel Most of those posts still have unapproved comments though. If you want, you could go back to your posts and approve some old comments, to help put a dent in that 740 figure. C) Who is still handling blog comments? I think it's down to just Georg, with Mikeperry temporarily on it because he just did a post? Once upon a time it was just me, and then Yawning took a shift for some months, and then for a while we had a "if you do a blog post, you need to either disable comments, or handle the comments for your blog post" policy -- and then I fear it's falling back to just Georg. D) To be clear, I'm not saying we should approve all of the non spam posts. Some of them are crazy distracting multi page rants, for example, and if our goal is to have a focused discussion of the topic of that blog post, it makes no sense to approve everything that isn't selling shoes. I think Georg and I feel strongly that it's valuable to have a way of interacting with our users that doesn't require them to sign up for the full modern cloud identity infrastructure in order to participate. In summary: If you want to help, please do! --Roger

2 1

Summary of meek's costs, October 2016
by David Fifield 21 Nov '16

21 Nov '16

Here's the summary of meek's CDN fees for October 2016. App Engine + Amazon + Azure = total by period all 2014 $600.63 + $917.89 + $0.00 = $1518.52 January 2015 $464.37 + $669.02 + $0.00 = $1133.39 February 2015 $650.53 + $604.83 + $0.00 = $1255.36 March 2015 $690.29 + $815.68 + $0.00 = $1505.97 April 2015 $886.43 + $785.37 + $0.00 = $1671.80 May 2015 $871.64 + $896.39 + $0.00 = $1768.03 June 2015 $601.83 + $820.00 + $0.00 = $1421.83 July 2015 $732.01 + $837.08 + $0.00 = $1569.09 August 2015 $656.76 + $819.59 + $154.89 = $1631.24 September 2015 $617.08 + $710.75 + $490.58 = $1818.41 October 2015 $672.01 + $110.72 + $300.64 = $1083.37 November 2015 $602.35 + $474.13 + $174.18 = $1250.66 December 2015 $561.29 + $603.27 + $172.60 = $1337.16 January 2016 $771.17 + $1581.88 + $329.10 = $2682.15 February 2016 $986.39 + $977.85 + $445.83 = $2410.07 March 2016 $1079.49 + $865.06 + $534.71 = $2479.26 April 2016 $1169.23 + $1074.25 + $508.93 = $2752.41 May 2016 $525.46 + $1097.46 + $513.56 = $2136.48 June 2016 $0.00 + $1117.67 + $575.50 = $1693.17 July 2016 $0.00 + $1121.71 + $592.47 = $1714.18 August 2016 $0.00 + $1038.62 + $607.13 = $1645.75 September 2016 $0.00 + $932.22 + $592.92 = $1525.14 October 2016 $0.00 + $1259.19 + $646.00 = $1905.19 -- total by CDN $13138.96 + $20130.63 + $6031.91 = $39301.50 grand total https://metrics.torproject.org/userstats-bridge-transport.html?start=2016-0… The number of users had a big drop, from 7,500 to 5,000. I initially thought that is was due to some new blocking event, because the drop was particularly severe in China. It affected several countries too, though, and that kind of coordinated blocking is unlikely. Our best guess for what happened was a bug in an Orbot release: https://bugs.torproject.org/20495#comment:8 It's since been fixed and the numbers went back to previous levels. == Amazon a.k.a. meek-amazon == EU (Ireland) 368M requests $442.35 2765 GB $218.62 Global 6M requests $6.78 27 GB $2.13 US East (Northern Virginia) 373M requests $373.43 2746 GB $215.36 -- total 748M requests $822.56 5539 GB $436.11 charge for alarms $0.50 https://atlas.torproject.org/#details/F4AD82B2032EDEF6C02C5A529C42CFAFE5165… == Azure a.k.a. meek-azure == This is the first time we've had charges for Zone 3 and Zone 4. According to https://azure.microsoft.com/en-us/pricing/details/cdn/, the zones are: Zone 1: North America, Europe, Middle East and Africa Zone 2: Asia Pacific (including Japan) Zone 3: South America Zone 4: Australia Zone 5: India Zone 1 6898 GB $600.10 Zone 2 328 GB $ 45.32 Zone 3 1 GB $ 0.22 Zone 4 3 GB $ 0.36 -- total 7230 GB $646.00 https://atlas.torproject.org/#details/AA033EEB61601B2B7312D89B62AAA23DC3ED8… Earlier reports in this series: https://trac.torproject.org/projects/tor/wiki/doc/meek#Costs

1 0

Notes from November 17 2016 Vegas team meeting
by Karsten Loesing 21 Nov '16

21 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 See this posting for context: https://lists.torproject.org/pipermail/tor-project/2016-April/000223.html Notes for November 17 2016 meeting: Roger: 1) We know of zero Tor talks that were accepted for 33C3. The Tor Browser one got rejected, the OONI one got rejected, and ahf's erlang one got rejected. While I admit that there's a little part of me that says "well ok, let's take our ball and go home", I think we need to be well connected to Europe now more than ever. 2) Any new news on the blog migration? 3) New network team job offer! Plus they're gearing up to find a second person. 4) I increasingly think we need a network team engineer who focuses on the censorship side of things. We have a growing number of countries where Tor is being blocked in new and surprising ways -- Kazakhstan, Egypt, Turkey, etc -- and there is nobody on the Tor side who is investigating them or working to fix them or even keeping up-to-date on what's happening. I get that there's value in having another more generic network team developer too, so I don't want to stomp in and declare this as a priority over that though. 5) I have a vague memory of suggesting an in-person Vegas team meeting sometime. Should we move that forward? 6) Should we start calling for volunteers to attend the Valencia festival? Georg: 1) We got our releases with the donation banner out (although this time it is was a way bigger PITA than usual). From Nov 23 on our users will see it (assuming everything works the way we think our code works) 2) SponsorU progress Arturo: 1) OONI hackathon in Berlin went great! 2) Discussed with metrics team about integrating some OONI data into tor metrics. Nick: 1) Hacking all day; team is covering well I think. 2) 0.2.9.5-alpha needs testing Kate: 1) Answering press queries, etc. 2) Edited Tor phone prototype blog post and contacted reporters; Wired is interested. Mike: 1) Kevin has finished about half of the deliverables on the blog contract. He is also working on a document for Hiro for how to admin and update it and Tor Labs. We should put him in contact with her. Shari: 1) Working on final crunch to start end-of-year campaign on November 22. 2) Writing letters to former donors/supporters and blog post for campaign. 3) Getting new CFGO up-to-speed. 4) Working on budget for 2017. Let me know if there are things I might not know to include. Isabela: 1) finished reports 2) linda is working with the metrics team on the redesign/update of user experience - i am helping reviewing stuff 3) trying to get the global south effort organized, ilv is helping and sukhe shared interest in doing something - i need to get many different people who are coming to me with some way to help on it connected so we can better coordinate efforts 4) catching up on a lot of things i have on my list like network team wiki page update, following up with sida and maybe changing our strategy here a little and decouple the website deliverable so we can get this money fast and do this work in 2017 (aiaiai) and following up on some PETS work with Roger. Karsten: 1) Making pretty good progress on UX project to redesign the Tor Metrics website. 2) Moving forward with JavaScript on Tor Metrics website discussion. Alison: 1) Most of my time right now is being spent working on scaling outreach given the huge surge in demand. -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJYMuvOAAoJEC3ESO/4X7XBCSMH/1yZ627OMRZXx70J5IqgAcLI veBOGPfUztvHFVsgoRgKiPuHm/pFzk/2lq0SwzYvJBGCTTbvWxQtNVvhlvMwYTPw FfI8SfgqcAt41HYaG2O8AAtL4veVO9umLbEp2hqkzAYWVvDuRvJ0jM0JXmI3g5wl DI0fXVmi2mZ+KxAgqOADBzanka+ZPkAbq46RsHb61kYy6AL11KMnHKcWmpaNNxD8 i19Og9XJeOThaCwTZhF50Au9wWVyciqnHhkCy5V5poqNhYWjG53NnhH0kay+sJbF FWra3wnl+YZDx2D6Gzqnrk5wnfQiDWxS318FN2E4G1SzcnV9dQ4hkVGii/epOWo= =amF8 -----END PGP SIGNATURE-----

1 0

Requiring JavaScript on Tor Metrics
by Karsten Loesing 17 Nov '16

17 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone, I'm moving this (old but recently continued) thread from an internal mailing list to this list as suggested by Roger. Any feedback would be most useful by Wednesday, November 16. Thanks! All the best, Karsten On 07/12/15 14:09, Karsten Loesing wrote: > Hi everyone, > > we're discussing changing the graphing engine on Tor Metrics from > generating static images on the server using R/ggplot2 towards > generating interactive visualizations using JavaScript on the > client. > > As a result, Tor Metrics will require Tor Browser users to switch > to Medium-High Security or lower. > > This switch has some potential with respect to visualizations, and > the visualization people in the metrics team want to do it. It > allows producing more graphs like Lunar's bubble graph: > > https://metrics.torproject.org/bubbles.html > > In fact, it would allow all kinds of visualizations like the ones > seen in the D3 gallery: > > https://github.com/mbostock/d3/wiki/Gallery > > So, my question is: can you all live with this change? > > The next step will be to ask users on tor-talk@, but I figured I > should ask here first. If I don't hear any strong objections by > Thursday, I'll go ask on tor-talk@. > > Thanks! > > All the best, Karsten On 07/12/15 15:22, somebody else wrote: > I assume it would be infeasible to maintain non-Javascript > fallbacks, correct? > > Likewise, I assume it would be too difficult (for now (?)) to try > something crazy-fancy like render the javascript versions on the > server and serve them as images in that case? [0] > > [0] I'm hand-waving about whether or not this is possible, but it > seems like it in theory, and at least one person has tried: > http://blog.davidpadbury.com/2010/10/03/using-nodejs-to-render-js-charts-on… On 08/12/15 00:34, somebody wrote: > I don't understand why you would want Tor users to lower their > security in order to get prettier graphs. Is there some obvious > thing I am missing? > > Personally I run with Javascript disabled on the vast majority of > web sites I access (via NoScript), and with third party "included" > Javascript disabled virtually everywhere (via PrivacyBadger and > sometimes RequestPolicy). Having web sites run their own choice > of programs in my computer seems like a really stupid idea. I can > only assume that its prevalence as a technique reflects how little > respect the average web site has for the security of its users. On 09/12/15 08:45, another person wrote: > I'd like to know how much work it would be. On 09/12/15 13:59, Karsten Loesing wrote: > I'll try to find out. I think that having non-JavaScript > fallbacks written in a different language would be infeasible. But > I could imagine that we render D3.js graphs on the server using > Node.js and return images to the client. > > I'm mostly worried about the lack of interactivity. I'd really > want to get away from requiring a full round-trip from client to > server and back just to change something in the displayed graph. > Maybe we can keep them somewhat interactive, or at least add > tooltips, by using SVG as image format. > > But please understand that while I'm doing okay at processing > large amounts of data, I don't know much about web development. If > people here have ideas, please let me know! > > Note that investigating these options may take a while, mostly > because people in the metrics team are busy. But we won't switch > to client-side JavaScript before we know about possible > alternatives. > > Thanks for the feedback. This is very helpful! > > All the best, Karsten On 12/11/16 16:37, Karsten Loesing wrote: > Hello everyone, > > apologies for digging out such an old thread, but after almost > starting a new thread on the exact same topic I remembered that we > had this discussion almost a year ago. I figured it's better to > continue this thread to avoid discussing the exact same things > again and instead add new thoughts below. > > So, on Thursday, Linda, iwakeh, and I met in Berlin to talk about > making the Tor Metrics website more usable. We came up with some > pretty good ideas to better address the various user types---from > journalists to data scientists---coming to the Tor Metrics website > to learn interesting things about the deployed Tor network. We'll > share results with you in a few weeks from now when there's > something to see and click on. > > But in this context I want to bring up the topic of JavaScript > once more. > > To be clear, our immediate plans---including reorganizing > information and displaying sparklines as quick entry points into > the data---don't require JavaScript on Tor Metrics. And even our > planned improvements might work without JavaScript---including more > customizable graphs and even a dashboard with user-selected > graphs---can be made to work without JavaScript. Though the latter > will be a stretch. > > The question is: do we have to keep stretching by avoiding a web > techology that would make our lives and the lives of our users so > much easier? > > This isn't really something that we can work around by generating > graphs with a JavaScript library on the server. I'd want us to > switch to another graphing framework such as R Shiny (which I used > for the webstats prototype) or D3.js (which we currently use on Tor > Metrics just for the bubbles graph, though not in the most > efficient way). > > - From a development perspective this switch would make a lot of > sense, because we'd have to write a lot less code for new graphs > and because there'd be potential contributors out there who'd > appreciate working with a known framework. Our current graphing > engine doesn't scale much longer, and this does slow us down. > > Note that I'm not arguing to use JavaScript in all places, just > because we can. I'm in favor of keeping all the parts of Tor > Metrics where we provide textual or static information entirely > JavaScript-free, so that our data will still be available to users > that don't have or don't want to use JavaScript. And services > like ExoneraTor could easily stay JavaScript-free. > > But the parts of Tor Metrics where we're providing visualizations > and letting users explore our data would require JavaScript. This > would include all graphs and tables, because we shouldn't be > maintaining two graphing engines. > > So, how do we decide this? I believe that this should be a > Tor-wide decision. My main worry is that we're sinking weeks and > weeks of development effort into this switch without many Tor > people noticing, and then once we publish and they get aware, we > need to roll back, wasting all the effort. > > But to be honest, we're wasting effort right now by keeping the > workarounds and implementing hacks with dynamically generated HTML > forms and potentially dozens of parameters just to avoid the devil > called JavaScript. This feels like a bad use of our time. > > Here's my suggestion: unless somebody raises a valid concern how > requiring JavaScript on Tor Metrics is *bad for Tor*, say, by next > Wednesday, November 16, we're putting this on the hold again. > (That's the day before the next metrics team meeting and Vegas > meeting, and it should be enough time to raise your voice.) > > Otherwise we'll switch. > > Oh, and if you're in favor of switching, please consider saying > that, too. Thanks. > > All the best, Karsten On 13/11/16 05:04, Roger Dingledine wrote: > Does this mean that we'd be breaking the "download a static version > of the graph" feature too? I use that feature a lot for grabbing > snapshots to put into presentations, and we also want to use it for > pulling in metrics graphs in blog posts, e.g. > https://blog.torproject.org/blog/tracking-impact-whatsapp-blockage-tor > > as well as for external journalists. > > Oh, I should also say this would be a great topic for the > tor-project list, since it doesn't need to be sekrit (and since > then other people could know that it's a topic we're considering, > and maybe even help us make the right decision). On 13/11/16 10:08, Karsten Loesing wrote: > It's quite easy to implement that feature using Shiny, for > example. Either Shiny would produce a .png file that you can > download using your browser's "Save Image As..." feature, or there > would be a "Download Graph" button. It would be just a few lines > of code. > > And we'd be able to provide features like a "Download graph data" > button with just a few more lines of code, which would require a > lot more effort right now. > > Good idea. How about I move over the thread with all responses so > far and with names of previous posters redacted? I can do that > later today, unless I hear it's a bad idea. > > All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJYKIymAAoJEC3ESO/4X7XBMFUIAMAP1LJYv+QEEUtQN5AAXaGP ZvmPrIlWrnhvoY1Uy/iPkYMsLqTtHNn3RkIfvfBj5LOafBBinkRL/pm8DHnHDrGw OLoo12t1ZHKiQk62eB+FNnnBfXdDoitdcaFCm92N+aItHY37qe9pJRICkA/QvtwA eUHRBAsrn/g6F6CSQT+jpSTJfCOnmWuPrD9nEqA6DD3e37+f1MDyBnre/mgMQG2e hZ5jhdwToX4z4LBIL4ilJoFkWjLDPlc4H+MdaMEXN3CHwd5XTXK7xJUhsaJwb/+k JzujeI5J7p6kJCEx2PbhCZMqSyNLmjiFjTWE0Xi1YNLyaQ6QtDvf8nzpBdRcvkY= =HA4c -----END PGP SIGNATURE-----

6 10

About the importance of website metrics
by Nima Fatemi 16 Nov '16

16 Nov '16

Hey there, I just found out about https://tor-metrics.shinyapps.io/webstats/ through 'boklm' on IRC and after playing around with it for a couple of mins I found so many important and noteworthy things and it got me excited too much to not to share it with the list. Here's just one of the things I noticed. If you look at this graph from Aug 2016 to Sep 2016 [1], you'll notice that: - the number of hits on home page are (~55k on average) lower than the number of hits on download page. - the number of initial downloads are (~50k on average) lower than number of hits on download page. Of course it needs much deeper analysis but that quick look tells me one of the primary goals of the people who visit Tor Project website seems to be downloading Tor Browser and a big portion of them fail to do so. We can definitely use this data while rebuilding the website. You might say it's obvious that the download of our primary product on the website, but it's something else when you can measure it with actual data. Specially when things aren't as good as their potential and when there's room to improve. This is really exciting and amazing work. Kudos to metrics team and Sebastian for providing anonymized webstats and visualizing them. PS: I've a question: how often do the web stats get pushed? seems like the last push was on Sep 15th. And whether it's possible to have them in a closer-to-real-time basis. (ie. once a day). PPS: Apologies about the cross-post. It seemed like this email is valid for all three lists, and members don't necessarily overlap. [1] https://people.torproject.org/~nima/ux/home_dl-page_dl.png Cheers, -- Nima 0X58C4B928A3E218F6 | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

2 1