Proton is now hosting its own version of a researcher’s map of more than 300,000 Flock Safety surveillance devices, after a trademark complaint filed for Flock sought to get the original taken down. The case shows how researchers who publish what a vendor left exposed can face legal pressure afterwards, and it is a useful test of how UK hacking law would treat the same work.
What happened
This week Swiss privacy firm Proton began hosting a searchable map of Flock Safety devices across the United States. Proton says it is mirroring an inventory compiled by independent security researcher Joshua Michael and does not host or distribute his underlying dataset.
Michael launched his own Flock Surveillance Map on 23 September. The next day Doppel, a brand-protection firm acting for Flock, filed a trademark-infringement complaint to get it removed. The Intercept first reported the complaint, which argued that the site’s use of the “FLOCK SAFETY” name, even in a disclaimer saying the site had no connection to the company, could confuse customers. In a 25 September update, Michael said Flock had also threatened to sue him in a cease-and-desist letter, and had told customers it had notified law enforcement.
Proton’s head of legal, Marc Loebekken, called the takedown attempts “frivolous”, according to Cybernews. Michael has said he will not be censored through what he calls lawfare. Proton argues that, without a Swiss court order, a foreign takedown demand has little practical reach; that is Proton’s legal position, and no court has ruled on it in this dispute.
The technical picture
In November 2025, Michael noticed that one of Flock’s web properties would issue an access token to any visitor, without a login. That token was accepted by ArcGIS, the Esri mapping service behind Flock’s device-location records, which he could then query directly. He took a snapshot of the inventory in December 2025, and the exposure appears to have been closed around then.
The snapshot lists more than 170,000 cameras and roughly 130,000 other units, including acoustic detectors, processing hardware and networking kit. Flock has publicly cited about 120,000 cameras. Proton notes the data is frozen at December 2025. The gap may reflect different counting methods, but Hardware Busters reports that The Intercept found a camera at each of six random Arizona locations it checked.
The disclosure itself was bumpy. Michael says he contacted Flock three times from 13 November. Flock acknowledged the report on 20 November, said it was triaging internally, and then went quiet, according to The Intercept. Flock has since insisted in public that it was never hacked and that nothing leaked. CyberInsider reports a more nuanced account in Flock’s notice to customers. It said it closed the access path and at first found no evidence of unauthorised access, but a later investigation found anomalous activity involving the token. Flock says its forensic work showed customer data was unaffected.
Why it matters for UK organisations
This is my analysis: the Flock case is a clean example of the legal grey zone UK researchers have worked in for decades. In the US, the dispute so far has been about trademark and reputation. In the UK, an obvious question would be section 1 of the Computer Misuse Act 1990, which makes it an offence to cause a computer to perform a function intending to secure access the person knows is unauthorised.
The Act has no statutory defence for good-faith security research. Whether pulling data with a token that a vendor handed out publicly counts as “unauthorised” is a point UK courts have not clearly settled for this kind of case. A researcher can argue an unauthenticated public endpoint is implicitly authorised; a vendor can argue authorisation turns on the owner’s intent, not the weakness of the control. That uncertainty is what makes threat letters effective.
Ministers have said that reforming the Act is a priority. In September, Computer Weekly reported, the government rejected a Lords amendment to the Cyber Security and Resilience Bill seeking a review of a statutory defence for cyber professionals, saying reform would come when parliamentary time allows. No draft defence or timetable has been published. Until one is, UK researchers who find exposed data rely on the target’s goodwill, the discretion of police and prosecutors, and whatever safe harbour the organisation’s vulnerability disclosure policy offers.
For UK organisations running number plate recognition, CCTV or IoT platforms with cloud back ends, the lesson is that your response to a report decides whether the next one arrives privately or on a public map.
Expert view
In my experience, an access token that anyone can get without credentials is about as basic as exposures get. What stands out is how the response escalated from silence to a trademark complaint to a legal threat, while the company publicly insisted nothing had leaked.
That approach rarely works. A takedown can remove one website, but it cannot make a dataset unknown once it has been verified on the ground and cited publicly. Threatening the researcher turns a quiet fix into a public story about how the vendor treats disclosure, which does more damage than the flaw.
When we test organisations, the ones that handle reports well share a few traits. They publish a clear vulnerability disclosure policy with explicit safe-harbour wording. They have a named owner for triage. They give the reporter regular updates. And they decide in advance that legal action is a last resort reserved for clear bad faith. None of that needs new legislation, just a senior decision that an unsolicited report is a favour.
What to do now
- Publish or review your vulnerability disclosure policy. Include a security.txt file, a clear scope, response times and explicit wording that you will not pursue good-faith reporters who follow the policy. The NCSC’s Vulnerability Disclosure Toolkit is a sensible starting point.
- Hunt for tokens that need no login. Review public web front ends, mobile apps and mapping or GIS integrations for API keys and tokens issued before authentication. Scope them to the minimum data and set them to expire. This sits under Cyber Essentials secure configuration and access control.
- Question suppliers. Ask providers of plate recognition, CCTV and IoT services how their back ends are authenticated and whether they run a disclosure programme.
- Agree a response playbook before you need one. Decide who triages reports, how quickly you reply, when legal and communications teams get involved, and what bar has to be met before anyone sends a threat letter.
- Check your logging. Make sure API and data back-end access is logged and reviewed, so you can tell whether an exposed token was used.
- If you are a researcher in the UK, stay within a published policy where one exists, keep data collection to the minimum needed to prove impact, record your steps, and take legal advice before publishing data you retrieved.
Bottom line
Flock’s exposure was trivial and its legal response was not. For UK organisations, the takeaway is to fix exposed tokens quickly and treat reporters as allies. For UK researchers, the case is a reminder that until the Computer Misuse Act gains a real research defence, the law protects you less than the vendor’s goodwill does.
Sources
- Proton: Flock camera map – find the Flock cameras watching you
- Proton: A researcher mapped 335,000+ surveillance cameras across America
- CyberInsider: Proton hosts map of 300,000 Flock devices amid legal threats
- Cybernews: Flock Surveillance Map moves to Proton after takedown attempt
- Gadget Review: Proton is hosting a map of 300,000+ surveillance devices
- Hardware Busters: The Flock Surveillance Map charts 335,701 devices, and Flock wants it gone on trademark grounds
- Computer Weekly: Government rejects Computer Misuse Act amendment to protect cyber professionals
