What Leaked May Never Have Needed to Be Collected

On October 22, Capcom announced that information tied to roughly 11.77 million CAPCOM ID accounts had been leaked. On October 27, So-net and plala announced a leak of about 2.59 million member records. Every time this happens, we are told the same things: change your password, watch out for suspicious email. That advice matters. If you reuse passwords, change them, and check that two-factor authentication is on.

But there is another question behind the response. Much of what leaked would never have existed if it had not been collected in the first place.

When we look for work, we are asked for our name, phone number, sometimes even a government ID — before we know who the other party is or what the work really involves. What is collected stays on someone’s server. And what stays can one day leak. This week’s announcements quietly proved the point: the So-net leak included people who had already cancelled their membership.

So I am testing a design that reverses the order. What is public is only what is needed and what can be offered. Personal information is exchanged later, in stages, between the parties themselves, once there is a reason to talk. Signing up requires only a display name, an email address, and a password. That does not mean “anonymous forever.” At the stage of a contract or a payment, the parties do need to verify each other. The design simply refuses to replace that judgment with one bulk upload at the door.

The same thinking applies to contact. In inclinq, the service I am building, creating an account is free. A Project’s ad is free during this validation period; afterwards it becomes a prepaid advertising fee. Once a Project has paid that fee, it can enter and open THREADs without per-contact charges. I deliberately avoided per-click or per-message billing for advertisers: if bots flood a listing, the victim’s bill must not be the thing that grows. An advertiser’s cost is fixed in advance.

What scales with volume is only the cost of starting a conversation. When a Talent enters a THREAD with a Project, it costs $1 — and another $1 for every 10 messages after that.

This is not a scheme to earn fees. For the price of less than a daily soda, a real payment method passes through Stripe, and that passage itself is the gate. Instead of collecting ID documents and building my own identity-verification system, the design lets Stripe carry that checking work. For one genuine conversation, the burden is almost nothing. But send 100 or 1,000 messages, and the cost grows in proportion to the volume. A hijacked account is no different: one payment does not buy unlimited sending, because every 10 messages costs again.

The premise is that no system can completely eliminate malice. The goal is not to win a detection arms race. It is to break the economics of abuse: raise the cost, and keep what an intruder can take down to an email address. Cheap for good faith, unprofitable for malice. That is what the $1 means.

AI follows the same line. inclinq does not embed its own AI. People use the AI they already use; AI MATCH COPY simply prepares material to bring into it.

And the order matters. First, a person reads the other side’s About with their own eyes. Only then does AI help organize it. An AI, an external recruiter, or an internal hiring manager can only judge a person against the conditions in the ad — if they select outside the conditions and it fails, they are the ones held responsible. But matching conditions alone does not find the people who move a company forward. An About page may hold experience that is slightly off-spec yet aligned with a future the company has not announced yet. The only eyes that can spot that — and take responsibility for the deviation — are the eyes of the people running the business. Companies that grow do not look at people through required conditions alone. So the design keeps AI from pre-filtering, and leaves room for human eyes to go first. The decision is always a person’s.

Honestly, this is still an experiment in progress. I am testing whether 30 Projects and 30 Talent profiles can meet through ads and direct conversation before exchanging more personal information. That is not yet something I can call a proven platform. The US, JP, and Global Remote boards are separated, so conversations only happen when density is built inside one board. The board I am starting with is the US one.

In the same week, PHP itself — the foundation my own service also runs on — was found to have critical vulnerabilities allowing unauthenticated remote code execution, and services everywhere scrambled to apply emergency patches. The more a system has been patched over, the less anyone knows what is still left inside it, and the bigger the incident becomes. What gets breached is always the old part. Frankly, inclinq was not affected beyond running checks. Right now it holds only dummy email addresses, and even as real users join, an email address is all there would be to take. Building without patchwork fixes was a decision made for exactly a week like this one. Preparation is not about nothing ever going wrong. It is about not being lost when something does.

I want to put this order of things on the record now, while new services are still being built in the old order. “Collect everything, apologize when it leaks” is not the only answer. Reversing the order of collection, and shifting the cost onto the side of malice, is another answer that deserves to exist.

I will not call this a leak-proof service. My service also holds email, posts, and conversation records. That is exactly why what is collected first should be less. From a design that apologizes after a leak, to a design that does not collect. I am not making a big pitch. I just want people to know that an experiment with this order already exists, under the name inclinq.

Sources:

• CAPCOM ID: announced 2026–10–22, 11,774,247 accounts — ITmedia, 2026–10–22
• So-net / plala: announced 2026–10–27, 2,585,481 records, including members who cancelled from March 2026 onward — ITmedia, 2026–10–27
• PHP critical vulnerabilities: disclosed 2026–10–21, CVE-2026–109618 / CVE-2026–109619 (unauthenticated RCE, CVSS 9.2) — ITmedia / ZDNET Japan, 2026–10–21–22