[tor-dev] Comments on proposal 279 (Name API)

[Yawning Angel]

On Fri, 7 Apr 2017 11:44:03 +0100
Alec Muffett <alec.muffett at gmail.com> wrote:
> If I was in charge, I would say that we risk overthinking this, and it
> would be better to:
> 
>    - mandate use of fully DNS-compliant syntax, including but not
> limited to: acceptable max length, max label length, charset and
> composition

Fully DNS-compliant only limits max length and max label length, unless
there's something that supersedes RFC 2181.  I'm fine with both of
those restrictions.

>    - declare a registry of short, valid labels, in the
> second-from-right position in the name
>    - reserve "tor" and "name" in that registry (ie: *.tor.onion,
>    *.name.onion)
>    - park the entire issue for 12 months

I intentionally left a lot of this unspecified because one of the use
cases I envisioned was an "/etc/hosts" analog that lets users easily:

 * Stick all their hidden services under their own name hierarchy.

   eg: git.yawning -> <long public key>.onion

 * Increase mobile quality of life by aliasing their HSes to addresses
   consisting entirely of emojis.

   eg: 💯👏💩👏🖕.😫 -> <long public key>.onion

 * Force redirect any site to anything else, really.

   eg: git.example.com -> <long public key>.onion
       banner.ads.and.malware.example.com -> 127.0.0.1
       social.spacebook.trackers.example.com -> 127.0.0.1

I could do this with MapAddress, but a plugin would make my life
easier, especially since it beats editing multiple torrc files.

(Going further into this rabbit hole, I assume most exits won't resolve
 the OpenNIC TLDs...  What do I do if I want to view `example.pirate`
 or whatever over Tor?)

> Hence "parking" the issue because this is all meaningless until
> prop224 addresses ship, and there should be plenty of time in the
> next 12 months for people to think about how to fill the usability
> space with $PET_IDEA, and to my mind the changeover period between
> 80-bit and 256-bit addresses should be long enough that nobody need
> fret about it right now.

IMO the existing onion addresses already are a usability disaster.  It
should be easy for researchers to experiment with designs to solve the
problem *now* before prop224 addresses make a bad situation worse.

There's also a world of difference between implementing/shipping the
capability to override the name resolution via plugins, and "Shipping
the YawningCoinNamezTLD plugin with Tor Browser, enabled by default".

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170408/8bfd8852/attachment.sig>