[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor and Google error / CAPTCHAs.



On Sun, Oct 2, 2016 at 5:53 PM, Alec Muffett <alec.muffett@xxxxxxxxx> wrote:
>    "How many more of X?  How many X should there be in total?
> So now we need "more than 1" proxy network - but still, how many?

Fermi Napkin is legit approach.
Though network quality and purpose must also be included in that.

> ...if we wanted it enabled by default, then what we are actually saying is
> that there is a feature of "anonymity <blah blah blah>" which needs to be
> hardcoded into TCP, because everyone would want it for every occasion.
> This is clearly a nonsensical position - because I neither need, want or
> desire the overhead of anonymity for the vast majority of my bytes

Everyone isn't aware of why they might want it, and what they
are up against today. So of course their current position when
asked might be as such. Educate them and maybe they'll think
differently.

> but also that most traffic will not need anonymity
> (else we'd be petitioning the IETF to amend TCP) ...
> in order to smooth traffic
> and bury access signals in noise.

There was a cryptography@metzdowd thread on integrating
fill traffic and encryption into the phy layer of all point-to-point
links making up the internet from tier-1's to home's, as an
IEEE / IETF process. Defeating traffic analysis at that level.
Simple line rate stuff possible today with a handful of gates
in next years model. Don't know where that discussion went.

When the options are everywhere, and it's not really costly
whether in amortized dollars or performance, the use cases grow,
and the point of trying to define need over want just becomes
moot and you turn it on by default.

Nevermind that it's probably harder excercise to find example
where you want non-addressees of *your!* communications
to be reading or able to listen / see it.

> so we need 7000 proxy networks to support them.

I see what you did there working Fermi in reverse
behind 7000 proxies, ftw ;)

> lack of penetration of
> advanced internet anonymity practices into *Darkest Peru and other parts of the world.

Peru could change the world.

> all those proxy
> networks which are designed to let people watch TV when they are not in
> their home country <cough/>

That would be one of "purpose"s above.

> So I am not ever going to bitch about how many networks we need to have,
> since my guess of how many we "need" approximates reality.

Quantity, perhaps. But there's lots of work to make what they
claim to do match reality.

> Perhaps instead I could bitch about is 'Market Dominance' of Tor?

I already wrote about that elsewhere re diversity.

> So we should take that million+ people that Tor already has, and break it
> up in order to foster more networks?

No need, plenty of new users to collect. Of course some Tor ones will
come along for the ride.

> We want big crowds of about that size.

Yes, underutilization is a problem, especially for anonymity
networks that require utilization to deliver claimed properties.

> Good question.  My take: innovate and evangelise, stop pretending that
> one-size-fits-all.

Tor has plenty of both, so the next step is to get off tor lists and get
on to the next size list.

> Shoot any user-experience consultants who tell us that people can't deal
> with complexity & nuance.

No ivory tower needed to build stuff, though UX can't be ignored.

> Use & improve Tor for access to Onions & for the clearnet.

TPO is doing tor.

> Foster & support I2P for... well, whatever I2P is good at. I have no
> interest in filesharing and a major valueprop of Tor to me is bridging to
> clearnet through exit nodes

I2P offers exit services. Its users can operate exit nodes.
Using the feature is more like choosing proxies or vpns
and requires some setup vs being integrated like tor.

Exactly like how I outlined tor exit operators could run openvpn
terminations to provide other-than-TCP-exit-only service,
and IP block dodging. I don't expect tor to do either anytime soon.

> having a namespace which intersects the rest of the web

s/namespace/URI scheme/

> I'd like to go play with it but I am missing a reason to do so.

It's different, and has different knobs?

> Create _new_ stuff.  That'd be superb.  Just don't try to be like the early
> Torfork weenies, proclaiming that they would split the Tor userbase (and,
> presumably, onion namespace) and that this would be "progress".

It's one approach, and forking is valid per license, so cannot complain.
https://rotorbrowser.com/ https://twitter.com/indieonion

It's really no different than anything here.
https://trac.torproject.org/projects/tor/wiki/doc/ListOfTorImplementations

I'd support any Independant Onion project, same for any non onion
project in the field.

>> Then I want graduated service enablement based on
>
> Oh, that's *bullshit*

Not really. Discriminating human from bot, is different than human
from human, and nym from IRL, and good from bad. You're right,
I'd be quite careful when selecting which of many tools to use
to help enable access for users of these nets.

> #STRAWMAN "<social networks> are creating databases of user interaction
> behaviour - your typing speed, how long you take to solve a captcha - in
> order to track you and deanonymise you"

We know the whitepapers tell us some of these systems have
enough bits^2 to do that. That researchers are collecting and
making anonymized statistical analysis from live systems. And
we know there are deployments of same or similar ideas for those
exact purposes in places from advertising to NSA.

What's more revolting than it happening, is that users aren't
being told by those who are doing it that it's happening.

> The issue is that "authentication" and "deanonymisation" are from many
> practical perspectives **exactly the same thing**.

Depends on the context.

> I am with you on "graduated service enablement" as a fine goal - that if
> you have only authenticated to a weak level, you should only be permitted
> to do less-harmful things

"Authenticated to a weak level" ... no. Well, correct user:pass is at
least minimally authenticated (AAA meaning), regardless of other
layers inside. But in the nym space we must respect wish not to
authenticate to IRL, that from the user perspective, they have valid use
of the service contexts that do not require it, and for which it is bad.
Which your quote does not seem to consider, but more like the
concept of "levels" of bitcoin exchange authentication to IRL.
Which may be useful there, but not in context of nym.

> people cannot cope
> with a bank transfer failing when they try to do it over SMS but not over
> Wifi, from the same app.

Users are to blame too.
Though at this early stage we probably have to say that masses
dl'ing app from bank are probably not same class of user installing
anon / overlay networks.

>> For such services, I want canceling of accounts, not canceling of IP's.
>
> To reduce harm and cost, sometimes you will get a little of both.

With a bit of training, an entry level helpdesk junkie can review and
nuke an amazing amount of genuinely bad accounts. I'd suggest the
big corps can afford to dedicate a junkie or two to similar tasks,
under recognition that IP blocks alone take out good with bad.

They'll have to dedicate anyways, exactly as they have to clearnet,
as the clearnet and anon overlays begin reaching relative parity
bad:good ratios and overall unignorable user counts and demand.

>  The wise
> company will treat blocking of known-proxy-network IPs differently from
> those which are more inarguably evil.

Of course, if they're rigged to discriminate between, and wish to.

> I think you are saying similar things to me

Nothing to you.

> judgemental place.

Yes, users are frustrated with current methods.
Probably because they can see at least some other
more finegrained options out there that aren't yet being used.

It's not as if legit users are wrong for simply wanting to
use a service, even anonymously so. It's interesting
if they are pushing their use case, whether or not they
can yet articulate it in disciplined manner to CEO.

Even the esteemed tor project doesn't really have a
division dedicated to helping users do this. And they
assassinated and lost some voices in the speaking circuit.

> You can't blame people who don't know about Tor and similar technologies,
> from blocking the IP addresses associated with it.

If the CIO/CSO/CTO, even on down into the techs, at any of these top N sites
in their categories, did *not* know about tor / vpn / proxy (or have a staffer
they knew to go ask about what's up with the IP's), after decades of these
tools existance and relavance as a class to netsec, even if only in a "Oh
is that that DeepSilkLeaks thing I heard on the news" sort of way, I'd consider
them incompetant and fire them.

Also not supposed to give the history eraser^W^W block button
to clueless morons.

> Solution: make Tor more well-known, and associated with social enablement
> and do-gooding.

s/Tor/Anonymous Networks/

> Parachuting clones of me into organisations is not what changes things.
> ...
> but there are also these *other* people who use the service

Yes, the gist of what I meant was, they don't trust hearing it from
users, and they don't trust hearing it from the likes of Tor Project,
to them they're both biased and outside. But if they hear it from some
lateral in another company, or from certain other circles, they're more
likely to listen and implement.

> who need especially it in sudden
> rushes when bad things happen, so we need to build things such that
> accommodations are made for that.

That's backwards, you're not going to onboard users when shtf unless
you've already done the work to allow them in general population
long beforehand.

> so we need to build things such that
> accommodations are made for that.

> You have to fix the *culture* and *perception*, not parachute-in a
> Muffett-shaped widget.

Then drop in mullet wearing mullahs named Mufasa and mix it up.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk