Re: Torbutton 1.3.0-alpha: Community Edition!
Drake Wilson wrote: Quoth Mike Perry mikepe...@fscked.org, 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/
Tor 0.2.2.17-alpha is out
Tor 0.2.2.17-alpha introduces a feature to make it harder for clients to use one-hop circuits (which can put the exit relays at higher risk, plus unbalance the network); fixes a big bug in bandwidth accounting for relays that want to limit their monthly bandwidth use; fixes a big pile of bugs in how clients tolerate temporary network failure; and makes our adaptive circuit build timeout feature (which improves client performance if your network is fast while not breaking things if your network is slow) better handle bad networks. https://www.torproject.org/download.html.en Packages will be appearing over the next few days. Changes in version 0.2.2.17-alpha - 2010-09-30 o Major features: - Exit relays now try harder to block exit attempts from unknown relays, to make it harder for people to use them as one-hop proxies a la tortunnel. Controlled by the refuseunknownexits consensus parameter (currently enabled), or you can override it on your relay with the RefuseUnknownExits torrc option. Resolves bug 1751. o Major bugfixes (0.2.1.x and earlier): - Fix a bug in bandwidth accounting that could make us use twice the intended bandwidth when our interval start changes due to daylight saving time. Now we tolerate skew in stored vs computed interval starts: if the start of the period changes by no more than 50% of the period's duration, we remember bytes that we transferred in the old period. Fixes bug 1511; bugfix on 0.0.9pre5. - Always search the Windows system directory for system DLLs, and nowhere else. Bugfix on 0.1.1.23; fixes bug 1954. - When you're using bridges and your network goes away and your bridges get marked as down, recover when you attempt a new socks connection (if the network is back), rather than waiting up to an hour to try fetching new descriptors for your bridges. Bugfix on 0.2.0.3-alpha; fixes bug 1981. o Major bugfixes (on 0.2.2.x): - Fix compilation on Windows. Bugfix on 0.2.2.16-alpha; related to bug 1797. - Fix a segfault that could happen when operating a bridge relay with no GeoIP database set. Fixes bug 1964; bugfix on 0.2.2.15-alpha. - The consensus bandwidth-weights (used by clients to choose fast relays) entered an unexpected edge case in September where Exits were much scarcer than Guards, resulting in bad weight recommendations. Now we compute them using new constraints that should succeed in all cases. Also alter directory authorities to not include the bandwidth-weights line if they fail to produce valid values. Fixes bug 1952; bugfix on 0.2.2.10-alpha. - When weighting bridges during path selection, we used to trust the bandwidths they provided in their descriptor, only capping them at 10MB/s. This turned out to be problematic for two reasons: Bridges could claim to handle a lot more traffic then they actually would, thus making more clients pick them and have a pretty effective DoS attack. The other issue is that new bridges that might not have a good estimate for their bw capacity yet would not get used at all unless no other bridges are available to a client. Fixes bug 1912; bugfix on 0.2.2.7-alpha. o Major bugfixes (on the circuit build timeout feature, 0.2.2.x): - Ignore cannibalized circuits when recording circuit build times. This should provide for a minor performance improvement for hidden service users using 0.2.2.14-alpha, and should remove two spurious notice log messages. Bugfix on 0.2.2.14-alpha; fixes bug 1740. - Simplify the logic that causes us to decide if the network is unavailable for purposes of recording circuit build times. If we receive no cells whatsoever for the entire duration of a circuit's full measured lifetime, the network is probably down. Also ignore one-hop directory fetching circuit timeouts when calculating our circuit build times. These changes should hopefully reduce the cases where we see ridiculous circuit build timeouts for people with spotty wireless connections. Fixes part of bug 1772; bugfix on 0.2.2.2-alpha. - Prevent the circuit build timeout from becoming larger than the maximum build time we have ever seen. Also, prevent the time period for measurement circuits from becoming larger than twice that value. Fixes the other part of bug 1772; bugfix on 0.2.2.2-alpha. o Minor features: - When we run out of directory information such that we can't build circuits, but then get enough that we can build circuits, log when we actually construct a circuit, so the user has a better chance of knowing what's going on. Fixes bug 1362. - Be more generous with how much bandwidth we'd use up (with accounting enabled) before entering soft hibernation. Previously, we'd refuse new connections
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: BetterPrivacy - necessary?
IMHO its important to suppress active content (Flash, ActiveX, Silverlight, JavaScript etc.) and other junk and therefor I prefer 'Privoxy' [1] instead of Polipo. I concur but doesn't TorButton do all this suppression? That said: what was the rationale in moving from Privoxy to Polipo? Did it happen because TorButton became standard? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: BetterPrivacy - necessary?
On Fri, 01 Oct 2010 22:29:48 +0100 Matthew pump...@cotse.net wrote: IMHO its important to suppress active content (Flash, ActiveX, Silverlight, JavaScript etc.) and other junk and therefor I prefer 'Privoxy' [1] instead of Polipo. I concur but doesn't TorButton do all this suppression? Torbutton disables plugins (e.g. Java and Flash), and restricts the capabilities of JavaScript code. That said: what was the rationale in moving from Privoxy to Polipo? Did it happen because TorButton became standard? I think Polipo was a better cache, and since an HTTP proxy can't filter evil content out of HTTPS responses, Privoxy's filtering was not very useful. Robert Ransom signature.asc Description: PGP signature
Re: BetterPrivacy - necessary?
On Fri, Oct 01, 2010 at 10:29:48PM +0100, pump...@cotse.net wrote 0.5K bytes in 12 lines about: : I concur but doesn't TorButton do all this suppression? : : That said: what was the rationale in moving from Privoxy to Polipo? : Did it happen because TorButton became standard? https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#WhydoweneedPolipoorPrivoxywithTorWhichisbetter -- Andrew pgp 0x31B0974B *** 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: BetterPrivacy - necessary?
I think Polipo was a better cache, and since an HTTP proxy can't filter evil content out of HTTPS responses, Privoxy's filtering was not very useful. Note though that the definition of evil can be game changed by running your instance inside a secure sandbox, behind a nat, and minding your session data appropriately. With no access to the rest of the system and no crosssite cookie/etc trails, that's a good win. You're really only left with the case of a rogue applet doing a 'whatismyip.com' to defeat your use of 1918 space and then sending the result to whoever your adversary may be. Depending on what the user is doing, that could be a big weakness that warrants the tradeoff of disabling 'evil' features. As usual, it would be awesome to have a tool that could de and re encapsulate https so that proxies and caches could do their thing with it. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
