Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment The real reason (Score 1) 555

I will likely be downvoted, even though what I write is absolutely true.

Revolution was predicted at least 6 years ago, a result of public land policy changes made 50 years ago and yet nobody talks about it. In fact, if anybody brings it up, they are immediately dismissed as radical, or simply silly.

Starving people are dramatically more likely to revolt than well fed people. Somehow, mentioning this ridiculously obvious fact is universally dismissed.

Comment Re:I Bet This Article Will Do As Much Damage... (Score 1) 108

If the author hasn't been played in any way, then the damage is still done: the scammers just got a great idea they'll no doubt literally capitalize on.

If you think that anybody who's written or executed ransomware hasn't already thought about ransoming medical devices, you have an astonishingly low opinion of others. Just how smart do you think you are?

Anybody who's spent the time necessary to write ransomware and attempt to profit from it has had more than enough time to consider the all reasonable possibilities, even if it took somebody as *brilliant* as you 5 minutes to come up with this idea. This isn't some global super-conspiracy; this is as brilliant as banging chips off a rock with another rock.

Comment Re:We don't need "backdoors" (Score 1) 259

Put simply, there exist plenty of systems and techniques that don't depend on a third-party who could possibly grant access to secure communications. These systems aren't going to disappear. Why would terrorists or other criminals use a system that could be monitored by authorities when secure alternatives exist? Why would ordinary people?

That's a really easy answer -- terrorists use these simple platforms for the same reason normal people do: because they're easy to use. Obviously a lot of our techniques and capabilities have been laid bare, but people use things like WhatsApp, iMessage, and Telegram because they're easy. It's the same reason that ordinary people -- and terrorists -- don't use Ello instead of Facebook, or ProtonMail instead of Gmail. And when people switch to more complicated, non-turnkey encryption solutions -- no matter how "simple" the more savvy may think them -- they make mistakes that can render their communications security measures vulnerable to defeat.

I'm not saying that the vendors and cloud providers ALWAYS can provide assistance; but sometimes they can, given a particular target (device, email address, etc.), and they can do so in a way that comports with the rule of law in free society, doesn't require creating backdoors in encryption, and doesn't require "weakening" their products. And of course, it would be good if we were able to leverage certain things against legitimate foreign intelligence targets without the entire world knowing exactly what we are doing, so our enemies know exactly how to avoid it. Secrecy is required for the successful conduct of intelligence operations, even in free societies.

Comment Re:We don't need "backdoors" (Score 1) 259

Sure. One hypothetical example:

The communication has to be decrypted somewhere; the endpoint(s) can be exploited in various ways. That can be done now. US vendors could, in theory, be at least a partial aid in that process on a device-by-device basis, within clear and specific legal authorities, without doing anything like key escrow, wholesale weakening of encryption, or similar with regard to software or devices themselves.

The point is that when US adversaries use systems and services physically located in the US, designed and operated by US companies, there are many things that could be discussed depending on the precise system, service, software, or device. Pretending that there is absolutely nothing that can be done, and it's either unbreakable, universal encryption for all, or nothing, is a false choice.

To sit here and pretend that it's some kind of "people's victory" when a technical system renders itself effectively impenetrable to the legitimate legal, judicial, and intelligence processes of even democratic governments operating under the rule of law in free civil society is curious indeed.

Comment We don't need "backdoors" (Score 3, Informative) 259

And the NYT has a new and extensive story that absolutely "mentions" crypto.

We don't need "backdoors". What we need is a clear acknowledgment that what increasingly exists essentially amounts to a virtual fortress impenetrable by the legal mechanisms of free society, that many of those systems are developed and employed by US companies, and that US adversaries use those systems against the US and our allies, and for a discussion to start from that point.

The US has a clear and compelling interest in strong encryption, and especially in protecting US encryption systems used by our government, our citizens, and people around the world from defeat. But the assumption that the only alternatives are either universal strong encryption, or wholesale and deliberate weakening of encryption systems and/or "backdoors", is a false dichotomy.

Comment Re:yes, but directory traversal and buffer dos, so (Score 1) 74

HOWEVER, -all- of the "download.php" scripts I've ever looked at have at least two of the same three vulnerabilities.

1) Protection from directory transversal is harder than it looks,

2) fopen_url, and

3) memory depletion from failing to disable the output buffer before reading and writing chunks of the file.

I'm a PHP dev, and the first two are relatively straightforward to prevent. EG: Check that basename($file) == realpath(Basename($file)) kind of stuff. But #3 is interesting to me; how would the following cause any problem?

$fp = fopen($hugefile, 'r');
while ($line = fgets($fp, 1024))
      echo $line;

In this case, the buffered output will be spooled to Apache/end user as it fills. Or did you mean OOM errors from trying to load a 2 GB file into RAM?

Comment Re:I miss pgsql (Score 1, Insightful) 83

... and the replication systems are typically not worth much more than a dime, sadly.

We have a pretty beefy set up; 4x 16 Core Xeon DB servers with 128 GB of RAM each and Enterprise SSDs, serving hundreds of instances of like-schema databases, one per (organizational) customer, serving an aggregate peak of about 1,000 queries/second in a mixed read/write load.

And we've never been able to get replication to work reliably, ever. In every case we've ever tried, we've seen a net reduction in reliability. Every single time. Not that we've stopped trying, it has just never reached "just works" territory.

Replication is PG's Achilles's heel.

Make it right before you make it faster.