HarmBlock+ World's Safest Smartphone: Please Rotate Responsibly.

** NSFW Warning **

Back in July 2025, the Online Safety Act was a hot topic. Many sites were frantically adding age verification under threat of criminal prosecution, if they failed to protect children from online harm.

The law, technology and implementations were... flawed; I presented an AI-generated video of the-then Technology Secretary, Peter Kyle, in order to skip intrusive censorship. That turned out to be unnecessary, as a smiley face drawn on a thumb also bypassed the "robust" verification process.

The general public (and the media) were quick to condemn the technology. In reality, these failures were largely caused by companies wanting to appear compliant with little/no impact on their financials.

But, what happens when safety isn't a reluctant add-on, but the entire selling point?

Premise

In August 2025, HMD launched the Fuse: a children's phone built around an AI content filter called HarmBlock, developed by SafeToNet. It scans photos on-device and quarantines anything harmful before the child sees it. No cloud uploads, no privacy trade-off. It's marketed as "the world's safest phone"

The device supposedly detects explicit and illegal harmful content, allows the parent/guardian to restrict app access and track their child's live GPS location.

Over the last 12 months, I've examined every layer of their security/privacy/safety claims: the AI model, the apps, the quarantine system, the file scanner, the camera integration, the backend API, and the code that ties it all together.

What I found is not a product that needs refinement. It is a product whose defining feature, the one on the box and in every press interview, is architecturally incapable of doing what it claims... whilst putting every child at significant risk.

Grab a coffee and let's dive in.

Findings

Change Any Parent's Password (September 2025)

We've all done it. A service asks for a password and your mind draws a blank.

You hit the "forgot password" button and receive a one-time password by email.

A secure system ensures your OTP is:

1. used just once.
2. is actually yours.

Xplora's API (the company running the Harmblock backend) had no such check.

The OTP simply gated access to a password entry/confirmation screen which, upon changing the email address, allowed an attacker to change the password for any/all accounts on the platform.

Keep in mind, they didn't notify the parent/guardian that their password had been changed. The attacker effectively became the guardian of any account, simply by presenting an email address.

This flaw (along with others) prompted the system to be taken offline for the first time in 2025. To my knowledge, nobody involved (SafeToNet/HMD/Xplora) put out a public statement.

I strongly advised everyone involved to have their entire platform thoroughly audited, though it's not clear if that ever happened.

"HarmBlock+ is baked into the device, it cannot be disabled, bypassed or circumvented. It is the government of the device"

The initial setup screen is an immediate red-flag.

If it's baked into firmware, why does a parent need to grant HarmBlock+ permissions to anything?

In reality, it's not baked into firmware in the way they claim. It's effectively side-loaded, just like any other application. This seems like trivial nit-picking at first, but you'll soon see why this matters.

Pairing with an HMD Fuse

In order to "pair" with the child's device, you must scan a QR code.

I thought, somewhat naively, the QR code would be a unique, ephemeral secret which cryptographically tied the phone to the parent's guardian app.

Oh good lord, how wrong I was.

It's the phone's IMEI number.

No cryptography, no secrets, no challenge/response mechanism... just a predictable IMEI which you can trivially calculate in seconds.

Ironically, someone in post-production blurred the QR code in the demo to keep it a secret; unaware the value isn't a secret in the first place. It's on the box, shown in pictures of ebay listings, sent across various networks, in several databases and used as identifiers across many mobile apps.

Crucially, it's a static non-secret. No amount of factory resets can change it. Remember that for later.

What can you do with it?

Become the parent/guardian of any child, anywhere in the world... and neither they nor the parent would know.

There is no "pairing" mechanism in the typical sense. You simply ask the API for access to a phone and it hands it over. It doesn't even need to be powered on, or even sold.

Remember, this app provides live GPS coordinates of every child on the platform.

This wasn't a bug either. This was by design.

Upon reporting this to HMD, the platform was taken offline immediately on July 8th 2026 and remained as such until September 10th 2026. No announcement, no public statement... just "offline for maintenance", according to the app.

After a few weeks, parent's understandably started complaining and asking questions; one of which had seen my many tweets and asked HMD if the system had been breached & was there any risk...

"It has not been hacked. Everything is safe and nothing to worry about. Rest be assured", HMD Support, August 3rd 2026

At which point, the app was updated to reflect the fact it had been down for a few weeks due to "a technical issue". It's not clear who decided upon that vague wording, but it's not exactly transparent.

Who owns this IMEI?

When you scanned the QR code, the app asked the API if the IMEI was valid/registered.

