We're not discussing censorship, but the removal of potential exploitable data. Its not a keyword system, it removes cookies, web bugs, adds jitter to timings, etc. It can be disabled with a click.
Regards, Mark McCarron > Date: Tue, 7 Jan 2014 09:56:41 -0500 > From: [email protected] > To: [email protected] > Subject: Re: [tor-talk] Risk of selectively enabling JavaScript > > You have to keep in mind it's a slippery slop of censoring the content > of users that use the Tor network. If we were to add an option for > filtering out Javascript what would stop a exit-node operator to decide > he wants to filter out any webpages that have keywords in them that he > finds "distasteful". > > What I'm saying is by trying to make it safer for the users of the Tor > network you are in turn making the network itself more vulnerable to > censorship by making it easier for exit-node operators to censor > traffic. I know it can still be done by the exit-node operator if they > want to via a proxy with filtering policies, but why make it easier? > > Regards, > Andrew Paolucci > > On 1/7/2014 09:47, Mark McCarron wrote: > > 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: [email protected] > >> To: [email protected] > >> 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 - [email protected] > >> To unsubscribe or change other settings go to > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > > > -- > tor-talk mailing list - [email protected] > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
