The raid was based on a complaint from the publisher (Google Translate to English), which has a near-monopoly on educational materials in Latvia, often linked with shady connections in the Ministry of Education

Here's a free protip. Live in a former soviet bloc?

Are you lacking the skills to be anonymous?

Is there a monopoly on something?

Don't challenge it.

Finis.

Now lets be clear that I'm not talking about a FPGA! In a FPGA if you "reload" the software you will change the machine because in essence the "software" for a FPGA is like the internal gear system, you can configure it in 1000 different ways to do different tasks. One day it can be a conveyor build and the next it will be a bottle cap remover. So before someone comes in here and blows a gasket at me, I fully accept the fact that a FPGA is very different then a Computer.

Ah, but an FPGA can be simulated in software. Therefore, if you reload the software in the simulator, you change the virtual machine. How is the fact that one is emulated and the other is physical relevant?

The way I look at it, software certainly adds a new state machine into the picture. Whether that qualifies as a machine for patent purposes is a separate question, and there are legitimate arguments on both sides, but whichever way you decide, an FPGA should play by the same rules as software.

Sure... but even if they really DO care, who's to say they just weren't successful at keeping your info safe anyway?

I've been saying for years now that "computer security" is largely a sham. Time and time again we find out that the biggest manufacturers of anti-virus software are companies run by shifty individuals with poor coding abilities, and respected makers of firewall appliances and routers sourced components from countries like China which had back-doors built into them at the processor level. Encryption schemes provided by all the big commercials software makers are suspect too, since U.S. govt. seems to demand they give them "keys" to break in, if needed.

Look at the stream of security flaws being found in Java, and think about how often it gets used in the design of web applications.

How many web sites run on IIS -- another product historically full of security holes?

There's a LOT of money to be made by promising people you can help secure their systems, and as long as nobody really TRIES to get past whatever you put in place, you can brag about its "100% effectiveness". Anyone trying to do e-commerce business online has a primary goal of generating a profit selling the goods or services they're concentrating on providing. So right off the bat, these people are simply NOT going to have the time to invest a whole lot into securing customer data. They're going to go with the existing "pre fab" tools and products that are advertised as secure and recommended by others. When it turns out one of those isn't so great after all -- oops, there goes your private data again!

I think you really DO have to place the lion's share of the blame with the thieves - which include both the hackers who took the data, AND the "computer security" folks who made a small fortune selling half-baked products and services to people trying to achieve security.

For instance, I suspect we waste more energy moving tap water in plastic bottles between cities.

"Well, people get shot all the time, so what's the big deal if I shoot someone?"

Doesn't work that way, does it? It sounds a bit like you're arguing a nirvana fallacy, namely that because this trend of saving energy in datacenters doesn't save energy everywhere, it's useless.

But then you have companies such as Google and Microsoft building data centers next to rivers for cheap hydroelectric power in remote parts of the Pacific Northwest and reporting insanely low PUEs (below 1.1 in some cases).

Power Usage Efficiency has nothing to do with the source of the power you're using.

It's not even a measure of efficiency of equipment.

What people invariably want is a state which has rules enforcing human rights, and little else.

Sort of. What people invariably want is a state where the rules benefit them, or at least not stopping them from doing what they want to do.

It would be the strong doing whatever they wanted to the weak.

Given Brin and company are arguably the most powerful people in the world, it's not terribly surprising he wants a land where there are no rules, is it? See above.

Thanks for the explanation. My memory of the actual math involved was a little bit off.

Either way, though, the point remains that if the token is in software and the host is compromised, an attacker can obtain the current value of the key and can generate a new number transparently at any time, and it won't be detectable so long as the attacker updates the button press count on compromised device so that the server doesn't see the same button press count twice with different time stamps.

One advantage that the Pebble has over rumored watches from big names like Google and Apple is existing.

Apple has rarely entered a market first. iPod, iPhone, iPad, Air, etc. Hasn't stopped them from being successful, and in some cases reshaping or redefining the market.

Do you want to be the first to jump into the water, or see what happens to the other person when they jump in the water?

And cookies. But yes, you're right that they don't necessarily have to wait for the user to log in to Google unless that's the only site they care about and the user has not yet logged in to that site. (And apologies for my bad grammar for saying "log into" as well.)

If that were the case, then a single failed login (because of network congestion, for example) would prevent you from ever logging in again. Nobody destroys the shared key. They prevent using passwords twice by using an authentication server that marks the last successful login time and won't let you use a time-based authentication token generated on or before that time stamp (or some similar technique).

The way time-based auth usually works is that either the shared key is hashed with some sort of time stamp or the shared key is used as one of the inputs to a PRNG function whose other input is the number of 30 second periods since some arbitrary time in the past. Given the same key and the same time, the two endpoints can generate the same pair of values, and the authentication server can compare the received value with the expected value. In the latter case, it also typically compute one period before and one period after the current one, to allow for clock drift.

