I feel your pain, but I'm not sure the people complaining in this thread understand the sheer size of YouTube. It's literally the entire worlds video repository. There are over 100 hours of video uploaded every minute. Over 100 hours! Even if YouTube employed an entire army of specialised copyright lawyers trained in the international nuances of fair use, there's no possible way the enormous number of disputes could ever be mediated in a fair way.

When you upload to YouTube, you get a lot of stuff for free, but you don't have to use them. You could host the video yourself and then the disputes would come to you directly instead of being auto-resolved by a machine. If you aren't willing to pay the costs of doing that, then you need to accept the consequences of YouTube's razor-thin profit margins and vast economies of scale.

Many years ago there was an R&D project inside a large tech company. It was exploring many of the hot research topics of the day, topics like mobile code, type based security, distributed computing and just in time compilation using "virtual machines". This project became Java.

Were all these ideas actually good? Arguably, no. Mobile code turned out to be harder to do securely than anyone had imagined, to the extent that all attempts to sandbox malicious programs of any complexity have repeatedly failed. Integrating distributed computing into the core of an OO language invariably caused problems due to the super leaky abstraction, for instance, normal languages typically have no way to impose a deadline on a method call written in the standard manner.

Just in time compilation was perhaps one of the worst ideas of all. Take a complex memory and CPU intensive program, like an optimising compiler, and run it over and over again on cheap consumer hardware? Throw away the results each time the user quits and do it all again when they next start it up? Brilliant, sounds like just the thing we all need!

But unfortunately the obvious conceptual problems with just in time compilers did not kill Java's love for it, because writing them was kind of fun and hey, Sun wasn't going to make any major changes in Java's direction after launch - that might imply it was imperfect, or that they made a mistake. And it was successful despite JITC. So when Microsoft decided to clone Java, they wanted to copy a formula that worked, and the JITC concept came along for the ride.

Now, many years later, people are starting to realise that perhaps this wasn't such a great idea after all. .NET Native sounds like a great thing, except it's also an obvious thing that should have been the way .NET worked right from the start. Android is also moving to a hybrid "compile to native at install time" model with the new ART runtime, but at least Android has the excuse that they wanted to optimise for memory and a slow interpreter seemed like the best way to do that. The .NET and Java guys have no such excuses.

Perhaps I will phrase the question in a more helpful manner.

Let's take it as read that you are indeed a (possibly former) Intel employee who worked on RDRAND. Given the black box nature of the RNG and the fact that some time ago someone posted anonymously to Slashdot claiming that a small number of chips were jinxed so that RDRAND was predictable, do you know of a good way to rebuild confidence in the integrity of a particular chips RNG?

More generally, do you have any interesting thoughts on the topic of building trust in blackbox hardware, whether it be an RNG or otherwise (e.g. Intel SGX)?

Hey Kasper,

It's Mike H, remember me? We used to work together in SRE ;) How is the startup going? I have also recently moved on from the big G.

Now. When this thing first started to bubble up, I didn't feel very concerned either. OK, so I got fewer emails from recruiters than otherwise would. No big deal, not like there was exactly a shortage of those.

However, I just want to point out one thing:

I would only consider there to be a real problem, if facebook would reject resumes submitted by candidates, just because they happened to work for Google. I have seen no evidence of such a practice existing.

Did you read the article? It seems that the only reason such a situation did not occur is because Sandberg told Google to pound sand. During the time in question, these emails clearly show that a very senior Google executive was directly asking Facebook not to hire Google employees, even if they employees in question wanted to go work there and what's more, good corporate relations were being pegged to that demand.

I must admit, I never knew much about Rosenberg and don't have many memories of him (can't even recall what he looks like). But regardless, this paints Google in a very negative light indeed. Rosenberg was willing to threaten other companies in order to make them stop not just pursuing but actually hiring "his" people. Facebook refused, but who knows what other companies didn't? Was that really the only time he took that approach? Was this a Rosenberg-specific moment of madness/idiocy or does it run deeper? I await further discovery with great interest. Even if this was a brief failure on the behalf of just one executive, that's still completely unacceptable and Rosenberg needs to be fired, now. Employees are not assets whose freedom of employment can be traded for corporate deals and to treat them that way is completely unacceptable.

The problem is CAs get suberted all the time into issuing certs they shouldn't issue.

Can you please prove this? Unless you're using a very flexible definition of "all the time", there is no publicly known evidence for this point of view. There are millions of certificates in the world and the number of bad certs is low enough that people can enumerate all the compromises on wiki pages.

HSTS is designed to solve the problem of people not requesting encrypted sites.

You realise you can do key pinning in SSL as well, right? The point of certificates is to let you find out a public key when you don't have advance knowledge. Certainly for mobile apps, there's no requirement that the app trusts any CA.