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.k...@gmx.de > To: tor-talk@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@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk