Summary

This morning we mitigated a coordinated registration-abuse attempt against meil.no. No existing accounts were compromised, no email contents were accessed, and no outbound abuse left the platform. We caught it early.

But the more interesting part is not what we blocked. It is the dilemma it surfaced — one I think more privacy-focused services will have to talk about openly: how do you stop modern fraud and abuse without turning every legitimate user into a surveillance object?

This is my view as the CEO of WAYSCloud, written alongside our formal Trust Center report on the same event.

The abuse we used to understand

A few years ago, this kind of abuse was easier to reason about.

One IP created too many accounts. A datacenter range stood out. A bot failed a basic check. The abuse started immediately, and so the response was simple — you blocked the IP, tightened a rate limit, added a CAPTCHA, and moved on.

That is no longer how it looks.

What we saw was not simple, low-effort bot traffic. It was coordinated, distributed, and deliberately shaped to look less automated than it actually was. Residential network access instead of obvious datacenter infrastructure. Completed verification steps. Varied timing between actions. New accounts that appeared "seasoned" rather than abused on day one.

That last detail matters more than any single signal, so it is worth stating plainly.

The goal has changed

This is one of the more important shifts in account-abuse patterns, and most defensive instincts are still calibrated for the old version of it.

The goal is often no longer to create an account and abuse it right away. The goal is to create many accounts, make them look ordinary, let them age, return to them periodically, and only later use them for spam, fraud, or other abuse — if the service grants trust too quickly.

In that model, a per-IP rate limit means very little. Each registration can appear to come from a different residential endpoint. Basic bot checks weaken the moment the actor completes verification and behaves with human-like delays.

The signal is no longer one IP, or one failed check.

The signal is the cohort: repeated structure across signup behaviour, verification flow, timing, naming patterns, regional settings, and network distribution. Individually, each of these looks harmless. A country is not suspicious. A language setting is not suspicious. A verification method is not suspicious. Together — aligned across many registrations at once — the pattern becomes visible.

In plain terms: A single suspicious-looking sign-up tells you almost nothing today. The abuse only becomes legible when you stop looking at accounts one at a time and start looking at the shape of the crowd they arrived in.

Why this is harder for a privacy-first service

For a privacy-focused email service, this creates a real design challenge.

Large platforms can lean on invasive profiling — device graphs, cross-service tracking, broad identity signals. That is the conventional way to detect a seasoned fake account: you simply know more about the human behind it than they would like.

We deliberately avoid that.

We do not want to solve abuse by collecting more identity data from everyone. We do not want privacy to become the thing legitimate users have to sacrifice in order to be protected. That would be a strange bargain to offer on a service whose entire premise is the opposite.

So the answer cannot simply be: collect more data.

A better model: progressive trust

The better answer is progressive trust.

A new account should not receive full capability on day one merely because it passed registration. Trust should build over time — through legitimate use, targeted verification, careful sending limits, strong audit trails, and proportionate risk controls.

That matters especially for email, because email is where the real damage lives. The risk is rarely the signup itself. The risk is what happens later, if quiet, aged accounts are suddenly allowed to send at scale.

So we treat capability as something earned, not granted. A newly created free account does not automatically receive the ability to send external mail at scale just because it completed a sign-up form. The accounts in this incident never reached that point — our investigation indicates they were still in the early "ageing" phase, before any outbound abuse, which is precisely why containment was clean.

In plain terms: Passing the front door should not hand you the keys to the whole building. You get more room as you demonstrate, over time, that you actually live here.

What we are deliberately not publishing

There is a tension in writing any of this down.

We are intentionally not publishing detailed indicators — exact thresholds, network attributes, verification fingerprints, or carrier-level findings. That information would help the next attempt evade the next defence. Transparency about what happened should not become a tutorial for how to do it better.

So this is the honest boundary: I can tell you the shape of the problem and the philosophy of the response. I cannot hand over the detection logic, and you should be sceptical of any security team that does.

Privacy and abuse prevention are not opposites

It is tempting to frame this as a trade-off — more privacy, more abuse; less privacy, less abuse. I do not think that framing holds.

Privacy and abuse prevention are not opposites. But if you care about privacy, you have to design abuse prevention differently:

Less broad profiling. More contextual risk. Less permanent data collection. More short-lived security signals. Less "prove who you are". More "earn trust through behaviour".

This is a difficult balance, and I will not pretend we have it perfectly solved. It is also a necessary one. Privacy-first services cannot be naive about abuse — they are attractive targets precisely because they are trustworthy. And anti-abuse systems should never become an excuse for unnecessary surveillance.

Closing

We caught this one early, contained it, and used it to strengthen how new accounts earn trust over time. No customer needs to do anything; the controls are designed to detect automation, not to identify people beyond what is needed to run and secure the service.

But I am writing about it because the underlying shift is bigger than one morning on one platform. The era of "block the bad IP and move on" is ending. What replaces it will either be more surveillance for everyone, or more patience about trust for everyone. Those are very different futures, and privacy-focused services are going to have to choose deliberately rather than drift into the easy one.

We are choosing the patient version. It is harder. I think it is the right one.

Sources

Tags Privacy Cybersecurity Trust