[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