tor-project November 2017

tor-project@lists.torproject.org

17 participants
23 discussions

"Capture the onion" + Tor village at next Defcon
by Roger Dingledine 17 Jan '18

17 Jan '18

tl;dr I would like to (A) design a "capture the onion" contest to get people trying to break the next-gen onion service protocol and code, and run the contest at the next Defcon; (B) craft a funding proposal to help us do A well; and (C) run a Tor village at the next Defcon too. Part A: We have this new onion service design, and one of its features is that we hope it is now impossible to discover onion addresses through in-protocol flaws. How do we know that we designed it right? How do we … [View More]know that we implemented it right? Imagine if we deploy a local Tor network on the Defcon network, where random Defcon attendees can run relays. The anonymity properties would be terrible, because the trust isn't distributed over a large area and because Sybil attacks and other shenanigans are likely. But new-style onion services should be able to advertise themselves, and have their onion address remain private, even in this terrible environment. The goals of the contest would be getting people to (1) beat on our new onion service design, and (2) learn more about the Tor design and code. A proper contest has a variety of puzzles at a variety of difficulty levels. (If the only challenge were to uncover our private new-style onion addresses, most people would fail, and they would quickly become bored.) So we would want to include intermediate challenges. One example would be to run old-style onion services too, since there are known attacks against the old design. In an ideal world we'd brainstorm 15 or 20 puzzles, not all onion service related, to keep the attention of a variety of skill levels, and more importantly to raise the amount of Tor clue for people at each level. (The way you actually "capture" an onion could be by visiting the website behind it, and being given a token that proves you went to it.) Many fun contest designs include both offense and defense, i.e. they pit teams against each other rather than against the game itself. I don't know how to make use of this point, but maybe we will come up with ideas. I also pondered whether we could team up with an existing contest, e.g. ask the capture-the-flag people to be a module in their bigger plans. But capture-the-flag has been going through contortions to keep the offense from being too easy -- for example, this year they surprised people with a 27-bit architecture that uses 9-bit bytes and is middle-endian. Sounds fun if you're into that, but maybe not so useful for our needs. :) Part B: Our SponsorR program manager has expressed interest in helping to make this idea happen. In fact, it started out as his idea. He's asked us to put together proposals for the low end, the medium end, and the high end of what it would cost. (I asked him for hints on what he meant by each category, and he wouldn't commit, saying instead "whatever it would cost".) Piece one that would want attention is contest design, i.e. coming up with the puzzles, and figuring out how one would implement them, and also balancing the game so it's fun -- everybody can make progress at something, there aren't any puzzles that will destabilize the whole thing, it's clear who made the most progress, etc. Piece two would be sorting through how to harden a Tor network to survive being run in this terrible environment. We'd probably want to make the directory authorities more robust, like by making them onion services themselves, and/or making them "push" the consensus to the fallbackdirs rather than being able for pulls. This piece could involve large amounts of design and coding, so we'd want to make a roadmap and prioritize items. (We will want to declare certain types of attack out of scope for the contest, and frowned upon if people do them, but also we will want to show up with a robust network.) Piece three would be the actual operations of the contest, including deploying the network and sandboxing the components, but also including running everything during the weekend. The first year will be a learning experience all around, but the more we can learn surprising things rather than expected things, the better. :) We might also be wise to deploy the network, and parts or all of the game, beforehand for playtesting. And I bet some of the puzzles will work better if people know about them, and prepare for them, beforehand. Part B2: Now, there is a strong argument that if what we want most is an exploit on the new code, we should sign up for Pwn2Own or the like, and offer a $10k+ prize. After all, weekend contests are fun for raising interest and getting people to learn more, but in isolation they may not be an efficient way of getting people to discover complicated bugs. I think it's worth exploring both approaches, and maybe combining them in some cool way if we can think of how best to do it. Note that we already have our bug bounty program in place, and it would be very straightforward to highlight and advertise this category of bug for the top tier $3k payout, or even a higher payout if we wanted. But coordinating with a higher profile zero-day event could still bring more attention to the topic. Part C: A bunch of people I ran into at Defcon expressed interest in a Tor village next year. Rather than taking on all the logistics issues ourselves, I've instead been coordinating with organizers from two existing villages, who each have no plans to use their village space from 5pm onward each evening. This way we could have a designated "hang out and answer Tor questions" spot, with quite low logistics costs. And if we wanted to make it into something more we could. Eight years ago, when I was last at Defcon, I saw many many Tor shirts. This year I saw almost none. We have definitely been paying less attention to the American hacker scene lately than we should have been. I think it would be really great to get a huge pile of Tor shirts there next year, perhaps with a table in the Tor village, and perhaps also at already established booths like EFF and Calyx. --Roger [View Less]

