[Freedombox-discuss] DNS solution that doesn't require paying money or using a central server.

[Fellow Traveler]

On 7/4/11 8:58 AM, Marc Loupias wrote:
> Hello,
> 
> some comments on this :
> 
> 
...
>>
>> WHAT IF I DON'T ALREADY HAVE THE CONTRACT? HOW DOES THE PLUGIN FIND IT?
>>
>>
>> SHORT FORM:
>> In most cases it already has the ID (in the URL), so it just downloads
>> the contract based on that ID, via P2P or from a Distributed Hash Table.
>> Then it verifies the contract based on the ID and the signature, and
>> then it actually connects to the website and displays it, using one of
>> the addresses inside the contract (whether via i2p, tor, freenet, ip,
>> dns, etc. The contract supports as many as you wish.)
>>
> 
> There is a big problem here.
> 
> If i modify my contract, i need to update ALL the links on the web not
> only thoses on my website. Including those given by other people and
> pointing to my website.
> 
> You write that the ID is the contract hash. So if i add a connection
> type or if i update the IP (moving to another ISP for example) the ID
> will change.
> 
> It will quickly go to a maze of deadlinks.


This is true, but I provided a solution in my original post:

9) It's easy to update contracts in the DHT as necessary. Perhaps the
"main ID" is just a DHT address where the "current version ID" can be
found. This way you can change versions without changing your main ID.
The DHT address can be a hashed public key, where the owner is the
holder of the private key.


>>
>> WHAT IF IT NEEDS TO RESOLVE THE NAME FIRST, TO GET THAT ID?
>>
>>
>> LONG FORM:
>> In this example we actually have to resolve the name "freedombox.otc"
>> and find the right contract.
>>
>> 1) The plugin can make a request via P2P. (Coming soon to
>> Open-Transactions out of necessity for the digital cash, due to the
>> nature of the minting files.) The plugin thus asks my peers to lookup
>> the contract ID in their own local lists, and so I can find the contract
>> via a "web of trust".
>>
>> 2) Optionally, alternately, or additionally, my plugin may contact
>> certain specialized "search engines for contracts", which I predict will
>> arise on darknets. This is only a matter of time.
>> Thus, instead of searching Google for "freedombox" and getting a list of
>> sites, there would be various darknet-based aggregator sites where I
>> could type "freedombox" and get a list of contracts.
>>
>> 3) Whether the plugin uses p2p or search engine, or both, EITHER WAY,
>> MULTIPLE CONTRACTS might come up for the SAME NAME!
>>
>> This is okay!!!!!! People automatically assume this is some big problem
>> to be solved, but you can instead realize that IT'S NOT A PROBLEM AT
>> ALL. The sun will still come up in the morning. The sky is not falling.
>>
>> 4) If such a name conflict happens, that's okay: just check the
>> fingerprint and approve the correct one. You'll see the list of IDs, and
>> you can click and view each contract. You probably got the site ID off
>> of a business card, anyway. THIS IS JUST LIKE VERIFYING A FINGERPRINT
>> FROM A BUSINESS CARD, OR VERIFYING A FINGERPRINT DURING OTR CHAT. (And
>> you only do it once, in the rare event of a conflict.)
>>    
> 
> Oh no this is not okay.
> 
> 99% of people need SIMPLE things.
> 
> Giving them a choice before accessing a ressource on the net is bad for
> the user experience.
> In the most case, people will pick a random contract just because they
> dont understand what is goin on with this new window.
> 
> And if they have a single click to access a ressource with DNS and 3 or
> 4 with your system the result is known by advance : They will not use
> your system.
> 
> There is a second big issue, i click on a link and my browser pop a
> windows with 10 contract pointing on freedombox.org. How can i choose
> the correct contract ? On which basis ?
> 
> And what about softwares using your system ? For example P2P. Who will
> click on the right contract ?


-- Your logic is undeniable that people need simple things, and I
consider this to be the big trade-off against having some central
authority, which is what I'm trying to solve.

-- However, I think there are good solutions already in my post, to the
questions you raised...



> i click on a link and my browser pop a windows with 10
> contract pointing on freedombox.org. How can i choose
> the correct contract ? On which basis ?


-- Because the link will already have the ID in it, and preferably the
name, too (think of the name like the alt-text for an image tag.
Optional, NOT unique, but still AVAILABLE in the contract/link.)

-- Therefore, in this situation, the user will never have to choose from
a list, since the choice was already made when the HTML was edited.

-- Remember, there are still UNIQUE names (the ID) and there are also
still HUMAN READABLE names (in the contract.) We still have both
functionalities. They are just in separate variables, instead of having
a unique AND human-readable name in a single value, like DNS does.



> And what about softwares using your system ? For example P2P. Who will
> click on the right contract ?

-- Clicking is not a problem (see above) since the correct ID is already
known when the HTML was edited.

-- This will only be an issue when entering a new human-readable URL by
hand, that you have never visited before, that you would have to choose
from a list. (Much more rare...)

-- Often I would expect the user has the fingerprint ready in such a
situation, and he can just verify it directly. Perhaps it's on the
business card, or whatever. Just like verifying an OTR fingerprint or a
PGP fingerprint. (One time.)

-- I think any other situations after that will be handled by
web-of-trust (the p2p votes for this contract) as well as the new
darknet search engines I described in my original post (for contracts),
which will probably exploit crowd-sourcing as well.

