You don't need to.

You can't sign away many such rights.

As the article hints at, it's almost certainly legally unenforceable anyway.

And if you're that worried, use another place and TELL THEM WHY. Because they are requiring you to sign an unfair contract, which is unenforceable anyway, and they lost your custom because of it.

But the fact is, you can't sign many such things away. Even if you sign it. Even if you agree with it. Even if you wanted to.

Just because someone puts something in a contract, and even if you "agree" to it by signing it (or even ACTUALLY agree with that line of the contract, which is something else entirely), it does NOT mean that it's automatically legally enforceable.

Some rights cannot be signed away. Ever. Even if you want to. If you've ever read "This does not affect your statutory rights", it's an acknowledgement of this (and, in fact, they don't even need to say that - because not saying it wouldn't affect those rights either!).

And "Can not sue" clauses generally don't exist in a vast majority of jurisdictions around the world. Because firstly, they are stupid. Secondly, they are unfair. And thirdly, they are not (generally) legally enforceable anyway.

If you ever thought otherwise, just replace whatever line with "I agree to be killed". Just because you sign it, just because you want it to happen, does NOT mean that the other party in the contract is able to do it to you.

It doesn't mean that nothing is enforceable, but stupid shit like this has nothing to do with the company "backing down"... they just asked a lawyer and realised that they couldn't actually enforce that clause anyway, and they risk large swathes of the same contract being revoked because of such unfair clauses that might come under similar scrutiny.

Don't be stupid and sign away your rights, but equally don't assume that you CAN sign away such rights either. Especially where "like" on Facebook means you can't sue... sorry, ABSOLUTE BOLLOCKS, and would be thrown out of any court.

But now we hit the crucial point of electric cars. At some point, you have to pay a fortune and destroy the environment in order to put another, unrepairable, battery back into them.

This is the point at which two things can happen, if batteries are too expensive: People bin the cars and get a new one. People bin the cars and buy something else.

It's not like an iPad or something where this is a throwaway expense and the device goes out of fashion before it's required and replacement can be done on the cheap. WE HAVE NO CHEAP BATTERIES suitable for electric cars. It doesn't matter how huge your factory is, you just can't make the batteries that cheap. If you could, you wouldn't even need to make an electric car yourself, you could just make a living from the batteries alone and could have done many years ago before you sold the cars.

And the problem is there for all manufacturers, all end-users, all producers. We just don't have that kind of energy capacity that cheap yet. Except, possibly, in liquid form.

When these batteries start dying, the cars won't even get as far as the second-hand market. Nobody will touch them. They will be destroyed (recycled) rather than sold on. Now factor the cost of that battery over 8 years... chances are it comes in at about the same (with charging costs) as just using petrol all that time ($40k buys a LOT of petrol...). We honestly haven't saved anything. But done so at great expense.

And, historically, even battery "breakthrough" that I ever heard of resulted in pretty much zero commercial success (mainly because they never achieved anywhere near as much as they promised they would). And every battery "breakthrough" that I did witness as successful was done literally overnight without almost any fancy scientists telling us how great they'd be - laptops just started to come with NiMH, and then Li-Ion batteries - and then I saw a LiPo battery in a product - and at the time you'd never even heard of them. Even back in the early days of rechargeable batteries, they just appeared on the market out of nowhere and then stayed there for years while dozens, if not hundreds, of alternate ideas were given air-time and resulted in nothing because their improvements never actually materialised.

I'm not saying there's not something on the horizon. But the amount of battery chemistry changes that have commercialised successfully can, literally, be counted on your fingers. And the amount of "battery research" that resulted in nothing, where we were told they'd be the next big thing in 5-10 years time? Innumerable. I can remember being told that aerogels were the future of batteries... have yet to see one.

This is, as far as I can see, a face-saving exercise. Nobody has managed to build a better battery. Many of the electric cars of the last decade literally use laptop cells to do so - just stacked differently. And yet we've had proven commercially-viable electric vehicles since the 60's at least (anyone over 30 in the UK knows the sound of the milk-float).

They bet the whole show on someone, somewhere, building a better battery and - pretty much - selling at a loss hoping it would arrive if they just sold enough cars. And now that bubble is starting to collapse in on itself. Nothing has really changed in battery technology. Nothing looks likely to in the immediate future. So all they can do is ramp up production and hope there's enough lithium to use it.

And who gets the bum end of the deal - the first adopters who, to be honest, I have little sympathy for as they made the same predictions / gamble on batteries as Tesla have. Give it a couple of years and they will have a very expensive paperweight that can't even get them down the road and it'll be cheaper to buy something else entirely.

I'm not completely anti-electric. Hell, I was pricing up all-electric scooters/mopeds/motorbikes only the other day. They are viable. In the time it would take me to kill them, I would save enough in petrol to buy them all over again. But the fact is that they have a limited purpose and limited potential precisely because the engine power just isn't there. There's no point having a Ferrari to go down the shops if the fuel tank will barely get you there.

