[tor-talk] Possibly Smart, Possibly Stupid, Idea Regarding Tor & Linux Distributions

Wed Jan 4 13:29:08 UTC 2017

Hi Alec,

> On 04 Jan 2017, at 12:24, Alec Muffett <alec.muffett at gmail.com> wrote:
> 
> Actually, I don't believe that you do disagree with the problem statement
> :-)
> 
> I believe that you may concerns with one of my proposed solutions to the
> problem, and that's okay because I do too.  :-)
> 
> Let me see if I can reframe the problem statement, and maybe pose another
> alternative?
> 
> 
> == Problem Statement, Reframed ==
> 
> I believe that, at the moment, the Debian "installiverse" assumes that
> people who want to use Tor -- on a server -- are skilled and knowledgeable.
> 
> Case in point:
> 
> * For setting up relays you want to stand on a solid foundation, so Debian
> "stable" works really well.
> 
> * But I will bet that you are not running the relays by using the 0.2.5
> codebase which it offers. :-)

I currently maintain 15 debian systems privately (mostly VMs). All but one
of them have tor installed. Only four of them use the tpo repository (those
provide either public or private network relays or dirauths). The others
use regular debian-provided packages.

> ** (Not least, I believe that the crypto in anything older than 0.2.7.*
> will be a lot slower?)

This doesn't matter unless you run a high-performance relay. Also, I think
going from 0.2.7.x to 0.2.8.x increased my cpu usage on my busy relay.

> * So I believe that you are probably not running 0.2.5 because you are
> skilled enough to use backports or roll your own.

I consider myself skilled enough, but I'd rather keep the amount of custom
repositories to the bare minimum. Especially my more trusted computers
don't get additional repos if I can help it at all.

> Now, for contrast, consider Tor Browser Bundle:
> 
> * TBB is designed for use by "normal people".
> 
> * It is not running 0.2.5.* either, because it would be foolish to push out
> such "old code" to the clients.
> 
> * TBB runs code which we might call "Tor Stable", being probably a similar
> version to the code which you yourself would deploy for a relay.
> 
> * Therefore: "Debian Stable" is not offering "Tor Stable", instead it is
> offering "Tor Stale", or "Tor Stagnant".
> 
> 
> == Summary ==
> 
> Debian Stable, by default, offers code that we would deprecate on the
> servers, and would never ship on the clients.

Well, we're not currently deprecating it. It's still recommended by the
dirauths to run one of those versions.

I am not sure, but I think the main reason to ship recent Tors in TB is
because we have to ship new Firefox releases anyway, so the pain of adding in
some more software is minimal. That and the increased benefit of new
security features, better blocking resistance, etc.

> How is this to anyone's benefit?
> 
> It's like the old chef's rule about "never cook with wine that you would
> not drink by yourself"
> 
> 
> == Challenge ==
> 
> Consider schools. Consider journalists, hobbyists, non-CS university
> students. Consider "IoT tinkerers".

I'm a sysadmin at my school for a student computer pool, we have around 13k
users and around 250 physical machines for students to use. The biggest
thing I'd wish for were a system-wide installable Tor Browser that we can
keep updated for our users. And we would do it, just like we keep everything
else updated (for that job, while we do run debian stable, we're constantly
chasing down last versions for a variety of software where the latest version
is necessary for teaching or because it was requested by some students).

> Consider people who don't know what "vim" does. :-)
> 
> These are people who can use Tor for good purposes, and I believe that Tor
> should seek to "enable" them, and make Tor easier to use for them.
> 
> But the Tor code which comes with Debian, and thus with Raspbian, and
> kinda-with-Ubuntu, is (by the metaphor) bad wine which you would never
> offer to these people to actually drink nor cook with.

In my world, these people don't really use apt-get, they will look to
install something they can download from a website while following some
instructions. TB seems to fit for that mental model. I just see a kind of
disconnect between the hapless user and the advanced usecases where TB is
not enough.

If the user does know apt-get, they could install the torbrowser-launcher
package on debian stable, which helps get them a shiny new TB. Admittedly,
I have no idea about availability on Ubuntu.

> In my previous e-mail I suggested removing Tor from Debian precisely
> because of this future-staleness problem.

