[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Possibly Smart, Possibly Stupid, Idea Regarding Tor & Linux Distributions
Hi Sebastian!
On 4 January 2017 at 06:24, Sebastian Hahn <sebastian@xxxxxxxxxxxxxx> wrote:
> Hi Alec,
>
> thanks for your thoughts. I have just one very quick comment, but
> it seems you haven't addressed it yet:
>
Okay, I'll give it a go :-)
I install Debian stable on my servers precisely because they don't
> necessarily track the latest packages for everything.
Yes, I totally understand that. Especially for a long-lived platform I can
totally see the utility, sanity and wisdom of doing that, especially where
the person administering the system is skilled and knowledgeable.
When I have
> installed them and they work, I don't need to do super frequent
> maintenance - I get security updates, but not much more.
Yes totally.
> Tor updates for
> relays frequently require you to read the changelog carefully to have a
> sane upgrade path, other software does that too - having to do that
> constantly when you're not actually need any of the new features is
> super annoying imo.
>
Yes.
> There are some select pieces of software where this isn't the case -
> the kernel on my gaming system, the tor package on my relays, some
> others - where I selectively use backports or custom repositories. I
> would imagine if the main purpose of my machines wasn't providing tor
> relays, I'd prefer to just run whatever debian stable provides.
>
Yes.
> > So this is kinda the problem statement:
> > - old versions of Tor are out there in the wild
> > - they pollute the software environment, representing "cognitive load" /
> > barriers to easy adoption and learning
> > - adoption and learning are critical to the growth in use of Tor
>
> I guess I just disagree with this problem statement.
>
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. :-)
** (Not least, I believe that the crypto in anything older than 0.2.7.*
will be a lot slower?)
* So I believe that you are probably not running 0.2.5 because you are
skilled enough to use backports or roll your own.
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.
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".
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 previous e-mail I suggested removing Tor from Debian precisely
because of this future-staleness problem.
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
And it would (ideally) also ship with some portable, stupid but bombproof,
interactive and scriptable CLI wizards for setting up Onion services.
== 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.
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.
- alec
--
ps: major, yuge props to Filippo, Str4d and GTank for their video work, I
was largely off working on RTC when they did the above video stuff
footnote: The announcement of 0.2.5.10 was October 2014.
--
http://dropsafe.crypticide.com/aboutalecm
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk