[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Risk of selectively enabling JavaScript
Point by point.
Javascript, by itself, is not an issue and poses no more of a security threat than any other type of data transferred online. Coding errors in image handling, html parsing, ftp, etc., can all be used to inject code.
Note that (potential) privilege escalation bugs are found way more in
the Javascript component of Firefox. The Javascript engine is a
complicated and heavily optimized beast and (Javascript-accessed)
browser APIs have seen much more active development.
It is very reasonable to assume that more security problems are found
there, and it might be reasonable to use a whitelist to mitigate those
problems.
The idea that you are gaining some security or increased anonymity by disabling javascript is outright nonsense. As TBB is a standard product, its fingerprint should be the same for everyone.
It's not "outright nonsense". It's supported by fact. Disabling
Javascript will protect you against Javascript 0days in TBB (or
non-0days deployed by the FBI against non-updated users). You may argue
that it's not a good or realistic defense, but not that it doesn't do
anything.
The fact that TBB disables javascript is a [blah blah non-sequitur]
TBB doesn't disable Javascript by default. The premise of your, argument
falls apart.
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. This will kill any fingerprinting, injection and tracking attempts. If anyone still requires full non-modified access, they should be forced to explicitly allow that by clicking a button.
Filtering at a exit-node level is ridiculous for multiple reasons. You
don't want to fix these issues on a stream level, and there are no
advantages compared with client-side filtering. NoScript is rightfully
in the TBB.
Also, claiming that any amount of filtering will "kill any
fingerprinting, injection and tracking attempts" is naive at best. I can
think of dozens of attacks, starting with a malicious exit-node.
That said, all of this is a complete waste of time if Tor does not start integrating techniques to prevent traffic analysis.
Location-privacy and privacy between different (pseudonymous) identities
have different attacks. We're talking about the latter here.
Furthermore, end-to-end traffic confirmation attacks (if that is what
you mean with traffic analysis) are not in Tor's adversary model. Tor is
very vulnerable to them.
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk