This is exactly what TOR was designed to protect against. Even a large scale compromise fails to do two things:

1. Compromise user identity (e.g. originating IP address), and
2. Analyze packets non-discretely (e.g. as streams).

So the most they'd be able to determine is how much traffic is coming from what appear to be other relays, and also that it is encrypted. They probably wouldn't even be able to decrypt a single block of data - it's like solving puzzles within puzzles, where the shapes of the pieces are constantly changing.

Unless your name is "The Iranians," I don't understand how you can speak in such broad terms and not be modded as a troll.

So, it's not our business until it's time to weigh in our thoughts? All I can say is that with that kind of attitude, I hope you too are stereotyped to be the same as everyone else in your country when it begins to collapse and everyone says, "Well, they made their own mess. Let's just condemn them all for now and take action against them if we feel threatened." I hope you don't wonder where the compassion is when you are suffering.

Read some books, watch a few movies, maybe even go to Iran. Then tell me the same things you've said here without knowing you're lying. Nobody deserves to be oppressed or "condemned" for actions they cannot control.

And for fuck's sake, please don't title your unsubstantiated bullshit as "The Grotesquely Ugly Truth".

Why do I have this subconscious urge to suggest.... PDF?

Actually, IIS does use the process model, but each worker process is threaded and talks directly to the kernel-mode HTTP server.

IIS worker processes have a request queue. Whether or not you use asynchronous functions to handle requests, there is a fixed maximum number of threads each worker process will run to process requests. While reading from a socket, the worker thread does block but more threads are not spawned to handle connections. Instead, the worker process puts new requests into a queue until more threads are available.

I believe this works because there is a timeout associated with the completion of a request. Sure, it might be difficult to distinguish a slow DoS from a slow client, but it wouldn't be impossible to set a reasonable time limit on non-POST requests. That would be a relatively easy way to fix the issue in Apache.

As far as POST goes... well, that's a different (and valid) way to perform a slow DoS attack:

Server: What would you like? Ham bacon spam, or spam eggs bacon spam with spam?
Client: I'm actually here to deliver some SPAM!
Server: How much SPAM?
Client: SPAM, SPAM, SPAM.... (3 hours later) ... SPAM SPAM SPAM...

Slowloris can do this too. By default, IIS only reads the up to first 48KB of post data (I see much smaller numbers in practice), at which point the request is sent to an extension/app. Before this, the request doesn't leave the kernel-mode driver (http.sys). The apps can easily ignore the data or read more (on a timeout). I wouldn't be surprised if Lighttpd did the same thing (sans kernel driver).

It could've been ammonia, just like on the ironically-named planet Eau

Thanks for that!

... because I wasn't joking or anything ;)

That's some serious cash... I mean, almost twelve US dollars!

I'm jealous... mine is off by 1!

It wouldn't change the logarithmic nature of the distribution of the digits, AFAIK.

My math degree is getting dusty, but I'm pretty sure that the same pattern could be represented in another base by changing their generalization of Benford's law to include it, and the distribution would look like log(x)/log(9) or log(x)/log(11). Remember, changing the base of a logarithm is easy: for example, log(x)/log(e) = ln(x)

So you get the same distribution, different base.

Maybe they didn't count high enough? I wouldn't blame them, I get tired of computing primes by 7...

She read some academic papers on mesh & vehicle networking (DARPA funded for sure), and pooped.

... not really. TFA is a senseless non-story. Chase is just regurgitating the same "big picture" vision statements you'll see in dozens of academic papers. Nothing makes her ideas so special.

You can't just slap a mesh router on a car and expect to be able to pull up /. while cruising through the boonies. I've been working in the field of vehicular networking for a long time now, and the big problem is that everyone thinks you can get end-to-end connectivity no matter where you are or how fast you're going. That just doesn't happen "because it's a mesh network". Go read about the packet delivery ratio of AODV or DSR in a large-scale vehicular network if you're interested in some proof. Small and discrete pieces of information are more manageable, but then why not just use cellular? (There's reasons you can't, but I digress).

Mesh networks are great in some situations, but not in vehicular networks on a city-wide (or country-wide) scale. 200 mesh routers in Vienna is cool, but what about 500,000, moving at an average speed of, say, 30mph? In this case:

Is absolutely not true unless you're talking about storage volume rather than bandwidth. I can't wait to see someone spend millions of dollars to equip 10,000+ cars and watch everything fail, as long as they don't take away from my research funding.

TLDR: Leave the mobile networking ideas to the people who know what works and what doesn't.

... BYU Prof. David Wiley Will Be "Irrelevant" By 2020.

Just wait till that pipe bender tells you to bite his shiny metal ass. Then you'll call it a robot!