January 2018 - tor-dev - lists.torproject.org

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
by George Kadianakis 26 Oct '18

26 Oct '18

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header ======================================================================== 1. Motivation: Lots of high-profile websites have onion addresses these days (e.g. Tor , NYT, blockchain, ProPublica). All those websites seem confused on what's the right way to inform their users about their onion addresses. Here are some confusion examples: a) torproject.org does not even advertise their onion address to Tor users (!!!) b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion address and completely wrecking the UX (loses URL params, etc.) c) ProPublica has a "Browse via Tor" section which redirects to the onion site. Ideally there would be a consistent way for websites to inform their users about their onion counterpart. This would provide the following positives: + Tor users would use onions more often. That's important for user education and user perception, and also to partially dispell the darkweb myth. + Website operators wouldn't have to come up with ad-hoc ways to advertise their onion services, which sometimes results in complete breakage of the user experience (particularly with blockchain) This proposal specifies a simple way forward here that's far from perfect, but can still provide benefits and also improve user-education around onions so that in the future we could employ more advanced techniques. Also see Tor ticket #21952 for more discussion on this: https://trac.torproject.org/projects/tor/ticket/21952 2. Proposal Websites use the Alt-Svc HTTP header to specify their onion counterpart: http://httpwg.org/http-extensions/alt-svc.html The Tor Browser intercepts that header (if any) and auto-redirects the user to the onion site. Tor Browser only does so if the header is served over HTTPS. (That's it.) 3. Improvements 3.1. User education through notifications To minimize the probability of users freaking out about auto-redirects Tor Browser could inform the user that the auto-redirect is happening. This could happen with a small notification bar [*] below the URL bar informing users that "Tor Browser is auto-redirecting you to the secure onion site". The notification bar could also have a question mark button that provides the user with additional information on the merits of onion sites and why they should like them. [*]: like this one: http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg 3.2. Auto-redirects too intrusive? Make them optional. If we think that auto redirects are too intrusive, we should consider making them optional, or letting the website specify the desired behavior. If a website wants to specify an onion address but doesn't like auto-redirects, it could specify that as part of Alt-Svc and we could still inform the user that an onion is available using a notification bar again. 4. Drawbacks This proposal is far from the perfect solution of course. Here are a few reasons why: 4.1. Auto-redirects are scary Novice users or paranoid users might freak out with auto-redirects since it's unexpected. They might think they are under attack or they got hacked. An argument against that is that we are already using HTTPS-everywhere which is basically a redirection layer, and while its redirection technique is simpler, sometimes the derivative URL is not similar to the original URL, and we still don't see people freaking out. I think that's because people trust Tor Browser to do the right thing. Combining this knowledge with section 3.1 might solve this problem. 4.2. No security/performance benefits While we could come up with auto-redirect proposals that provide security and performance benefits, this proposal does not actually provide any of those. As a matter of fact, the security remains the same as connecting to normal websites (since we trust its HTTP headers), and the performance gets worse since we first need to connect to the website, get its headers, and then also connect to the onion. Still _all_ the website approaches mentioned in the "Motivation" section suffer from the above drawbacks, and sysadmins still come up with ad-hoc ways to inform users abou their onions. So this simple proposal will still help those websites and also pave the way forward for future auto-redirect techniques. 4.3. Alt-Svc does not do exactly what we want I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL in the location bar, document.location or any other indication of where the resource is; this is a “layer below” the URL.". IIUC, this is not exactly what we want because users will not notice the onion address, they will not get the user education part of the proposal and their connection will still be slowed down. I think we could perhaps change this in Tor Browser so that it rewrites the onion address to make it clear to people that they are now surfing the onionspace. [*]: https://www.mnot.net/blog/2016/03/09/alt-svc 5. The future As I said this is just a simple proposal to introduce the auto-redirect concept to people, and also to help some sysadmins who are currently coming up with weird ways to inform people about their onions. It's not the best way to do this, but it's definitely one of the simplest ways. In the future we could implement with more advanced auto-redirect proposals like: a) Have a "domains to onions" map into HTTPS-everywhere and have it do the autoredirects for us (performance benefits, and security benefits under many threat models). b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested by comment:42 in #21952. But both of the designs above require non-trivial engineering/policy work and would still confuse people. So I think starting with a simple approach that will educate users and then moving to more advanced designs is a more normative way to go. ====================================================================== Let me know what you think :) (Should this be part of torspec?)

10 25

Proposal: Expose raw bwauth votes
by Tom Ritter 17 Jul '18

17 Jul '18

I'm not sure, but I think https://trac.torproject.org/projects/tor/ticket/21377 needed a proposal so I tried to write one up. -tom

5 8

Proposal Waterfilling
by Florentin Rochet 09 Mar '18

09 Mar '18

Hello everyone, In order that our paper does not fall into the list of "yet another seems-to-be-cool-feature is that never going to be discussed because researchers moved on another topic", here is an attached proposal in which we summarize our work published in the last PETS event and how it can be implemented. And, if you find this interesting, I would be glad to submit a patch :) Any kind of feedbacks is more than welcome! Cheers! Florentin

