Having driven a '94 honda civic with a power steering rack and no power steering pump for years, the only time you'd notice the lack of "power" is at rest and very low speeds (i.e. people-pushing-the-car speeds.) The manual rack feels almost exactly the same when in motion -- I only know it's different because I know the rack was changed.

The loss of power steering isn't what created a wreck. Driver panic is at least 90% of it. Further panic when the brakes lost boost, plus the unsafe speed and wet roads... and someone plows into her while the airbags aren't armed.

I have an account, for one.

As it was provided by a human being, who is presumed to have the capacity for rational thought, that would be sufficient as "authorization". If they were not actually authorized to provide such "confidential" customer information, then they would be on the hook, not use you as the receiver of the information. Computers, on the other hand, do exactly as they are programmed; programmers do make mistakes. Those errors are not authorization.

If we return to the office building example, this would be equivalent to walking into a building, past a security desk (manned or not), through a set of doors with no locks or signs, down a corridor to a common printer and taking whatever unclaimed output is still there.

Hah. Only because David called him first and hung up.

(by today's screwy courts, we'd add identity theft/fraud to his charges for pretending to be Prof. Falken, i.e. not correcting WOPR/Joshua when it asked.)

[I know, I'm ruining the movie.]

the server provided the information to him.

Right. He was just sitting there looking at a gmail screen when an AT&T server just started filling his browser with ICC's and email addresses.

He had to *request* the address for each, individual, ICC, through an internal interface that is not publicized. An interface he found while digging through the activation process (looking at the network traffic), apparently. The CFAA has no requirements for a lock-and-key system to constitute unauthorized access; without authorization is just what it says on the tin... no "authorization" has been given. (the old "well, they didn't tell me I couldn't" argument.)

Fighter's have radar jamming and other "stealth" technology making them very hard to track. And if you really think someone cannot fly a plane into or out of US airspace without a dozen systems watching them, you are a paranoid freak. This sort of crap happens all the time -- smugglers and drug runners do it often enough. ('tho no one is doing it with a 777 :-))

It's doable with S4, but it's going to be insanely expensive and increasingly harder to find the tapes. LTO 4, 5, or 6 would be a better choice.

*I* use S4 for the high volume systems, but I'm only doing a full dump once per quarter (if that.) The majority of that data never changes. But I need to be able to rebuild any of those systems if they fail. (which is a growing likelihood -- those drives are getting really old.)

(But for archiving stuff that doesn't change, blu-ray is a perfect choice. It's not like he'd be storing 20TB every month.)

Tape vs. hard drive is a wash for the first 20TB. (minus a controller, HD is a bit cheaper) HOWEVER, with tape, capacity scales very cheaply... the next 20TB costs less than a single HD.

DLT-S4, the last generation, holds 800G native. But it's deadend technology now... it hasn't been manufactured in years, and finding actually new tapes is next to impossible. (noone on ebay is selling "new" S4 tapes. I don't give a shit what they claim. The eMAM proves them liars -- any tape without a SN has been bulk erased, RUN away from those.) Also, when you do find "new" (as in never used) tapes, they're old and freakin' expensive.

That's what I was thinking. Legal "hard" copies of all that stuff would be far cheaper than any archival backup technology (tape, blu-ray, etc.)

It would take a lot of blu-ray's, but as the content is entirely static, it wouldn't be that much work to backup. (actually, "archive" is correct term.)

There's only one... ns1.booen.com and ns2.booen.com are the same IP. It's entirely possible comcast's server(s) couldn't get there, but that's a SERVFAIL not NXDOMAIN. And then there's the answer it spits out for www... six identical A's.

Who knows what's actually happening. My money is on comcast having a shit DNS system. (it's the simplest option.)

In this case, it's specific against SSL. But in general, this is another form of differential crypt-analysis. Any credible encryption system takes steps to prevent this. (simply put, a single bit change in either key or plaintext should not have an easily predictable effect on the ciphertext.) As far as I know, no one has tried this method on other crypto methods.

Size alone is a very weak means of mapping content. Almost every modern web application has some variability in the output size at any given URL. Plus it's likely there will be many URLs generating the same size output.

Personally, I was gonna blame the Big Bang. If you're going to make an absurd connection, take. it. all. the. way.

In CA, I don't know -- it's an expensive place to live. The average (over the entire country) salary of a patrol officer is what, $30k??? (read: a whole LOT less than 200k, but a cop is the very definition of "high maintenance".)

Right. They first crawl the site to build a map of the encrypted pages. Then by looking at other encrypted streams, they can guess, with approx. 89% accuracy, what page it was. The overwhelming point here is that it is a complete and utter GUESS . Without decrypting the contents, they don't know for sure what it is. The issue for SSL is that it's not very good encryption if my https traffic for foo.html is sufficiently the same as another https session's traffic for foo.html -- i.e. it's failing the test of differential analysis.