A tiny, everyday phone feature briefly tripped our security systems this week. Here’s what it actually shows about how
closely we monitor and protect every school site.

This week, a handful of staff at some of the schools we host noticed their school website briefly hesitate to load, in several cases moments after someone had texted or iMessaged a colleague a link to the site to review a page they had created or edited. Every affected school’s website stayed live, active, and fully protected throughout.

What actually happened is a good, concrete illustration of just how far our security monitoring reaches, right down to spotting and resolving something this small and this unusual.

The cause was an everyday feature built into modern smartphones. When you share a website link in a text message on an iPhone or Android phone, the messaging app automatically builds a small preview card underneath it, the thumbnail with a title, an image, and a short description. To build that card, the messaging app quietly fetches the page in the background, before the message is even sent. For technical reasons that go back years in how these preview features were built, that background request represents itself as a well known type of automated web crawler, the kind used by search engines and social media platforms.

Why our systems are built to catch this sort of thing

Every school website we host sits behind layers of security with one layer that watch constantly for automated crawlers, scanners and scrapers trying to copy or extract content they should not harvest. This matters enormously for a school site specifically, because it is not only pages of text sitting there, it is policy documents, newsletters, photographs and images, often of pupils and school life, that need protecting from being harvested by tools with no legitimate reason to be touching them. Our systems are deliberately tuned to be alert/sensitive to exactly that kind of automated activity.

Because the phone’s link preview request presented an identity built to look exactly like one of those crawlers, our security systems correctly did their job. They flagged it and subsequently blocked it. In a small number of cases that meant a brief interruption to the wider connection the request came from, a direct sign of the system working exactly as designed, treating an unfamiliar automated request with appropriate caution.

Most schools operate with teachers using their wifi on both their computers and mobile phones. This means everyone presents to the website using the same IP address. Once this IP address is flagged and blocked by our security systems it means everyone from that IP is blocked temporarily from accessing any of our services. In the main this approach slams the door shut on bots, scanners and AI harvesting tools. This week the feature caught us out after the security tightening due to this seemingly innocuous feature in how mobile phones and Apple devices produce preview cards.

Apple’s own Messages app has been documented building its link previews this way since at least 2019, a pattern independent security researchers have continued to verify as recently as this year.

Yesterday we ran our own internal tests across our servers send URLs in iMessages and Text messages between Android and iPhones, Macbooks and iPads and replicated this behaviour in our logs with 100% success.

Why are messaging apps not just telling the website who they really are?

Most websites deliberately special-case a small list of “trusted” crawler identities. Site owners want Googlebot to index their pages, and they want Facebook’s and Twitter/X’s crawlers to fetch clean previews when someone shares a link, because that is good for their SEO and their social reach. So it is extremely common for a site’s bot-defences, rate limiters, Web Application Firewalls, anti-scraping tools, even paywalls, to explicitly allow those specific User Agents through unhindered, while treating anything unrecognised with suspicion (rate-limit it, block it, serve it a stripped-down page, throw a CAPTCHA at it). All this helps defend resource wastage on the servers so the website is there to serve legitimate requests and protect your data.

That creates a strong incentive for anyone building a link-preview feature to borrow one of those trusted identities rather than use their own. If Apple’s Messages team shipped their link-preview fetcher with its own honest User Agent like (AppleMessagesLinkPreview/1.0), it would hit exactly the kind of resistance real unknown bots run into on plenty of sites, rate limits, blocks, stripped content, inconsistent results. By presenting as facebookexternalhit/Twitterbot instead, it rides on trust that Facebook and Twitter/X have already effectively negotiated with the entire web, just by being big enough and old enough that most bot-defence systems allow them by default. It’s a pragmatic shortcut allowing reliable fetching of a page’s title/image/description from any website. Building a preview of a site becomes a hard problem if you present as an unknown identity, and trivially easy if you present as a known-trusted one. However, with the rise in bots around AI the amount of information scraping has increased significantly and our Web Application Firewall rules have had to move in line with harder sanctions on unknown user agents that could if left uncheck make websites unavailable/slow/unstable by requesting more resources than the system can server effectively block legitimate users from seeing their web pages.

Why have messaging systems used this user agent for so long and why has it spread?

Because it makes it easier to get around website defences to get the data they want. It is also partly just copy-pasted legacy code, not a fresh decision each time. The exact combined string, facebookexternalhit/1.1Facebot Twitterbot/1.0, has been documented since at least 2019 and keeps turning up verbatim across different tools and web development kits and in software development kits (SDKs). It looks like a template that got reused rather than something each developer independently chose to fabricate. Once one implementation proved it worked reliably, it likely got copied by others.

What this actually demonstrates

This is precisely the kind of small, unusual pattern that our ongoing monitoring is built to notice, however mundane the eventual explanation turns out to be. We traced it, reproduced it deliberately on real phones under controlled conditions to understand it completely, and refined our systems to recognise this specific everyday pattern going forward. That is the day-to-day reality of keeping a school website properly secure. It requires constant testing, constant probing of our own defences, and a willingness to dig into even the smallest anomaly until it is fully understood, not just seemingly resolved.

This anomaly is a useful reminder that strong security is not a one-off setup you complete and forget. It is an active, ongoing process, watching for new patterns, testing how systems respond to security scans and audit, and tightening things further whenever something like this arises. This particular pattern is now built into how we recognise legitimate phone activity fleet-wide, and every school site we host benefits from that immediately, not just the ones where it was first spotted.

What we are doing about it

We have refined how our security systems respond to this specific pattern so this particular everyday phone activity is recognised correctly going forward, while every layer of protection against scanning, scraping and malicious activity remains exactly as strong as before. We proved the fix the same way we found the issue, by reproducing it live on real phones and confirming the improved behaviour, before rolling it out across every school website application firewall we host.

If anything about your school website’s availability ever looks unusual, let us know. That is exactly the kind of small signal our monitoring is built to chase down, and if you report behaviour like this the stories build a picture for us and this is what keeps every school site we host actively protected. As with any good system we keep it simple. We operate a simple policy internally called See, Hear, Say. If you see something unusual or hear someone talking about an unusual behaviour on your website the best people to say it to is the tech team at iTCHYROBOT. We will log, track and trace the issue until we are content we understand, can explain and if needed add defences for everyone.