couldn't the originating user register through a distributed table, or automatic registration if the website doesnt already exist, and this would give this user the power to set up the default hosting locations (freedombox, box's, some server somewhere, etc) This power user could specify that if the default location (Location1) goes down, to then use my specified location 2 (Location2)? This would allow a distrubuted approach with some resistance to poisoning. The multiple locations of the mirrored site backups could all be hosted on freedombox's for all we care, heck other freedomebox users could opt to help host/mirror a site/file/ect <br>
<br>if a location that is mirroring a site goes bad, the admin could of course remove this from the registered DSN setup<br><br>the real trick is, to keep these records, and connections anonymous. No standard emails used for registration, not recording various information like ip address's/macs <br>
<br><br><br><br><div class="gmail_quote">On Mon, Jul 4, 2011 at 11:58 AM, Marc Loupias <span dir="ltr"><<a href="mailto:list@marc-loupias.fr">list@marc-loupias.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<br>
some comments on this :<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
First, WHAT PROBLEMS WOULD THIS SOLVE?<br>
<br>
<br>
<br></div><div class="im">
5) Eliminates the need for certificate authorities. (A FAILED SECURITY<br>
MODEL, YES?)<br>
<br>
<br>
</div></blockquote>
<br>
GPG does not eliminate certificate autorities problems. It just move the trusting problem.<br>
The technology is not the problem, as you are using GPG or X.509 PKI the problem remains the same : Which self-signed certificate can i trust.<br>
<br>
This question can't be solved by any geeky technical hack, it is a matter of person.<br>
<br>
For exemple if the Mozilla Corpo dont trust VeriSign, it can build his own X.509 PKI and distribute his own root certificate in his browser. And the millions of people using it will see the Mozilla certificate as legal.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<div class="im"><br>
<br>
<br>
WHAT IF I DON'T ALREADY HAVE THE CONTRACT? HOW DOES THE PLUGIN FIND IT?<br>
<br>
<br>
SHORT FORM:<br>
In most cases it already has the ID (in the URL), so it just downloads<br>
the contract based on that ID, via P2P or from a Distributed Hash Table.<br>
Then it verifies the contract based on the ID and the signature, and<br>
then it actually connects to the website and displays it, using one of<br>
the addresses inside the contract (whether via i2p, tor, freenet, ip,<br>
dns, etc. The contract supports as many as you wish.)<br>
<br>
<br>
<br>
</div></blockquote>
<br>
There is a big problem here.<br>
<br>
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.<br>
<br>
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.<br>
<br>
It will quickly go to a maze of deadlinks.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[...]<div><div></div><div class="h5"><br>
<br>
<br>
WHAT IF IT NEEDS TO RESOLVE THE NAME FIRST, TO GET THAT ID?<br>
<br>
<br>
LONG FORM:<br>
In this example we actually have to resolve the name "freedombox.otc"<br>
and find the right contract.<br>
<br>
1) The plugin can make a request via P2P. (Coming soon to<br>
Open-Transactions out of necessity for the digital cash, due to the<br>
nature of the minting files.) The plugin thus asks my peers to lookup<br>
the contract ID in their own local lists, and so I can find the contract<br>
via a "web of trust".<br>
<br>
2) Optionally, alternately, or additionally, my plugin may contact<br>
certain specialized "search engines for contracts", which I predict will<br>
arise on darknets. This is only a matter of time.<br>
Thus, instead of searching Google for "freedombox" and getting a list of<br>
sites, there would be various darknet-based aggregator sites where I<br>
could type "freedombox" and get a list of contracts.<br>
<br>
3) Whether the plugin uses p2p or search engine, or both, EITHER WAY,<br>
MULTIPLE CONTRACTS might come up for the SAME NAME!<br>
<br>
This is okay!!!!!! People automatically assume this is some big problem<br>
to be solved, but you can instead realize that IT'S NOT A PROBLEM AT<br>
ALL. The sun will still come up in the morning. The sky is not falling.<br>
<br>
4) If such a name conflict happens, that's okay: just check the<br>
fingerprint and approve the correct one. You'll see the list of IDs, and<br>
you can click and view each contract. You probably got the site ID off<br>
of a business card, anyway. THIS IS JUST LIKE VERIFYING A FINGERPRINT<br>
FROM A BUSINESS CARD, OR VERIFYING A FINGERPRINT DURING OTR CHAT. (And<br>
you only do it once, in the rare event of a conflict.)<br>
<br>
</div></div></blockquote>
<br>
Oh no this is not okay.<br>
<br>
99% of people need SIMPLE things.<br>
<br>
Giving them a choice before accessing a ressource on the net is bad for the user experience.<br>
In the most case, people will pick a random contract just because they dont understand what is goin on with this new window.<br>
<br>
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.<br>
<br>
There is a second big issue, i click on a link and my browser pop a windows with 10 contract pointing on <a href="http://freedombox.org" target="_blank">freedombox.org</a>. How can i choose the correct contract ? On which basis ?<br>
<br>
And what about softwares using your system ? For example P2P. Who will click on the right contract ?<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5) In most cases, THIS STEP ISN'T NECESSARY, since in most cases you<br>
will be clicking on a link, not typing the name by hand, and the link<br>
itself will ALREADY have the ID, (no need to resolve it from the name.)<br>
<br>
</blockquote>
<br></div>
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.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Instead, the plugin IMMEDIATELY loads (or downloads) the appropriate<br>
contract based on its ID, then verifies its signature, and then connects<br>
to the website.<br>
<br>
6) Also, remember once you enter the ID the FIRST TIME, then the name<br>
will work EVERY time after that. (Since the plugin can just look it up<br>
locally.)<br>
<br>
7) You can even choose to import contracts that both claim the same<br>
name. (This will rarely or never happen.) When the plugin encounters<br>
such an ambiguity, it'll just pop up the list and ask you to choose one.<br>
No big deal!<br>
<br>
</blockquote>
<br></div>
Choosing IS a big deal for 99% of the users. Especialyy on a trivial thing like clicking on a weblink.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
8) The contracts themselves can be globally available in a DISTRIBUTED<br>
HASH TABLE. This way the owner can continually update the contract,<br>
everyone can see it, and it's censorship-resistant.<br>
9) It's easy to update contracts in the DHT as necessary. Perhaps the<br>
"main ID" is just a DHT address where the "current version ID" can be<br>
found. This way you can change versions without changing your main ID.<br>
The DHT address can be a hashed public key, where the owner is the<br>
holder of the private key.<br>
<br>
</blockquote>
<br></div>
So the ID is not the contract hash ?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
WHAT PROBLEMS DOES THIS SOLVE?<br>
<br>
1) People can use any "DNS name" they want for their website. It will<br>
never be "already taken".<br>
<br>
2) There is no central "DNS server". No central authority.<br>
<br>
3) Name conflicts are rare, and easily handled. Conflicts also naturally<br>
cause the user to choose the right one based on the FINGERPRINT. Isn't<br>
this a good direction?<br>
<br>
</blockquote></div>
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.<br>
And it introduce complexity where there isn't for the DNS. So people will just not use your system.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4) Supports ALL PROTOCOLS. (Whichever addresses you put in your<br>
contracts... tor, i2p, ip, dns, freenet, etc.)<br>
<br>
5) Eliminates the need for certificate authorities. (A FAILED SECURITY<br>
MODEL, YES?) You already have the site's public key from their contract,<br>
so your browser can just use that to encrypt a session key.<br>
<br>
</blockquote></div>
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 ...<br>
<br>
<br>
<br>
<br>
Theses are my comments/questions. Maybe i am totally wrong but i'm curious about this.<br><font color="#888888">
<br>
<br>
Marc.</font><div><div></div><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
Freedombox-discuss mailing list<br>
<a href="mailto:Freedombox-discuss@lists.alioth.debian.org" target="_blank">Freedombox-discuss@lists.<u></u>alioth.debian.org</a><br>
<a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss" target="_blank">http://lists.alioth.debian.<u></u>org/cgi-bin/mailman/listinfo/<u></u>freedombox-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Thank you for your time<br>~Nathan<br><a href="mailto:nathan1465@gmail.com" target="_blank">nathan1465@gmail.com</a><br><br>