Re: 99.995% is impossible
"A minister wouldn't lie would they?"
No, but they might knowingly avoid learning their brief so that they remained too ill-informed to make a true statement on matters where the truth conflicted with Party Policy.
8168 publicly visible posts • joined 14 Jun 2007
The figures sound perfectly reasonable to me.
99.995% of the internet is cat videos and only 6% of terrorist beheading feature kittens, so the test dataset was the entire internet and the algorithm is: (drumroll)
return false == IsCatPresent();
(More seriously, given any non-random algorithm that isn't completely one-sided, I can obtain any error rate I want by fixing the test dataset.)
"And consider fusion reactor research in space, where they can afford to take bigger risks... and have a natural vacuum to assist them."
Actually, a fusion reactor in space would face an almost insurmountable problem that Earth-bound reactors solve quite easily: heat disposal.
You see, your common or garden power station generates about twice as much heat as it does electricity and then uses a heat engine at less than 100% efficiency to convert the heat to leccy. The remaining heat then has to be disposed of. On Earth, that usually involves warming up a few buckets of water and chucking it away. In space, you'd need a closed-cycle alternative capable of shedding roughly as much heat as your reactor was delivering in electricity. Since convection and conduction are out (pesky vacuums) that leaves radiation, so we're probably talking about a space station that is "very bright in the near infrared".
I'm not an engineer, but the problem would appear to be Quite Hard.
"If a dependency breaks for whatever reason, such as the developer pulling the repository, then your next pristine build is going to fail, you will spot the problem and then do something about it."
Either you or I have mis-understood the person you were replying to. I took the suggestion to be that you make yourself dependent on your local copy (fork, or whatever) of the third party code. That dependency cannot break. (If the original source disappears, you lose the ability to update your local copy, but since there cannot now be any new fixes being posted to that original source, this isn't actually a problem.)
You seem to be advocating just linking to the remote source and only taking a local copy *after* the remote one goes titsup. Sorry, but to me that sounds like being lazy and having to face the consequences at an inconvenient moment, possibly after everyone who understands exactly what to do has left the company.
I've always been slightly puzzled why they don't do just that.
If I pick up a phone and make some inflammatory statement to a friend, that's a private call. The phone company has no business listening in and Mr Trump has no cause to complain about what I said. If I pick up a billboard and splash the same comment around so that everyone in the area can see it, I'm liable. Social media are *much* more like the second case than the first, so they shouldn't have the same protections as "carriers".
Sure, it would mean the end of these sites, but why should centuries of legal practice be put aside just to facilitate someone's new business model?
A fine suggestion, and one that I suspect is well within the capabilities of the people behind the NHSbuntu project, significantly easier to sell to NHS managers, and sufficiently easy to support that the handful of people concerned might actually be sufficient.
In fact, perhaps they should create it as a product and start a company to sell it.
"This on equipment that costs 10's if not 100's of thousands of pounds."
This is a contract failure. Any product that includes software running on COTS Windows boxes or networked machines must come with a guaranteed maintenance period and a line in the contract that says it must run on the patched OS (or in a fully patched LAN) as updated in accordance with Microsoft's schedule until the end of the contract, *because it isn't safe not to*.
If vendors try to wriggle out by limiting the term of the contract, let them, and then tell your bean counters that they must amortise the full purchase cost over the reduced contract period, *because it isn't safe to use the equipment beyond then*.
Then sit back and watch as the crap vendors get priced out of the market.
tl;dr:- Oi! NHS! Grow a pair!
I think it is more likely that we're seeing how journalism works. There are always stories about bad stuff happening, but it your new story is "like the last one, but bigger" it is easier to persuade an editor to run with it. The result is that stories around a particular theme come along in groups, like the proverbial busses.
"I saw it written somewhere that Windows now only brings in 10% of Microsoft's revenue"
But without Windows to run their other revenue sources on, their entire product line would dry up. OK, maybe not the entire line, but just how much of Microsoft's revenue stream does not require a copy of Windows to make it usable. Not much, and their competition is fiercest in those segments.
The only reason MS recommend you stick with Office 32-bit is that there are too many third-party gizmos that only exist in 32-bit form. They won't work in the 64-bit version. If you aren't using any of those, it has been OK to use the 64-bit version for at least 10 years. Conversely, if you are then you will be stuck with 32-bit Office in 2019 as well.
On the other hand, *most* people's documents are under 1GB.
"I'm sorry, but in the real world, AMD just isn't part of the any discussion about server chips. There's only one player in that market, and they'll be the one everyone buys replacement chips from."
True, but in the real world *now* there is no player at all in that market. Whilst it is reasonable to expect that Intel will come up with a safe CPU on roughly the same timescale as AMD, they do need to deliver on that expectation.
"The point is that chip engineers left security in the glovebox the day they parked up in the company lot and walked in to design those parts of the pipeline."
That's a tad unfair. At the launch of the Pentium-Pro, to exploit Spectre you would need to have used the RDTSC instruction to get the necessary timing resolution. That instruction, introduced in the Pentium, can be kept away from user-level code precisely because Intel knew that it would assist side-channel attacks. It is probably still possible to keep RDTSC away from user-level code, although I suspect it would make a lot of programs unhappy.
As far as I know, it isn't possible to keep it away from a guest kernel. However, anticipating the security needs of a VM host was perhaps not on everyone's radar at that time. (There were serious academic papers around explaining why the x86 ISA was not virtualisable and VMware only managed it through a heroic exercise in on-the-fly disassembly and re-writing of code.)
"I mean, what's the probability for me to become a target ? "
As I noted in a reply to a comment a few remarks above this one, the probability might be higher than you think, since the attack is easily automated and almost risk-free for the perpetrator. A state-level attacker rolling out a global offensive might easily catch you in the cross-fire simply because it is impractical *not* to attack you.
"Having another country capable of it does not really make a difference."
On the contrary, if you are a US company (or a close enough friend), it is unlikely that the NSA will write such a letter with the intention of causing your business to suffer a cataclysmic accident that wipes you off the map. (OK. In practice it might be more sensible to cause you a thousand minor headaches that, over time, make you less competitive than your rivals. But you get the idea.)
Some other countries intelligence agencies might have different priorities.
"Probably not better, but hopefully good enough."
Since you are not trying to secure against an attacker who is legitimately already running on the same hardware, you don't *need* to be better. You don't even need to be as good. I think that's the point that your critic was missing.
"For reliability you want your VMs spread across hosts and data centers."
There's no reason why you can't have your dedicated iron spread across several locations. Still, I'm not sure that the article's optimism is well placed. Whilst you may not be sharing iron with other customers, you are sharing it with your VM provider. That provider is still "at risk" from whoever they rent the iron to. Furthermore, as I understand it there is no way to *detect* that you are under attack from Spectre.
Against that, it is probably true that an outfit like VMware can afford to replace all their kit as soon as safe hardware is available and, as valued customers, will be at the front of the delivery queue.
"the whole supply-chain needs to be informed [...] so they can make a co-ordinated release of patches, when the situation is made public"
If you are going to inform the whole supply chain, that makes it public. You can't keep a secret between (quite probably) several hundred people across several dozen organisations in several countries.
"People keep saying they did it for those 3, so maybe we should haul their arses into court."
I foresee quite a long and heated discussion over how many arses "they" actually possess between them. Quite a large number of people died over the course of the first millenium AD trying to settle that one.
"Both should be prosecuted for gross negligence ..."
It is demonstrably not gross negligence and I would expect such claims to be tossed out of court on day one.
The technique of speculative execution has been widespread throughout the industry for twenty years. There were a few people in academia asking whether cache lines could be used as a side-channel. I think there was at least one of those 2 or 3 years ago, but since it came to nothing then I think we can conclude that it wasn't *obvious* that the answer was "yes".
For negligence, you need to have a situation where a knowledgeable person would, if aware of the action, think that it was careless or unwise. We had an entire industry full of such people for 20 years, well aware of what was being done, and the most damning criticism that any of them came up with was "This looks like a possible weakness but despite my best efforts I can't actually exploit it.".
Then, finally, six months ago, someone managed, and Intel's response was to start working on a solution whilst trying to keep the problem away from Black Hats to protect customers.
Yeah, *so* negligent ... not.
"No clear documentation for patches for the end user. I'd like to clear on JUST ONE LINK to be told what exactly is an an update/patch"
Oddly enough, Linux seems to be ahead of the game here. Windows PCs appear to have the constraint that they can't update microcode without permission from the BIOS, which requires the involvement of the BIOS vendor, who is reached through the OEM, and ... FFS! (Ordinary punter loses will to live and never does any of these things. Film at eleven.)
Whereas ... it appears to be the case that Linux systems will pick up a microcode update through their normal automatic updates mechanism and feed it to the CPU at the next reboot.
We had the same ridiculous dependencies for the IME bugs. Perhaps one good thing that might come out of this is that heads will be knocked together so that the OS vendor can do it by themselves. Otherwise, this is getting a bit like Android, with "BIOS vendors" playing the obstructive role of "phone vendors" or "carriers".
I'm not aware of evidence that the customers demand speed at the expense of security, but I suppose it may be true.
If the marketplace starts to offer chips that are Spectre-proof and chips that aren't, we'll see. As far as I'm aware, the latter aren't yet available. (And yes, ARM fans, I *am* going to restrict my argument to x64 chips because I'm not aware of an easy way to run all my closed-source x64 Windows apps on your ARM chips and I'm not inclined to take a few years off using a computer whilst the entire software industry pulls its finger out and re-writes everything, for free.)
"And even formal verification of the logic doesn't guarantee that you won't have problems like ..."
...like Spectre? Let's not lose sight of the fact that Spectre is not a bug. The chip is doing exactly what its designers intended. It's just that, with hindsight, they wish they'd intended something less susceptible to side-channel attacks.
"There aren't that many left alive. The computer age is older than you think."
The computer age for nerds dates from WW2. The computer age for normal people started around about 1990. Most people over 50, of which there are quite a few left, probably had their first serious encounters with a computer in adulthood. Those over 75, and there's a few of those left too, may have decided at the time that this was a young person's thing and they'd give it a miss. Only now, with the government full of spotty teenagers who can't believe anyone could not want to do everything on the web with their smartphone, do that generation realise that this might have been a bad call.
You might be surprised. Testing (or even writing a user guide) can often be enough to make the original dev think about edge cases and sometimes they are the only people who know where the edges are. Or to put it in the language of testing, you need white-box testing as well as black-box testing.
Writing a user manual is another activity that can make the original dev consider their work from a new angle. I know no-one reads them anymore, but that doesn't mean there is no value in writing them.
Well "M" is fixed, as I understand it, by the current round of patches and didn't affect all chip designs anyway, so we're really only worrying about S. S, in turn, is only an issue for people running untrusted code at lower privilege levels, so folks like Google running a completely in-house software stack (at least on some of their iron) don't need to worry about it anyway and folks whose only instances of untrusted code are JavaScript in web browsers can dial down their timer resolutions a bit and push the feasibility of the attack into long grass (or possibly even into a different time zone).
On the other hand, if you are selling VM guests, S makes your entire business model recklessly unsafe both for you and your customers, so that's annoying. Either you or your customers will just have to take the performance hit or buy more hardware, or a bit of both.
"How about a on-by-default/easily-installed/strongly-suggested plugin on plain git?"
Maybe, but that will be defeated by the kind of person who, when setting up a new repo, carefully goes through the configuration and disables everything that they don't personally understand or didn't personally set up, on the grounds that they are too smart to need such bloatware.
It's evolution in action. You make something idiot proof and then sit back whilst Nature evolves a better idiot.
"why is it still a pile of unstable garbage nearly 3 years after it's release?"
Possibly because the info that reaches MS is skewed towards those don't know about it, or who can't switch it off, or who use the box only for testing purposes. That's a population that is skewed away from the IT literate and towards those who believe whatever you write on the tin. Perfect for advertisers, but shit for the official purpose.
"They had lots of heroes including the local techie who had the presence of mind to turn off one of the DC's once they realised what was happening - that saved their AD."
Hmm. Yes. I imagine the rebuild might have taken more than 10 days if it had included typing in a new AD from scratch.
"If I can create an application that can sort what was once disparate data and produce useful and practical information faster than all previous methods, then bring it on!"
Umm ... UNIX command lines, shell scripts, pipes, tools that do just one thing ... and it probably wasn't a new idea then. (Someone else has already mentioned "subroutines", which is another perfectly fair example of the same concept.)
"68K architecture, which I read somewhere doesn't have this problem. "
68K probably doesn't have this problem because the architecture was commercially dead before out-of-order processors took over. A 68K chip designed for performance last year would have been out of order and would almost certainly have suffered this problem, just like the highest performing cores from ARM, MIPS, SPARC, ...
Intel are getting flack from Linus because they are being dishonest about the fix, not because of the bug.
"What have they being doing for 6 months?"
One group will have been figuring out how to change the design of the next generation of chips, which you might see in the shops by Christmas, to avoid the problem. A second group will have been figuring out whether the facilities accessible to *existing* microcode are sufficient to allow a patch, at any performance cost. (Based on the flakiness of the patches so far the answer appears to be "possibly not".) A third group, I hope, will have been trying to think of related attacks that get around whatever strategems the first two groups come up with.
Given the nature of the attacks, I think it is very naive for anyone to assume that a complete patch is actually possible. If Intel *have* internal switches to, for example, turn off speculation then that is both fortunate and frankly rather surprising. (What were they for?)
"For 'Gospel truth', it lacks rather a lot in backup evidence."
In my experience, things are only ever presented as Gospel truth when there is no actual evidence and belief is purely a matter of faith. FWIW, that's seen as a plus point by the enthusiasts: <cite>Thomas replied, “My Lord and my God!” Jesus said to him, “Because you have seen Me, you have believed; blessed are those who have not seen, and yet have believed.” </cite>. It's just the atheists who insist on actual evidence.
For your next president, choose a person who is honest, passably intelligent, willing to listen to advice, familiar with your Constitution, and fully persuaded of the need to uphold it.
You have got one of those, haven't you?
If they possess the aforementioned qualities, their political leanings don't actually matter.
"You do realise that the PC and the OS are the least valuable bits of a computer and the user's data is worth a fortune in comparison?"
You do also realise that, once the PC and OS have been compromised, the only safe repair process is a low-level wipe with independently-sourced installation media. Most end-users are not aware of that, have neither the media nor the know-how to do it even if they knew they ought to, and probably couldn't find someone who could. (You can't, for example, trust whatever's on that hidden partition on the hard drive and what's the betting that if you take it into a High Street shop that's all that they'll bother to do, or perhaps even all that they'll know how to do?)
You stopped this line of reasoning too soon. The defendants are essentially arguing that the damage to the wider public (caused by early disclosure) is less important than letting them sell shares early. This has two flaws. The first is that had the disclosure been made, the share price would have fallen, almost certainly before *they* personally had time to sell. The second is that by recklessly causing a zero-day disclosure, *they* would presumably be the target of other people's litigation.
It is really hard to see how the world would be a better place for these people if they win.
"It will supposedly be based on this theme, "
Sigh. Themes are evil. All themes.
Time was that people who actually researched usability for a living discovered the "amazing" fact that sticking to the same theme as every other app actually made your one more usable, because human beings only had to learn once how everything worked. But that was learned ages ago, so it probably isn't true anymore, or something.
These "labels" just mean we've got our priorities straight and we're not finding truckloads of bugs every few months to justify major changes. As a software developer who values "working", I'd be proud to stick either label on my work. I suspect that Thunderbird's target audience is already dominated by folks who feel the same way.
I'm sure the "form over content" brigade can find another email client.