How many unauthenticated remote exploits in a HTTP stack does it take to lose a customer?

Not many, I should imagine, but your comment is irrelevant because there were no such bugs fixed in this Java update. The way Oracle describes these bugs is horribly confusing. Normally we expect "remotely exploitable without authentication" to mean you can send a packet across the network and pwn the box. If you actually check the CVEs you will see that there's only one bug like that, and it's an SSL downgrade attack - doesn't give you access to the box. All the others are sandbox escapes. If you aren't trying to sandbox malicious code then they don't affect you.

Java doesn't have security holes like C or C++ .... or so I was told.

Then again, I haven't seen too many security patches for gcc or libstdc++ or glibc

You're comparing apples and oranges. The "remotely exploitable bugs" in this Java update, like all the others, are assuming you download and run malicious code in the sandbox. GCC and glibc don't have protecting you from malicious code as a goal, in fact Linux typically requires all software to be installed as root no matter what. Obviously if you never even try, you cannot fail.

The interesting story here is not so much that sandboxes have holes (look at the Chrome release notes to see how many security holes are fixed in every update), but rather than the sandbox makers seem to be currently outrunning the sandbox breakers. In 2014 Java had security holes, but no zero days at all - all the exploits were found by whitehat auditors. Same thing for Chrome, people found bugs but they were found by the good guys.

I'm not sure if this means the industry is finally turning a corner on sandboxing of mobile code or not, but it's an interesting trend.

Go look at the source code to one of the open source projects like OpenPilot,
they integrate accelerometers, gyros, magnetometers, barometric altimeter and GPS for their navigation system,
modern GPS chips also have anti-hijacking/jamming, eg SiRFstarIV GSD4t consumer device chipset,
and the off the shelf radio control kit can do encrypted spread-spectrum comms.

It is not trivial to stop one by jamming, a shotgun up close is way more effective

GC tuning can do a lot, but yes, huge heaps where the GC cannot keep up with the rate of garbage requires a full stop the world collection. However, if your application is really keeping a 15 gigabyte working set, I suspect you'd hit problems with fragmentation and memory leaks using something like Rust long before scaling to such sizes.

Why don't you watch the talk and find out?

Actually I'll just summarise it for you. If you run a lot of Tor nodes you will eventually get picked to host a hidden service directory. Then you can measure lookups for the entries of hidden services to measure their popularity, and crawl them to find out what's on them.

[Java took a very different approach to the problem of "how to we get rid of segfaults and memory corruption". Java basically banned all interesting use of the stack, forcing everything onto the heap, and barred developers from using RAII. Nowadays, with more advanced compilers able to do advanced lifetime analysis, we can reconsider languages - such as Rust - that take a less draconian approach.]

I think it's rather misleading to state that more advanced compilers have obviated the need for Java's approach.

Firstly, Rust doesn't solve automatic memory management like garbage collection does. Their solution appears to be basically smart pointers with move semantics + reference counting for the cases where data doesn't have a lifetime cleanly tied to scope. Well, great. It's back to the 1990's and COM. Reference counting notoriously cannot handle cycles, which are very common in real programs. Any tree structure where you want to be able to navigate both up and down, for example.

In addition to the difficulty of breaking reference cycles and preventing memory leaks in complex programs, refcounting also has poor performance especially if you want threads involved. Garbage collection has now been optimised (in good implementations like HotSpot) to the point where it's faster than refcounting.

If we start seeing teams of non-expert programmers writing large programs in Rust, you will see programs with memory leaks all over the place.

Additionally, you realise that Java compilers have got smarter over the years too, right? HotSpot can stack allocate objects in a bunch of different circumstances, when analysis reveals that it'd be safe.

Basic Income is welfare, not something that sounds like it. The difference between it and normal welfare is, everyone gets a basic income whether they want it or not. It's meant to be enough to live off.

The idea of a BI is a very old one. It has nothing to do with cryptocurrency, and I'm not sure what relevance cryptocurrency has (and I say that as a Bitcoin developer, so I'm a fan of CC in general). In theory a society rich enough to afford it would have moved to the oft-fictionalised post work utopia that you sometimes see in things like Star Trek. Because everyone gets it whether they want it or not, unconditionally, the basic income would be supposedly stigma free. Thus if you want to pursue things that are not very profitable but are beneficial to society nonetheless (production of art, charity, etc) then you could do that and not have to worry about being seen as a welfare sponger.

I love the concept in theory, but a society rich enough to afford one is pretty unimaginable in today's world. Western societies are clearly incapable of even providing the current levels of welfare let alone a vastly larger level. I see a BI as a useful goal to inspire people about the future rather than something practical for today.

That was true 10 years ago. These days browsers make them un-ignorable and in some cases like with HSTS unbypassable.

They aren't allowed to impersonate another company, I suspect that's rather the point. Look at the screenshot: the HTTPS indicator was crossed out. I guess you have to click through a big fat warning to get there ..... and I'm surprised it's even possible at all. I thought YouTube was SSL pinned. Maybe it's just google.com

In all of my years of being a network engineer, I've never heard of managing bandwidth that way and can't think of why someone would mange bandwidth that way.

Me neither but we have no idea what kind of filtering system you can install onto a plane.

My guess is that they can't filter by DNS lookup for some reason (people's devices have cached answers?) but they can do SSL rewriting, and for big sites like anything Google runs IP address blocking isn't useful because all their sites share IPs. They know browsers and apps won't accept their fake certs, it's just a way to create an unbypassable error.

You're not thinking like someone who has to deal with the general public.

People who read slashdot can easily rattle off some semi-accurate estimates for how much bandwidth a particular online activity consumes. Load BBC News? Less than 1mb (I hope). Listen to a streamed MP3 of a pop hit? Probably 3-4mb. Watch a 40 second video? Maybe 5-8 megabytes. Windows update? Errrmm ..... maybe 20-30? Stream a full TV episode. Multiple gigabytes.

None of this means anything to your average flyer. They don't think in units of bits. Telling them they have 300 megabytes of transfer quota is just meaningless nerd speak to them. What they understand is watching youtube, browsing the web, downloading TV episodes, etc. This is the fundamental problem all brokers of bandwidth have: their customers don't really understand what they're buying.

So now we come to the question of why GoGo is serving bogus SSL certs. The most obvious reason I can think of is that doing so breaks both websites and apps in such a way that they will stop immediately, rather than switching to alternative hostnames or IP addresses or constantly hammering away and retrying stuff. If you're trying to selectively kill off YouTube and other video sites so you can tell people "Sure, browse the web and play with your phone, have fun" in a massively bandwidth starved environment, causing unbypassable errors for specific websites is probably not the worst way to do it. People will be happier this way than thinking they're gonna surf for an hour before going to sleep, and then getting a quota exceeded error after five minutes because they accidentally clicked on a YouTube vid.

I don't think people wielding guns in Gaza has much to do with them being Muslim.

Obviously a ban is not the same thing as a well enforced ban.

Note that the most recent comparable incident in the UK involved two Muslim men hacking a soldier to death with a machete. But there was only one death. It's much easier to kill people, much faster, with guns than with machetes. The UK has been very serious about gun control though, so the lack of guns in the last attack wasn't a huge surprise.