Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] IANA Stewardship Transition - WAS: Radical-safest TLDs in 2014

Travis Biehn tbiehn at gmail.com
Tue Oct 14 05:53:46 PDT 2014


Survey and ML [soliciting feedback from the general public] for stewardship
transition:
https://www.surveymonkey.com/s/IANA_stewardship
http://lists.arin.net/mailman/listinfo/iana-transition

-Travis

On Tue, Oct 7, 2014 at 5:08 AM, Cathal Garvey <cathalgarvey at cathalgarvey.me>
wrote:

> > Can we further reduce ambiguity by reducing the set to those TLDs
> > recognized by ICANN?
>
> Isn't it more useful to reduce the set to TLDs that the "average user"
> can connect to? That's why I shared the rumours about .onion in Firefox:
> who cares what ICANN thinks, if a large enough userbase can access it
> OOTB without configuration?
>
> By contrast, .onion *today*, along with .i2p and .bit, are all
> configuration-heavy, meaning virtually nobody will actually access or
> use them unless they're already completely dedicated customers. The Silk
> Road managed to pull people in because it was essentially the only place
> to buy drugs "safely" online (along with plenty of other reprehensible
> things), but that's a completely exceptional case.
>
> I'm thinking of benign web services that enrich the world in some way,
> but suffer censorship or legal assault because they disturb the
> status-quo. The next start-up that MPAA want to crush, or the next
> whistleblowing site, or the next transborder social network. Those
> people will need TLDs they can rely on. If .onion goes surprisingly
> mainstream in the near future, that'd be very powerful.
>
> Of course, .onion will remain slow as sin, but for those websites they
> can use .onion with 304 redirects to non-onion TLDs for each visitor; as
> their clearnet TLDs get shut down they can just register new ones and
> 304 redirect to them on the fly for each new visitor; whack-a-mole on a
> grand scale, a total losing battle for the censors. The critical bit is
> that there's one canonical URL for new visitors that will always lead to
> service.
>
> On 06/10/14 21:00, Travis Biehn wrote:
> > Rysiek,
> > Can we further reduce ambiguity by reducing the set to those TLDs
> > recognized by ICANN?
> >
> > I don't think you can 'rely' on any of them, to coderman's point.
> >
> > Your best bet is to enumerate the list of TLD delegated authoritative
> > servers, then recursively send legal threats to each.
> >
> > The one who demonstrates the most impressive apathy may be your winner :)
> >
> > Of course, you may want to follow the concept of pitting two
> noncooperative
> > countries against each other.
> > If the threat to your name isnt specifically tied to a subset of all
> > jurisdictions.. You might have a problem.
> >
> > You might, then, establish a protocol. The hash of the website CNN.com's
> > contents, for instance, may serve as a backup domain.
> >
> > Realistically its really down to finding a cool registrar & TLD pair. TBP
> > may be your best example here.
> >
> > As a final note: if you're worried about these kinds of problems you
> > probably shouldn't be using clearnet.
> >
> > Travis
> > On Oct 5, 2014 6:50 PM, "coderman" <coderman at gmail.com> wrote:
> >
> >> On 10/5/14, rysiek <rysiek at hackerspace.pl> wrote:
> >>> ... which TLD should I choose for a "clearternet"
> >>> version of the website?
> >>
> >>
> >> for present day, "clearnet" version,
> >>  winner is .bit / namecoin.
> >>
> >
>
> --
> Twitter: @onetruecathal, @formabiolabs
> Phone: +353876363185
> Blog: http://indiebiotech.com
> miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
>



-- 
Twitter <https://twitter.com/tbiehn> | LinkedIn
<http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn>
| TravisBiehn.com <http://www.travisbiehn.com> | Google Plus
<https://plus.google.com/+TravisBiehn>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20141014/4444d555/attachment.html>


More information about the liberationtech mailing list