Isn't that assumption where the whole argument for notifying selected parties in advance breaks down?

If you notify OpenSSL, and they push a patch out in the normal way, then anyone on the appropriate security mailing list has the chance to apply that patch immediately. Realistically, particularly for smaller organisations, it will often be applied when their distro's mirrors pick it up, but that was typically within a couple of hours for Heartbleed, as the security and backporting guys did a great job at basically all of the main distros on this one.

As soon as you start picking and choosing who else to tell first, yes, maybe you protect some large sites, but those large sites are run by large groups of people. For one thing, they probably have full time security staff who will get the notification as soon as it's published, understand its significance, and act on it immediately. For another thing, they probably have good automated deployment systems that will systematically patch all their affected servers reliably and quickly.

(I accept that this doesn't apply to those who have products with embedded networking software, like the Cisco and Juniper cases. But they can still issue patches to close the vulnerability quickly, and the kinds of people running high-end networking hardware that is accessible from outside a firewall are also probably going to apply their patches reasonably quickly.)

On the flip side, as long as you're giving advance warning to those high profile organisations, you're leaving everyone else unprotected. In this case, it appears that at least two different parties identified the vulnerability within a few days of each other, but the vulnerability had been present for much longer. There is no guarantee that others didn't already know about it and weren't already exploiting it. In general, though it may not apply in this specific case, if some common factor prompted the two contemporaneous discoveries, it might well be the case that additional, hostile parties have found it around the same time too.

In other words, you can't possibly know that nobody was harmed by hearing about it a day later. If a hostile party got hold of the vulnerability on the first day, maybe prompted by whatever also caused the benevolent parties to discover it or by some insider information, then they had a whole day to attack everyone who wasn't blessed with the early knowledge, instead of a couple of hours. This is not a good thing.

As I did say in my previous post, but you omitted when quoting it, this might stand up if all parties agreed to the arbitration. Sometimes C2C contracts include these kinds of terms, for example.

However, it's going to be tough in most jurisdictions (obviously not everyone in the world is subject to the US legal system) to convince a judge that such a heavyweight term in a contract of adhesion that one of the parties may not even have realised existed should be enforced. For example, in my country we have the Unfair Terms in Consumer Contracts Regulations 1999. If you like, you can search down that page for the words "Compulsory arbitration clauses are automatically unfair for the purposes of most consumer disputes" and you can look up the law itself to see why.

Of course, all of this presumes that a contract even exists in the first place, which is another obvious avenue of attack against this strategy. For example, contracts generally require some form of consideration in both directions. What is in it for the guy who clicked 'Like' to accept such a draconian restriction in return? And if the original action was simply buying cereal from your local store, then the contract is almost certainly between you and the store, not the cereal company. While legal systems have been known to recognise third party rights under some conditions (again, varying by jurisdiction etc.) you'd probably come back to things like whether such terms were an expected part of the contract of sale, and whether they were unfair/unconscionable. And guess who is going to rule on that...

Most religions claim otherwise. I think those religions that "survive" the competition from other religions (like an evolutionary process), are those that "procreate" well into the next generation.

Therefore, successful religions must force people (with the threat of divine punishment) to adopt the theory, like belief in god.
Religions that would not mandate a belief in god, and promise punishment to those that don't, would die out fast.

Indeed. Good luck arguing in court that someone gave up their right to sue. The legal profession tends to be awfully sceptical of such measures, and none more so than judges. While it might stand up if, for example, all parties agreed to use some reasonable form of binding arbitration instead, it's hard to imagine the big company would get anywhere against the little customer under these conditions.

Really? My motto is don't treat your idiots and children like users.

Having patches approved by a CAB should not be a big deal. A brief write-up of the patches to be applied -- or an attachment listing the patches, reasons for applying them, etc -- was all that was required. Every CAB I've ever worked with has a procedure for an emergency like applying a patch for something like Heartbleed. All it usually took was a phone call to certain people and getting a verbal authorization. (You filled out the standard change request forms after the fact.) Working with a CAB is no big deal. Really.

But speaking of pointless paperwork... We had someone in a QA role stand up in front of the IT group and tell us that they wanted a screen shot of every single patch installation for every single server the patch was installed on. (And the rest of the QA team nodded their heads in unison like robots.) When it was pointed out that the length of time required for making a separate screen shot -- signed and dated by hand to boot -- for each of the patches in your typical Microsoft service pack times hundreds and hundreds of servers and that such a process would be prohibitive (to say the least) they eventually backed off. If that initial request wasn't bad enough, they actually wanted the process to be: Install the first patch, take the screen shot, print it, label it, sign and date it. Only after those steps were completed would you move onto the next patch or server. If their plan had been implemented the company would have had to build a new building just to house the printed screenshots.

Not since the Reagan administration. What actually makes the big news story is when an acquisition/merger is actually denied.

Not that AT&T will sit back and let this happen. It would be surprising if they weren't already hard at work lobbying their bought-and-paid-for Congresscritters to cut funding to any and all government agencies that would enforce this auction decision.

We're being driven from our humanity by various forms of corruption in civilization, and technology is helping us escape...inward.

All the guns in the world will do you no good if you can't motivate the people using them.

People are motivated, by and large, through the use of words.

Though both are hedging as you say, I think both desperately want the other to overwhelmingly succeed. MS on ARM is not competitive due to a complete lack of support for legacy x86 applications and an otherwise uninspired design, so MS wants the world to run on x86 where they have home court advantage. Similarly, while Intel still has mostly better offerings, they cannot extract the desired margins out of such a highly competitive market like ARM where people will go without the very latest semiconductor process and gobs of performance. They want a software ecosystem that demands x86, which only Microsoft really has.

So yes, each has some 'worst case' contingency intended to keep them in the market. Those contingencies are both such long shots and will forever reduce margins even if they are 'successful'. That's why Intel has double downed on engineering with MS about platform sleep states and such without giving Android nearly as much attention (basically just token attention).

Microsoft and Intel should be best friends. They are each others main hope for relevance. Intel competing against the horde of ARM vendors on even ground is not going to end well for Intel's margins no matter how much share they hypothetically get. In much the same way that MS is nothing without the momentum of decades of x86-only applications, Intel isn't much without MS applications. Well, Intel's products are a bit respectable in their own right, but the primary driver of their large margin is the x86 ecosystem where MS is ubiquitous.

Intel may be hedging their bets to try to assure they aren't completely left behind in an Android-centric world, but I wager they are strongly hoping for MS to provide a software platform experience on x86 that is too compelling to overlook. I will say that even the 'best' Android apps I deal with are pretty crappy ( having to mysteriously be killed because it hangs, sometimes needing their persistent storage wiped because it has no idea how to work back to working state from whatever state it stored persistently). Even chrome randomly decides 'I'm just going to stop being able to render certain pages altogether'. It's bizarre, since on Windows and Linux desktops I don't see nearly as much wonkiness from many of the exact same application vendors doing about as equivalent a product as can be imagined. For a given price, I'd honestly prefer an x86 tablet so long as secureboot can be disabled to run platforms I have a great deal of familiarity with.