Could you tell me the dangers of javascipt?
Pretty dangerous. Since it is turing complete it enables an attacker to run arbitrary code on your machine if there is a security hole in the interpreter (which is a common occurrence).
On a Linux machine, the browser is the biggest gaping security hole you can have.
Thank you for telling me.
It depends on your threat model.
“a security hole” does not mean “giant gaping hole resulting in sandbox bypass and RCE”.
Much more common than when it is not involved. While it would work on a vulnerable Tor Browser in Whonix, a further total compromise would need exploit chaining to break out of the hypervisor.
Exploits are used with a variety of intentions and to target people sometimes indiscriminately. So assuming one is not doing XYZ and therefore safe is a false sense of security.
Who knows what other hardware level bugs are out there? JS exploits are definitely a bridgehead on people’s machines that open the door to more powerful attacks.
People won’t waste highly valuable exploits on some random person. The likelihood of the FBI or something using thousand dollar exploits on you for no reason is extremely low.
I’m not denying that JS can be dangerous but calling RCE exploits common is untrue.
iphone exploits are the most highly valued in the industry carrying a price tag of millions. However recently discovered mass attacks by China disprove the commonly held idea that such attacks are rare because of the reasoning you mention.
In the case of freedom hosting, the Feds were slinging exploits at everybody even those who unwittingly used services that had nothing to do with the illegal ones.
There are plenty of plates on the FF bug buffet other than RCEs.
Blocking JS handles most if history is an indicator.
Apple disputed that and claimed it was actually “narrow focused”.
First, the sophisticated attack was narrowly focused, not a broad-based exploit of iPhones “en masse” as described. The attack affected fewer than a dozen websites that focus on content related to the Uighur community. Regardless of the scale of the attack, we take the safety and security of all users extremely seriously.
Because they can’t tell the difference between innocents and pedophiles by just seeing them connect to the website. If they could, that’d probably be even more concerning.
Also, people who were affected by that attack were using outdated versions of TBB. The vulnerability was patched a month before it was exploited.
So stay updated. Mozilla will likely fix these pretty quickly once they are found.
There is also a major difference between a vulnerability being found and it being actively exploited.
As far as exploits there are probably some that exist right now that we are not aware of yet.
Can we trust Mozilla or Tor to disclose security issues to the public right away and not alert various governement entities first? To answer that I would need to see where all their funding comes from. It would be shortsighted to take them on their word–not because they are necessarily hiding something, but because it is always better to be over-cautious instead of too lax.
Apart from that, I try to err on the side of caution. Keep js disabled and use common sense while using the internet. Have a secure system, update it and be proactive. Thats the best we can do. Joining the mailing list can help to keep informed too
I think what you say makes sense.
I also disabled javascipt as much as possible and turned it on only when necessary.
JS assisted deanonimization or at least efficient fingerprinting can occur even without any RCE exploits / zero days, within a fully patched and updated system, even in Whonix, through correlation attacks.
Example: a 3rd party JS script by google or facebook (very very common) running in different tabs of a JS enabled Torbrowser, or even at different times (fingerprinting still good) or in different VMs, or in a VM and on the host (clearnet) in parallel, or in a VM and on any other device, clearnet, using the same access point in parallel (at least the latter would be, I believe, very hard to completely eliminate).
Yes the above paragraph did not make a distinction between “mere” fingerprinting and full IP discovery. One can lead to another so the line isn’t very clear to draw.
I’d say block JS by default.
When it’s absolutely neccessary for the site to function, enable only required scripts and continue blocking 3rd party scripts.
If the 3rd party scripts are also neccessary, be aware of the increased risk you’re taking.
TBB mitigates most fingerprinting attempts anyway.
The license of the code/JS scripts != safe not malicious, just that you can inspect, copy and modify it.
“dangerous” is indeed a wide term though. Better discuss issues of “security”, “anonymity” and “privacy” more specifically.
That is indeed very true and receives less attention than it deserves.
the correct answer is simply this. proper risk management involves preparing for the worst case scenario, regardless of how unlikely it is. think about your risk exposure, and play it from there. if you need to be hyper paranoid, whonix alone won’t help you anyways. you’ll need to find physical isolation means that create a true dead end if you are exploitable. for example, an entry point that you’ve used once, is not attached to you, and is nowhere predictable to your home. is that a pain? yes. is it needed for most? no. but, a number of quite skilled people have been ensnared by someone because they ignored or forgot this.
Maybe worth mentioning, to mitigate the fingerprinting problem somewhat you can also use different VMs, or different TB instances on the same machine, at different security levels simultaneously. The latter is not recommended by the Tor developers, but I’ve never been able to figure out why exactly.
What tempest was taking about was the per site whitelisting feature of NoScript not the security slider levels.
TPO decided its safest to hide the NoScript icon altogether in the latest releases.
Yeah, I meant using separate VMs or instances for per-site js blocking instead of using NoScript’s per-site features. That way you get similar per-site control, but without making you more fingerprintable. If you have the resources, probably the best thing to do is open a new instance/VM for every site* and set the security slider to the level you feel comfortable with for that site. It also limits your trackability across different sites or identities, as TB doesn’t attempt to isolate activities within the same instance until you restart it. I normally have 2-4 instances open at any given time, sometimes more.
*Not necessarily for every single domain, but for each group of related tabs, or logical compartment if you will.