Instead of a somewhat safe "yes/no" response, the API dutifully returned the child's full name and telephone number.

By simply registering, you've already leaked your child's live GPS location, name & telephone number.

An attacker can reset your password without your knowledge, to become the guardian of your child... or simply "pair" with your child's device to take full control over it.

At this point, it's already a write-off in terms of safety... but that ignores the potential benefits which may still outweigh the risk.

Let's look at HarmBlock itself.

Meet Richard & Sharon Pursey, Directors at SafeToNet.

We've already established it's not truly embedded into the device, but they seem to believe it's "safe the moment it's switched on".

But, that's not true. Out of the box, the HMD Fuse is a standard smartphone. If you factory reset it, it reverts to being a standard smartphone. The parent must go through a fairly lengthy setup process in order to turn any protection on.

If the parent/child skips setup, it remains a standard smartphone.

"Everything passes through HarmBlock AI"

But that's not true either.

I think there's been a substantial breakdown in communication between HMD and SafeToNet here. While SafeToNet's product can absolutely work across every application on the device, that's not the case on the HMD Fuse.

The Fuse has an explicit whitelist; 433 apps which are not scanned at all and cannot be removed from the whitelist.

They're not outliers either. Wikipedia, ChatGPT and unbelievably, the Microsoft Office suite... exactly the applications a child will likely install & use at school. Even Roblox is whitelisted!

Initially, I thought this was dead code; an artifact of internal testing which someone forgot to remove... so I tested it.

Wikipedia:

Microsoft Word:

I genuinely don't understand the point of a whitelist.

They've invested millions developing a supposedly sophisticated AI "harm prevention" system... then disabled it for 433 apps by default.

That'd be fine if parents were aware, but they claim it operates across the "entire device, every app" and cannot be bypassed.

Kids are clever. They'll often find new & ingenious ways to get around any obstacle.

Unfortunately, the HMD Fuse is trivially easy to bypass.

Settings.txt - Let the child configure it

The application uses a file called settings.txt to store screen scanning intervals.

By default, it's every 1000ms or 1 second. That's fine.

The issue, is that settings.txt is accessible to the child & can be modified to increase the interval from 1 second... to infinity.

Settings.txt - No error handling

The application expects numbers, so let's give it a non-alphanumeric value.

Who needs permissions anyway?

Incredibly, the application has no permissions.

Any app on the device can trigger the "setup completion" screen, allowing the child to simply disable any/all protection.

Disable HarmBlock via ADB

Although they've made a poor attempt to disable ADB, it's still possible to remove all protection with a single command.

adb shell pm disable-user --user 0 com.hmdglobal.app.ksg

Disable HarmBlock via Google Find Hub

When your child loses their device, you can use Google's native "Find Hub" app to safely factory reset/wipe your HMD Fuse.

But, so can your child.

Click "Factory reset" and in a few minutes, the device is wiped completely.

This is not only native functionality to all certified Android devices, it cannot be removed/disabled without losing that certification. That means losing access to the Play store and rendering the phone basically useless.

You'll recall, the device is a standard smartphone out of the box. To make matters worse, the parent is none the wiser. The Fuse still shows up in the Guardian app, but now the data is stale. Their GPS doesn't update, you can no longer enable/disable apps - that link has been severed by a child doing nothing other than factory resetting their own phone.

Static RSA keys?!

The APK behind the Harmblock service contained static RSA keys, meaning they're identical across every device.

Once extracted, anyone can emulate any Fuse device, anywhere in the world.

As a proof of concept, I created a NodeJS application which presented itself to the API as a Fuse I didn't own/possess. The API diligently updated its records, showing the device at the Eiffel Tower one moment, then back in the UK seconds later.

A Chinese root certificate authority

The device has a Chinese root CA from iHuatek - facilitating TLS traffic interception.

The password for the private key?
"Aa123456"

They don't appear to be doing anything more than SNI inspection, but quite why there's a Chinese CA on a child safety device is beyond me.

Passwords are MD5'd... at the client!

MD5, deprecated in 2004, is entirely unsuitable for password hashing.

Despite the world moving away from it 22 years ago, Xplora (the HarmBlock+ backend) used MD5... in the client app of a child safety platform! No salts either, so every password hashed to the same output.

Password reset OTPs have no rate limiting.

If you initiated a password reset, the resulting 6 digit OTP had no rate limiting whatsoever. As a result, an attacker could send all 1 million possibilities to the API in just 42 seconds and gain access to any account.

