
Improving on Tor .onion Address Usability - EdgarAllanPwn
https://blog.torproject.org/blog/cooking-onions-names-your-onions
======
apeace
The way DNS works in I2P[0] is pretty neat[1]. Nothing in this post sounds
quite like it. It provides a great "default" user experience while allowing
for finer-grained control and tighter security if a user chooses. To
summarize:

\- Users have a local "Address Book" which maps friendly names (e.g.
forum.i2p) to I2P destination keys.

\- There are well-known I2P hidden services providing address book
subscriptions. The default install includes a subscription that is maintained
(and signed!) by the project maintainers.

\- The address book makes it clear where names are coming from. So if you
decide to un-trust one of your existing subscriptions, you can still keep
addresses you added yourself, etc.

\- New sites submit their name & key to popular address book services, but
there is an additional trick you can use. Pass people a link like
[http://mysite.i2p/?i2paddresshelper=<key>](http://mysite.i2p/?i2paddresshelper=<key>).
This is known as a "jump" link. Your local HTTP proxy will take you to a page
asking if you would like to add the name to your address book, or if you'd
simply like to keep the name for this session but not save it.

The whole system is easy to use while staying flexible, secure, and in the
user's control. I'm curious if the Tor team has tried out I2P or considered a
system like this.

If it's not making sense to you from my summary, I highly encourage you to get
I2P and try it out!

[0] [https://geti2p.net/en/](https://geti2p.net/en/) [1]
[https://geti2p.net/en/docs/naming](https://geti2p.net/en/docs/naming)

~~~
nikcub
It's similar to what ideas 2.1 and 2.2 are in the blog post - a local
directory that is maintained and authenticated centrally and then distributed
to browsers that perform a central lookup.

The downsides are that it is too centralized - it isn't difficult to imagine
that a government agency would want to sinkhole silkroad.tor from the default
registry.

With an alternate registry, you have the balance between knowing enough about
the directory provider so that you can trust them, but not enough known about
then where they are open to legal recourse.

ie. i'd trust a registry from riseup or duckduckgo, but that same registry is
likely going to be the target of legal and hacking attempts. Likewise any
provider who is sufficiently protected from those threats likely isn't well-
known enough to be trustworthy.

One of the benefits of the existing names is that they also authenticate the
site (assuming you check it correctly, usually out of band from a trusted
source like a directory or search engine) - this part can be replaced with
certificates and an issuance model that can be identical to what LetsEncrypt
does

In terms of hosting the directory - that almost has to be decentralized using
a p2p network. Similar to namecoin. Namecoin also solves the issue of
distributing names and typosquatting - and it could be adapted to auction
names.

~~~
apeace
> It's similar to what ideas 2.1 and 2.2 are in the blog post - a local
> directory that is maintained and authenticated centrally and then
> distributed to browsers that perform a central lookup. The downsides are
> that it is too centralized...

It is only centralized for users with the default install, who never go into
their address book.

I think the real achievement of I2P's name system is that _they have made it
easy for users to understand_, and the tight integration in the UX is the main
differentiator I see between I2P's approach and any of the approaches in this
blog post.

While I think Namecoin sounds cool and all, I really hope Tor considers a
simpler approach. I think it's a mistake for us to make this into a technical
problem, when it's a UX problem. We're never going to get 100% secure names in
a trustless environment, so why not focus on making the default pretty secure,
and making the system understandable and useable?

------
CraftThatBlock
This is a great step forward, however the nature of all "domains" is
centralised. DNS is a great idea, that decouples the centralisation to many
parties, but it is central at many points; registrars, ICANN, DNS servers
(though can be local). Tor's unique .onion address are the perfect way to fix
the centralisation and the security, but comes at the cost of human
readability.

~~~
lettergram
I really liked the idea that created peercoin. I.e. a currency that also
enabled distributed the registrar's (at least I believe so).

~~~
AgentME
You mean namecoin.

------
Buetol
It's best to piggyback on DNS rather than inventing on new scheme (address
books, namecoin,..) since this would surely result in a petty holy war and
would confuse users. But it would be a nice way to destroy ICAAN monopoly over
the domains.

The .onion protocol should behave exactly as https for http, it's just a
protocol upgrade. Instead of a green lock, you would get a purple lock
indicating privacy.

To do the protocol upgrade, the SSL field annotation seems like the most
robust way but I would go with `Alt-Svc` in the mean time since it's easier to
implement (server and client side). To mitigate the privacy issue, tor could
download a list of popular 'domain->.onion domain' (exactly like DNS caching)

------
ComodoHacker
Why they don't explore such an obvious approach to improving usability as
various graphical representations of onion addresses? It works for security
verification codes in WhatsApp, Telegram etc., it should also work for onion
addresses.

------
yjgyhj
Why not use Namecoin? Seems like a good fit.

~~~
larrysalibra
Larry from Blockstack.

We used use Namecoin and migrated to Bitcoin when we discovered that one miner
controls more than 51% of mining power which is a security problem in a proof
of work blockchain.

If you're interested in learning more, there's a peer-reviewed paper on it
here:
[https://blockstack.org/blockstack.pdf](https://blockstack.org/blockstack.pdf)

Section 3: "Lessons from Namecoin Deployment" may be of interest to you.

There's also an (old) thread discussing the problems encountered with Namecoin
here: [https://forum.blockstack.org/t/why-is-namecoin-being-
ignored...](https://forum.blockstack.org/t/why-is-namecoin-being-ignored-in-
favor-of-bitcoin-based-key-value-stores/51?u=larry)

~~~
cookiecaper
Bitcoin mining is also controlled by a small number of people. Over 50% of the
blocks hashed over the last 4 days are from the same 5 pools. [1]

The difficulty mechanism has been an abject failure and utterly destroyed
bitcoin's promise of decentralization. Under that mechanism, commodity mining
hardware automatically defeats itself.

We now have a small number of big players who've built custom, super-secret
hardware that can't be distributed or discussed or their investment will be
immediately destroyed, and normal people are unable to contribute in any
meaningful way (not even with GPUs anymore).

[1]
[https://blockchain.info/pools?timespan=4days](https://blockchain.info/pools?timespan=4days)

~~~
Nutomic
50% of hashrate coming from 5 pools doesn't sound like centralization to me.
Afaik many pools don't even have miners themselves.

~~~
janito
I don't want to be pedantic, and I do agree that the scenario isn't
centralization in a sense that it strongly threatens the network, but I thing
there's a point here worth clarifying. Pools don't need their own physical
miners to have power over the block generation process. AFAIK, the connected
miners are "dumb clients", delegating their block generation capability to the
pool in order to share rewards and therefore reduce income variability.

In short: the pool still defines the blocks that the connected miners will
mine. They centralize all the collective power of all connected miners.

------
andreyf
ew. gross.

CAs : Web of Trust :: domains : what Tor should do

~~~
Manishearth
They're not using a ca-like central authority model. They're using Namecoin
(or something like it), which is decentralized authority, verifiable via
crypto.

~~~
andreyf
never said they should. saying the kind of complexity presented by a
blockchain is an insane way to work in low-trust environments with competent
adversaries.

they should be working on reducing the complexity in the trust model. I trust
the person who told me about a service. why can't I just get the keys from
them, and verify that all of my other friends agree?

~~~
Manishearth
> why can't I just get the keys from them, and verify that all of my other
> friends agree?

You can, that's what a .onion address is. This isn't too great for regular
users; .tor addresses make it easier to work with. There's an observation here
that people are already trusting google and onion directories to non
maliciously give them the right onion address, this is trying to spread out
that trust to a blockchain.

The nice thing about a blockchain based model is that while you need to trust
the network to be sane, in case someone tries to use lots of computational
power to break past this, targeted attacks are still not possible, the attack
(redirecting a name) will be visible to the entire network.

~~~
andreyf
Not with a programatic standard I can't. I'm saying they should make the
equivalent of key server for GPG -- something simple.

Problems with relying on a blockchain to validate domains against
sophisticated adversaries range from obvious to unknown. Not good.

~~~
Jabanga
The problems related to blockchains are very well known. Blockchains have been
used extensively at this point, for highly critical applications. They're the
most censorship resistant platforms known to exist.

~~~
andreyf
Care to name a point where a blockchain stood between MSS and Chinese
dissidents? NSA and islamic radicalizers? SVR and someone Putin wants dead?

I'm stoked about blockchains as much as anyone else (heck, I quit a job at
Google and spent a year playing with them when Bitcoin first came on the
scene). But to say that they are a good thing to build on top of when facing
adversaries that have 7 figure USD budgets and capabilities to perform active
attacks on non-trivial chunks of the internet strikes me as just a bit naive.

------
emucontusionswe
By placing pretty wallpaper over strong-encryption, we are making it more
susceptible to damp.

------
vortico
I realize the task of recording your favorite .onion names is a small expense
of keeping your traffic private, but why is "taking notes in a text file"
considered ad-hoc now? That wasn't the case in 1990, where most computer users
had a library of floppy drives with their personal documents, notes, and
records. Has the world truly forgotten that you can store data in textual form
to your computer's filesystem? With how iOS is designed to hide the
filesystem, it seems so. I hear so many app ideas now that could be solved
with just a single text file and editor.

~~~
nerdponx
Good point about the filesystem, but this sounds like a really annoying and
slow task to have to manage manually. If someone wants to write an app that
spares me the drudgery of copying and pasting out of a text file every time I
want to go on a website, I will use that app. Not to mention the reduced
cognitive load from having fewer open windows to manage, and one less thing to
have to know where I put it.

~~~
eilyra
Am I missing something obvious, or isn't this something browser
bookmarks/favorites would handle? I.e. storing a more human friendly
title/description/tags for complicated URL's & paths.

This doesn't help with the potential complexity of sharing or remembering (on
a new device) the sites of course.