8 29

Nominate/vote for future proposal discussion meetings!
by isis agora lovecruft 21 Feb '18

21 Feb '18

Hello all, Is there an existing Tor proposal you'd like to discuss? Please use the following pad to nominate and vote for proposals for discussion. https://pad.riseup.net/p/Pxo2fQiiaSWo We'll be reviving our proposal discussion meetings soon, likely at the beginning of January once people have returned from their winter holidays. After the nominations/votes are taken, I'll start arranging meeting times. If you nominate and/or vote for a proposal, I may reach out to you at some point for your opinions on discussion items, open questions/concerns, etc. to include for the meeting preparation. Thanks! Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

6 18

onionoo.tpo stuck at 2018-01-21 22:00
by nusenu 04 Feb '18

04 Feb '18

Hi Karsten, just wanted to let you know that the delta between relays_published and current time is unusually high. https://onionoo.torproject.org/details?limit=0 {"version":"5.0", "build_revision":"0bce98a", "relays_published":"2018-01-21 22:00:00", This is currently blocking ornetradar reports. thanks for having a look, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 11

small fixes for the sources.list generator (and new options)
by nusenu 03 Feb '18

03 Feb '18

Hi, since the tor relay guide depends on that page and it has a few issues I made some small fixes to it: https://www.torproject.org/docs/debian.html.en Bug 25107: sources.list generator: remove yakkety (we do not offer packages for it) Bug 25107: sources.list generator: add Ubuntu Artful Aardvark (17.10) Bug 25107: sources.list generator: remove zesty (we do not offer packages for it) Bug 25107: sources.list generator: add nightly-master option Bug 24994: point to the actual content describing alpha/stable differences Bug 25107: sources.list generator: update tor alpha version to 0.3.3.x Bug 25107: Update the tor alpha version (noscript page version) Bug 25107: fix sources.list generator for Debian Buster If someone with commit privileges has time to review and merge before the weekend that would be great. https://github.com/nusenu/torproject-webwml/tree/debian_sources.list_genera… Note: I did not care about the "(from source)" option. -- https://mastodon.social/@nusenu twitter: @nusenu_

2 3

stem support for v3 ephemeral onion services
by Micah Lee 31 Jan '18

31 Jan '18

Now that Tor Browser 7.5 is released and includes the tor 0.3.2 series, which supports next generation onion services, I would love to make OnionShare use these by default. Here is the issue [1]. OnionShare is written in python3 and relies on stem to communicate with the Tor controller. Although tor now supports v3 ephemeral onion services, stem still doesn't. Just take make sure, here's a quick test, with Tor Browser 7.5 (providing tor 0.3.2.9) open in the background, and using stem 1.6.0: == from stem.control import Controller c = Controller.from_port(port=9151) c.authenticate() tor_version = c.get_version().version_str print("Tor version: {}".format(tor_version)) print("Creating ephemeral onion service") res = c.create_ephemeral_hidden_service({ 80: 8080 }, await_publication=True, key_type='NEW', key_content='BEST') print("{}.onion".format(res.service_id)) == When executed, it still creates a v2 onion address: (env) user@dev ~/tmp $ python3 onionv3.py Tor version: 0.3.2.9 Creating ephemeral onion service wrvsjo4nlww3edsi.onion Right now OnionShare is blocked by stem supporting v3 onions. Does anyone know when we can expect support for this? [1] https://github.com/micahflee/onionshare/issues/461

4 5

Starting with contributing to Anonymous Local Count Statistics.
by Aruna Maurya 31 Jan '18

31 Jan '18

Hey! I was going through the Tor Volunteer page and came across the Anonymous local count statistics project. As a student it would be a great starting point and an even bigger opportunity to get a chance to collaborate and learn in the process. I would like to contribute to it, and would love to start as soon as possible. It would be great if someone could guide me through. Thanks for your time!! -- Regards, Aruna Maurya, CSE,B.tech, Blog <https://themindreserves.wordpress.com/> | Medium <https://medium.com/@arunamaurya>

2 1

website patches for new Tor relay guide sidenav entry
by nusenu 30 Jan '18

30 Jan '18

Hi Silvia, I submitted a (trivial) patch (in #24881) to add links to the new tor relay guide on the website and to remove previous guides that have been merged into the new guide. I noticed that since than new commits have been merged and these patches will probably no longer apply cleanly. I will try to ensure they apply (rebase) shortly before you have time to look at them if you can tell me approximately when that will be. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

non-anonymous ephemeral onion services with stem
by Micah Lee 30 Jan '18

30 Jan '18

The stem documentation for create_ephemeral_hidden_service [1] says: "Changed in version 1.5.0: Added support for non-anonymous services." But I can't figure out to actually use this feature. There doesn't seem to be a new argument to say if you want your onion service to be non-anonymous. It also says, "Changed in version 1.5.0: Added the basic_auth argument." But there's a new basic_auth argument you can pass into the function to use that. [1] https://stem.torproject.org/api/control.html#stem.control.Controller.create…

5 12