Admittedly, this required a reasonable amount of effort which, upon further inspection, turned out to be entirely unnecessary as you could change anyone's password without the OTP.

Password Reset Tokens Do Not Expire

Once a valid reset token had arrived in your inbox, it never expires... even after your password had changed. Anyone, at any time thereafter, could use the same link to change the parent/guardian's password once again.

API keys hard-coded in the APK

Production API keys in code?!

These were later changed... but it gives some insight into how the wider platform was developed.

As it turns out, the developers didn't use those constants anyway...

Just copy/paste!

Instead of referencing those constants throughout the code, the developer simply copy/pasted them instead.

File Scanning

When you copy a file to the HMD Fuse, or someone sends it via a messaging app, it hits the file system and triggers the file scanning service.

The AI then classifies the image and, if it's deemed harmful, quarantines it automatically.

Sounds great, in theory. The child "can't save it, share it, view it" etc... as per the marketing material.

However, it works by scanning files which are indexed by Android. But what happens if the file is in a directory path which isn't indexed, by design?

You guessed it. Any directory with a .name convention is ignored completely.

So the child can create a folder called ".porn" and store whatever they like. There's nothing preventing them sharing it either.

Camera Scanning

The camera scanner works on the same premise; scan the picture for harm and if it's detected, block the camera with an overlay.

However, it's sluggish and very fragile. If you happen to capture something harmful, you'd hope the file scanner would detect it afterwards.

... and it does, unless you save it in .porn.

Screen Scanning

Here's where it gets really interesting.

In order to test the screen scanner effectively, I extracted the AI model from the HMD Fuse and began synthetic testing using their own code.

The results were... mind-boggling. Suffice to say, the model's performance was so poor, I immediately began questioning my testing methodology.

At first glance, you'd be forgiven for thinking 15 false positives across 2000 test images is very good.

Look closer.

The model has multiple output neurons, but only 4 actually respond in any meaningful way.

The only two used by the SDK are "neutral" shown in blue and "NSFW" in red.

Spot the problem?

Whilst the "neutral" neuron varies as you'd expect, the "NSFW" neuron is basically fixed at 0.065; so slight, it doesn't show up on a graph.

The model/system has detected largely neutral/safe images, thus the majority of images pass as safe.

But, what happens if we test with 2000 NSFW images?

1630 images blocked, 443 (21%) incorrectly categorized as safe.

Once again, the "NSFW" neuron output is basically fixed across all 2000 test images.

If the NSFW neuron isn't moving from an effectively fixed baseline, the model isn't detecting harm. If it's not detecting harm, how does it work?

When all else fails, fresh tactics.

I wasn't happy with those statistics; something didn't add up.

Either the model was effectively broken, or my testing procedure was giving anomalous data.

As a result, I moved away from synthetic testing and pivoted toward a much simpler, cleaner approach.

1. Load an image on the phone.
2. Wait for the screenshot service to fire.
3. Grab the logs, parse the "neutral" and "porn" outputs.
4. Rinse, repeat.

That way, there's no possible way I'm misinterpreting data. I'm literally watching a physical device load neutral/porn images and collecting massive (and I mean massive) amounts of data.

The astute amongst you will note, I said "neutral" and "porn" in #3, as opposed to "NSFW".

That's not a mistake. For whatever reason, the model labels them as "neutral" and "NSFW" but the SDK later reclassifies that output as "porn".

They're two entirely different concepts, but I digress.

The Harmblock SDK uses a "softmax" function.

Put simply, a softmax function creates a competition between neutral & porn.

This is a very ineffective way to measure harm in this context.

If you measure harm as a competition against neutral, a failure to recognise neutral makes everything look like harm.

Let me put it another way...

Imagine a dog that barks at everyone it doesn't recognise. You could reasonably say, “My dog barks at people he doesn't recognise.” But you couldn't reasonably conclude, “My dog barks at burglars 100% of the time.”

The dog has no knowledge or understanding of what a burglar is. It is simply reacting to unfamiliarity, and occasionally a burglar will be among the people it barks at.

In deliberately simplified terms, that's the failure mode I'm seeing with HarmBlock. It doesn't look like “detect harm” so much as “if this doesn't look sufficiently like what I know to be neutral, increase the NSFW score.”

If you test the model directly with raw images, this becomes much easier to see. If you test the complete pipeline, including the softmax transformation, the distinction can be surprisingly easy to miss, even if you're looking at the system professionally.

Hang on a minute?!

If they've used a softmax function over two values, what happened to the claimed "11 unique categories of harm".