And what most people really need is something that can do 70mph, with 2 adults, 2 kids, a shed-load of luggage, and drive hundreds of miles between charges, and not "die" if they then don't use it for a while. And when you get into that scenario, or even the scenario of everyday commute, they quickly become so reliant on the battery that you have to worry about it. I'm not going to spend tens of thousands on a car with a dubious resale cost at the end of it. And that resale cost is almost entirely limited by the battery.

The next few years will be interesting as these things die off.

That someone bothered to answer the question at all worries me. That kind of thing shouldn't even warrant an answer at this stage... literally, who cares?

The code has been a collection of driftwood for many years and ONLY when there's a major, major, major problem (one big enough for an awful lot of people to say "Fuck using that again"), do we then get any kind of code cleanup. Literally people never bothered to go through and clean up ancient crap that shouldn't even be in there any more.

And nobody bothered to lay a simple API over this heap-of-shit (yes, I've used it - yes, I've spent most of the time copy/pasting others and the "official" examples because there's so little useful documentation that it's the only way to get vaguely working code... and even then you have to "hypothesise" any number of corner cases for yourself on even the simplest of code and hope that (or make) the examples complete).

To me, this is nothing more than reactionary cleanup. If the problem hadn't happened, we'd still be running this crappy code on production hardware for decades to come (and may still be yet!). That's not at all reassuring. And, to my eyes, such cleanup stinks more of "Fuck, look at the state of this code, we can't even begin to fix this, we have to clean it up first" more than anything.

Sorry, but OpenSSL (and, by extension, the OpenBSD team) have lost an incredible amount of respect from me. Enough that I may not bother to touch their code again if I can help it. I thought it was just that the security of the code was so high that you weren't supposed to fuck with it without knowing it inside out, but it turns out that it was just antique obfuscation caused by code-rot and no suitable documentation.

It's going to take more than an overly-verbose reasoning as to why they won't rename it to get that kind of respect back. And it also makes me query deeper issues with other code they write too.

Because static analysis cannot catch all problems.

It's as simple as that.

