Features
Smoothly rolls down from the top of your screen

After which I stopped reading.

A cryptosystem that allows inferring the secret key (necessary for encryption/decryption) from plaintext+ciphertext with less-than-brute-force effort is considered broken. I'm guessing that successful cryptolockers use non-broken encryption. So no, having a plain and encrypted version of the same file is not enough to undo cryptolocker damage.

Usually symmetric ciphers use a block size between 128 and 256 bits, the amount of different blocks you can compose from those (and which your file would need to contain) is astronomical. Also, when used properly, the cipher output is also dependent on the cipher's internal state (initialized with a random vector, likely different for each file), so that repeated encryptions of the same block of plaintext in a different file (or different position in the same file) will be different.

Not a specialist, but I took the crypto 101 at school.

"Lol, I told them we don't want nuclear weapons. I think they believed that."

(Spoiler: of course they want nukes, they'd become a because-I-say-so superpower in their own local neighborhood. And of course foreign intelligence knows this, and thinks they want nukes, no matter what anyone says)

In Finnish, a double consonant (as in, two *same* consonants) would be followed by a wovel (probably exceptions, but can't think of any). Also, there's no double j, and there are very few words that end in r.

If I were to blame that word on someone, it would be Norwegians. ;-)

Maybe call the house. Can be done while the patrol/SWAT is on their way, so doesn't slow down response. Explain what the situation is (reported crime in progress) and ask people inside the house to cooperate by coming out of the house. Also safer for the officers involved in case the inhabitants cooperate. In the case there was an actual crime going on, the suspect is now warned about imminent police arrival, but wouldn't he be expecting the police anyway?

IMHO the proper way to run a local dev environment is in a VM. That way everyone can get the production environment replica to run their code in, AND use whatever they like best for their host OS.

I would find that level of sophistication very unlikely, your average ISP's branded end-user box is put together from the cheapest pieces of shit they've been able to find.

And they have no reason to care about the power consumption of end-user equipment, they're not paying for that power.

Seems to me that would only make things worse when your libraries have bugs: Why rings 1 and 2 aren't used?

Good luck with that. Particularly, with the part of figuring out which software is good enough to not require a sandbox. And that's before considering the bugs your sandbox has.

Seems like a management oversight. I would be shocked to find that I have to pay for upgrades every couple of years.

• If I view the nightly report on the bus on my way to work (flaky internet connectivity, is the dashboard mobile optimized?)
• If I am resposible for watching reports for multiple sites (I don't want to learn 10 different url/username/password combos for 10 different dashboards + learn to use each one of them)
• If I need to forward the report to someone else (I don't want to give my personal username/password away)
• If I need someone else to temporarily take over watching the reports (ditto. It's just easier to set up mail forwarding than to get an extra temporary user account)
• If the dashboard uses something fancy like websockets to work that require me to ask the IT department to pop holes to firewall?
• If I need to see backwards in history and the dashboard doesn't provide that (as already mentioned above)?
• If the dashboard is just something someone threw up in one afternoon after lunch, with no consideration of contents and usability.
• If the dashboard is continuously "improving", i.e. they keep hiding the things I want to see every two weeks.

My understanding of the "shouting fire" metaphore is that it generally assumes it's a false alarm, but I may be wrong. If there really is a fire, the situation becomes very different (there is damage potential for announcing the fact, but there is a larger damage potential for not doing it).

I see this boils down to free will of pepole in a situation they perceive threatening. My understanding about panic (a physical reaction turning off the decision making parts of your brain in a threatening situation, since the decision has already been made: there's a fire, get out now), is that you don't choose whether you get it or not. It depends on how prone you are to get in panic (something you do not have a choice in), and how threatening exactly you consider the situation (in which you do have some choice, by of practicing the situation beforehand).

If we look at the situation statistically, in a full theater there's likely several people who panic at the prospect of being burned alive while queuing for the exit (or by the fact that they may get trampled by other panicing people). The situation is set up in a way that there's direct damage potential from someone shouting a false alarm.

So that mass panic in the theater would have happened anyway, without anyone shouting "fire"?

Looking at the events after they're happened, we can conclude that someone unnecessarily shouting "fire" in a crowded theater was a sufficient condition (thus, leading) to people getting hurt. Was it a necessary condition for people getting hurt that way? Common sense says it was.. also anyone who's looking someone to blame.

Before someone shouts it out? No way of knowing what will happen.

If you offer an incentive (survive a theatre fire / money) to someone for committing a crime (trampling someone to death / shooting someone), did you cause it, or was it all on the person who committed the act?

How about this: If you find yourself needing a firewall, your system design has already failed. Every single system should assume actively hostile environment.

I can only repeat your original subject.