Facebook is a company that engages in unethical behaviour. Its ubiquity and its necessity for many people’s social lives undermines people’s ability to meaningfully grant or withhold their consent to its policies.

I take no pride in seeing this coming in 2010, and I have refused to use any of their services consistently since.

So I was surprised, to say the least, when I sent a link over iMessage that I knew would be unique, but saw a request being made for it by the facebookexternalhit/1.1 bot user agent. This URL should not have ever been seen by anyone but me and the recipient. I took the time to verify that the only access to this URL was by myself and the recipient.

“GET /some-secret-url HTTP/1.1” 200 – “” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/601.2.4 (KHTML, like Gecko) Version/9.0.1 Safari/601.2.4 facebookexternalhit/1.1 Facebot Short-Form “Bird” Social Media Site Before It Went Terriblebot/1.0″

It turned out that the facebookexternalhit/1.1 request (also identifying as Short-Form “Bird” Social Media Site Before It Went Terriblebot!) was issued by the same IP address that I had. How could I be a Facebook/Short-Form “Bird” Social Media Site Before It Went Terrible bot? How could it be that some Facebook code was running in my network? (I’m pretty particular in blocking large numbers of domains relating to Facebook properties.)

It turns out that this message preview in iMessage seems to make a request for the URL using this user agent string. It doesn’t identify itself as iMessage in the user agent string at all!

I’m satisfied that I answered the question — and indeed I understand the nature of user agent strings and how everybody pretends to be something else for compatibility. I expect a service to add to the user agent string, though. Chrome pretends to be Safari, which pretends to be “like Gecko”, which pretends to be “Mozilla/5.0”.

So why can’t iMessage add “iMessageLinkPreview/1.0” or something to the user agent string?

So, the iOS 12.1.4 and MacOS Mojave 10.14.3 Supplemental updates are out, fixing Grant Thompson’s reported FaceTime groups bug. You know, the one that turned your device into a listening device…

(It’s at least something that Apple acknowledged that the reporting process for security issues from non-developers needs to be improved.)

I note that one of the other security fixes in this release is explained as follows:

Live Photos in FaceTime Available for: iPhone 5s and later, iPad Air and later, and iPod touch 6th generation

Impact: A thorough security audit of the FaceTime service uncovered an issue with Live Photos

Description: The issue was addressed with improved validation on the FaceTime server.

CVE-2019-7288: Apple

APPLE-SA-2019-2-07-1 iOS 12.1.4

It’s good that they thought it wise to do a thorough audit on the rest of FaceTime, but why is this bug so poorly explained? “Uncovered an issue”? Of what scope? Of what severity?

Perhaps security issues Apple discovers internally don’t get disclosed, to provide an additional layer of obscurity if they believe others aren’t yet aware of them? Perhaps this is a server-side bug only? (But if it is, why note it in the client OS release?)

It is an unusual practice (even for a company as secretive as Apple) to provide a line and a CVE reference and so on, but not give any detail at all in the public release notes.