How can it possibly detect CSAM if the model doesn't output anything resembling a CSAM score?

Put simply, it can't.

There are 11 outputs from the SDK.

1. Neutral
2. Porn
3. Art
4. CSAM
5. Face
6. Family
7. Hands
8. Hentai
9. Pet
10. Subjective
11. Confidence

Hard-Coded Categories of Harm, including CSAM.

So how do you get 11 values when the system only uses 2?

You hard-code them!

Seriously. Every single category of harm, including CSAM, is hard-coded to 0.

Not "no data", not "coming soon"... the SDK gives the impression the model has output 0. In reality, there was never any value to pass on... so it spoofs it.

That still doesn't explain why our statistics are wildly different...

My synthetic tests replicated their exact model & code to the letter, yet my performance figures were off.

The results were mind-boggling. So much so, I had to rework the testbench and test the device itself.

Please Rotate Responsibly

Forget how accurate the model is, even if it classifies an image as harmful, my testing shows a 70% chance that rotating the phone collapses the confidence level to such an extent, the harmful image reappears.

These aren't isolated cases either. I ran the exact same corpus through the revised testbench... and the figures deviated by 2%, or within the margin of error.

Did nobody think to try the "world's safest phone" in landscape too?!

More to the point, why does the application (files/photos) affect the result so dramatically? It's almost as if they've trained it not to recognise harm, but to recognise exceptions from normal.

The above video is running on the actual device and shows how the orientation massively affects the confidence score.

But it's not clear how so few pixels, from an application overlay to the navigation buttons materially affect the confidence score.

Here's a better example.

To test my (admittedly wild) theory, I hit the model with thousands upon thousands of bizarre images. None of them NSFW in any measurable way, but sufficiently random to confuse a model looking not for harm, but deviations from normality.

Suffice to say, it failed miserably.

It really doesn't like pumpkins. Ironically, it's not a fan of finger plasters either.

Richard's explanation gives us an insight into how their model has been trained... and possibly explains the failure modes I've witnessed.

Whilst there's nothing inherently wrong with hard-negative training to an extent, it's designed to help a model better understand the boundary between harm and harmless content. If the response to every false positive is simply to add more instances as “neutral”, the process progressively teaches the model what isn't harmful without proportionally strengthening its understanding of what is.

The correct question is to ask what about the false-positive image did the model consider harmful? Was it the lighting, exposure, angle, composition, or, in this particular case, something as simple as an elongated shape?

The negative class isn't supposed to become the thing the model primarily understands. Otherwise, you risk ending up with a model trained to identify exceptions from a rule, rather than harm itself.

Take that last image in particular. The model assigned it a 52% NSFW probability, enough to trigger the block. If we cannot reasonably identify what characteristics of the image constitute evidence of harm, that should trigger an uncomfortable question: have we collapsed to a bias? Has the model stopped learning “harmful” in any useful sense, and instead learned what does not look sufficiently neutral?

If you're not careful, you create an exception-driven training loop: every false positive becomes another exception to teach the model, rather than an opportunity to understand why it failed to recognise harm. You're treating the symptom, not the cause.

This is an important distinction, and one which has perhaps eluded SafeToNet.

Now, I can't point the finger squarely at Richard Pursey here. His passion clearly exceeds his technical knowledge, by his own admission. But when the person promoting the technology openly acknowledges that the model “blocks strange & spurious things”, that should ring alarm bells. “Spurious” isn't a technical explanation for a false positive. It's a description of the failure. The question is whether the people building the system understand why it happens.

Quarantined Files

The quarantine section is a reasonable solution to inevitable false positives; giving the parent the ability to restore harmless images & more importantly, delete harmful ones.

"Encryption"

When a file is quarantined, Harmblock encrypts it with AES-CBC and moves the file to a location inaccessible to the child.

Whilst the cryptographic primitive is sound, the implementation is not.

There's no HMAC, thus no integrity whatsoever. But more importantly, the "secret" key they've used to protect the file is...

The IMEI number.

Someone thought they were being smart running it through PBKDF2 at 10,000 iterations, with a fixed salt of "HarmBlockFixedSalt" - but PBKDF2 is supposed to make brute-force attacks computationally infeasible against a secret.

It also has a faint whiff of someone who Google'd "how to encrypt files on Android" and copied the first result from 2015. 10,000 iterations was fine, in 2015. In 2026, the recommended minimum is 600,000. But again, nobody is brute-forcing a value printed on the box... they're just burning CPU cycles whilst pretending it adds security.

You're on your own, kid.

