For a user, the UI is the OS.

Or does this mean that the desktop gets a phone-type experience again, like on Win 8?

And that wouldn't surprise me at all.

Samsung is massively profitable - but almost certainly their margins are lower than Apple's - if only because they develop about ten models for every one Apple model. After all, Apple just has iPhone in two, three incarnations, while Samsung has a whole lineup of phones.

Secondly, there are many, many companies in the Android phone market, many of whom must be loss making. It's just impossible with all that competition for all to be really profitable. That "compensates" for the high profits of Samsung, and pushes the whole Android segment down.

Please read the thread before you reply.

This was about firmware images provided on the web site of the manufacturer. Not about reading/modifying the firmware of a drive - which indeed we know is possible by design (otherwise this whole discussion would be pointless to begin with).

As many already pointed out: you can not trust the firmware image provided by the drive itself, for the simple reason that you have to talk to the very firmware you try to verify, and which may be compromised.

Think of the kid calling "are there any monsters under the bed?", and the monster under the bed answering "no!".

If you don't have proper reading comprehension skills, you are unqualified to reply.

No-where did I try to say it's not a big deal.

Copying some data is quite different from replacing data, and far easier to do unnoticed. The NSA copied existing SIM encryption keys; they did not attempt to replace them with their own keys or so.

It is pretty hard to detect an intrusion, access to data, and copying of that data. Especially if the attacker gets access through an authorised account by getting their hands on someone's login credentials.

It is much easier to detect the replacement of data: this can be done with e.g. automated cryptographic checksum tests against remotely stored known good checksums, or against a freshly compiled copy.

A lot of data will have to be replaced unnoticed (source code is being read by humans, who may detect changes if it happens to be the part they work with) to stand any chance of getting a compromised binary on someone else's site unnoticed.

I doubt you need much, really.

All the malware part has to do is to read the rest of the software from disk upon boot, then hide that part of the drive from the OS. This way you could hide a pretty big piece of software on the disk, and with today 500 GB kind of capacities being the norm, the user won't notice unless they look really really carefully at the numbers.

You can't, but you can be quite sure that the manufacturer will take serious measures to make sure this doesn't happen. This protection against tampering to compromise computers just piggybacks on more general protections to keep firmware sound, such as tests to make sure there are no bugs in the firmware that cause data loss, and that software published on the web site is the software the company intends to publish.

This for the simple reason that one mistake here may result in bankruptcy, as people may lose trust in the whole company. Without trust in its products by its customers, a company can't survive - especially when it's about storing valuable data.

Most likely there are no such tools as no-one thought it could be a vector of infection. Just like the BIOS; which used to be a non-reprogrammable ROM chip. I for one didn't know current hard drives even had firmware that can be replaced by the user, let alone that it may be a potential attack vector for malware.

Depending on how hard it is to read the installed firmware from a hard drive (is this even possible in the first place?) it shouldn't be too hard to write a tool that can read the firmware, and calculate a checksum for verification. The hard part is going to be, how do you know that your software gets the actually installed firmware - or just a known good but inactive piece of code provided by a compromised firmware, pretending that this is the software that's installed? The moment a firmware is installed, you probably need to call onto that very firmware to get a copy of it from the drive. Unless this read-firmware routine is provided by a special, hard coded circuit.

Exactly. What people also forget is that it's not just about the whiteboard, it's at least as much about the beers afterwards. Getting to know your colleagues in person helps a lot in getting cooperation going (it helps you interpret the writing in their e-mails properly, for example).

There is no real substitute for in-person meetings. And considering the problem at hand has already the budget of flying people around to get it solved, you'd better make use of it.

Start with a partner or friends. If it's about UI issues or related things, they don't need to be programmers or versed deep into the problem at hand. People that know nothing about it actually can at times give you the best ideas, exactly because they know nothing about it and haven't yet restricted their minds by thinking about it. The programmatic implementation itself of course you have to do yourself, but that's generally the straightforward part (after you properly defined the problem, and the solution you want to work towards).

Part of the problem this is not that big news may be that it's about the US, where power outages and the like are the order of the day. Just ask around on /.: how many of you Americans routinely install a UPS in your home? How many have a generator on hand? Now compare this to the non-Americans that live in what we commonly call the "developed world".

Even emergency services were affected. Something that many Americans find so important that it's always used as a major argument against banning/jamming mobile phones in movie theatres and so, or as key reason primary school kids must carry a phone on them at all times. Even this major service was disrupted. So no matter what, something was terribly wrong here, and some company did not get their redundancies and automatic rerouting right.

Good chance the thieves found out the pipe didn't contain any copper the moment they cut it through. This is supported by the observation that, according to TFS, the pipe was just cut at one place, and nothing had been removed.

So all those important communication lines went trough a single pipe, with no backup, and that pipe was fully exposed to boot? That's just asking for trouble.