Exactly. We don't have any problem seeing emotional life-likeness in even very schematic comic characters, plush animals, and occasionally even objects that don't have a face at all. I'm willing to bet if tomorrow very strange aliens descended from the sky, having totally un-earthlike features, we would still connect with them emotionally without a problem, because we can learn to interpret non-human reactions and features. Yet somehow human characters that are "not quite right" irritate us.

Since even clearly perceived falseness doesn't trip us up at all when interacting with non-human characters, I hypothesize that the uncanny valley could actually be caused by a visual subsystem that deals with recognizing sickness and death in humans, triggering an involuntary repulsion that then is rationalized after the brain realizes it has this reaction mainly when looking at dolls. People do appear to have associations with death as they jokingly described the Polar Express as something reminiscent of a zombie movie. This is probably also the reason why zombie movies (where the undead don't look like live people with excessive makeup) are so effective. That legless zombie girl in "The Walking Dead" pilot creeped me out to no end...

The salt just complicates the rainbowtable lookup method. It's not supposed to be super secret. It makes every password require a expensive brute force lookup rather than a O(1) operation.

While that is true, it just delays the inevitable. In fact, even with salt, any large scale leaks such as the Gawker crack will always contain a good number of stupid passwords that are easily brute-forceable even without a rainbow table. It will always be relatively easy to either crack a single account you're really interested in, or alternatively crack a huge number of accounts that are particularly low-hanging fruit, even if every single account was salted differently. Rainbow tables are nice for crackers on a budget of 0, but today everyone can rent dirt-cheap GPU-assisted brute force cracking power.

Hashed passwords provide a degree of protection, so long as you salt the hash, and store a different salt for each password (for maximum protection [codinghorror.com]).

In cases where the pertinent part of the codebase/config was lifted as well, such as in the current example with the Gawker data, this doesn't help. At some point, the password algorithm has to have access to the salt. An attacker who has both the complete code and the database will also have access to the same salt, no matter how "secure" the individual hashes are computed.

At some point, adding complexity does very little to the actual security of software. There is always information supposedly internal to the system that is needed for decoding or verifying security info. Once that info gets out, it's out, and those logins can be reconstructed never mind how convoluted the hashing function behind them may (or may not) be. The only viable option for Gawker would be to set the entire password column to null and send out notifications with a confirmation code to all registered email addresses, prompting them for a new password.

This isn't about intelligence, though. It is about fear. Fear is an emotional state and not tied at all to intelligence.

It may not be about intelligence, but it certainly is all about stupidity and ignorance - traits that enhance a person's susceptibility to self-destructive fear and political manipulation.

I agree. While the addition of a simple true or return statement at the end should not make any (significant) difference in a straight-forward execution scheme, it might very well convince a simplistic "dead code" optimizer to not prevent the execution of the for loop. I say simplistic, because the optimizer (if it indeed exists in IE) should still recognize that none of the operations in the for loop have any meaning and a constant value is returned in any case (=null), but instead it probably just checks if anything happens after the loop. By the way, it would be trivial to run a few tests to investigate if this is only happening with SunSpider code. My guess would be that it works the same way for any code that exhibits this pattern.

I've also seen thermostats that, while they don't directly control the system, do alter the way the system cycles.

This might be a rational illusion your brain constructs because on one hand the thermostat control doesn't produce directly observable results, on the other hand it looks like a pretty legit button, so we just assume that the input actually goes somewhere into a complex and intelligent system where it will be observed and acted upon in some convoluted and unprovable way. Because it feels like the pedestrian signal is changing "just a bit" faster, like the elevator door is closing "just a bit" sooner, like the temperature is balancing out "just a bit" more favorably, like the ruling parties were "just a bit" impressed by your intent on election day. We construct these illusions because we want our desires and wished to matter, or when that's not possible, we at least want borderline-plausible deniability about the insignificance of our actions.

That's an excellent point, thank you! Apart from the fact that I don't really have the influence to publish some lofty new protocol standard (and make people care about it at the same time), I absolutely agree with you that things should be tested in real life first. There are many examples where I believe the committee-designed version was horrible compared to something already in practical use - such as XML Schema versus Relax NG.

Case in point, I was totally proud of the protocol I used for the prototype of my project, right up to the point where I discovered that it was horribly misguided and too error-prone. That was an awesome experience, because now I get to do a much better version and if other people ever have to re-implement it, they'll probably be thankful for it.

This is where you're simply wrong. When the user's connection breaks, he still has the cookie for server 1, which is presumably the server all business was being conducted on until the failed handover. There is nothing preventing people from clicking the "next" button one more time if their connection tragically failed on the first attempt.

Also, it is not susceptible to replay attacks, because it's a one-time auth token. In other news, you know what else actually is susceptible to replay attacks? Cookies! And not only at the moment of any handover too, but every single request! Of course SSL solves all this but why it failed to become the default web protocol, that's probably a topic for another thread...

