On Jun 12, 2015, at 1:56 PM, Always Learning <cen...@u64.u22.net> wrote: > > It is my understanding that Java and Javascript are different;
They’re as different as India and Indiana. > Java is dangerous whilst Javascript is (hopefully) harmless. That’s a pretty unsophisticated way to look at it. *Ideally*, Java is quite safe. It was designed with security in mind, and browser Java is much more tightly constrained in terms of what it can do than desktop, server, or embedded/mobile Java. Yet, there’s been a continuous stream of security updates to Java for the past 20 years, with no reason to believe this will slow down. Why? The big problem is those four major use scenarios for Java, all handled by one runtime. We keep finding ways for browser Java to do things that should only be possible in one of the other scenarios. If you trust the source of a Java applet, it’s probably fine to run it. But, I wouldn’t enable Java in the browser if you don’t know for a fact that you need it. Whitelists are probably the best ultimate solution, short of getting rid of Java entirely. As for JavaScript, there isn’t too much harm you can do with it directly. It doesn’t have all that desktop, enterprise, mobile, and embedded stuff built into it as with Java, so it doesn’t have to try to wall all of that off. The main point of blocking JavaScript is that it throws a spike strip in the path of many other types of attacks. For instance, a Flash exploit often relies on some JS probing code to run before it can run, so blocking JS provides a second layer of protection while you’re waiting for Adobe to get around to patching the Flash plugin. There is some minor evil possible directly from JavaScript. Some examples: * The original popup problem is largely solved, but now it’s resurfacing as main-page takeover ads. Block JS and you generally block these, too. * A script can probe your surfing history by dynamically generating hyperlinks in a hidden browser DOM, then checking how the browser styled those elements to infer whether you’ve clicked on that URL before. It’s a brute-force kind of thing, so it’s not too serious in practice, but it is a privacy leak. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
