ShadowRegent

When Apple says your data doesn't leave their servers, that doesn't mean those servers have to be in their own datacenters or that Apple doesn't have other vendors that help them deliver their service. It also doesn't mean those companies have access to your unencrypted data. That data also, by necessity, likely traverses other networks in encrypted form on its way between you and Apple.

They're old, but it's really disappointing to see them end even basic temperature control (except physically on the device).

I'm not so sure. One of the potential benefits of removing ports from the iPhone is improved water resistance (personally, I'd still rather have the port). I don't foresee going swimming with my AirPods case.

It’s only been a couple of business days, and it’s likely that they themselves will need root cause from equipment vendors (and perhaps information from the utility) to fully explain what happened. Perhaps they won’t publish anything, but at least give them an opportunity before trying to do it for them.

Maybe, but I think that their "Informed Speculation" section was probably unnecessary. They may or may not be correct, but give Flexential an opportunity to share what actually happened rather than openly guessing on what might have happened. Instead, state the facts you know and move onto your response and lessons learned.

Interesting choice to spend the bulk of the article publicly shifting blame to a vendor by name and speculating on their root cause. Also an interesting choice to publicly call out that you're a whale in the facility and include an electrical diagram clearly marked Confidential by your vendor in the postmortem.

Honestly, this is rather unprofessional. I understand and support explaining what triggered the event and giving a bit of context, but the focus on your postmortem needs to be on your incident, not your vendor's.

Clearly, a lot went wrong and Flexential needs to do their own postmortem, but Cloudflare doesn't need to make guesses and do it for them, much less publicly.

Close, but not quite. The keys were for consumer Microsoft accounts, but accepted for organization accounts as well.

> Am I right to assume that because the attacker had the signing key all of the extra authentication mechanisms that would have been enabled on accounts were bypassed by the attacker...?

That's my understanding.

> Interestingly, GSM does allow for priority of emergency calls (112, 999, etc). IIRC, the SIM can make a priority request to be connected to the emergency services. The network could disconnect a non-emergency call to free up the air interface.

An emergency call on GSM doesn't really "call" a number in the traditional sense-- the number is never even transmitted. This is also why emergency services can be reached by the GSM standard number (112) or other emergency numbers specified by the phone or the SIM itself.

“Twitter, whose press office has been largely destaffed and set to autoreply to requests for comment with a poo emoji, did not acknowledge the reports.”

Of course he did that.

A CA doesn't need to be online for HTTPS to work. If it's offline, it won't be able to issue new certificates, but existing ones will be just fine. In fact, Root CAs are often kept offline as a best practice to limit their exposure.

EarthBound took a similar approach with it's anti-piracy measures if you work around the obvious ones. There are far, far more enemies to make the game less enjoyable. They also added random freezes when entering certain areas. If you managed got to the final boss despite everything else, it freezes and deletes your save.