ErikD

That uses mostly data collected clientside using javascript and flash. HTTP headers alone are no way enough.

With and option to disable this behavior from the HTML websites could chose to disable it on forms which might contain sensitive data. Browsers could even disable it by default and let the websites enable using an attribute.

I think anothermachine meant it should be default behavior in browsers. I agree, with the attribute to disable or enable this from the html it would be a nice feature for browsers to implement.

That's what https is for. It should prevent them from doing anything useful with the packets.

What apps do you have installed? This is interesting to know since the data might be from a popular app instead of Apple.

Does it really matter that the hacker doesn't know which hash belongs to the user? He will still be able to do a dictionary attack using the same method you use to login.

Wouldn't this just make dictionary attacks easier? Now the hacker doesn't have to find one exact password but has the option to match any of his dictionary passwords to any of the password hashes.

I know that there are hardly any collisions and that in practise this wouldn't really change a thing. But in theory the dictionary attack would be faster this way.

Using mk-slave-delay you can do this with Mysql as well. We always have a slave running behind a day. You can fast forward the slave using the 'START SLAVE UNTIL' command.

Once Chrome and *JS support SourceMap it shouldn't be that hard to debug.

Opa means Grandpa in Dutch.

Keep in mind that serving already properly minimized png, jpg and gif images with gzip can actually increase their size.