On Friday 14 March 2008 11:21:55 you wrote: > On Tue, Mar 11, 2008 at 08:35:17PM +0000, Robert Hogan wrote: > > - A frame (or image link ) that launches a request to > > http://[unqiuesessionid].tor/test.jpg. This frame has a caption stating > > that 'could not resolve domain name' or a blank image means you are > > leaking DNS. If you are not, Tor recognises the sessionid and special url > > and serves a 'DNS OK' page or image in that frame. > > Thanks for the suggestion. > > The reason I didn't use this approach is because what happens if the > browser is not configured to use Tor. A blank image or generic "could > not resolve domain name" error message is not very helpful. With my > proposal, a user would be sent to a webpage which explains what went > wrong and how to fix it. > What I had in mind was html along the following lines: <p>This wizard will test if your browser is correctly configured for using Tor.</p> <p>Take a look at the box below. Does it contain an image of the Tor logo?</p> <IMG src="http://jfklsfjslkfdsl.tor/torlogo.jpg"; alt="If you can see this text, please click 'No'" width="200" height="200" align="middle" border="2"> <br> <INPUT type="button" name="Yes" value="Yes"> <INPUT type="button" name="No" value="No"> Clicking 'No' (as prompted by the alt text if the image is not displayed and/or the text above the image) would serve the webpage describing what the user needs to do to prevent dns leaking. If the image is properly displayed, the user would click Yes and go to a page serving another image that tests external connectivity. There's no reason why both these pages couldn't be served directly by Tor also. > There is still one problematic case, which is if the proxy > configuration is set to the wrong port. Here the user would see a > generic error message. Maybe there could be some way to combine the > two approaches, since connections to 127.0.0.1 will bypass proxy > settings in most cases. > > This does mean, however, that if Tor is not running at all, the user > would get a generic error page. I can't think of a solution which > fixes both cases in a neat way. The tor web service I'm suggesting would only be useful for controllers, since presumably users aren't going to want to type something exotic like 127.0.0.1:9999 into their address bar. In this situation the Torbrowser bundle or TorK will have configured the actual port for the webservice so will know where to direct the request. It would also be the responsibility of the controller to ensure the webservice is available, and tor is running, before allowing the user to access the page through their browser. This would mitigate against both the problems above, but it's probably impossible to prevent them ever happening. I think our use cases may be different enough for both to be worth pursuing separately. An internet-based web service that Tor knows about and can use to advise users if they're properly configured is good for torbutton users and the like who just want something to click when they're asking for help on IRC or reading the docs. A tor-based web service would be good for controllers since they can make sure it's available and configured before use and can avoid the problems associated with relying on an external service outside their control. I'll do up a proper proposal so the pros and cons of what I'm suggesting are clear. > > That said, the main scenario I want to prevent is a user thinking > they're using Tor when they're not. Having their browser unable to > access any web page is undesirable, but at least they're not going to > do anything unsafe. > > Steven.
Attachment:
signature.asc
Description: This is a digitally signed message part.