Security isn't just something you "turn on". Security is a mindset, a set of systems and practices that affect all aspects of your work environment. And implementing security practices--especially in an organization devoid of such--is a daunting task.
Firewalls, Intrusion Detection Systems, and the like are only as good as the policies that govern them. The first step in implementing security is to define an information security policy.
Java was designed with a heavy-duty security model, using sandboxes and virtual machines and such to make sure that you could safely download code from other sites and run it, and while it's probably possible for somebody to come up with some implementation bug that lets you outside the box in ways that are exploitable, it's basically been solid since it came out, because it was designed to be safe.
Javascript was designed to be lightweight, friendly, and convenient, and almost anything related to security was later bandaids applied to the gaping wounds. It's possible and easy to write perfectly safe Javascript, but that's unfortunately totally irrelevant because it's possible to write Evil Javascript as well - so anybody who wants to run your "Safe" Javascript has to leave Javascript turned on for the Evil Javascripters as well.
IE does theoretically have a "security zone" mechanism that lets you identify trusted sites, so you can theoretically allow it to run purportedly-safe Javascript from people you trust while not running it from people you don't trust, but that's an annoying hassle. It'd be much safer if they'd built "WimpyScript", designed to be absolutely safe even if all it lets you do is make stuff flash decoratively when you wave a mouse at it; I guess CSS is as close as we get to that. PDF used to be safe, back when all it would do would be display static black or colored marks on virtual paper, but now it's helpfully willing to open web pages and run programs on your PC too.
Well sending message by being untraceable is a good thing but it also has its disadvantages. Message that are being untraceable is a safe way to communicate by without encryption and decryption because encryption and decrytion involves a lot of algorithm. This way is very safe when facing with the crackers. But it also has its disadvantage where the message that been sent cant be traced back after read once. It will be lost after the receiver have read it. Another disadvantage is where if the message is lost on the transmission, it is lost forever. The sender will not have details about the sending and the receiver will not know whether the sender has sent him a message
Slashdot Mirror
Security isn't just something you "turn on". Security is a mindset, a set of systems and practices that affect all aspects of your work environment. And implementing security practices--especially in an organization devoid of such--is a daunting task. Firewalls, Intrusion Detection Systems, and the like are only as good as the policies that govern them. The first step in implementing security is to define an information security policy.
Don't say for every message you want to screenshot. You will have to keep a storage for every screenshot then.
Java was designed with a heavy-duty security model, using sandboxes and virtual machines and such to make sure that you could safely download code from other sites and run it, and while it's probably possible for somebody to come up with some implementation bug that lets you outside the box in ways that are exploitable, it's basically been solid since it came out, because it was designed to be safe. Javascript was designed to be lightweight, friendly, and convenient, and almost anything related to security was later bandaids applied to the gaping wounds. It's possible and easy to write perfectly safe Javascript, but that's unfortunately totally irrelevant because it's possible to write Evil Javascript as well - so anybody who wants to run your "Safe" Javascript has to leave Javascript turned on for the Evil Javascripters as well. IE does theoretically have a "security zone" mechanism that lets you identify trusted sites, so you can theoretically allow it to run purportedly-safe Javascript from people you trust while not running it from people you don't trust, but that's an annoying hassle. It'd be much safer if they'd built "WimpyScript", designed to be absolutely safe even if all it lets you do is make stuff flash decoratively when you wave a mouse at it; I guess CSS is as close as we get to that. PDF used to be safe, back when all it would do would be display static black or colored marks on virtual paper, but now it's helpfully willing to open web pages and run programs on your PC too.
Well sending message by being untraceable is a good thing but it also has its disadvantages. Message that are being untraceable is a safe way to communicate by without encryption and decryption because encryption and decrytion involves a lot of algorithm. This way is very safe when facing with the crackers. But it also has its disadvantage where the message that been sent cant be traced back after read once. It will be lost after the receiver have read it. Another disadvantage is where if the message is lost on the transmission, it is lost forever. The sender will not have details about the sending and the receiver will not know whether the sender has sent him a message