<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 31 December 2017 at 02:46, nullius <span dir="ltr"><<a href="mailto:nullius@nym.zone" target="_blank">nullius@nym.zone</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For the foregoing reasons, I will propose that subdomain data, if any, be kept separate from the Bech32 coding. It may be either kept in a separate string, or somehow affixed with a special delimiter either before or after the Bech32 representation of the onion. Off-the-cuff, which of these looks best to you?<br>
<br>
<font face="monospace, monospace">www:onion19qzypww2zw3ykkkglr4t<wbr>u9</font><br>
<br>
<font face="monospace, monospace">onion19qzypww2zw3ykkkglr4tu9:w<wbr>ww</font><br>
<br>
<font face="monospace, monospace">another-level.www:onion19qzypw<wbr>w2zw3ykkkglr4tu9</font><br>
<br>
(My choice of a delimiter here may be wrong, if we want for the browser’s address bar to translate it. I should think more about this.)<br></blockquote><div><br></div><div><br></div><div>I need to think about this more, and after coffee, but my first concerns would be:</div><div><br></div><div>1) that having multiple representations of a site's onion address is likely to break many/most sites, because of Host/Origin headers being complicated enough already.</div><div><br></div><div>2) anything involving colons in any position ("<font face="monospace, monospace">https://</font><span style="font-family:monospace,monospace">onion19qzypww2zw3ykkkglr4tu9:w</span><wbr style="font-family:monospace,monospace"><span style="font-family:monospace,monospace">ww</span><font face="monospace, monospace">/</font>") is likely to break both client-side-web-browsers and server-side-CMS-software unless they are specially re-engineered for Tor, which is likely to inhibit use *of* Tor; colons are a port-number separator in URLs, unless they come as part of an IPv6 address in [square brackets].</div><div><br></div><div><br></div><div>My general sense is that: </div><div><br></div><div>a) if Onion addresses suddenly stop looking very-similar-to DNS addresses, Tor risks returning to a world where special expertise is necessary to build software for it, thereby harming growth/adoption</div><div><br></div><div>b) if Onion addresses have 2+ forms, one like the current (<font face="monospace, monospace">www.<span style="color:rgb(84,84,84)">4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.</span>onion</font>) and the other being apparently more human-usable because it contains a CRC, the one which allows access to websites will win.</div><div><br></div><div><br></div><div>My expectation to date has been that the problem with "<span style="color:rgb(84,84,84)"><font face="monospace, monospace">4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad</font></span>" is that that there is no place for the eyeball to rest when typing it in; as such I've presumed that a canonical form, defined by Tor, would be something like:</div><div><br></div><div><font face="monospace, monospace"><a href="https://www">https://www</a>.<span style="color:rgb(84,84,84)">4acth47i-6kxnvkew-tm6q7ib2-s3ufpo5-sqbsnzjp-bi7utij-cltosqem-ad.onion/</span></font></div><div><br></div><div> ...being N groups of M characters (where N and M can be argued, feel free...) and where any unused characters within the 63-character DNS-compliant budget can be used to implement a credit-card-like running checksum or CRC, for quick client-side checks; eg: the URL bar can identify that you are typing in an Onion address and leave it red-or-grey until you type something which satisfies the checksum, before flinging it at tor-daemon for attempted resolution.</div><div><br></div><div>Or, indeed, you could leave out the hyphens and do the same; the Prop224 Onion address is 59 characters, leaving a budget of 63-59==4 characters or 20 bits; we could put these at the end, in the space marked "@@@@":</div><div><br></div><div><div><font face="monospace, monospace"> <a href="https://www">https://www</a><span style="color:rgb(84,84,84)">4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad@@@@.onion/</span></font></div></div><div><font face="monospace, monospace"><span style="color:rgb(84,84,84)"><br></span></font></div></div><div>....and use those 20 bits to implement 5x 4-bit checksums over 12-character chunks:</div><div><br></div><div> <span style="font-family:monospace,monospace"> https://{www</span><span style="font-family:monospace,monospace;color:rgb(84,84,84)">4acth47i6}{kxnvkewtm6q7}{ib2s3ufpo5sq}{bsnzjpbi7uti}{jcltosqemad@}@@@.onion/</span></div><div><font face="monospace, monospace"><span style="color:rgb(84,84,84)"><br></span></font></div><div><span style="color:rgb(84,84,84)"><font face="arial, helvetica, sans-serif">...so that any UX component which wants to help the user can highlight (in red? or bold?) where the problem is, picking out a chunk of 12 characters which contain the typo:</font></span></div><div><font face="monospace, monospace"><span style="color:rgb(84,84,84)"><br></span></font></div><div><div><font face="monospace, monospace" style="background-color:rgb(255,255,255)"> <a href="https://www">https://www</a><font color="#545454">4acth47i6kxnvkewtm6q7</font><b style=""><font color="#ff0000">ib2s3ujpo5sq</font></b><font color="#545454">bsnzjpbi7utijcltosqemadwxyz.onion/</font></font></div></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="monospace, monospace"> ---------------------------------^^^^^^^^^^^^ </font></span></div><div><br></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif">Spot the errant 'j'.</font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif">The advantage of a system like this is that it's not perfect, but a typo mostly has to happen twice and be quite fortunate to go undetected.</font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif">Of course it's not perfect, but nothing will be, and clever selection of checksum and encoding will result in something which is still DNS- and Browser-compliant.</font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif"> -a</font></span></div><div><span style="color:rgb(84,84,84);background-color:rgb(255,255,255)"><font face="arial, helvetica, sans-serif"><br></font></span></div><div><span style="font-family:monospace,monospace;color:rgb(84,84,84)"><br></span></div><div><br></div>-- <br><div class="gmail_signature"><a href="http://dropsafe.crypticide.com/aboutalecm" target="_blank">http://dropsafe.crypticide.com/aboutalecm</a><br></div>
</div></div>