I'm somewhat bemused by the keyboard thing. I bought a load of MBPs for my team the first year the butterfly keyboards came out, then replaced my own old model with an i9 the year after. None of us have experienced any problems whatsoever with them, and we're heavy keyboard warriors, developers, sysadmins etc.

Luck of the draw perhaps, but for someone like me who cut hit teeth on 6502 stuff 40 years ago can learnt to type at a preposterous speed decades back, I've found it to be the fastest keyboard I've ever, literally, laid my hands on and it's never been any trouble at all.

Has there ever been a root cause established for the supposed reliability problems? eg. techies covering keyboards in potato chips etc (or "crisps" as we call them in the UK?

This is exactly true. If it's Bernie, Trump wins. I'm British, definitely on the moderate left, and have just seen what happened to Corbyn. Nobody expected him to win, but few expected him to get hammered as hard as he did.

You do not need a private key to revoke a certificate. You need the certificate serial number.

The issuer should NEVER set eyes on a private key which isn't theirs. If you want to make life easier for your customer, do it client-side with JavaScript and throw a PFX at them once the issuance has completed.

It still stuns me how many in tech, even CAs, have such a poor understanding of how PKI works.

In the UK in the early/mid 80's we had the BBC Micro which shared the market with the like of the C64 and Spectrum. Pretty standard kit; 6502 CPU with 32k RAM (later 128k on the BBC Master). BASIC was where I started, but it didn't take long to get into writing assembler - somewhat necessary in order to do anything cool like *ahem* copying games which relied on raw sector reads of deleted data on 5.25" floppies as copy protection. Our local radio station even had a computer show on a Wednesday evening where they would play programs out over the air for people to record on their handy tape deck.

When I started high school they had a whole Econet network built around BBC machines with an SJ Research file server. That sparked a whole new interest and, under the premise of writing a multi-user network game, I managed to persuade SJ to send me a load of very useful documentation. A matter of weeks later I was blowing my own PROMs at home and discreetly slotting them into the BBCs in one of the music classrooms. The docs from SJ were what today's coders would describe as "undocumented APIs", but you would essentially just load up the registers and JSR to a particular address to unleash teenage stupidity with gusto.

Instead of trying to steer me toward applying my skills in a more constructive manner, my school decided to ban me from using any computer in the school for a year. Being somewhat "on the spectrum" I went a little off-piste at that point and headed off down the road of rock n roll, girls and weed for a few years; until it became necessary to actually earn a living.

When I came back to computing things had changed a lot and the PC was taking over; it was late 486 and very early Pentium dominating the market which I found fairly easy to slip into. I became relatively capable with a lot of the common languages of the time and whilst I'm decent with x86 it's only on a handful of occasions I've ever needed to write it in the raw.

I don't work as a coder, but that early experience has been enormously valuable in terms of understanding how things actually work under the hood, being able to turn my hand to most common languages when the need arises, and in terms of the problem solving mentality I learned back in the 80's.

I'm guessing you live in the US? If so, erhaps you should petition your local person of power (senator? congressman? whatever) to address the pitiful consumer laws in your country. In Europe such things are legally bound, in terms of products being fit for purpose for their intended lifetime. In the UK this is implemented in (amongst other things) the Sale of Goods Act which gives you significant ammunition in terms of demanding it be fixed for a period of (I believe) up to 5 years.

Genuinely not trying to be a smart ass; you could be in Europe and be unaware of such laws - hopefully you are. Companies, as a matter of course, will conveniently forget to mention these rights until you beat them around the head with them. But then, that's business - deny deny deny, until you're banged to rights.

Agree and disagree...

If the employee has never been cause for concern there's no need to be a dick about it, but this is basic risk management. Pat the guy on the back, knock off early and buy everyone a round of beers. But you have to lock him out. Pay him his notice and let him go.

Certificate Authorities who operate on the scale absolutely do NOT keep private keys of the issuing intermediate available for harvest. That's what HSMs are for; devices which hold the private key material and perform signing operations on behalf of the CA. The CA can never retrieve the private key(s) so compromising the CA in that scenario should never result in private key disclosure.

The main issue is that Oyster does do some level of cleverness. I only ever skimmed the paper so don't recall the details. The main issue in most use cases is that the spec says the token UID should be read-only. When you can buy tokens from China which completely disregard this and let you write sector 0 it's game over immediately for huge swathes of RFID installations which rely on UID alone.

My work ID does door access, printing, loads of stuff. Spoof the UID onto a blank token, remove the chip/antenna, place inside rear cover of watch. Super convenient, but alarmingly easy.

And you know that "tap and go" stuff your credit card has, distinct to the chip & pin functionality, for low-value purchases like a Double Whopper with cheese? Don't even get me started on that...

Honestly, what the actual fuck? Have you listened to yourself?

I don't actually use public transport. I just do some NFC work for the day job and know how weak the keys are in old MiFare stuff. No wonder you posted AC with that outburst of verbal diarrhoea.

Well thanks Anonymous Coward (latin: buffoonus maximus), but that's a bit of a tenuous jump. I don't even use public transport, I'm just a guy who does a bit of NFC engineering for the day job and knows the difference between the wrong way to do it and the way I do it. The token security is weak, certainly, but it's easy to protect against with some very low-overhead crypto.

Old MiFare stuff is toast, security wise. Any old fool can order some UID-writable tokens on eBay from China, grab a copy of libnfc and mfoc, then things get interesting pretty quickly.

Well someone got out the pedantic side of the bed this morning. And no, it's an allocation of my ISP's /16. If I'd got the range from RIPE I wouldn't need PTR delegation would I?

I don't actually need the whole block any more, it was something I was doing for a PhD project a few years back. A /27 would do me these days, but they don't seem in a hurry to have them back.

Very well put. Getting a large ISP whose staff "follow the flowchart" to provide such things is not as easy as some make out. I have a number of non-catalogue products including bonded FTTC which has saved me a fortune on what I used to pay for dedicated hosting (I don't need 5 9's uptime). Instead of a call centre grunt giving a standard "We don't provide that service" response, I get a technically literate person on the end of the phone who understands what I'm asking for and says "Let me have a word, see what we can do". You pay for that kind of service, but for me it's worth it.

Not A&A actually, but along those lines. It's a little more than just PTR NS records, but that's not really relevant to the discussion.

Personally I'm not a big user of these kind of services, but it's only a handful of the "big" ISPs who are doing the blocking. I prefer a more personal service so I use a small ISP which offers special geeky extras (full class C, reverse NS delegation etc) and they perform no such blocking. But even if I didn't it's trivial to bypass such blunt instruments.