Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving on Tor .onion Address Usability

blog.torproject.org

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Improving on Tor .onion Address Usability

#21

Post by nerdponx »

vortico wrote: post #11

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 h…

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.

Re: Improving on Tor .onion Address Usability

#22

Post by cookiecaper »

larrysalibra wrote: post #20
yjgyhj wrote: post #5

Why not use Namecoin? Seems like a good fit.

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 Section 3: "Lessons from Namecoin Deployment" may be of interest to you. There's also an (old) thread…

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

Re: Improving on Tor .onion Address Usability

#23

Post by im3w1l »

apeace wrote: post #6

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…

> The default install includes a subscription that is maintained (and signed!) by the project maintainers.

This sounds like a legal risk the maintainers need to be careful with.

Re: Improving on Tor .onion Address Usability

#24

Post by Jabanga »

yjgyhj wrote: post #13
Jabanga wrote: post #7

Earlier quoted context omitted.

That's what they're doing: >During the past years, many research groups have experimented and designed various secure name systems (e.g. GNS, Namecoin, Blockstack). Each of these systems has its own strengths and weaknesses, as well as different user models and total user experience. We are not sure which one works best for the onion space, so ideally we'd like to try them all and let the community and the sands of t…

Missed that! Thanks for correcting me.

Pleasure!

Re: Improving on Tor .onion Address Usability

#26

Post by nikcub »

apeace wrote: post #6

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…

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.

Re: Improving on Tor .onion Address Usability

#27

Post by phaer »

AgentME wrote: post #14
apeace wrote: post #6

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…

Does that mean when a site links to "forum.i2p", then it's up to your own local address book where that actually goes? (Assuming people don't use the ?i2paddresshelper thing for literally every link, unless that is what is done.)

I don't know how i2p works, but isn't that pretty much they way the "normal" net works? If you click a link to "news.ycombinator.com" in your webbrowser, it's mostly up to your local or ISPs DNS resolver where that takes you, no?

Re: Improving on Tor .onion Address Usability

#28

Post by belorn »

nikcub wrote: post #26
apeace wrote: post #6

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…

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…

The problem of attaining trust from within anonymity is a interesting one, but the simple solution sounds to be to just have the directory servers make a consensus over what registry should be used as default. The tor network already depend on the directory servers, and if the registry ever get compromised the directory operators can always change the consensus. If a single directory operator get legal problems, the other operators consensus will override any recourse that may happen.

Re: Improving on Tor .onion Address Usability

#30

Post by 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)

Post reply on HN