2 2

Intent to Minimise Effort: Fallback Directory Mirrors
by teor 09 Jan '18

09 Jan '18

Hi, Fallback directory mirrors help Tor clients find the tor network, and take load off Tor directory authorities. [0] Since Tor 0.2.8, I've generated a fallback directory mirror list every 6 months or so. I'd like to minimise the amount of effort I put into this in future. (But I think it's valuable, so I won't abandon it.) I'm happy to spend half a day every 6 months to update the input lists and run automated checks on a bunch of relays [1]. But contacting relay operators to agree to go … [View More]on the list (opt-in), or check their relay details, is a time-consuming process. Here's what you can do to help: * We ask relay operators to opt-in. We could ask them to opt-out (contact us to be taken off the list) instead. The opt-in list hasn't been updated for about a year, so we will have to switch to opt-outs soon to get enough good fallbacks. - If we do opt-ins, who is going to contact relay operators? - If we do opt-outs, how do we make sure operators know they can opt-out? - (And how do we make sure we get stable relays?) * I wrote down the opt-in process in [1]. Maybe it's too complicated. - Can you design a better process? * If you're good at mail merges or scripting mail, that's one way we could contact a bunch of relay operators without it being time-consuming and error-prone. - Can you do mail merges? (I can't!) * We can improve the fallback script to make it easier to use. (See [1] and [2].) - Can you write python? If anyone wants to help out with any of these things, let me know. I'm going to do a fallback directory mirror refresh some time in the next few weeks. About 12% of fallbacks have failed, and it looks like this is placing extra load on the directory authorities. [3] There's already a ticket for it [4], and I'm happy to do a minimal refresh. If we don't get 150 fallbacks from a minimal refresh, I'll switch to opt-out and see how that goes. [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [1]: https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectory… [2]: https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… [3]: https://lists.torproject.org/pipermail/tor-relays/2017-August/012886.html [4]: https://trac.torproject.org/projects/tor/ticket/22271 T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n ------------------------------------------------------------------------ [View Less]

4 7

reducing spam on bad-relays@?
by nusenu 28 Nov '17

28 Nov '17

Hi, I know bad-relays@ is more exposed to spam because it does not require subscription for obvious reasons, but would it be possible to reduce the amount of spam on that mailing list by sending potential spam candidates to the moderation queue? thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

Please welcome Tor's new Outreachy intern, Parinishtha!
by Alison Macrina 27 Nov '17

27 Nov '17

Hello Tor community, I'm pleased to introduce Tor's new Outreachy intern, Parinishtha Yadav. Parinishtha will be working on some things related to user support and communication, including helping with content for the forthcoming support portal and organizing user feedback/issue reports for developers. Please join me in welcoming Parinishtha to our community! Here's more about her in her own words: Hello! I am Parinishtha, a fourth year student at IIT Roorkee, India, who will be working as … [View More]

1 0

Network team meeting notes, 27 Nov 2017
by Nick Mathewson 27 Nov '17

27 Nov '17

Hi! You can see a transcript of our latest meeting at http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-11-27-17.00.html Below is a copy of our pad. ================= Network team meeting pad, 27 November 2017 Welcome to our meeting! Every Monday at 1700 UTC on #tor-meeting on OFTC. (This channel is logged while meetings are in progress.) Want to participate? Awesome! Here's what to do: 1. If you have updates, enter them below, under your name. 2. If you see anything … [View More]you want to talk about in your updates, put them in boldface! 3. Show up to the IRC meeting and say hi! Note the meeting location: #tor-meeting on OFTC! (See https://lists.torproject.org/pipermail/tor-project/2017-September/001459.ht… for background.) ===== This of course is the way to talk to dragons, if you don't want to reveal your proper name (which is wise), and don't want to infuriate them by a flat refusal (which is also very wise). No dragon can resist the fascination of riddling talk and of wasting time trying to understand it. -- J.R.R. Tolkien, _The Hobbit_ ====== Meeting notes from last week: * https://lists.torproject.org/pipermail/tor-project/2017-November/001576.html Announcements: - Sponsor M is no longer billable: please let me or isabela know if you need to do more work on M stuff, and we can work something out. - On the roadmap spreadsheet: Please start taking december/january tasks. (If somebody else has already taken something you want, please talk to them and/or add yourself too.) https://docs.google.com/spreadsheets/d/1Ufrun1khEo5Cwd6OwngERn829wU3W3eskdr… - Team rotation for December please: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/TeamRot… - Please review stuff in review-group-26: https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… - Remember: many people take time off in December! If you're going to do something in December that requires another person, please confirm that they will be around. - Soon it will be time to triage 0.3.3.x tickets. Please assign tickets in that milestone that you will do to yourself. - Aiming for many releases next Tuesday (5 Dec) Discussion Topics: - meeting time -- 1800 UTC is yes. Not sure whether to track DST yet. Going to say "yes", but we can change our mind between now and the next DST transition. Will flip a coin to decide whose DST. teor: - Last week: (actually two weeks, sorry it's so long!) - Revised prop#283, which moves relay IPv6 ORPorts from microdescs to the microdesc consensus - Started designing relay IPv6 ORPort reachability checks, turns out they need IPv6 relay extends https://trac.torproject.org/projects/tor/ticket/24404 - consensus health got a "ReachableIPv6" pseudo-flag, thanks tjr! (#24287) https://consensus-health.torproject.org/ - Relay Search (Atlas) got IPv6 ORPort and IPv6 Exit "additional flags", thanks irl! (#10401) https://atlas.torproject.org/#toprelays - Merged code that adds rend point IPv6 addresses to HSv3 client intro cells, thanks neelc! (#23577) (There's still more work to be done for HSv3 IPv6, see #23493.) - Patched metrics onion service graphs to show which ones measure v2 and v3 services (#24048) https://metrics.torproject.org/hidserv-dir-onions-seen.html - Wrote and rewrote parts of the new "PrivCount in Tor using Shamir Secret Sharing" proposal https://github.com/teor2345/privcount_shamir/commits/noise-limits - Fixed a nasty little bug where Tor checks cached bridge descriptors, rather than confirmed running bridges (#24392) - Opened a ticket about pruning our list of supported consensus methods https://trac.torproject.org/projects/tor/ticket/24378 - Why is a zstd-compressed microdesc consensus larger than a gzipped one? Am I doing it wrong? https://trac.torproject.org/projects/tor/ticket/24368#comment:1 [nick: I tried to answer, but found even more questions! See the ticket.] - Tried to help out asn with the microdesc fetch bugs - Kept implementing PrivCount features for the next release - This week: - PrivCount Experimental features, bug fixes, and release komlo: This week: - Submitting #23881 (rust logging) for review (hopefully Tuesday) isabela: last week: - sent out reminder to testers for Nov test - worked on dec 1st deadlines - met with asn, geko and antonela on HS UX tasks - elected a couple for December this week: - focus on my deadlines - organize hs states on google doc for antonela to add icons - checking in on moat server <- question for isis catalyst: last week (2017-W47): - investigated Tor Browser error reporting oddities (#24367, now specifically in #24428; thanks brade!) - investigated client-in-future clock skew errors * with an expired consensus that's not reasonably live (+27.5h) it looks like stuff hangs far earlier than with the expired yet reasonably live (+3.5h) case * looks like there are situations where we might hang indefinitely but don't because enough relays are unreachable that we hit the warning error count * it also looks like +27.5h gets a "trusted" clock skew indication from a dirauth sooner than +3.5h does? this week (2017-W48): - bug triage - start sketching out larger-scale bootstrap progress/error reporting improvements - roof monsters are eating my roof so i'll be sporadically unavailable - investigate sporadic oniongit CI pipeline failures (low disk space?) - starting to think that a heuristic for inferring client clock skew from non-dirauth relays might start looking like EWMA (with incremental variance too); maybe we can refactor the circuitmux EWMA code to help with this? Nick: last week: - Released 0.3.2.5-alpha - Reviewed open proposals wrt privcount; commented. - Started implementing some privcount backend stuff in Rust - Worked on a faster monotime_coarse_absolute() for 32-bit platforms (#24374) - Worked on free-macro rewrite (#24337) - Opened review-group 26. - Reviewed and merged various fixes - Fixed bugs in consensus diff corner cases. - Analyzed hashring storage failure probabilities (#23170) and workarounds (#24425, #24426) - Wrote trivial C backend for Rust to call our logging functions - Analyzed and wrote fixes for the bugs GeKo found with STACK (#24423) This week: - Try android performance tools (sponsor 8.) - Inform packagers and users of upcoming releases on/around December 5. - Backport more tickets to earlier stable series, as appropriate. - Write/revise TROVE advisories and revise patches (as needed). - (Also get CVEs) - Prototype and publish revised privcount/shamir proposal - Review some stuff in review-group-26 - Publish other pending proposals (if any) - Clarify and revise our security policy on bug severities (#22962) - Review December roadmap; convince everybody to take on tickets there. - Other TBD. - Please grab me to talk about design or code whenever you want - Meet with a namecoin person who's in town. dgoulet: - Last week: * Worked on TROVE-2017-12. Needs review/merge on the security list. * Worked on #24313 HS bug. A patch exists. * Finalized #23709 that is removing in/out channel's queue. That branch is in need_review for 033 and has bumped the code coverage of channels to 84%. I've been running that code on both my relays with running with valgrind. So far so good. * After the above, I've made a "cell tracing" branch that tracks cells from inbuf to outbuf. Idea is to have a way to measure performance of the cell fast path at every steps and try to find possible bugs with cells stuck for too long or try to answer questions like "why 2.78 seconds on average?" (not a "confirmed number"). * Tried to find the bug on #24346 but we need to add more logging to hunt it down. * Review couple tickets in review-group-25. - This week: * Re-re-revalidate the cell tracing branch, clean it up and run it more thoroughly to try to identify where and why we might have cell latencies in order to identity if the scheduler is at fault. * Continue ticket review/patches for 032 and 033. * If I receive my Android device this week, I'll maybe try with ahf to setup the dev. environement to profile HS and scheduler. asn Last week: - Got #23817 merged. This should help a lot with #21969. - Attended UX+onion+TorBrowser meeting. tl;dr is that we should focus on #23247 in the short-term, and we also discussed #21952. We have another meeting this Wednesday. This week: - Catching up with last week's backlog. Please let me know if I should pay attention to something that I'm not mentioning below. - Continue review of #23100 and #23114. - Plan development on md/guard issues (#24113, #23863) - Figure out next most important guard/prop224 stuff that I should be doing. mike: Last week: - Began testing #23101 (pre-building HS-specific circuits for vanguards/pinned middles). Still needs more testing, unit tests, cleanup. This week: - Cleaning up #13837 (pinned middles) and #23101. Let them run for a while with prop247 simulator, monitor paths built and timeout rate, write tests, etc. - Maybe write a simple patch for #24228 (to slow down CBT circuit building by 3X or so)? ahf Last week: Sponsor 8: - Landed `simpleperf` notes in tor.git - Optimization meeting with Nick - Looked into n8fr8's new split orbot work. - Do multiple builds for different ABI's for testing to get 64-bit information. - Put Tor's bench+tests on device via the Orbot APK, but still no way of automatically running them without using adb/shell. - Started looking into the event loop code in Tor for instrumentation. - Looked into HC's (from Guardian Project) work with automated Orbot-build-via-gitlab-ci-to-fdroid-repository(!) This week: Sponsor 8: - Get event loop instrumentation into tor.git - Update sponsor 8 wiki documentation on n8fr8's split orbot changes as that will probably simplify things for people. - Get `simpleperf` results for via-onion/via-exit/bootstrap tests for both 32-bit and 64-bit for comparison. - Help others (David and Nick) with getting up and running on Android. Misc: - Look into #24368 [compression, zlib, zstd] and maybe see if we should tune our parameters there (as per Nick's comment). - Tor specification meeting with Mozilla. Maybe: - Look into David's tracing code in Tor and see if it can be made to work with the Android NDK tracing features. isis: last week: - revisited prop#249 prop#269 and prop#270 and began revising - looked at my beginning implementation of prop#269 from last year - re-read a couple lattice papers and reviewed a reference implementation of one of the NIST submissions - took the rest of the week off this week: - re-raise prop#249 discussion on the ML and hopefully put that one into "accepted" state - re-write prop#269 and prop#270 - track down and fix some bug in the moat server - work with dcf on getting the meek tunnel working? [View Less]

1 0

List announcement: tor-packagers@
by Damian Johnson 26 Nov '17

26 Nov '17

Hi all. I'm pleased to announce tor-packagers@, a list for our lovely tor packaging community... https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-packagers https://trac.torproject.org/projects/tor/wiki/doc/packages Care to get involved in packaging? Then please sign up! This is a moderated, low-traffic list for package maintainers to stay in the know about new releases, and for tor developers to pitch their project when they'd like to have help packaging. Cheers! -Damian

1 0

Weekly network team meeting notes (20 Nov 2017)
by Nick Mathewson 20 Nov '17

20 Nov '17

Hi, all! You can find the logs of our latest weekly meeting here: http://meetbot.debian.net/tor-meeting/2017/tor-meeting.2017-11-20-16.59.html Below are our notes: ============== Network team meeting pad, 20 November 2017 Welcome to our meeting! Every monday at 1700 UTC on #tor-meeting on OFTC. (This channel is logged while meetings are in progress.) Want to participate? Awesome! Here's what to do: 1. If you have updates, enter them below, under your name. 2. If you see … [View More]anything you want to talk about in your updates, put them in boldface! 3. Show up to the IRC meeting and say hi! Note the meeting location: #tor-meeting on OFTC! (See https://lists.torproject.org/pipermail/tor-project/2017-September/001459.ht… for background.) Meeting notes from last wek: * https://lists.torproject.org/pipermail/tor-project/2017-November/001568.html Announcements: - Remember, it's a US holiday on Thursday. Some US folks will be on limited availability Wednesday afternoon through Monday. - Sponsor M is no longer billable: please let me or isabela know if you need to do more work on M stuff, and we can work something out. - On the roadmap spreadsheet: Please start taking december/january tasks. (If somebody else has already taken something you want, please talk to them and/or add yourself too.) Discussion Topics: - 0.3.2 planning - Time allocations dgoulet: - Last week: * Various 032 tickets work (review and patches). * Finalized the hs v3 control port support (#20699). Missing some unit tests before ready for review. * Worked on TROVE-2017-012 * A bit of thinking on channel/scheduler problem especially how to better handle DESTROY cells. I've started writing a proposal (not finished). (https://lists.torproject.org/pipermail/tor-dev/2017-October/012536.html) - This week: * Making #20699 in needs_review. * As usual, ticket work on 032 milestone. * Tackle #23709 which is the removal of the in/out queues from channels. This will need much more unit tests than we currently have so I expect most of the work will be writing those and chasing down bugs. * Continue the "cell handling" proposal. Isabela: Last week: - working on proposals and reports (never ends) - sent Tor Launcher check in email - start to QA the new UI too :) - scheduled sync for HS UX tasks (which is schedule for wed) This week: - send out an earlier reminder to testers for Nov test (left for last moment the previous months :( - review where teams are on roadmap / state of deliverables - I have a big deadline on Dec 1st so I might be busy with that just FIY† asn Last week: - Progress with md (#21969) work. #23817 got merged! Might need a bit of a fixup still. Progress with #24113 and #23863 but need more work. - Reviewed #23100 some more, but got stuck with #23114. Will continue next week. - Wrote two UX improvement proposals for onions: https://lists.torproject.org/pipermail/tor-dev/2017-November/012595.html https://lists.torproject.org/pipermail/tor-dev/2017-November/012610.html - Opened master ticket for onion service DoS improvements: #24298. We got many requests to look into this but we didnt really do much, let's use that ticket to coordinate. - Wrote some things for our censorship circumvention position. This week: - Hopefully finalize #23817. - Attend UX+TB+network team meeting on Wednesday. - Take some personal time off. Mike (may miss part/all of meeting :/) Last week: -- Git juggled #23100 and #23114 into more reviewable shape. - Did some work on #23101 - Reviewed and discussed #23681 This week: - Maybe get #23101 working? komlo: (will be on IRC for the meeting ~15 minutes late) This week: - I want to have a patch for #23881 this week (adding logging support for rust) - One question about this: we use macros on the C side to wrap log_fn_ (such as log_warn), I'm not sure if we want to replicate this in Rust, or if we should instead create helper functions in C. - I was thinking about taking a first stap at #23891 (writing a blogpost about Rust) to get a long headstart and lots of feedback before the 0.3.3 release ahf: Last week: Sponsor 4: - Attended the OTF summit together with GeKo, Shari, and the OONI people. Some highlights: * Met with Hans from the Guardian Project and discussed a lot of Android tooling/problems I have had. * Met with two activists from Nigeria who gave me some insights in mobile usage in their country (focus country for Sponsor 8). We exchanged contact information to be able to stay in touch. * Conversations with the Briar people about what they could be interested in from Tor. Sponsor 8: - Tried out my `simpleperf` notes in a clean VM to ensure things worked. Misc: - Reviewed some small patches in #24167, #24097, and #20963. This week: Sponsor 8: - Talk with Nick about initial set of optimizations for bug #24062. - Get `simpleperf` document into the `doc/` tree of tor.git. - Begin optimization work. - Land my Android logging patch for #24362. - Look at Nathan's "split" Orbot work. [nickm: please let the rest of us know what you find.] [ahf: yes, will update the https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Sponsor8 page for it] - Finish automated build's of Orbot-with-tor-master to an fdroid repository and find people who are interested in testing it out (maybe some people from the network team are up for that?) Nick: - Last week: - Worked on separating key/cache directory for limited disk users. - Hunted/triaged bugs in 0.3.2 milestone. Fixed some - Solicited review on 24107, 24204 APIs (hibernation and communication for mobile) - Started work on making tor restartable in-process (#23847), which led to #24337 (make all the X_free()s into macros that NULL their targets). Is that a good idea? - Dove into glibc 2.26 and how to make it play nice with libseccomp2. - Backported various fixes. - Updated UTF-8 proposal - Reviewed David's channels thread. - This week: - Release 0.3.2.5-alpha (on Tuesday or Wednesday!) - Ahf, do you have time to talk about prioritizing the optimizations to be made for mobile? [ahf] Yes! Let's do it early in the week? - Taylor, would you like to talk more about bootstrapping some time? I can make time tonight or tomorrow or maybe even another day. [catalyst: yes! tomorrow probably works] - Try to finalize fixes for TROVE-2017-{009,010,011} [dgoulet] TROVE-2017-12 as well :) [nickm] I'm hoping you'll finialize it :) (On the mailing list) (will look) - Try android performance/developer tools recommended by ahf - Fix or defer remaining consensus-diff tickets in 0.3.2.x - Analyze severity of HS descriptor hashring failures corresponding to missing ed25519 identities. - Continue work on #23847 (restartable in-process tor). - Time permitting, start groundwork on making Tor wake up less often. - Open review-group-26, if we finish review-group-25 (hint, hint) - Time permitting, write a logv variant for komlo to use in rust for 23881. catalyst: Last week (2017-W46): - tried to make more progress on bootstrapping stuff; useful talk with nickm - TB auto-update did some weird things (#23968 is back) - useful chat with Sebatian and others on IRC about expectations about LOG_NOTICE messages and how comprehensible they should be to relay ops. we should clarify these expectations and document in easier-to-find places This week (2017-W47): - talk more with nickm about bootstrapping stuff - investigate the cold cache guard state initialization stuff some more in the client-is-in-the-future scenario (having narrowed down +3h..+4h as the possibly most problematic case, confirm whether that holds in practice) - review some CoC stuff - do we want to move our meeting to 18:00 UTC? isis: last week: - fixed some bugs in the moat server and deployed it #22891 - spent a bunch of time debugging the meek -> apache -> meek -> bridgedb tunneling, gave up and emailed dcf asking for help - started rewriting prop#269 - reread the XE5 lattice handshake reconciliation paper and started thinking about what that would look like for another PQ proposal - made my tooling/setup for testing out alpha releases locally better this week: - finish up proposal writing - still haven't done expense reports (oops) [View Less]

1 0

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

17 Nov '17

Notes for November 16 2017 meeting: Nick: 1) Planning next alpha release (0.3.2.5-alpha) around 22 or 27 Nov; and for stable releases and 0.3.2.6-rc around 8 Dec. 2) Who should help figure out what a Censorship Team is? [Roger, please review the pad!] Georg: 1) New releases are out (7.0.10 and 7.5a8) 2) Blog post about our Fastly usage, who is working on that one? Deadline is probably Friday next week (Nov 24) 3) Being at OTF and talking to quite some people: Adam from OTF, Torsten from the … [View More]

