Bill C-22 and WebCull's Right to Build Software That Cannot Spy
Canada's Bill C-22 has drawn warnings from some of the largest encrypted technology providers. Signal has warned that it could pull out of Canada if asked to compromise its users' privacy under the bill. Apple has said the bill could allow the government to force companies to break encryption by inserting backdoors into their products. Meta has warned that Part 2 of the bill could require companies to build or maintain capabilities that break, weaken, or circumvent encryption or other zero-knowledge security architectures. The Canadian government has responded that the bill would not require technology companies to introduce systemic vulnerabilities into encryption.
For WebCull, the core issue is simple: software companies should be allowed to build products that cannot spy on their users. A service that does not hold encryption keys is not hiding data from the law. It is choosing an architecture where user-owned data stays under user control. That distinction matters because there is a major difference between producing data a company actually has and forcing a company to redesign its product so it can access data it was never meant to control.
Bill C-22 is not settled law at the time of writing. It is currently being studied in committee in the House of Commons after second reading, which means the final shape of the bill may still change. That matters because the debate is not only about what the government says the bill is intended to do. It is also about what the text could allow once the law is in place and regulations or ministerial orders start being used.
The Canadian government says Bill C-22 is meant to modernize lawful access and help law enforcement and CSIS access information when they already have legal authority to do so. The government's framing is that the bill does not create new powers to intercept communications or obtain information, but instead creates a framework so electronic service providers can comply with existing legal authorities. That sounds narrower than some of the public debate around the bill. But the practical concern is what "able to comply" means when applied to encryption, zero-knowledge systems, and software designed so the provider cannot see user data.
WebCull's position is that encrypted user-owned bookmark data should remain unreadable to us. When a WebCull user encrypts their saved bookmark data, WebCull stores encrypted user-owned data, not readable bookmark data. We do not hold the keys for those users with end-to-end encryption (E2EE) enabled. We do not have a hidden recovery path that lets us turn an encrypted bookmark vault back into plaintext. That is not a customer service policy layered on top of the system. That is the shape of the system.
This is important because encryption is often discussed as if companies are simply refusing to cooperate. That is the wrong framing for zero-knowledge systems. A zero-knowledge product is designed so the provider does not have the thing being requested. If WebCull does not hold the key to a user's encrypted bookmark data, then WebCull cannot provide the plaintext contents of that data. We can only provide what we actually have. For encrypted bookmark storage, that means encrypted blobs and limited operational records. It does not mean readable saved URLs, folder structures, icons, notes, tags, descriptions, or other bookmark data stored inside the encrypted payload.
That is the whole point. Privacy should not depend only on whether a company says no. Privacy should be built so the company cannot say yes to something it never had access to in the first place.
Signal has warned that it could pull out of Canada over Bill C-22, which matters to us because Signal has a similar principle at the content layer as WebCull. Signal cannot normally hand over plaintext messages because it does not hold the message contents in readable form. Signal has also built systems to minimize the metadata it stores. Signal says its service is designed not to keep records such as contacts, social graph, conversation list, location, profile name, group memberships, group titles, or group avatars. Signal has also published examples of legal requests where the producible data was limited to account creation time and last connection time.
That explains why this debate is not only about message text. A messaging app can protect the content of messages and still become dangerous if it is forced to retain reliable metadata about who contacted whom, when they communicated, what accounts were in groups, what devices were involved, or what network information was attached to those interactions. For journalists, lawyers, activists, whistleblowers, political organizers, abuse victims, and ordinary people, the existence of a communication can be sensitive even when the words are never read.
WebCull is not a messaging app, and bookmark storage is not the same thing as a live communications network. There is no person-to-person social graph inside WebCull in the way there is inside a private messenger. But the architectural lesson is the same. A privacy-first product should avoid creating sensitive records it does not need. The more data a service collects, indexes, logs, and retains, the more data can later be demanded, leaked, breached, or misused. The safest data is the data the service never had.
Bill C-22's broad language is why this debate matters for more than Signal. The bill creates a framework involving electronic service providers, and the bill summary says Part 2 is meant to ensure that providers can facilitate access to information under authorities found in the Criminal Code and the Canadian Security Intelligence Service Act. The bill also defines electronic services broadly enough that many modern software services need to pay attention, not only telecom companies or messaging apps.
The concern is not that Bill C-22 clearly bans encrypted software. It does not appear to say that Canada is banning zero-knowledge products, banning end-to-end encryption, or requiring every software company to hold user keys. If that were the bill's text, the issue would be much worse. The concern is that the bill could create pressure on privacy-preserving systems through future regulations, metadata retention obligations, access capability requirements, or provider-specific orders, which is still very concerning and potentially a step towards a less secure internet.
That is why companies like Apple and Meta have objected. Their concern is that the bill could be used to require companies to break, weaken, or circumvent encryption or other zero-knowledge security architectures. Public Safety Canada has responded that the bill would not require companies to introduce systemic vulnerabilities into electronic protections such as encryption. The disagreement is not about whether encryption matters. The disagreement is whether the bill's safeguards are clear and strong enough to prevent lawful access from becoming forced redesign.
Bill C-22 includes language around “systemic vulnerability". The bill treats encryption as a form of electronic protection and says providers are not required to comply with certain regulations or orders if compliance would require introducing a systemic vulnerability or prevent them from fixing one. That safeguard matters. A system that requires WebCull to start holding decryption keys, intercept plaintext before encryption, or silently redesign the product so encrypted bookmark data becomes readable would not be a small compliance feature. It would change the security model of the product.
The hard part is that this distinction can become a legal argument instead of a technical fact. A government may say a requested access capability is limited, lawful, targeted, or not systemic. A privacy company may say the same access capability breaks the architecture that protects everyone. This is why technical architecture needs to be defended clearly. If a product is designed so the provider cannot read user-owned encrypted data, forcing the provider to create a way to read that data is not ordinary compliance. It is compelled product redesign.
WebCull's position is not that companies should be above the law. The position is that the law should respect the difference between data a provider actually controls and user-owned encrypted data a provider merely stores. If a provider has account records, billing records, operational logs, or encrypted blobs, those are different from the plaintext contents of encrypted user data. A legal demand for records that exist is one thing. A demand to change the product so the company can access data it was never meant to control is something else.
Weakening encryption does not only affect the target of an investigation. A backdoor or forced access mechanism changes the risk profile for every user. It creates a new thing to steal, abuse, misconfigure, leak, or secretly expand. Security systems do not know whether a vulnerability is being used by a good actor or a bad one. Once a product is redesigned so someone other than the user can access protected data, the system has created a path that did not previously exist.
This matters for bookmark data because bookmarks can reveal more than people realize. A bookmark collection can show what someone is researching, what medical issues they are reading about, what legal problem they are trying to understand, what business they are building, what political material they follow, what personal situation they are dealing with, and what private interests they do not want exposed. A bookmark manager is not a chat app, but saved links can still be deeply personal.
The right direction for privacy software is not to collect first and protect later. The right direction is to avoid collecting readable data when readable data is not necessary. For WebCull, that means encrypted bookmark data should stay encrypted. It means the user should own the sensitive contents of their bookmark collection. It means WebCull should not create plaintext indexes, recovery paths, or unnecessary side channels around encrypted data just because doing so might be convenient.
This is also why the phrase "we cannot decrypt it" is stronger than "we promise not to read it." A promise can change. A company can be sold. A policy can be rewritten. An internal tool can be abused. A server can be breached. But if the provider never receives the key, never stores the key, and never builds a recovery path around the key, the provider's power is limited by design. That is what user-owned encryption is supposed to accomplish.
The Bill C-22 debate asks a bigger question than whether one company or one app can operate in Canada. It asks whether privacy-preserving architecture will be treated as legitimate, or whether every digital service will eventually be expected to preserve enough access for someone else. That question affects more than Signal. It affects every product trying to reduce the amount of private data it can see.
WebCull's answer is that encryption should remain legal, normal, and expected. Companies should be able to build systems where user-owned data stays under user control. Governments can use lawful processes for data that companies actually possess, but they should not require companies to redesign privacy-preserving systems so that user-owned encrypted data becomes company-accessible.
WebCull's position is that the right to build software that cannot spy should be protected. A secure system that cannot read user data is not a loophole. It is the point.