[tor-talk] Neal Krawetz's abcission proposal, and Tor's reputation

[Jacki M]

This would also effect Onionshare’s user hosting anonymity, it would require file hosts to Reveal their identity or there onion address would keep changing.
onionshare <https://github.com/micahflee/onionshare>
> On Aug 30, 2017, at 10:18 AM, Roger Dingledine <arma at mit.edu> wrote:
> 
> This is a really important point. Thinking of onion space right now as
> the sum total of all that it can be is cutting off all of the future
> innovation.
> 
> My claim isn't "onion services are 3% of Tor traffic, so don't get
> upset about anything you find on an onion service" -- my claim is "onion
> services are still very early in terms of adoption, and as is usual for
> many decentralized techologies the extra-early adopters are not great use
> cases, and that means we need to help the space grow, and as it grows,
> if we do it right, it will become more broad and thus more good".
> 
> One concrete example of an onion service that the proposed design would
> cut off is Ricochet. Ricochet users want longterm-stable identifiers,
> and they want the identifiers to be self-authenticating. And of course
> making every Ricochet user register and maintain a domain, plus run a
> webserver, is both silly and harmful.
> 
> This example also helps to illustrate why thinking of onion services as
> only websites also artificially constrains their future. What if your
> smart refridgerator registers an onion address when you first plug it
> in, and it's only willing to receive secure updates via that channel,
> meaning it has a hugely reduced surface area to attacks?
> 
> As Alec says, the list of "things that could benefit from having a safe
> communication channel" is both enormous and open-ended. People like to
> use phrases like "dark web" or "dark continent" to evoke mystery and
> intrigue, but really, do you want to use the communications channel where
> you know for sure that you're talking to the person you meant to talk
> to, and you know that it's hard for somebody to eavesdrop on the content
> or the metadata? Or do you want to use the communications channel where
> you don't know who you're talking to, you don't know who is listening,
> and you don't know whether somebody is modifying the traffic?
> 
> Calling onion services the "secure web" and everything else the "insecure
> web" isn't very catchy, so maybe we should settle on calling everything
> else (the places where you don't know who you're talking to or who's
> listening) "dark". :)
> 
> For those following along who haven't watched our 32c3 onion services
> talk, you might find it enlightening:
> https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think <https://media.ccc.de/v/32c3-7322-tor_onion_services_more_useful_than_you_think>
> (The Defcon talk has a few more details about the next-generation onion
> service design, but I'm told the video for it won't be up for another
> couple of months.)
> 
> I think finding ways to tie onion addresses to normal ("insecure web")
> domains, when a service has both, is really important too. I'd like to
> live in a world where Let's Encrypt gives you an onion altname in your
> https cert by default, and spins up a Tor client by default to let users
> reach your webserver using whichever level of security they prefer.
> 
> And for those who made it this far down the mail, you might enjoy this
> historical tor-talk mail too:
> https://lists.torproject.org/pipermail/tor-talk/2015-April/037538.html <https://lists.torproject.org/pipermail/tor-talk/2015-April/037538.html>
> (see the paragraph towards the bottom that starts "I should also make
> clear my opinion on some of the bad uses of Tor.")