That seems like an important detail to have disclosed.
I would recommend changing the title of that post to be less provocative and to add supporting data to it with the caveats about the selection bias behind it. It sounds like there was a regression at some point and ⅓ is definitely high enough to warrant attention but as written it sounds like clickbait to say that storage isn't encrypted when the storage encryption system is disabled. Since FileVault has always been the answer to that question, this is really more about understanding that it is still necessary and should be checked.
> It sounds like there was a regression at some point
You are continually asserting incorrect information about this topic.
The behavior I describe where skipping iCloud setup causes FileVault setup screen to not be shown as always been the case. There has been no regression.
You're right about the skipped iCloud path — it's been too long since I've done that without automation (we use separate work iCloud accounts so it normally never comes up).
It doesn't really change the point, though, because this isn't a bypass or flaw in the encryption system but a gap in the initial setup flow. It's an important audit point and definitely good to surface for your customers but it's not exactly a surprise that if you don't enable storage encryption, you don't have encrypted storage. I know that there's a long history of attention-seeking blog posts from companies selling products but you're trying to make a reputation as an honest security company and I think that marketing is a key component of that.
> It doesn't really change the point, though, because this isn't a bypass or flaw in the encryption system
But it does. If what you stated earlier was actually the truth, then FileVault would be enabled on far more devices and your point about the post not really being as big of a deal as we are trumping it up to be would have some merit.
If we had written a blog post saying "Data on Encrypted iPhones can be trivially accessed unless a passcode is enabled", I would agree with your point because...
1) There is no historic context that Passcodes and encryption were considered the same thing.
2) There are no tools that confuse the differences between a passcode being set and encryption being on.
3) It is extremely difficult to set up an iPhone today without a passcode.
But none of those things are true on the Mac. Back in reality, a significant number of devices set up by organizations do not have FileVault enabled by default. Once you take that new fact into consideration and add the facts conveyed in the linked blog post and multiply it by tens of millions of Macs, you now have a high probability outcome that an organization will lose a device, act as if the contents are inaccessible to the thief, and learn later that the were acting on bad information.
It's a big deal to folks who could be caught up in the above scenario. We wrote the post for them.
> I know that there's a long history of attention-seeking blog posts from companies selling products
When you have something important to say, seeking attention is warranted. Just because we sell something doesn't mean it is correct to dismiss everything we say. HN is primarily a community of startups and hackers. Both are folks that may have found this content relevant.
We wrote this post because we have unique visibility into a substantive issue that requires educating MacAdmins about these differences so they don't get tripped up during an incident.
Tools like MunkiReport and Osquery are incredibly popular among these communities for collecting attestations about devices. This is especially true for shops who do not feel comfortable paying for a full MDM solution. The fact that these systems may cause admins to believe their devices have FileVault enabled, when in fact they do not, is a serious problem.
> but you're trying to make a reputation as an honest security company and I think that marketing is a key component of that
It's ok if we don't agree that this post is important or that the level of urgency is warranted (I think it's a super big deal, but I don't think I can convince you of that fact). That said, there is nothing dishonest happening here. We could have easily patched this issue for our customers, explained it only to them and moved on. We wrote the post because it's information we thought needed to be out there.
The error I made was assuming people knew that FileVault is not on by default in very common scenarios. We've amended the post which I think adds valuable context about that.
> We wrote this post because we have unique visibility into a substantive issue that requires educating MacAdmins about these differences so they don't get tripped up during an incident.
I agree — my point is simply that Apple has always said that you need to enable FileVault to protect against physical access to the device and that didn't change with the T2 or newer Mac hardware. The most interesting part here to me is the osquery improvement you contributed since that exposes a situation which became more nuanced than it used to be.
I'm entirely supportive of anything which spread the word that you really want to make sure you confirm that FileVault is enabled. My objection was to the title wording which made it sound like some promised functionality wasn't working was a distraction.
That seems like an important detail to have disclosed.
I would recommend changing the title of that post to be less provocative and to add supporting data to it with the caveats about the selection bias behind it. It sounds like there was a regression at some point and ⅓ is definitely high enough to warrant attention but as written it sounds like clickbait to say that storage isn't encrypted when the storage encryption system is disabled. Since FileVault has always been the answer to that question, this is really more about understanding that it is still necessary and should be checked.