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.
Improving on Tor .onion Address Usability
11–20 of 40 posts
Re: Improving on Tor .onion Address Usability
#12The 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…
hate to be tinfoil-hat about this, but I2P seems sane in every way that Tor seems all-but-intentionally insecure in the face of sophisticated adversaries. this seems a good example of "fruitful surface area" for security vulns. another unrelated design decision is for Tor to reuse a single route which can be identified with relatively high accuracy via traffic analysis.
I2P benefits from router's by default also being nodes (not saying Tor should do that though), meaning there's more "spread" of where the nodes are. Most Tor nodes, even if ran honestly, are generally in the same few data center companies; digital ocean, flokinet, etc.
Also, its important to note that I2P's addresses (which are usually seen as something.i2p), can also be used directly in their 'hash' form like Tor, if you don't trust the jump/address book services.
Re: Improving on Tor .onion Address Usability
#13Why not use Namecoin? Seems like a good fit.
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.
Re: Improving on Tor .onion Address Usability
#14The 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.)
Re: Improving on Tor .onion Address Usability
#15This 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.
I really liked the idea that created peercoin. I.e. a currency that also enabled distributed the registrar's (at least I believe so).
You mean namecoin.
Re: Improving on Tor .onion Address Usability
#16Earlier quoted context omitted.
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.
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?
> 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.
Re: Improving on Tor .onion Address Usability
#17Earlier quoted context omitted.
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?
> 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…
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.
Re: Improving on Tor .onion Address Usability
#18Earlier quoted context omitted.
> 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…
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.
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.
Re: Improving on Tor .onion Address Usability
#19I 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…
But then the user has to create a file, in their filesystem. Hard work! They have to remember the name of it, and type things and everything. They have to press enter at the end of lines and keep it all organised. It's so hard.
It's up to you to determine whether the above is satire.
Re: Improving on Tor .onion Address Usability
#20Why 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 discussing the problems encountered with Namecoin here: https://forum.blockstack.org/t/why-is-namecoin-being-ignored...