Re: Torbutton 1.3.0-alpha: Community Edition!
Thus spake Drake Wilson (dr...@begriffli.ch): > > 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. > > Dear gods. > > Okay, I suppose that probably means that horse has already bolted. > This is sad. I tentatively retract my suggestion in light of that. Well I think that specifying that urls are technically officially supposed to be http+tor://, but that the http+ can be omitted gives us the best of both worlds. These urls seem to be then treated mostly correctly by dumb link parsers, because they will just become tor:// links if parsed, which would then work as normal. The exception is that https+tor:// may then be treated as just a tor:// url by a link parser, which effectively converts it into a torrified http url, dropping vital ssl support. Hence, I think we should also provide tors:// as an "unofficial" backup scheme for these cases. So no, your suggestion wasn't totally busted. It just required lots of attempts to make it actually be practical. :) -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpRxL1EIgQhj.pgp Description: PGP signature
Re: Torbutton 1.3.0-alpha: Community Edition!
Quoth Mike Perry , on 2010-10-03 13:46:29 -0700: > 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? I don't believe in small increases in "friendliness" at the expense of a characteristic I'm a bit too drowsy to name properly right now. :-) > 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. Dear gods. Okay, I suppose that probably means that horse has already bolted. This is sad. I tentatively retract my suggestion in light of that. See, I'm not _completely_ impractical. :-P ---> Drake Wilson *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Torbutton 1.3.0-alpha: Community Edition!
- Original Message > From: Mike Perry > To: or-talk@freehaven.net > Sent: Sun, October 3, 2010 10:46:29 PM > Subject: Re: Torbutton 1.3.0-alpha: Community Edition! > > > 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. Worse, it does so in the default browser. Even if you have Tor running in Firefox, your request may be sent through a new instance of IE without Tor. Instead of using a protocol to tell Torbutton to ensure routing through Tor, have you considered using the .onion TLD for that purpose? That would also help guard against accidentally revealing which hidden service you are looking for if you try to hit it when Tor isn't running. The links could look like http://www.google.com.onion/ or https://www.google.com.onion *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Torbutton 1.3.0-alpha: Community Edition!
Thus spake Drake Wilson (dr...@begriffli.ch): > Quoth Mike Perry , 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 pgpz46FZHPAX2.pgp Description: PGP signature
Re: Torbutton 1.3.0-alpha: Community Edition!
On Sat, 02 Oct 2010 14:59:42 -0500 David Bennett wrote: > I haven't tried the new version yet, is there a descriptive popup that > explains what's happening when a user clicks a tor:// or tors:// ? Yes. Robert Ransom signature.asc Description: PGP signature
Re: Torbutton 1.3.0-alpha: Community Edition!
On 10/01/2010 08:51 PM, Mike Perry wrote: > 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? > > There is no reason why not. As long as there are no obvious risks with a user clicking on a public tor:// URL and initiating the proxy layer. My understanding of the implementation is that all traffic occurring in the host browser after a tor:// request is initiated would be re-routed unless the 'tor' schema handler launched a separate host browser. This may not be the intention of the user and may conflict with accessing IP whitelisted services (FTP hosts, etc...) I haven't tried the new version yet, is there a descriptive popup that explains what's happening when a user clicks a tor:// or tors:// ? --Dave *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Torbutton 1.3.0-alpha: Community Edition!
Quoth Mike Perry , 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. Other possible points, all somewhat weak in isolation: - There are potential future uses of the "tor:" schema that would be more generic to Tor as a whole, such as URI references for relays. Imagine registering a schema with a QR code reader for more conveniently transmitting a bridge descriptor on paper. - The schema doesn't make it clear what protocol is actually in use. If I've never seen one of these before, I have to guess what that URI actually means, as opposed to it being a clear variant on the underlying HTTP URI. 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:, ... ? (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.) ---> Drake Wilson *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Torbutton 1.3.0-alpha: Community Edition!
Thus spake David Bennett (dbennett...@gmail.com): > On 09/30/2010 08:36 PM, Drake Wilson wrote: > >> This release features "tor://" and "tors://" urls that will > >> automatically enable Tor before loading the corresponding http or > >> https url. > >> > > Ick. This sort of layer-mixing is the sort that forces people to use > > a certain protocol for no actual reason. > > ... > > Is there a reason not to use something like tor+http and tor+https for > > the schema, thus opening up the space for (as a facetious example) > > tor+nntp or analogous usages later? > > > > Drake is correct, I don't think that scheme transport swap method is a > great idea. > > That being said, the ability to bookmark a site securely is > advantageous. Plus, relative URL's referenced on a host would inherit > the scheme. This is not the case. The way the featur works is that Firefox instantly converts the url to the real scheme after enabling Tor and before loading the page. > I do understand why it was implemented this way. Scheme stacking would > be much more difficult to pull off given current browser technology. To > the best of my knowledge, there are no browsers that would easily > support this. This rears its head in a lot of other places. For example, try emailing, IMing or posting these urls to google groups. If you specify tor:// as the prefix, worst case the url is not converted to a hyperlink, but best case it is, and the user can just click on it. However, all places I have tried to specify tor+http://link.com, the http://link.com portion of the url is transformed into a hyperlink by the software, but the "tor+" part is lost. This leaves room for user error and also makes things inconvenient. 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? -- Mike Perry Mad Computer Scientist fscked.org evil labs pgppcha8WnMM3.pgp Description: PGP signature
Re: Torbutton 1.3.0-alpha: Community Edition!
On 09/30/2010 08:36 PM, Drake Wilson wrote: >> This release features "tor://" and "tors://" urls that will >> automatically enable Tor before loading the corresponding http or >> https url. >> > Ick. This sort of layer-mixing is the sort that forces people to use > a certain protocol for no actual reason. > ... > Is there a reason not to use something like tor+http and tor+https for > the schema, thus opening up the space for (as a facetious example) > tor+nntp or analogous usages later? > Drake is correct, I don't think that scheme transport swap method is a great idea. That being said, the ability to bookmark a site securely is advantageous. Plus, relative URL's referenced on a host would inherit the scheme. Based on: http://labs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#scheme I agree that tor+scheme or tor.scheme would be a better nomenclature. It appears that +, _ and . can be used as separators. For example: tor.mailto:u...@someplace.org could use an SMTP anonymizer. I do understand why it was implemented this way. Scheme stacking would be much more difficult to pull off given current browser technology. To the best of my knowledge, there are no browsers that would easily support this. If you could specify tor.* as a scheme and that scheme would launch tor, set the proxy in the browser and then reprocess with the rvalue recursively then this would be feasible However, it would require non-trivial customization of the browser. I can think of other uses for this such as blind.http:// that would launch a non-visual accessibility browser. Then the visually impaired user could access anonymously using: tor.blind.http:// Someone needs to write a 'scheme stacking' URI extension RFC. --Dave *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Torbutton 1.3.0-alpha: Community Edition!
Drake Wilson wrote: > Quoth Mike Perry , on 2010-09-30 15:57:48 -0700: > > This release features "tor://" and "tors://" urls that will > > automatically enable Tor before loading the corresponding http or > > https url. > > Ick. This sort of layer-mixing is the sort that forces people to use > a certain protocol for no actual reason. (Cf. the "feed" schema, > which similarly forces HTTP with a certain interpretation, last I > recall.) Tor doesn't just work with HTTP, and URIs don't only refer > to HTTP resources, even if HTTP is one of the most popular protocols > in use today and possibly the only one many non-technical people would > recognize. > > Is there a reason not to use something like tor+http and tor+https for > the schema, thus opening up the space for (as a facetious example) > tor+nntp or analogous usages later? I really like the idea of "tor+http" or "tor+https" over tor/tors just like the way I hate the way Google Chrome has dropped "http://"; from their URL bar. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Torbutton 1.3.0-alpha: Community Edition!
Quoth Mike Perry , on 2010-09-30 15:57:48 -0700: > This release features "tor://" and "tors://" urls that will > automatically enable Tor before loading the corresponding http or > https url. Ick. This sort of layer-mixing is the sort that forces people to use a certain protocol for no actual reason. (Cf. the "feed" schema, which similarly forces HTTP with a certain interpretation, last I recall.) Tor doesn't just work with HTTP, and URIs don't only refer to HTTP resources, even if HTTP is one of the most popular protocols in use today and possibly the only one many non-technical people would recognize. Is there a reason not to use something like tor+http and tor+https for the schema, thus opening up the space for (as a facetious example) tor+nntp or analogous usages later? ---> Drake Wilson *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Torbutton 1.3.0-alpha: Community Edition!
"Release early and release often" is the motto, or so I'm told.. Well
I never liked getting up early, but maybe we can at least try for
often with this one. But probably not..
Despite these shortcomings of mine (among others), Torbutton
1.3.0-alpha is the first release of Torbutton where most of the code
has come from our community members!
This is great, because after many long years of Torbutton development,
I barely have enough time and sanity remaining to maintain bugfixes on
1.2.x. Not that I started with very much of either in the first place,
I suppose[1]...
And with that, it gives me great pleasure to announce Torbutton
1.3.0-alpha! Due to limitations of addons.mozilla.org, the alpha
series will only be available at the Tor website:
https://www.torproject.org/torbutton/releases/torbutton-1.3.0-alpha.xpi{,.asc}
This release features "tor://" and "tors://" urls that will
automatically enable Tor before loading the corresponding http or
https url. Useful for bookmarks of your tor sites, or sharing urls
with other Torbutton users to ensure that they load them safely
through Tor. It also features a cookie manager that attempts to allow
you to protect specific cookies that you want to preserve between Tor
modes, as well as intelligent referrer spoofing.
All three of these features were written by Kory Kirk, for his 2009
GSoC summer of code project. (What did I say about "early"?)
It also features support for a Transparent Proxy or Tor router (or
your regular connection), where Torbutton's protections can be enabled
without using any proxy. This feature was written by Jacob Appelbaum
and Kory Kirk.
These features should be regarded as *experimental*. In particular,
the cookie manager needs testing, to ensure that it is actually
properly protecting and deleting the right cookies, without leaking
them from state to state. Someone should also pay close attention to
the referrer behavior to ensure it is behaving sanely.
What little time I have for Torbutton development will be devoted to
supporting Firefox 4, and trying to work through this neverending set
of bugs for 1.2.x: https://trac.torproject.org/projects/tor/report/14
However, it would be great if we could drum up some more community
interest in developing these and other features, too. In particular, I
think it would be really swell if the cookie manager could be extended
into providing a "New Identity" button, complete with an optional
timer to run periodically. There's tons of other potential features
waiting to be implemented in the "Enhancements" section of that trac
report, too.
Here is the complete ChangeLog for 1.3.0-alpha:
* new: Support for transparent proxies in settings
(patch from Jacob Appelbaum and Kory Kirk)
* new: tor:// and tors:// url support to auto-toggle into tor mode
(patch from Kory Kirk)
* new: Cookie manager to allow individual Cookie protection
(patch from Kory Kirk)
* new: Add referrer spoofing based on modified same origin policy
(patch from Kory Kirk)
* new: Add DuckDuckGo.com as a Google captcha redirect destination
(patch from aiden tighe)
* bugfix: bug 1911: Fix broken useragent locale string on debian
(patch from lunar)
* bugfix: Fix captcha detection for encrypted.google.com
[1]. http://archives.seul.org/or/talk/Mar-2007/msg00417.html
--
Mike Perry
Mad Computer Scientist
fscked.org evil labs
pgp7g0wnUDodv.pgp
Description: PGP signature
