Title: "Have I Been Stalked" post-mortem
Date: 2026-02-11 00:30

With more and more databases from stalkerware being [made freely
available](https://techcrunch.com/?s=stalkerware), there were some internal
conversations at [Echap](https://echap.eu.org) about what could be done with
them to help victims. Everyone knows [Have I Been
Pwned](https://haveibeenpwned.com/), the website where you can put your email
address and check if it appears in *popular* database leaks. Wouldn't it be
nice to do something similar, but for stalkerware?

I built a prototype in [Flask](https://flask.palletsprojects.com/), but quickly
switched to [Django](https://djangoproject.com/) because of its autogenerated
administration interface. It also comes with a lot of nice things like a
declarative data model, integrated form validation, and so on.
For the database, [PostgreSQL](https://www.postgresql.org/) was suggested, but
I picked [sqlite](https://sqlite.org) instead, as not _that_ much traffic is expected,
and except for new leaks incorporation, access will be purely read-only. Also,
easy backups. To prevent enumeration/bruteforce and to keep bots in check,
[hcaptcha](https://hcaptcha.com/) is alright, and it'll likely have
a better accessibility than something homegrown.

The real questions were more about privacy than about the technical stack.
First of all, the decision was made of allowing users to query the database via
[IMEI](https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity),
and not phone numbers, since the later is usually public, and we don't want
anyone to check their *friends* devices. Another important piece was data
minimization: we already have databases with a ton of data in them, and
there is nothing we can do to reduce those, but what we *can do* is to only
put the smallest possible subset of this data on the website, to tell people if
their device was infected, when, by what, and possibly by whom.

The IMEI is stored [hashed](https://en.wikipedia.org/wiki/SHA-2), not for
security purposes as the number of possible IMEI is around 10¹⁴ making the
whole keyspace absolutely bruteforceable, but so that an administrator doing
maintenance/debugging doesn't see them in clear-text. Another nice trick to
prevent the website from knowing who is checking what device, is to generate a
dozen random IMEI client-side, and send them along with the real IMEI the user
is checking, so that it could only be inferred, if someone wanted to look after
the fact, that a given IP address checked a given set of IMEI. Of course, the
IMEI-checking queries are made via `POST`, and thus don't show up in the logs.

Speaking of data, the database leaks were either publicly available, or sent
to us by third parties. There is no plans to share them with anyone.

While I'm the one who wrote the code, this project is also the brainchild of
[Esther](https://esther.codes/), who provided technical expertise on "
Django and stuff in production", back'n'forth conversations on everything
privacy-related, as well as an early Django-based prototype.

The website looks like this:

[![main page]({static}/images/hibs.png)]({static}/images/hibs.png)

[![faq page]({static}/images/hibsfaq.png)]({static}/images/hibsfaq.png)

Now where can you find this marvel of modern engineering? Well you can't
(albeit I can provide the code if you really want.) It was eventually decided to not
go through with the project for several reasons, including:

1. It's a legal minefield that Echap, as a miniscule non-profit, isn't equipped
   at all to navigate.
2. On haveibeenpwned, the remediation steps are straightforward: change your
   password, email you [national data protection
   authorities](https://en.wikipedia.org/wiki/National_data_protection_authority),
   go on with your life. For stalkerware, not so much; it's a traumatic event
   to be told that one's phone has been spied on, and removing the stalkerware
   might tip the attacker and worsen the situation. Moreover, Echap's is
   only providing technical expertise/support/training/documentation to
   entities doing actual assistance, not the assistance itself.
3. While I'm more-or-less confident in my technical skills, hosting such
   sensitive data on the internet makes is the kind of thing that keeps you up
   at night.

It was an interesting idea, with exciting privacy challenges, but in the end,
I'm glad it was shelved. But rest assured that other things have being worked
on ;)