I find this to be totally the wrong thing. We all want all our users to
run our latest code, nownownow. It's a completely understandable line of
thought, after all we're developers and passionately implemented features,
created better architecture, debugged and fixed bugs for days. I think it's
still kind of arrogant/presumptuous. As long as there are no reasons to
kill an older version (like security issues, incompatability with a newer
protocol where the cost of keeping to support the older version is
significant, etc) I don't think we should break compatibility.

> I still believe that this is a decent idea, because stale code sucks.
> 
> Another possible solution would be creation of a "Tor Server Bundle" -
> designed and maintained to run successfully on most major platforms, it
> would be a bunch of scripts that find existing, stale versions of Tor, kill
> and remove them, and migrate the platform to a more recent version, with
> *optional* enabling of auto-updating because you will want to have a stable
> environment. :-P

I don't think these would be accepted under Debian's policies, at least I
would find a package that did this without very clearly labelling what's
going on to be unacceptable. Note the point above about breaking changes
or new major security features that require work to get right.

> And it would (ideally) also ship with some portable, stupid but bombproof,
> interactive and scriptable CLI wizards for setting up Onion services.

Do you really want onion service creation to be something that isn't done
automatically for you like in Ricochet, but rather something a user has a
tool to do manually? The footgun possibilities are endless.

> == Why? ==
> 
> Large chunks of the Tor community are focused on Tor's primary purpose as
> an anonymising proxy, and that's very, very important.
> 
> It is Tor's primary and best-understood, to provide people with a secure
> and generally anonymized means to connect to cleartext websites.
> 
> But (subjective opinion) I think the future of Tor is in disintermediated
> networking.  I think the future is in onions.

I think onions will either be the future or the downfall of Tor. We will see
which one of these it'll be :)

> Prop224 is coming soon.
> 
> Prop224 will provide a larger, more secure means of onion addressing,
> possibly permitting even DV SSL certificates.
> 
> Having DV certificates available would permit (for instance,
> hypothetically) LetsEncrypt to issue certificates to arbitrary onions,
> unlocking SSL-only features like WebRTC to permit disintermediated,
> onion-secured, user-hosted, location-anonymised video chat
> 
> Aside: this was part of why we drunken reprobates were doing this stuff at
> 33c3 -- https://twitter.com/FiloSottile/status/814641733212536832 --
> leading to nice, fun stuff like this --
> https://twitter.com/isislovecruft/status/815882213808074752
> 
> I want other people to have an easier time innovating with onions.
> 
> Prop224 is due to land in tor 0.3.1.x.
> 
> But the generation of students, hobbyists, tinkerers who will be using
> (say) Raspbian in 2018, 2019, 2020+... they will all be using "Stretch" by
> default, and they will all be locked on 0.2.9.* unless they:
> 
> - CLUNKY: learn that the first thing to do is ignore the code in front of
> them and that instead they must roll their own / poke their system or
> 
> - CLEAN: install Tor directly from torproject.org because tor is not in
> "Stretch", or
> 
> - INTERMEDIATE: install TorServerBundle which nukes the stale 0.2.9 stretch
> binary and installs Tor directly from torproject.org
> 
> I believe that we are now at a crossroads.
> 
> We can choose to avoid, or address, stacking up code/wine which will be too
> stale to use/drink by the time the next generation of innovators and
> tinkerers are booting up their 2020-era Raspberry Pi Model 5.
> 
> Or we can leave everything at the status quo, and just muddle along, like
> the technically capable (elitist?) geeks that we already are, and hope that
> a few more people may survive the process and join our ranks, eventually.
> 
> But me, I want to get _everybody_ - teachers, journalists, kids, everyone.
> 
> I want people to be able to use stuff like this (piece of crap, but it's
> just a proof of concept) https://github.com/alecmuffett/videonion - using
> onions to communicate directly with one-another.
> 
> I want everyone to have the opportunity to connect without an intermediary,
> if they choose.  It would be nice to have the option. :-)
> 
> But it needs to be easy, not clunky.

I can see where you're coming from. I agree that as a developer, I always want
everyone to use the latest version of all my stuff. As a user of a lot more
software than that which I develop myself, I really don't agree.

Cheers
Sebastian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20170104/b9473890/attachment.sig>