Author: Shao Shiwei
An article reposted by WuBlockchain asks a question that sits at the edge of software development, privacy tools, and criminal law: when does building an encrypted chat app become the crime of helping information-network criminal activity?
The article starts from a familiar premise for developers. Building a communications app is not, in itself, unusual work. A client asks for end-to-end encryption, and the developer implements it. The client wants disappearing messages or two-way recall, and those features get built as part of the product delivery. On the surface, that looks like standard software contracting.
Developers who do extra homework may even find reasons to feel safe. The piece notes that Bat APP, an encrypted chat app marketed around encrypted communication, hidden IP geolocation, and two-way recall, operates publicly in China and has internet information service filing records. A search through court judgment databases may not readily turn up criminal convictions based solely on developing chat software. AI tools may also feed the instinctive argument back to the user: WeChat and Feishu are communication tools too, criminals can use them as well, and building communication software cannot automatically be treated as a crime.
That sense of safety can collapse quickly. The article describes a hypothetical developer, Kevin, hearing that another developer had been arrested by police in China even though the software at issue had been developed for overseas use and had not been promoted domestically. The basis for the charge, according to the article, was that the encrypted messaging software had been used by an overseas online gambling platform. From there, the core legal issue becomes clear: can a developer rely on “technology neutrality” to avoid criminal responsibility?
The legal hinge is subjective knowledge
Citing Article 287-2 of China’s Criminal Law, the article says a software developer can face the offense only when three elements line up: the developer knew that another person was using information networks to commit crimes, still provided technical support or other assistance, and the circumstances were serious.
That means criminal use of software, by itself, is not enough. The article lays out the three questions that must be examined together:
- Did the developer know others were using information networks to commit crimes?
- Did the developer provide technical support or other assistance for those crimes?
- Did the conduct reach the threshold of “serious circumstances”?
The piece stresses that investigators cannot simply work backward from the fact that software was used in fraud or gambling and conclude that the developer must have known. For software developers, the most disputed point is usually this “subjective knowledge.”
In practice, the article says, investigators do not need a suspect to say outright, “I knew.” They commonly infer knowledge from conduct, transaction patterns, and the relationship between the developer and the client. It cites Article 11 of the 2019 judicial interpretation on handling criminal cases involving helping information-network criminal activity, which says clearly abnormal pricing or transaction methods, or the use of encrypted communications or false identities to evade oversight, can support an inference of knowledge. The article also points to Article 5 of an opinion on such cases set to take effect in July 2025, which says the assessment should consider the timing, method, frequency, whether prohibitive rules were violated, and illegal gains.
Case one: Changchun chat software developers were convicted
The first case discussed is a Changchun chat software case.
According to a report published by China News Service on Aug. 6, 2024, the Kuancheng District People’s Court of Changchun released a case titled “Determining subjective knowledge where defendants provide communication and transmission technical support in the crime of helping information-network criminal activity — the case of Li and others.” The article says the case was selected into the China Courts 2024 annual cases.
Its importance lies in who the defendants were. They were not users of the chat software. They were the developers.
Under case number (2022) Ji 0103 Xingchu 52, Li paid Wang and He to develop a chat app. After development, Li and Liu sold it externally. Wang and He continued to maintain the software and later joined the sales effort. They allowed buyers to add false identity labels to QR codes linked to software accounts, including labels such as “customer service for a beverage shop,” and then sold those accounts. The article says three victims were ultimately defrauded through this software.
All four defendants were found guilty of helping information-network criminal activity and received prison terms ranging from eight months to one year.
The article’s reading of the case is direct. These defendants could not shield themselves with the argument that they had merely written code or acted under technical neutrality, because they remained involved after delivery. They maintained the software, participated in account sales, and allowed false customer-service identities to be set on accounts.
Case two: a Shanghai developer avoided arrest and the case was later dropped
The second case came from a matter previously handled by Shao Shiwei’s legal team.
In that case, the head of a Shanghai technology company was criminally detained for 37 days by the Jing’an branch of the Shanghai Public Security Bureau after delivering a website framework to a client. Defense lawyers submitted the contract and delivery materials to show there was a formal agreement and that the software was expressly barred from being used for financial wealth-management products. They also argued that the company did not provide maintenance after delivery and did not control backend access, server access, or database access.
The procuratorate then decided not to approve the arrest within 37 days on the grounds that the facts were unclear and the evidence was insufficient. Several months later, police withdrew the case.
The article says the central reason was the lack of sufficient evidence showing the technology company knew the client was committing fraud and still provided help. The company had followed an ordinary commercial process, signed a formal contract, developed and delivered a general website framework, and included restrictive clauses in the agreement.
Still, the article warns against overstating the value of boilerplate language. A clause saying the software may not be used for illegal activity does not automatically exempt a developer from liability. It is only one piece of evidence regarding the developer’s state of mind and compliance posture. If a developer actually discovers that the client is committing fraud but keeps modifying the backend, hiding servers, deleting data, or collecting unusually high maintenance fees, a disclaimer alone will not erase criminal exposure.
What separated the two outcomes
Placed side by side, the two cases involved software or website development, and in both situations criminals ultimately used the product. One ended in prison sentences. The other ended in no approved arrest and later case withdrawal.
The article says the dividing line was what happened after delivery.
In the Changchun case, Li and the others stayed involved from development to sales to maintenance. They did not write the code and walk away. They kept servicing the product, later joined direct sales, and allowed fake identities to be attached to accounts. On that record, the article argues, it would be hard to say they knew nothing about the buyers’ intended use.
In the Shanghai case, by contrast, the technology company delivered the software under contract and did not keep participating in later operations or maintenance. The contract also contained restrictive language. That post-delivery conduct mattered.
The article’s takeaway is narrow but important: when investigators assess whether a developer had the “subjective knowledge” required for the offense, a major point is what the developer continued doing after the product was handed over.
Facts police usually examine
The article says police typically do not focus on a single software feature when deciding whether a chat software developer knew a client was engaged in online gambling or fraud. Instead, they look at a set of objective facts, drawing on Article 11 of the judicial interpretation and the 2025 opinion, as well as case-handling practice.
Who the client was and how contact was established
Investigators may ask who the client was, whether the developer ever met that person, and how the parties connected. Was the agreement signed with a real individual or a corporate entity, or did communication stay limited to a Telegram account, a false name, or an intermediary?
Where the software was deployed and whether it was compliant
They may also review which country or region the software targeted, whether it was listed in local app stores, and whether the necessary local permits, filings, or privacy compliance documents had been obtained. If an app had been removed from an app store, investigators may look at what happened next: did operations stop, or was the app relisted under a new name, icon, signature, or developer account?
How payments were made
Payment method is another recurring point. The article mentions bank transfers, corporate-to-corporate payments, and settlement entirely in virtual currencies such as USDT. It adds an important qualifier: using virtual currency does not itself prove criminality. But if the paying entity changes repeatedly, the source of funds cannot be explained, or the price is clearly above normal development fees, the transaction method or price may be treated as obviously abnormal.
Backend access and visible data
Police may ask whether the developer could still log into the backend after delivery, whether the developer could see registered users, group names, chat logs, server logs, or top-up data, and what exactly was actually visible.
Whether the requested features had ordinary business use
The article distinguishes between privacy features and evasion features. End-to-end encryption, disappearing messages, and two-way recall can all serve legitimate privacy purposes. The legal assessment may change sharply, though, if the client also asks for hidden server addresses, bulk generation of false accounts, ban evasion, automatic log destruction, or other features designed specifically to avoid supervision.
How end users were charged
Investigators may also examine the commercial model. The article notes that most ordinary chat software is free to use. If a communication app charges users clearly abnormal high fees, and those fees are tied to online gambling memberships, agent hierarchies, or recharge amounts, police may ask whether the developer understood that model.
How users accessed the app
Another question is whether the download and onboarding path fit the logic of a normal communication product. Could users download, register, and use it through standard channels, or did they need a QR code, a private link, a public-account redirect, or entry through a specific gambling website?
Identity checks, user policies, and logging
The article says investigators may look at whether end users had to submit identity information, whether the platform had basic user terms, a privacy policy, complaint channels, and a mechanism for handling illegal content. If anyone could register anonymously and the backend was deliberately designed not to retain logs, that design choice may draw scrutiny over whether it served reasonable privacy needs or the evasion of investigation.
Contract controls and the response to warning signs
Police may also review whether the developer put compliance clauses into contracts, user agreements, or delivery documents; whether those clauses were actually enforced; and whether the developer asked for explanations, suspended maintenance, preserved evidence, or terminated cooperation after finding anomalies.
If the developer had already received user complaints, app store notices, server-provider warnings, or had noticed extensive use of the software by gambling or fraud actors, the next step would matter. Did the developer stop service and preserve records, or continue maintenance, switch domains, migrate servers, and keep charging fees?
One abnormal fact is usually not enough
The article is careful on one point: a single fact is usually not enough to prove knowledge. Payment in virtual currency, encrypted functionality, and an overseas client cannot, each on its own, be treated as equivalent to crime.
Judicial authorities, it says, should still apply a principle of consistency between subjective and objective elements, taking account of the developer’s professional background, service content, the degree of abnormality, profit obtained, and what the developer did after risks came into view.
That changes if several red flags appear at once. The article gives examples: the client’s identity remains unclear throughout, payment methods are abnormal, the functions are clearly aimed at evading oversight, the developer can see gambling-related content, and maintenance continues even after warnings arrive. In that setting, the facts may reinforce one another and become important evidence for inferring subjective knowledge.
How developers can reduce risk
The article closes with practical risk-control steps. Developers can try to show the absence of knowing assistance to crime through client verification, contractual restrictions, permission isolation, anomaly review, evidence retention, and stopping service when needed.
Its comparison of the Changchun and Shanghai matters lands on a blunt point: both involved technical work, code writing, and product delivery, yet the outcomes were drastically different. For developers, programmers, and technology companies still engaged in similar business, the suggested response is to review ongoing projects against the questions above and identify where the cooperation actually stands.
If a developer finds that the counterparty’s situation is hard to explain, the payment method is abnormal, or the ultimate use of the software is unclear, the article treats those as legal risk points that should be addressed early. The recommendation is to collect supporting materials in time and cut off risky cooperation when necessary.
Original article link: https://mp.weixin.qq.com/s/21lDWJqEsCMa3yLcNp38VQ