1 0

A little bit about tor browser user path + user feedback on it!
by isabela 16 Nov '17

16 Nov '17

Hello Tor! USABLE project from Internews collected some feedback [attached a summary of it] from a group of 10 East African digital security trainers that they met earlier this year. They will be doing more of these and we hope to coordinate with them as well, giving feedback on their process, getting their help to test improvements we will be working on and so on. I decided to take this opportunity to talk about the user path for tor browser :) I would like to start to use the areas of this … [View More]path when describing user actions so we can think by those different moments of the user experience. For instance, this feedback Internews collected is more focus on the 'acquisition' part of this path. So what are these moments for Tor Browser? Before Montreal I was working with TB team, helping them prep stuff for their roadmap session. I asked them to organize tickets by 'awareness','acquisition' and 'retention'. These are very common phases that you can identify on any product. But for Tor Browser, this is how I think of them: awareness Is the moment someone hear, read, learn about Tor. That can be at a talk, training, social media or through a friend. So our presence on social media, our support to trainers, our outreach efforts, all goes into this. The common next step for someone here is to either search for Tor to find our site or try to go directly to our site. Or in some cases search for Tor on app stores. So our work on what information is displayed at search results, our work on our app store pages and most important, our work for solutions when these common paths are censored, like Get Tor, is very important. Here is an example of improvement focus on the above, we changed the copy of the search results to give a tip to the user in case they can't open our site [1]. Looking at data early this year (specially from our play store analytics page [2] we are not doing bad here, most people who comes to the store downloads the app. And looking at the steady number of downloads of the desktop browser [3] is not that bad either. Of course we need to improve a lot, our sites are not localized and are terrible. But in general we are doing better here than in other areas of the user path. acquisition If this was a social media app, acquisition is the 'sign up flow' the user goes through. For Tor, the way I think of it is that acquisition are all the steps the user goes from being able to download the browser and install it, then being able to launch and connect to the Tor network. Once the user has the browser open and can browse the internet, they are done with their acquisition path. You will see at the Internews feedback pdf, the tasks they asked the user to perform are around this area. Even though this feedback is not a big surprise for us, it does help us build a baseline to support our reasons to change things :) and of course, with this baseline we can later on, validate if our changes actually helped user. If their perspectives related to the experience has changed. For instance, problems related to tasks #3 and #6 of the attached pdf are things we are working on or has already on our roadmap[4]. With this baseline, we can test our changes and compare if we have improved from there. BTW - we assume we are loosing a lot of people here by looking at download numbers of clients and actual connections at the network. that said, this are assumptions, we can't prove anything :P retention This is one of the most important and hard parts of the user experience. For one we have no idea who we are retaining today, because we don't track that. We don't know if the 2M connections on the network today are users and if they are, we have no idea if they are the same ones that were there yesterday, or the day before and so on. This part of the path starts with the about:tor page and is everything else that is related to enable the user to understand what is going on and have control to customize their experience so they can have the results they are looking for. The more frustration the user has on any of the above, related to things not working or not knowing how to use things or not understanding what is going. Is a good enough reason for them to close the browser and maybe not open it again. That is a lot of work to be done here, and we do have items on TB team, Network team and UX team roadmaps related to it. And face to face user testing will help us validate if what we are doing is indeed helpful for the user. 'resurrection' Tor doesn't do this. Like, the moment a user gets frustrated with TB and closes it, we can't contact that user, send them an email saying 'hey we got a new feature, give us another chance' which is what resurrection means hehe getting someone who left your product to come back. But we should be pro-active in telling the world about our improvements. Specially visible changes improvements. That is our moment to reach people who have tried Tor and gave up, to give it another chance. I have been talking about this with the comms team and with their help we will start doing more of this type of work. Conclusion? This is just a little summary of how we are organizing our thoughts and tasks related to helping the user. Is a work in progress too :) we are always talking and reflecting about these things. I wanted to share these thoughts with a broader audience, I have done it before but have been a while, so I thought of doing it again. Thanks for those who read so far! Cheers, Isabela [1] https://share.riseup.net/#3iFTZxsII6C8Q0i9lx5k0g [2] https://docs.google.com/presentation/d/1a0Lwuj44mjtDqm28cSRKr2Udu2QVArLtGYc… [3] https://docs.google.com/presentation/d/1a0Lwuj44mjtDqm28cSRKr2Udu2QVArLtGYc… [4] https://docs.google.com/spreadsheets/d/1ELMvnIksL-m_r0vJt_rwpIkcjyzZpCyYiQJ… [View Less]

1 0

Damian's Status Report - October 2017
by Damian Johnson 14 Nov '17

14 Nov '17

Hi all! Here's what I've been up to this last month... http://blog.atagar.com/october2017/ Cheers! -Damian

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

tor-project November 2017