dionysiac

I know that systems such as OpenID and others perform authentication directly between the user and thetrusted provider (google, facebook, twitter, etc), and that the site ends up with a one-time token that confirms the user's identity. The site requesting authentication never gets the actual password to the openID account, which makes this approach viable in a technical security sense.

But here's the thing: general users are getting used to entering their centralized credentials to perform actions on untrusted sites. Technical users understand the design. We can confirm that, yes, TwitScoop does indeed direct us to twitter.com/oauth/... (no HTTPS, but that's another story).

Regular users posting a comment on a blog, though, don't see any difference between giving their credentials to a trusted Google login site and entering their credentials into some form on a blog.

If, for example, logging in with Facebook credentials becomes common, it would be trivial to create a rogue blog which collects login information. Fill it with a few incendiary posts, possibly create an official-looking Facebook login page that doesn't display its URL, and it would be possible to capture quite a few sets of credentials.

  # time find / -maxdepth 3 -perm -7 -type d -print
  /tmp
  /var/tmp

  real    0m0.034s
  user    0m0.005s
  sys     0m0.028s

  find / -maxdepth 3 -perm -7 -type d -print

Many people consuming alcohol are doing so for similar reasons.

Storing, say, a username and a password hash in your encrypted cookie is at least as secure as direct authentication at each page load; even if they break your encryption they still have to know the admin's password.

Start with the assumption that the locks you use for security will fail, and ask "how will this break?" If we take the encryption out of the picture, do we trust the client to log in as root (or similar) with just a username and no password? The lock in question (as I understand it) is failing for an unrelated (information disclosure) reason. The design decision to lean so hard on the lock is what makes this such an issue.

This.

My thoughts exactly. Purely as a reading device, it will be fantastic for scientific papers which are usually in hard formatted PDFs. Reflowing them for a small e-ink device sucks and makes them hard to read. Having color is a huge bonus (10 shades of grey in a color coded graph is a royal pain). The iPad + the GoodReader app will let you take hundreds of papers and technical books with you. The fact that it has a pretty good web browser and email app with WiFi is an awesome bonus.

As for the sound card - I agree, the DAC in the iPad is probably similar to the other iDevices in the past.. Pretty good for consumer standards, but poor by pro standards - not to mention multiple outs, ins, etc. Where the iPad stands to gain the most is as a remote controller for a larger rig running on a laptop - via Bluetooth or Wifi. Heck the audio jack could be used for modulated data and have it interpreted by the host machine as a control input, a la Serato et al. Ever since the $2k Lemur people have been hungering for this - it will happen sooner or later!

You need a computer to transfer data to it, so why not to program it? Yes, the toolchain is not available for windows, but that's at least understandable. The iPad is not currently marketed as a stand-alone device.

This article makes the analogy to the printing press; that the Internet is changing our worldwide society dramatically. Those who are for net neutrality (myself included) would likely agree - that this transformation is a positive thing and should move towards becoming an essential service.

How this is accomplished - either through private industry or government ownership - is really just a matter of culture. Many countries have significant government ownership of network infrastructure.