CryptoCard devices do the same basic thing, as I understand it, but the second input is the number of times the button has been pressed. On the server side, it computes the next n possible values after the last one successfully used (where IIRC n is configurable by the server administrator) and if any of them match, that becomes the last one successfully used going forward.

Either way, once that key is compromised (or in the case of CryptoCard, the key plus the number of times you've pushed the button), the system breaks down. This is why your IT department won't give you a copy of the private key associated with your dongle.... :-)

Here's how I know you don't know what you're talking about: All of the things I've talked about have happened already.

Really? Really? Just like that, compromises my cell phone, which is never out of my possession?

A smartphone? You bet. There have been at least two jailbreaks (read "root compromises) for iOS that were triggered by simply going to a web page. In those particular cases, the user knew that he/she was going to a website that did this, but it could just as easily be done surreptitiously.

Nobody bothers to root Android that way because there are generally easier ways to do it, but that doesn't mean it is impossible or even more difficult than it was for iOS. Nor is there any reason to believe that identity thieves do not already have such techniques in their arsenal.

And waits for the user to log into google Again, Really? Do you even have a clue how Google authenticator works? You don't log into google with the authenticator. You log in with some other computer over a ssl connection.

First, that's not necessarily true. Most users do use their phones as browsers, too, which means the device is often the same piece of physical hardware.

Second, even when you do have a proper physical separation between the authenticator and the browser, the only thing it changes is which attacks are relevant:

• If the computer is the compromised device, attacks 1, 2, and 3 are possible.
• If the mobile phone is the compromised device, attack 4 is possible.

In short, the separation is mostly a security no-op.

Even if you had a pre-compromised computer and an elaborate SSL spoofing setup in place ahead of time

Once the endpoint of an SSL/TLS link is compromised, you don't need any spoofing. You can drop an extra self-signed anchor cert into the appropriate trusted anchors list, and you're trusted. There's nothing elaborate about it. It's downright trivial. I can throw together a proof of concept in about three minutes.

For that matter, once the endpoint is compromised, you can just tweak it to display the little lock icon while sending data in the clear. SSL and TLS are worthless if the endpoint is compromised. Completely worthless.

But wait, that wouldn't work either because google already detects this.

Correction. Chrome detects this, but only if the user is running Chrome and that copy has not been modified by the attacker. Once the computer is compromised, you cannot rely on that, either. Any attacker capable of compromising the computer is also capable of compiling a copy of Chrome with those checks disabled. Besides, even if those checks could magically be made impossible to remove, they would still only effectively guard against attack #2, which still means the security hole is wide enough to drive an Abrams tank through it.

It is not possible to detect a man-in-the-middle attack where one of the endpoints is compromised. Period. You're trying to argue against one of the most fundamental tenets of computer security here. There is exactly one way to guarantee that a transaction is secure, and that requires either cryptographic signing or some other form of cryptographic authentication between two trusted endpoints.

Assuming the servers are secure (which isn't 100% certain, but it's sort of an unavoidable assumption), the remaining piece is a hardware device that is not field programmable, that has a screen to show information about a transaction, buttons to authorize or cancel that transaction, and a simple communication protocol, with code that has been proven to be bug free using formal verification techniques. Anything less than that is at best only trivially more secure than passwords.

Some of the Europeans I've run into say that Amtrak's on-board experience compares favorably to what they get in their countries, even if the trains are slower.

As someone who's travelled on more than his fair share of trains in Europeland - at least on the west coast, Amtrak trains are super-comfy. Big seats, loads of legroom, decent food (on the last trip - previous trip a few years ago involved a fossilised, tepid space-burger).

Best of all, there's often a carriage specifically for viewing the scenery going past. Of which there is a lot. Possibly including someone describing the scenery going past. I learned a lot about Mount Saint Helens that way. (Main reason for choosing trains - I fly a fair amount also.) Way better views than, say, the Eurostar - where you never even glimpse the sea you've been under.

I vaguely recall the WiFi working when I went from Seattle to Vancouver BC. Not terribly fast, but enough to email friends and family about the delays. (A swing-bridge had got stuck in the 'open' position, and the train had to wait for half an hour or so. The driver had then disappeared somewhere to get a sandwich, causing another ten minutes delay.)

Amtrak is great fun (some of the announcements on that Vancouver trip were gloriously surreal) but it's hardly an efficient means of transportation. I got the train from Seattle to Portland once, and realised it's a similar distance between the two cities as it is from Brussels to Paris. I used to catch the Thalys between Brussels and Paris - in the time it took to go from Seattle to Portland (including a freight-train-induced pause in sidings), I could have gone from Brussels to Paris to Brussels then back to Paris again.