Then describe those "other means".

First, this happens only rarely in practice. Most of the time these types of ID handovers are done by huge commercial sites such as eBay and even they have cleaned up their URL mess considerably in the last years. Nowadays, big sites tend to have multiple transparent front-end servers that handle incoming connections to a single domain. Using subdomains as a means of differentiating separate machines is not all that common anymore, especially when they exchange lots of data.

But if you really need this functionality, you can just as easily pass a one-time auth token by URL and create another cookie on the second server. There is really no trickery involved here. And if you need to make it very very secure, you can use OAuth, but that would be overkill for the scenarios we're talking about here.

With that restriction, you'd have had to log in to tech.slashdot.org, linux.slashdot.org, slashdot.org, and so on all separately.

Yeah, there is no technical reason to have those subdomains anyway. (Other than that it looks cool.)

As it is, you have to log into slashdot.org and {some subdomain}.slashdot.org separately.

If you really needed to pass auth tokens around through subdomains, there are other more secure schemes available to do exactly that.

But even if you're a total fan of semantic subdomains, there is a real argument to be made that you should first have to prove to the browser you actually own the root domain and the subdomain before being allowed setting cookies for them. Though such an extra step would have added complexity, it wouldn't have been anywhere near as ugly as the wildcard/TLD/heuristics mess we got today.

The world doesn't need more incompatible social networking platforms, it needs one well-defined, well-designed, social networking protocol.

I waste my time on what I feel like, thank you. What the world needs is more people who actually do things instead of sniping cheap shots from the sidelines. And my sig is completely irrelevant to this dicussion. Feel free to diss me in a private message anytime.

It's clear why it was created. I would argue, however, that the same effect can be achieved by other means on the server side and at the same time it would have made client implementations much much easier. And safer.

I still think allowing cookies to span more than one distinct domain was a mistake. If we had avoided that in the beginning, cookie scope implementations would be dead simple and not much functionality would be lost on the server side. Also, JavaScript cookie manipulation is something we could easily lose for the benefit of every user, web developer and server admin. I postulate there are very few legitimate uses for document.cookie

Vint Cerf should blame himself for the IPv6 mess instead.

Exactly. I assert that the migration would already have happened (and seamlessly) if we had just extended the address space and left everything else the way it was. To be fair, I believe this is a marketing problem. At the time when IPv6 became serious, all sorts of ideas were floated and sensationalized. A bunch of journalists said stuff like "in the future, a device will have just one static IP wherever it goes" and "we'll do away with firewalls". Which sounded insane! And while it's debatable whether getting rid of NAT is a good or bad thing, the rest of IPv6 is actually more like the incremental upgrade we wanted all along, and less like the authoritarian supernet it was advertised to be.

More than anything else, this is the single best reason for keeping your security tight and your password secret - especially from caretakers, who will have free, unfettered and prolonged access to your work computers after you've gone home..

It's technically infeasible (maybe even impossible) to secure a computer at your workplace from coworkers, even if you're an expert. Sure, you can make it harder for them, but in the end they can always get to you - be it with the OS install disk or a simple keylogger. The primary loophole used in this attack was not the victim's stupidly negligent password policy, but a justice system that makes it so very easy to frame people like that. Since it's a crime where you're guilty for mere possession of the material, nobody really cares how it got on your hard drive. You can say "I didn't put it there" all day if you want, fact remains it's there and you have it. The same mechanism applies to drug possession, which is also routinely used to frame people. Mr Thompson was just exceedingly lucky because his attacker was so mindbogglingly clumsy in framing him, then he got lucky again because police and the judge actually cared about the fact that he was "innocent". One can only assume that many people are not that lucky, the best they can hope for is a guilty plea bargain to reduce the inevitably draconian sentence.

The fact that hacks keep coming out and left reasonably open for local user leads me to believe that Apple in reality don't care so much, but have an obligation to the big content producers to give "best effort" to keep the device secure.

No, Apple would like to sue jailbreakers for their last penny if they could:
http://www.wired.com/threatlevel/2010/07/feds-ok-iphone-jailbreaking/

It's only after a protracted legal fight and sheer judicial coincidence that users are legally allowed to jailbreak their own devices. For the future, you can bet on two things:
1) Apple will put in a big effort to make jailbreaking more difficult even if it further undermines the usefulness of their devices for normal users
2) The courts will rule jailbreaking illegal in the long run. It escapes me how the recent ruling was even possible with the DMCA and all, rest assured they will "fix" this again.

Also, the distinction between Apple and big content producers is invalid. Apple has impossibly close ties to Disney, a content company famous for its hardcore litigation practices, shameless lobbying efforts, and unique in the way it seeks to infuse our culture with conservative religious "values".

Oh, and yeah, on a related note: I finally bought an iPad last week. I searched very hard for a real open alternative that had just the right features, there was none.