[tor-talk] Risk of selectively enabling JavaScript

Mark McCarron mark.mccarron at live.co.uk
Tue Jan 7 14:47:09 UTC 2014


The idea of edge filtering ensures that clients are not exposed to exploits.  It is a defense-in-depth strategy.  It does not replace any client-side measure, it adds to it.

When a stream leave an exist node to request a clearweb, non-encrypted page, there is an opportunity to strip potentially harmful aspects from the returned resource.  This should be the default behavior.  With requests to non-encrypted content there exists the ability to place additional values in the packet that indicate this should be disabled.

Its not really difficult and not applicable to end-to-end tls connections.

Regards,

Mark McCarron

> Date: Tue, 7 Jan 2014 15:00:41 +0100
> From: a.krey at gmx.de
> To: tor-talk at lists.torproject.org
> Subject: Re: [tor-talk] Risk of selectively enabling JavaScript
> 
> On Tue, 07 Jan 2014 12:58:49 +0000, Mark McCarron wrote:
> ...
> > The fact that TBB disables javascript is a testimony to how bad the javascript coders of Firefox are.
> 
> Ex falso sequitur quodlibet.
> 
> > I think there is a solid argument for adding filters to the exit nodes that strip anything that could be used against a person and enforce default headers ,etc.
> 
> Why should it? The default user uses TBB, i.e. the filtering (of the
> identical headers each TBB produces) can be done there as well.
> 
> The exit node doesn't even know that a) a given stream is a HTTP
> connection, b) can't look at all into HTTPS, and c) has no way of knowing
> that the user in question has clicked the don't-filter-me-button.
> 
> Andreas
> 
> -- 
> "Totally trivial. Famous last words."
> From: Linus Torvalds <torvalds@*.org>
> Date: Fri, 22 Jan 2010 07:29:21 -0800
> -- 
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
 		 	   		  


More information about the tor-talk mailing list