No model is perfect; false positives are a considered risk here. Both genuinely harmful images & false positives are quarantined automatically.

But what happens when the model fails to detect harmful content... a false negative?

Nothing.

Almost unbelievably, there's no mechanism for the child to protect themselves from content they deem harmful.

The entire safeguarding pathway depends on the model getting it right.

That's quite the omission in a child-safety device.

Pre-computed Recovery Paths

When Harmblock quarantines a file, you'd be forgiven for thinking it digests the image, runs a complex hashing algorithm across it and makes damn sure it never shows a harmful image again.

Nope.

The entire quarantine system works on paths/filenames.

If a harmless image is quarantined as /storage/flowers.jpg and a parent subsequently restores it, it creates a file called recovery_map.json which whitelists /storage/flowers.jpg from the file scanner.

You can guess where this is going...

Now, an attacker (or the child) can download any pornographic image to /storage/flowers.jpg and the file scanner dutifully ignores it.

Sigh. What a farce.

But because the recovery_map.json file is stored on external storage, you can simply create a file in advance, with all the pornographic images "restored".

Pre-computed Recovery Paths - No error checking

Much like the settings.txt vulnerability earlier, there's no defensive code here either.

Create a file with an invalid character in recovery_map.json and the scanner crashes completely, never to return.

Service Restored - Ignore the Security Warning

When the service came back online on September 10th 2026, users were greeted with this.

Such was the rush to get this back into service, their instructions explicitly tell users to ignore Google's security warning and install the update anyway.

They're teaching parents to skip security warnings... on a child safety device?! What could go wrong.

An indefensible legal problem?

Remember, HarmBlock is marketed as detecting and blocking harmful content, including CSAM.

Yet, based on the code, there appears to be no separate safeguarding pathway for content that falls into the most serious category. Instead, potentially harmful imagery appears to enter the same quarantine mechanism.

Let me explain the flow, step by step.

1. An image lands on the device.
2. The file-system scanner detects it and apparently classifies it.
3. The quarantine mechanism removes the original, creates a separate copy and encrypts that copy using a key derived from the device's IMEI.
4. That quarantined copy remains on the device for up to 30 days before automatic deletion.

Now consider what happens if the image isn't merely pornography, but an indecent image of a child.

UK law treats the making and possession of indecent images of children extremely seriously. “Making” has been interpreted broadly and includes creating an electronic copy of an image.

Whilst there are specific legal protections for people who necessarily make copies in order to prevent, detect or investigate crime or report suspected child-abuse material, that doesn't apply here. SafeToNet explicitly states "no data ever leaves the device" and although that's technically not true either, they make no attempt to notify the parent or authorities when an obvious CSAM image is detected.

But that makes the absence of an apparent safeguarding pathway even more important.

If the system has positively identified material as CSAM, what is the legal/moral reasoning behind creating a second encrypted copy, retaining it for 30 days, and making it available for subsequent parental review? Once you become the digital custodian of CSAM and control access to it, you're likely in severe legal hot water.

What happens when a parent opens the quarantine and the device displays the suspected CSAM to them? The application has literally disseminated material it knows is CSAM... and asks the parent to decide on an appropriate course of action.

Detection is not the end of the safeguarding process. It is the point at which the safeguarding process should begin. If your child is actively being groomed, the HMD Fuse is diligently clearing up the evidence every 30 days.

Who cares? We care.

I have to give massive credit to VodafoneThree for their response.

I notified the CEO, who promptly put me in touch with a senior executive. Within hours, the product had been quarantined from their websites; swift & decisive action. How refreshing.

That was a month ago... so I asked VodafoneThree for comment.

I'm slightly concerned to hear they've "paused sales", which suggests it may return... though I honestly can't see that happening.

I also asked the Internet Watch Foundation (IWF) for comment.

Summary

Child safety is a complex, nuanced & emotive topic. Technical solutions like these require our utmost attention & due diligence to ensure they deliver on their promises.

We desperately need more independent research to highlight material failures in basic governance, safety, security & accountability.

If you/your child still has one of these devices, you can return them as "unfit for purpose".

Furthermore, I would strongly advise everyone to submit a subject access request (SAR) to HMD (and/or SafeToNet/Xplora where necessary) to see if you've been affected by any of these vulnerabilities. Keep in mind, your logs will contain potentially sensitive information and should be handled appropriately; encrypted at source, shared securely and crucially... deleted upon closure of your account (right to erasure).

Do not simply throw your device away or stop using it. You must ensure you/your child's information has been expunged entirely.