Their "fix" is to mark all byte-swapping as "tainted" data... basically it's a heuristic they've decided on, not proof of foul play (which is almost impossible to get on static analysis of someone else's code).

Relying on things like Coverity to find everything will always end in disappointment. What you do is fix what it finds, when and where it's a problem. The fact is, they simply had no way to detect this issue whatsoever, but fudged one for now. The next "big hole" will be just the same.

All due to them, Coverity is a very powerful and helpful tool. But you can't just give the impression that because it's been "scanned by Coverity" (or Symantec Antivirus, or Malwarebytes, or ANYTHING AT ALL WHATSOEVER) that's it's "safe". That's just spreading false confidence in duff code.

It doesn't matter how clever you are... at some point, some session will have to run with more privileges than the user in order to be able to do something.

Or, as here, the session gets taken over as "just a user" and steals all their data / credentials anyway and tries to move deeper by finding more.

The problem of privilege separation can be fixed today, the tools are there. The problems described here aren't helped or hindered by privilege separation.

To be honest, what you have to have is an enormously fine-grained permission system no matter what, and that - in itself - is a recipe for disaster. Eventually you get to the point where you need to deploy tools to find out what permissions are given as certain users because it gets so complex.

Or you could just patch when a problem is noted, especially when it involves your SSL library.

With a laptop in idle? Pence.

10 hours with a 100W idle, even (nowhere close to screen-off usage, but let's over-estimate) - 1KWh. Unit price for that doesn't compare to even one trading card sold for penny-cheaper-than-every-other-similar-card for me.

Plus, I normally just have the game on in the background while I'm doing other things on the machine, so the actual "real" usage of electricity etc. is basically zero.

I'm not a $1-kind-of-guy. But, yes, I have made profit on the bundles. Especially if you buy quick, get the discount, and get the cards into the market before it gets flooded by all the other sellers.

But I don't buy bundles that don't have at least something worth the money in them, and don't beat-the-average unless there's a game I really want on that side either.

Especially since the trading cards.

I often buy a humble bundle, load up the games, leave them running to "earn" the badges, shut them down, uninstall them. (Then sell the cards, get Steam Wallet cash, buy more games, get more badges, etc....)

Stop this.

Seriously.

Just stop.

When I looked into my server, I found out:

The OpenSSL library I'm using wasn't vulnerable.
Thus, my keys are as "safe" as they were before.

Also, to enable PFS, I would have to upgrade - to one of those OpenSSL versions that is vulnerable (but obviously there are "fixed" ones now).

I would also only be able to use EC cryptography with PFS with OpenSSL. I don't trust EC personally, yet. It's just not been around long enough for me. And I find it suspicious that every time something happens, the answer is "Let's go to EC!". If anything, I suspect it might well be something that people we don't want deciding algorithms are driving us towards.

Sorry, but until I trust EC, I can't trust PFS. And I can't use either until I upgrade to a version of OpenSSL that was vulnerable to this attack for a long time without anyone noticing (whereas my current version wasn't).

Ironically I "score" more on certain SSL test sites with old OpenSSL than with the newer one... and I get artificially capped because I don't support EC.

Until someone shows me that PKE is broken, then EC is not necessary for my usage. PFS is something I'd like but, as OpenSSL only supported it when using EC algorithms last I looked, I don't see it as any more secure.

I'm sorry? Why would "decades without computers ... render computer science and related professions useless"?

I don't think you get that "science" bit on the end of it. Nor that much of computer science goes back to extreme basics. Morse Code? That's coding theory. It's only if you take a narrow-minded view that it doesn't appear as computer science.

You can build a computer from the simplest of building blocks - it just so happens we prefer semiconductors - but as has been historically proven you can build a mechanical computer capable of just about anything (and that was proven how? Turing machines? Oops, that's computer science!). Maybe not fast, but accurate and useful when it comes to larger calculations. We had a need for such things several hundred years ago and, even big projects aside, we made them and used them (Abacus for thousands of years? Calculating machines were rife for centuries from the 1600's).

The fact is that computer science is, like any other science, not only useful as a nurturer of people with a logical mind, but also directly useful in any size society once it's settled a bit. Mostly because much of it is maths. And the rest of it is directly applicable to real-world calculations.

Sure, you can live without it. But you can live without an awful lot of things. But with it, you gain an advantage. Where best to site my defence towers against the pillaging hordes? How best to send a message asking for allies to appear without the enemy knowing what is in it? How to ensure we don't waste time dividing food equally with various random weights and measures?

It's the old fallacy - but it's wrong. You do not need a computer to perform computer science. And you do not need a computer to get useful data out of your computer science. It just helps, and speeds along the process.

Fact is, in any kind of apocalyptic even like this, you'll be glad of any academic, especially one that can provably solve practical problems like this. Hell, simple ballistics is a nightmare to solve by hand.

And, if it comes to it, you can build a computer out of blocks of wood (there are several examples of this), water-filled tubes (the Russians did concrete calculations on one), or pieces of paper. We're all taught how to do at least the last one of those in computer science courses, too.

A computer scientist may not be the immediate asset who scavenges food or heals the sick or welds defences. But you'll want one on your team before long, and they'll give you an advantage over any group that doesn't have one.

I don't think you have much of an idea of what a kernel is.

Just because you have the same kernel does not mean that you can run the same applications.

More importantly, please tell me what's in the pre-flight safety check.

Chances are that you've heard it so many times that you could give it.

Your belt clips around your waist. You undo by lifting the buckle. Your oxygen mask will drop down from the overhead compartment. Your exits are here, here and here, etc. etc. etc.

The danger of the pre-flight "safety" check is that it's nonsensical to do it. Emergency measures should not be designed that people have to learn to use them. They should be clearly marked, with - at most - one simple diagrammatic instruction. If you can't make them that simple, redesign them.

Same goes for nautical safety but there's a lot more to go wrong by your own hands on a ship. In a plane, well, you're just holding onto your own backside and hoping it all goes okay no matter what.

Honestly, I think it's about time we scrapped them. They tell us nothing we'll remember in an emergency, even though we've memorised every step. They talk about extreme situations that happen in extraordinarily rare circumstances. They scare passengers who are nervous. And yet, pretty much, studies show that in an emergency it's every man for himself and we'll all forget the briefing anyway.

Take the briefing away. Take the flight safety card away, Put simplified instructions everywhere (oxygen mask is here, pull to start flow, with a little diagram). Let people relax on their flight without being FORCED to sit through a briefing they are desperate to shut the hell up so they can sleep.

If you want to have the briefing, do this - hand out a little app that lets you do it on a personal basis.

Most importantly - SHUT THE HELL UP on flights. Let people relax, sleep and journey and then - when an emergency happens - they won't be so stressed that they do quite so stupid things.

Can't say I'm surprised. OpenSSL is a pile of dung. It's nothing to do with being written in any language, it's just horrible.

There's not even any documentation. I mean, literally, none. Nothing vaguely useful. How do I programmatically load a certificate into the store, along with a chain of related trusted certificates, and then set my requirements (must be in-date, must be validly signed, etc.) and get out a "It's fine" / "Something's not right" response? The only answers I could ever find were to follow published examples and tweak.

And when it comes to working out where in the published examples structure X comes from, or how to convert it to structure Y, you're on your own unless you happen to have picked a comprehensive (and almost certainly not OpenSSL-supplied) example.

It's just that bad. I was writing a pseudo-DRM for a game / Steam-like distribution platform as a hobbyist project. It was literally horrible to even try to self-sign some certificate and then see if it all panned out later from another computer to guarantee integrity. In the end, I had to "imagine" every possible case and find a way to counter it (i.e. client cert expired, client cert invalid, server cert not signed client cert, server cert has bad chain of trust, client cert not signable for that purpose, etc.) - and almost always there was NOTHING to indicate what the recommended way to do it was.

There is no decent OpenSSL documentation at all. Not even a decent overview of the process of checking certificates. It scared me at the time, knowing how important the library is, and it can only lead to bad code.

In the end, I'm quite glad I don't have to program against it for a living. If I did, I'd be seriously looking for something else.