Unpopular though it is, if you can take a small(ish) performance hit, you could use a Java HTTPS server that proxies to your app. The Sun/Oracle JSSE SSL stack (in the Oracle VM, not Android) is pure Java and thus immune to these sorts of errors. In JDK8 it supports TLS 1.2, ECDSA, perfect forward secrecy and the use of AES-NI for hardware accelerated constant time stream ciphering.

I would say it is a problem with mailing lists. They are taking mail, rewriting it to say something different, then delivering it in such a way that they claim they didn't change it (with broken digital signatures). This isn't Yahoo breaking mailing lists. This is just mailing lists doing something stupid. The fix is for them to stop doing MITM attacks on people's mail or to do it, but to resign the mail themselves so they take responsibility for it.

It's not like DKIM is new by the way, mailing list developers and admins have had this coming for years. But you won't find a more backward or stubborn bunch than crusty postmasters who ran mailing lists the same way since the 80's.

I don't buy the "good today, crap tomorrow" mentality. XP still has a massive installed base. This will open the door for entrepreneurial geeks to create their own security and stability patches.

Diid Symantec or Macafee say they were dropping XP support? Nope, it's a huge cash cow for them.

Blah blah blah.

Java 8 has a full SSL stack written in Java itself, so no buffer overflows there, and which uses AES-NI for hardware accelerated encryption if available. It also supports perfect forward secrecy and other modern features (no session tickets though).

If you look at the CVE history of JSSE what you will find is that occasional bugs like the Heartbleed attack (not checking length fields correctly) get reported as denial of service issues because they cause managed exceptions that might, if you wrote your code non-defensively, cause your server app to quit. Or they might just cause the connection to drop, which is the right behaviour.

It's about a million times safer than an ancient piece of 1980's style C like OpenSSL.

I don't think Chrome uses OpenSSL, although they are thinking about switching to it. They use NSS, same as Firefox. I'm not sure any browsers use OpenSSL - it's mostly used on the server.

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.

... I shouldn't sell our two AppleTVs?

The astrophysicists at Adobe told me that it looks 'shopped.

If you can afford it, your computer's RAM should be maxed out to 640KB.

Every day at noon they compare it to the sundial out back.

... but they will still have to manually adjust for DST twice a year.

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.

We picked up a new car in September. Everything we looked at had cameras and they weren't super-expensive like a Ferrari. Granted we didn't look at Kia or the like. You can't see cameras when in traffic.

What cars don't have rear view cameras these days?

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)?