Intentionally? More than 10 years ago.

Unintentionally? 2 weeks ago at an ATM. You'd be surprised at how many ATMs still use modems. You wouldn't know it unless they leave the audio on during the connection sequence.

If you've ever made an online purchase with a credit card they already have the association with your IP/MAC/etc.

There NAS boxes designed to also be a set-top box.

Plex is not Roku-specific. It's a great media management server/client app designed for a 10' interface with support across a wide range of platforms and the ability to stream to tons of different devices (including Roku):

Windows - Server/Client
Mac - Server/Client
Linux - Server
Various NAS boxes - Server
Android - Client
iOS - Client
Various "smart" TVs - Client

I bought a Roku specifically because it could do Plex streaming, not the other way around. If you really want to go straight from your NAS to your TV, then by one of those set-top boxes that have slots or USB ports for hard drives.

When large cities have nobody living where they work, they become Detroit.

No, Detroit's problem is that all the jobs disappeared and now no-one lives there. Abandonment is a completely different problem from urban density and mixed-used development.

What the article is describing in San Francisco is the opposite of the usual downtown/suburban mix. People are living in the urban area, but working in the suburbs.

What about Linux for non-general-purpose machines?

Android or DDWRT.

That's exactly what they're saying, and providing a method for rating importance.

I know this is /., but did you at least read the summary?

So you're proposing every time the browser launches it gets the private key from Google?

Sandboxing to prevent javascript is already in place. So current scenario or your scenario, the risk of a content-based malware breaking the sandbox to execute code in user-land is the same. So it doesn't really matter if the private key is stored at Google or locally on the machine.

The only thing your scenario does over the current scenario is block the casual user from hitting "show password" if they step up to someone's unlocked machine while they're away from the keyboard. And even still, the UI could be programmed to display the password the way it currently does.

No matter what, it comes down to "if I trust the software to decrypt for me, then the software will decrypt for me, and anything that can act as me (without additional credentials) can trigger the decrypt"

The difference is that in an e-commerce site is that the private key is somewhere on the server where presumably a very limited number of people can access it.

If the private key that Chrome uses to decrypt your password chain is stored locally on your machine (somewhere in the Chrome binaries or user prefs) then it can be extracted by a local user. Doesn't make password attacking any more difficult (from a scripting standpoint) than it already is.

If the private key is hosted by Google, then Google is doing decryption of all your passwords. And there's already uproar about Google having wifi passwords saved in Google-hosted backups of Android devices.

It's really the same problem in both scenarios where people are screaming blood murder. If you trust the computer to be you, then the computer can do anything you can do. The only way to block it is to require the user to input a password every time (can be a master password), which is annoying for most people, and defeats the purpose of saved passwords.

And where do you keep the private key? Inside the distributed Chrome binary? That's locally accessible.

Which means Chrome's private key needs to be stored in Chrome itself (unless you want to start shipping everything off to Google for server-side processing), and so can be plucked out of the binary for decryption purposes.

Apparently you watch too much CSI. GPS is a passive technology, you have a device which triangulates satellite signals and tells you where the device is by cross-referencing a map (usually stored locally). GPS devices do not broadcast their location.

It's an easy technical measure, but horrible for expressing meaning. I read up on the definition of a becquerel, and while I get it, I still have no basis of understanding what 20-30 billion becquerels means.

Plus, even in the explanation page, it seems that the becquerel is usually expressed with per-volume or per-weight measure. So using the unit by itself is useless to the lay person. How many becquerels to the banana?

It sounds to me someone used this unit with the express intent of making it sound big and scary, and that's disingenuous even if accurate.

Interesting idea, but it's clear that systems like Wolfram Alpha, IBM's Watson, etc, are making inroads into language processing which means it's only a matter of time before this would be broken as well.

Agreed that CAPTCHA is not a be-all-end-all tool. However, it is the most effective and easiest to implement solution for the particular problems it solves.

Until there is something more effective than CAPTCHA, and at least as easy to implement, we'll be stuck with it.