-- (If I go to the "Darknet Search" site and type "cnn.com", there might
be 2000 different contracts that come up, but the one on top will be the
one that is 99%, and when I select it, I never have to do that step
again for that site. Since I'm used to "searching google" anyway, to
find something new, then I don't see that as a huge hassle.)


>> 5) In most cases, THIS STEP ISN'T NECESSARY, since in most cases you
>> will be clicking on a link, not typing the name by hand, and the link
>> itself will ALREADY have the ID, (no need to resolve it from the name.)
>>    
> 
> I totally disagree, if someone wants to poison a domain, it just have to
> build multiple contracts on the same DNS and it will go in a total mess.


-- See above for my answer.


>> Instead, the plugin IMMEDIATELY loads (or downloads) the appropriate
>> contract based on its ID, then verifies its signature, and then connects
>> to the website.
>>
>> 6) Also, remember once you enter the ID the FIRST TIME, then the name
>> will work EVERY time after that. (Since the plugin can just look it up
>> locally.)
>>
>> 7) You can even choose to import contracts that both claim the same
>> name. (This will rarely or never happen.) When the plugin encounters
>> such an ambiguity, it'll just pop up the list and ask you to choose one.
>> No big deal!
>>    
> 
> Choosing IS a big deal for 99% of the users. Especialyy on a trivial
> thing like clicking on a weblink.


-- We are not talking about clicking on a web link. See above. (I think
you misunderstood a bit what I wrote, sorry wasn't more clear.)


>> 8) The contracts themselves can be globally available in a DISTRIBUTED
>> HASH TABLE. This way the owner can continually update the contract,
>> everyone can see it, and it's censorship-resistant.
>>    9) It's easy to update contracts in the DHT as necessary. Perhaps the
>> "main ID" is just a DHT address where the "current version ID" can be
>> found. This way you can change versions without changing your main ID.
>> The DHT address can be a hashed public key, where the owner is the
>> holder of the private key.
>>    
> 
> So the ID is not the contract hash ?

I would say the better way is to have the "main ID", which would be the
DHT location. Use the hash of the public key as the DHT location, where
all changes to that location must be signed by the private key. Then put
the actual contract in that location.

That way, the owner can easily update the contract that appears in that
location, without having to change the ID of the website. (This is the
solution I provided in my original post, which appears at the top of
this one.)

Any updated contract could contain its own "main ID" within, as a
verifiable data member, the same as it stores the "DNS name" and all of
the various connection addresses as well. (They are all stored
internally to the contract.)

The browser can simply check the DHT for the latest contract before
actually connecting to any of the addresses (i2p/tor/freenet/ip/dns/etc)


>> WHAT PROBLEMS DOES THIS SOLVE?
>>
>> 1) People can use any "DNS name" they want for their website. It will
>> never be "already taken".
>>
>> 2) There is no central "DNS server". No central authority.
>>
>> 3) Name conflicts are rare, and easily handled. Conflicts also naturally
>> cause the user to choose the right one based on the FINGERPRINT. Isn't
>> this a good direction?
>>    
> In your system, making a lot of contracts for the same domain name is a
> good way to down the entire system for a given DNS or any other
> connection type.
> And it introduce complexity where there isn't for the DNS. So people
> will just not use your system.
> 

What about the additional "complexity" of waking up to see that your
website, along with 80,000 innocent others, suddenly has a message
stating "THIS WEBSITE HAS BEEN SEIZED BY THE DEPARTMENT OF HOMELAND
SECURITY" ?

I think, in light of the clarifications I have written today, you can
agree that my proposal is much less complex than your original
impression of it? In fact, much more usable?

Nothing of what I have proposed is that original, BTW. I2P has a similar
solution already, as does Freenet. The additional solutions I provided
(via Ricardian contracts) are not really something I can take credit for
either, since I think Ian Grigg invented Ricardian contracts.

The additional complexity that is introduced by these pieces is mostly
handled automatically, behind the scenes. I agree that a user must
OCCASIONALLY (not often) choose from a list, verifying either by
fingerprint or by web-of-trust or search engine, but I argue that this
will be rare, and that it's not much different than what we do today
when using search engines or fingerprints.

Furthermore, it simplifies a lot of other things in our lives, such as
domain registration and costs, as well as centralized control over the
naming system of the Internet itself.



>> 4) Supports ALL PROTOCOLS. (Whichever addresses you put in your
>> contracts... tor, i2p, ip, dns, freenet, etc.)
>>
>> 5) Eliminates the need for certificate authorities. (A FAILED SECURITY
>> MODEL, YES?) You already have the site's public key from their contract,
>> so your browser can just use that to encrypt a session key.
>>    
> It doesnt eliminate certificate authorities, it move the problem in a
> constellation of little certificate auth -> the people you trust, and
> the people trusted by the people you trust, etc ...

Decentralization does not eliminate the problem of trust.

But it DOES eliminate the problem of centralized DNS control (and
centralized spy agency access to certificate authorities).

Personally, if I want to be certain that I am secure, then nothing beats
that feeling of entering/verifying the fingerprint. It's an extra step,
but I already do it for chat sessions, and it sure beats that false
sense of security IMO.


> Theses are my comments/questions. Maybe i am totally wrong but i'm
> curious about this.
> 
> 
> Marc.
> 

You do have some good points, I think you just misunderstood part of it.
I'd love to hear any more criticisms from everyone, since it helps
refine the proposal.

-FT