{"slug": "harmblock-safest-smartphone-please-rotate-responsibly", "title": "HarmBlock+ Safest Smartphone: Please Rotate Responsibly", "summary": "Security researcher Paul Moore found that HarmBlock+, the AI content filter marketed as the core safety feature of HMD's Fuse children's phone, is architecturally incapable of delivering its promised protection and exposes children to significant risk. In a September 2025 finding, the Xplora-run backend allowed an attacker to change the password on any account by presenting an email address, because the one-time password gated only a password-entry screen and was never validated as single-use or account-bound; the platform was taken offline and SafeToNet, HMD, and Xplora issued no public statement. Moore also reported that HarmBlock+ is side-loaded rather than baked into firmware as claimed, and that pairing the parent app to the child's phone relies on the phone's IMEI number with no cryptography or secrets.", "body_md": "# HarmBlock+ World's Safest Smartphone: Please Rotate Responsibly.\n\n#### ** NSFW Warning **\n\nBack 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.\n\nThe law, technology and implementations were... flawed; I presented an [AI-generated video](https://www.telegraph.co.uk/business/2025/07/31/tech-secretary-peter-kyle-under-pressure-as-online-safety-a/?ref=paul.reviews) 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.\n\nThe 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.\n\nBut, what happens when safety isn't a reluctant add-on, but the entire selling point?\n\n## Premise\n\nIn August 2025, HMD launched the Fuse: a children's phone built around an AI content filter called HarmBlock, developed by [SafeToNet](https://safetonet.com/?ref=paul.reviews). 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\"\n\nThe device supposedly detects explicit and illegal harmful content, allows the parent/guardian to restrict app access and **track their child's live GPS location**.\n\nOver 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.\n\nWhat 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.\n\nGrab a coffee and let's dive in.\n\n## Findings\n\n### Change Any Parent's Password (September 2025)\n\nWe've all done it. A service asks for a password and your mind draws a blank.\n\nYou hit the \"forgot password\" button and receive a one-time password by email.\n\nA secure system ensures your OTP is:\n\n1. used just once.\n2. is actually yours.\n\nXplora's API (the company running the Harmblock backend) had no such check.\n\nThe 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.\n\nKeep 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.\n\nThis 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.\n\nI **strongly** advised everyone involved to have their entire platform thoroughly audited, though it's not clear if that ever happened.\n\n### \"HarmBlock+ is baked into the device, it cannot be disabled, bypassed or circumvented. It is the government of the device\"\n\nThe initial setup screen is an immediate red-flag.\n\nIf it's baked into firmware, why does a parent need to grant HarmBlock+ permissions to anything?\n\nIn 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.\n\n### Pairing with an HMD Fuse\n\nIn order to \"pair\" with the child's device, you must scan a QR code.\n\nI thought, somewhat naively, the QR code would be a unique, ephemeral secret which cryptographically tied the phone to the parent's guardian app.\n\nOh good lord, how wrong I was.\n\n**It's the phone's IMEI number.**\n\nNo cryptography, no secrets, no challenge/response mechanism... just a **predictable** IMEI which you can trivially calculate in seconds.\n\nIronically, 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.\n\nCrucially, it's a **static** non-secret.  No amount of factory resets can change it.  Remember that for later.\n\n#### What can you do with it?\n\nBecome the parent/guardian of any child, anywhere in the world... and neither they nor the parent would know.\n\nThere 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.\n\nRemember, this app provides **live** GPS coordinates of every child on the platform.\n\nThis wasn't a bug either. **This was by design.**\n\nUpon 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.\n\nAfter 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...\n\n\"It has not been hacked. Everything is safe and nothing to worry about. Rest be assured\", HMD Support, August 3rd 2026\n\nAt 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.\n\n### Who owns this IMEI?\n\nWhen you scanned the QR code, the app asked the API if the IMEI was valid/registered.\n\nInstead of a somewhat safe \"yes/no\" response, the API dutifully returned the child's full name and telephone number.\n\nBy simply registering, you've already leaked your child's live GPS location, name & telephone number.\n\nAn 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.\n\nAt this point, it's already a write-off in terms of safety... but that ignores the potential benefits which *may* still outweigh the risk.\n\nLet's look at HarmBlock itself.\n\nMeet Richard & Sharon Pursey, Directors at SafeToNet.\n\nWe'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\".\n\nBut, 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.\n\nIf the parent/child skips setup, it remains a standard smartphone.\n\n### \"Everything passes through HarmBlock AI\"\n\nBut that's not true either.\n\nI 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.\n\nThe Fuse has an explicit whitelist; 433 apps which are **not** scanned at all and cannot be removed from the whitelist.\n\nThey'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](https://www.theguardian.com/technology/2025/apr/14/risks-children-roblox-deeply-disturbing-researchers?ref=paul.reviews)!\n\nInitially, I thought this was dead code; an artifact of internal testing which someone forgot to remove... so I tested it.\n\nWikipedia:\n\nMicrosoft Word:\n\nI genuinely don't understand the point of a whitelist.\n\nThey've invested millions developing a supposedly sophisticated AI \"harm prevention\" system... then disabled it for 433 apps by default.\n\nThat'd be fine if parents were aware, but they claim it operates across the \"entire device, every app\" and cannot be bypassed.\n\nKids are clever. They'll often find new & ingenious ways to get around any obstacle.\n\nUnfortunately, the HMD Fuse is trivially easy to bypass.\n\n### Settings.txt - Let the child configure it\n\nThe application uses a file called settings.txt to store screen scanning intervals.\n\nBy default, it's every 1000ms or 1 second. That's fine.\n\nThe issue, is that settings.txt is accessible to the child & can be modified to increase the interval from 1 second... to infinity.\n\n### Settings.txt - No error handling\n\nThe application expects numbers, so let's give it a non-alphanumeric value.\n\n### Who needs permissions anyway?\n\nIncredibly, the application has no permissions.\n\nAny app on the device can trigger the \"setup completion\" screen, allowing the child to simply disable any/all protection.\n\n### Disable HarmBlock via ADB\n\nAlthough they've made a poor attempt to disable ADB, it's still possible to remove all protection with a single command.\n\nadb shell pm disable-user --user 0 com.hmdglobal.app.ksg\n\n### Disable HarmBlock via Google Find Hub\n\nWhen your child loses their device, you can use Google's native \"Find Hub\" app to safely factory reset/wipe your HMD Fuse.\n\nBut, so can your child.\n\nClick \"Factory reset\" and in a few minutes, the device is wiped completely.\n\nThis 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.\n\nYou'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.\n\n### Static RSA keys?!\n\nThe APK behind the Harmblock service contained **static** RSA keys, meaning they're identical across every device.\n\nOnce extracted, anyone can emulate any Fuse device, anywhere in the world.\n\nAs 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.\n\n### A Chinese root certificate authority\n\nThe device has a Chinese root CA from iHuatek - facilitating TLS traffic interception.\n\nThe password for the private key?\n\n\"Aa123456\"\n\nThey 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.\n\n### Passwords are MD5'd... at the client!\n\nMD5, deprecated in 2004, is entirely unsuitable for password hashing.\n\nDespite 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.\n\n### Password reset OTPs have no rate limiting.\n\nIf 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.\n\nAdmittedly, 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.\n\n### Password Reset Tokens Do Not Expire\n\nOnce 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.\n\n### API keys hard-coded in the APK\n\nProduction API keys in code?!\n\nThese were later changed... but it gives some insight into how the wider platform was developed.\n\nAs it turns out, the developers didn't use those constants anyway...\n\n### Just copy/paste!\n\nInstead of referencing those constants throughout the code, the developer simply copy/pasted them instead.\n\n## File Scanning\n\nWhen 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.\n\nThe AI then classifies the image and, if it's deemed harmful, quarantines it automatically.\n\nSounds great, in theory. The child \"can't save it, share it, view it\" etc... as per the marketing material.\n\nHowever, 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?\n\nYou guessed it. Any directory with a .name convention is ignored completely.\n\nSo the child can create a folder called \".porn\" and store whatever they like. There's nothing preventing them sharing it either.\n\n## Camera Scanning\n\nThe camera scanner works on the same premise; scan the picture for harm and if it's detected, block the camera with an overlay.\n\nHowever, it's sluggish and very fragile. If you happen to capture something harmful, you'd hope the file scanner would detect it afterwards.\n\n... and it does, unless you save it in .porn.\n\n## Screen Scanning\n\nHere's where it gets really interesting.\n\nIn order to test the screen scanner effectively, I extracted the AI model from the HMD Fuse and began synthetic testing using their own code.\n\nThe results were... mind-boggling. Suffice to say, the model's performance was so poor, I immediately began questioning my testing methodology.\n\nAt first glance, you'd be forgiven for thinking 15 false positives across 2000 test images is very good.\n\nLook closer.\n\nThe model has multiple output neurons, but only 4 actually respond in any meaningful way.\n\nThe **only two** used by the SDK are \"neutral\" shown in blue and \"NSFW\" in red.\n\nSpot the problem?\n\nWhilst 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.\n\nThe model/system has detected largely neutral/safe images, thus the majority of images pass as safe.\n\nBut, what happens if we test with 2000 NSFW images?\n\n1630 images blocked, 443 (21%) incorrectly categorized as safe.\n\nOnce again, the \"NSFW\" neuron output is basically fixed across all 2000 test images.\n\nIf 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?**\n\n## When all else fails, fresh tactics.\n\nI wasn't happy with those statistics; something didn't add up.\n\nEither the model was effectively broken, or my testing procedure was giving anomalous data.\n\nAs a result, I moved away from synthetic testing and pivoted toward a much simpler, cleaner approach.\n\n1. Load an image on the phone.\n2. Wait for the screenshot service to fire.\n3. Grab the logs, parse the \"neutral\" and \"porn\" outputs.\n4. Rinse, repeat.\n\nThat 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.\n\nThe astute amongst you will note, I said \"neutral\" and \"**porn**\" in #3, as opposed to \"NSFW\".\n\nThat's not a mistake. For whatever reason, the model labels them as \"neutral\" and \"NSFW\" but the SDK later reclassifies that output as \"porn\".\n\nThey're two entirely different concepts, but I digress.\n\nThe Harmblock SDK uses a \"softmax\" function.\n\nPut simply, a softmax function creates a competition between neutral & porn.\n\n**This is a very ineffective way to measure harm in this context.**\n\nIf you measure harm as a competition against neutral, a failure to recognise neutral makes everything look like harm.\n\nLet me put it another way...\n\nImagine 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.*”\n\nThe 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.\n\nIn 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.”\n\nIf 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.\n\n## Hang on a minute?!\n\nIf they've used a softmax function over **two** values, what happened to the claimed \"11 unique categories of harm\".\n\nHow can it possibly detect CSAM if the model doesn't output anything resembling a CSAM score?\n\nPut simply, it can't.\n\nThere are 11 outputs from the SDK.\n\n1. Neutral\n2. Porn\n3. Art\n4. CSAM\n5. Face\n6. Family\n7. Hands\n8. Hentai\n9. Pet\n10. Subjective\n11. Confidence\n\n### Hard-Coded Categories of Harm, including CSAM.\n\nSo how do you get 11 values when the system only uses 2?\n\nYou hard-code them!\n\nSeriously. Every single category of harm, including CSAM, is hard-coded to 0.\n\nNot \"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.\n\n### That still doesn't explain why our statistics are wildly different...\n\nMy synthetic tests replicated their exact model & code to the letter, yet my performance figures were off.\n\nThe results were mind-boggling. So much so, I had to rework the testbench and test the device itself.\n\n### Please Rotate Responsibly\n\nForget 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.\n\nThese 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.\n\nDid nobody think to try the \"world's safest phone\" in landscape too?!\n\nMore 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.\n\nThe above video is running on the actual device and shows how the orientation massively affects the confidence score.\n\nBut it's not clear how so few pixels, from an application overlay to the navigation buttons materially affect the confidence score.\n\nHere's a better example.\n\nTo 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.\n\nSuffice to say, it failed miserably.\n\nIt really doesn't like pumpkins. Ironically, it's not a fan of finger plasters either.\n\nRichard's explanation gives us an insight into how their model has been trained... and possibly explains the failure modes I've witnessed.\n\nWhilst 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.\n\nThe 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?\n\nThe 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.\n\nTake 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?\n\nIf 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.\n\nThis is an important distinction, and one which has perhaps eluded SafeToNet.\n\nNow, 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.\n\n## Quarantined Files\n\nThe quarantine section is a reasonable solution to inevitable false positives; giving the parent the ability to restore harmless images & more importantly, delete harmful ones.\n\n### \"Encryption\"\n\nWhen a file is quarantined, Harmblock encrypts it with AES-CBC and moves the file to a location inaccessible to the child.\n\nWhilst the cryptographic primitive is sound, the implementation is not.\n\nThere's no HMAC, thus no integrity whatsoever. But more importantly, the \"secret\" key they've used to protect the file is...\n\n**The IMEI number.**\n\nSomeone 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***.\n\nIt 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.\n\n### You're on your own, kid.\n\nNo model is perfect; false positives are a considered risk here. Both genuinely harmful images & false positives are quarantined automatically.\n\nBut what happens when the model fails to detect harmful content... a false negative?\n\nNothing.\n\nAlmost unbelievably, there's no mechanism for the child to protect themselves from content **they** deem harmful.\n\nThe entire safeguarding pathway depends on the model getting it right.\n\nThat's quite the omission in a child-safety device.\n\n### Pre-computed Recovery Paths\n\nWhen 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.\n\nNope.\n\nThe entire quarantine system works on paths/filenames.\n\nIf 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.\n\nYou can guess where this is going...\n\nNow, an attacker (or the child) can download any pornographic image to /storage/flowers.jpg and the file scanner dutifully ignores it.\n\nSigh. What a farce.\n\nBut 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*\".\n\n### Pre-computed Recovery Paths - No error checking\n\nMuch like the settings.txt vulnerability earlier, there's no defensive code here either.\n\nCreate a file with an invalid character in recovery_map.json and the scanner crashes completely, never to return.\n\n## Service Restored - Ignore the Security Warning\n\nWhen the service came back online on September 10th 2026, users were greeted with this.\n\nSuch 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.\n\nThey're teaching parents to skip security warnings... on a child safety device?! What could go wrong.\n\n## An indefensible legal problem?\n\nRemember, HarmBlock is marketed as detecting and blocking harmful content, including CSAM.\n\nYet, 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.\n\nLet me explain the flow, step by step.\n\n1. An image lands on the device.\n2. The file-system scanner detects it and apparently classifies it.\n3. The quarantine mechanism removes the original, **creates a separate copy** and encrypts that copy using a key derived from the device's IMEI.\n4. That quarantined copy remains on the device for up to 30 days before automatic deletion.\n\nNow consider what happens if the image isn't merely pornography, but an indecent image of a child.\n\nUK 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**.\n\nWhilst 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.\n\nBut that makes the absence of an apparent safeguarding pathway even more important.\n\nIf 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.\n\nWhat 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.\n\nDetection 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.\n\n## Who cares? We care.\n\nI have to give massive credit to VodafoneThree for their response.\n\nI 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.\n\nThat was a month ago... so I asked VodafoneThree for comment.\n\nI'm slightly concerned to hear they've \"paused sales\", which suggests it may return... though I honestly can't see that happening.\n\nI also asked the Internet Watch Foundation (IWF) for comment.\n\n## Summary\n\nChild safety is a complex, nuanced & emotive topic. Technical solutions like these require our utmost attention & due diligence to ensure they deliver on their promises.\n\nWe desperately need more independent research to highlight material failures in basic governance, safety, security & accountability.\n\nIf you/your child still has one of these devices, you can return them as \"unfit for purpose\".\n\nFurthermore, 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).\n\nDo not simply throw your device away or stop using it.  You **must** ensure you/your child's information has been expunged entirely.", "url": "https://wpnews.pro/news/harmblock-safest-smartphone-please-rotate-responsibly", "canonical_source": "https://paul.reviews/harmblock-worlds-safest-smartphone-please-rotate-responsibly/", "published_at": "2026-09-23 03:24:51+00:00", "updated_at": "2026-09-23 03:54:00.097850+00:00", "lang": "en", "topics": ["ai-safety", "ai-products", "ai-ethics", "artificial-intelligence"], "entities": ["HarmBlock+", "HMD", "HMD Fuse", "SafeToNet", "Xplora", "Paul Moore", "Online Safety Act", "Peter Kyle"], "alternates": {"html": "https://wpnews.pro/news/harmblock-safest-smartphone-please-rotate-responsibly", "markdown": "https://wpnews.pro/news/harmblock-safest-smartphone-please-rotate-responsibly.md", "text": "https://wpnews.pro/news/harmblock-safest-smartphone-please-rotate-responsibly.txt", "jsonld": "https://wpnews.pro/news/harmblock-safest-smartphone-please-rotate-responsibly.jsonld"}}