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

Re: Torbutton 1.3.0-alpha: Community Edition!



Thus spake Drake Wilson (drake@xxxxxxxxxxxx):

> Quoth Mike Perry <mikeperry@xxxxxxxxxx>, on 2010-10-01 18:51:07 -0700:
> > Intuition also tells me that tor:// and tors:// urls will be easier to
> > use, understand, and remember by the general public.. Can you give
> > some examples/reasons why just using these schemes actually prevents
> > us from doing this scheme layering idea for other protocols in the
> > future (when it is supported)? In otherwords, why can't we just do both?
> 
> It doesn't inherently do that, but it leaves a very bad taste in my
> mouth.  If the HTTP form is that much shorter, now it's implicitly the
> first-class one: it gets the premium name that people will actually
> use, and every other protocol is stuck with the leftovers.  This is
> the same layer violation, just enforced fuzzily by hordes of humans
> acting on their baseline psychology instead of by software, so I still
> consider it pollution of the URI space: it's supposed to be Universal
> Resource Identifiers, not A Pup Called HTTP.

Doesn't your suspicion that baseline psychology will lead users to use
tor:// over torhttp:// given the opportunity to use either tell you
anything about which interface is more user friendly?

> The fuzzy URI-matching you mentioned is something I hadn't considered,
> and is an unfortunate practical constraint in this case.  That would
> lead me to consider, say, prefixing schemas with "or" instead, to keep
> the whole thing alphabetic.  orhttp:, orhttps:, orirc:, ... ?

Heh, it turns out this has the same problem, at least with Pidgin.
torhttp://link.com still creates an http hyperlink that when clicked
on directly would be loaded outside of Tor.

httptor://link.com does not create a hyperlink, though.. Nor does
http+tor://link.com.

Perhaps the way we could specify this is that officially, the scheme
format is [scheme]+tor://site.com where if scheme is omitted, it
defaults to http. But then that still leaves tors as the bastard child
short-hand for https+tor://site.com. But I'm fine with bastard
children. 

> (I can say on a personal level that I am hardly unbiased, and that I
> will refuse to accept or produce tor: URIs if non-HTTP protocols get
> the short/long end of the stick/schema, not that that particularly
> matters.)

Call me an unrepentant utilitarian, but 2 computer scientists refusing
to use a feature for a reason that 90% of our userbase won't even
understand doesn't strike me as a compelling reason to do anything.

However, patches from said 2 protesters might change my mind ;)

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Attachment: pgpiFWrcd9nSc.pgp
Description: PGP signature