Re: [tor-dev] Detecting if a IP address belongs to a Tor Exit node.

fully degrade to disconnected operation. By the time you've coded all that up, you've replicated a big chunk functionality. But, hey, maybe the requirements are poorly stated. It's hard to tell without further info. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) signat

Re: [tor-dev] Detecting if a IP address belongs to a Tor Exit node.

;t have to handle any of the hard stuff. Just ping it a request like GET http://onionoo.local/details?search=10.9.8.7&type=relay and parse the returned JSON to check the exit policy. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) signatur

Re: [tor-dev] Grailo.net is live (but very young)

ripts via NoScript; this provides the ability to selectively enable scripting on sites you trust. However, Tor itself is agnostic to what you use it for. If you write an application that can talk to a SOCKS proxy, it can be pointed directly at Tor with no need to interface with the browser. Julian -

Re: [tor-dev] Proposal 205: Remove global client-side DNS caching

On Tue, 27 Nov 2012 20:53:03 -0500 Nick Mathewson wrote: > On Tue, Nov 27, 2012 at 10:08 AM, Julian Yon > wrote: > > > > So, perhaps have a cache but only consult it for making decisions > > about whether to use a circuit, not for resolving client requests? > > Alt

Re: [tor-dev] Proposal 205: Remove global client-side DNS caching

change to the microdescriptor. Obviously the client can cache this info, and any node which subsequently doesn't honour its declared policy can still be (temporarily?) blacklisted. (Please forgive me if I'm missing something obvious. I'm not yet as familiar with Tor's inner wo

Re: [tor-dev] Proposal 213: Remove stream-level sendmes from the design

le compromise: A stream level XOFF/XON instead of SENDME would allow us to save the flow control bandwidth for properly flowing streams and still have a way to deal with stalled ones. Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) signat

Re: [tor-dev] A modest proposal for a petname system in ideas/xxx-onion-nyms.txt

time. At this point the nym can be hijacked as no secret is needed to claim it. Am I missing something? Julian -- 3072D/F3A66B3A Julian Yon (2012 General Use) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@l

Re: [tor-dev] What Should Tor Bridges and Clients Do When They Get Hosed?

vices widely used, frequently seen with SSL support, that > handle traffic that kinda looks like Tor's and are easily > implementable, are also welcome. People use SMTP, POP, IMAP, XMPP over SSL (off the top of my head). Not sure any of them look convincingly like web traffic though.

Re: [tor-dev] Proposal: Bridge Detection Resistance against MITM-capable Adversaries

ut this but it wasn't clear whether he was intending to write the idea off entirely or whether there was room to explore it further. Julian -- 3072D/D2DE707D Julian Yon (2011 General Use) signature.asc Description: OpenPGP digital signature __

Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells

7;t know enough about this. I'll have to read the documents before I can comment. J -- 3072D/D2DE707D Julian Yon (2011 General Use) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org htt

Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells

#x27;s certainly subtle. You're left with the problem of what the client should do if it can't authenticate the bridge. It still needs to send something down the pipe that it opened, and the server still needs to respond to that, otherwise the unused connection will look

Re: [tor-dev] Proposal 189: AUTHORIZE and AUTHORIZED cells

; feel free to tell me where the flaw in my logic lies) Julian -- 3072D/D2DE707D Julian Yon (2011 General Use) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev