Writing Terms of Service on Trust

The Inverted Premise

Read the terms of service of any typical web service, and you will notice a foundational assumption: "We can access your data, therefore you must follow our rules." Data is collected, behavior is monitored, violations are detected, accounts are suspended. Disclaimers and prohibited uses are built on top of this power structure.

TokiStorage's usage guidelines do not share this premise. All processing happens within the user's browser. Audio, images, and text are never sent to a server. Even credit balances are stored in the browser's localStorage. TokiStorage has no means of accessing user data.

Terms of Service as Derivation

What is really happening here is the exposure of a hidden dependency: legal document formats have relied on the implicit assumption that servers hold data. The very existence of terms-of-service templates presupposes architectural homogeneity. There is a server, a database, user accounts, an admin panel. When that assumption breaks, the templates break with it.

The normal response would be "let's consult a lawyer and draft new terms." Engineers explain the design, legal translates it into legal language, and technical facts get abstracted away in the process. TokiStorage's guidelines were not made that way. Each technical fact of the architecture was written down directly, and that writing became the legal document. The terms were not "written." They were "derived" from the design.

What makes this structure unprecedented is the elimination of the translation layer between legal and engineering. Normally, engineers design, legal translates into terms, and marketing converts it into brand messaging. Three departments tell the same facts in three languages. TokiStorage's guidelines have no such abstraction. The single fact "data is not sent to a server" simultaneously serves as a technical specification, the basis for disclaimer, a privacy guarantee, and a brand statement. One fact performing four functions at once.

The Design Intent Behind Eight Sections

TokiQR's usage guidelines consist of eight sections. Each serves a role that differs fundamentally from conventional terms.

Section 1: User Responsibility for Content

Conventional terms say "if we discover violating content, we will remove it." TokiQR has no such capability. Data lives inside QR codes, not on TokiStorage's servers. So the guidelines state clearly from the start: responsibility for rights lies with the user. This is not blame-shifting. It is a statement of technical fact.

Section 2: TokiStorage Disclaimer

Disclaimer clauses typically serve as legal shields for the service provider. But this section's basis for disclaimer is structurally different. It states a factual reality: "We cannot access your data, therefore we cannot assume responsibility for it." TokiQR operates offline; data never traverses a network. The confession that monitoring and tracking are impossible becomes the very foundation of the disclaimer.

Section 3: Prohibited Uses

This is where the sharpest divergence from conventional terms occurs. Typical prohibited-use clauses carry an implicit warning: "Do this and we will ban you." TokiStorage has neither the means to detect violations nor the means to ban anyone. The section therefore opens with: "As stated in Section 2, TokiStorage has no means of accessing user data. Compliance with the following prohibited uses therefore rests entirely on the conscience and judgment of each user." This also serves as a bridge to Section 8, "Designed on Trust." Writing prohibited uses while entrusting their compliance to trust is not a contradiction. It is a design.

Section 4: What "Permanent" Means

No typical service terms contain a warning that says "this cannot be deleted." Deletion functionality is assumed. But data embedded in a QR code becomes independent of servers the moment it is printed. Data inscribed on quartz glass cannot be physically deleted. Data deposited with the National Diet Library is nearly impossible to retract. Precisely because permanence is the service's value, there is a responsibility to honestly communicate the risk of permanence.

Section 5: Technical Characteristics of TokiQR

This section appears aimed at engineers, but it is legally significant as well. The statements "data is processed entirely in the browser" and "nothing is transmitted to external servers" also underpin the privacy policy. Do you need a privacy policy for data you never collect? The answer lives here. By documenting technical characteristics within the terms, privacy guarantees are shown to be enforced at the architecture level.

Section 6: Prepaid Credits

Storing credit balances in the browser is a design choice. A server-side balance would enable cross-device sync and reduce the risk of manipulation. But it would also mean storing user data on a server. TokiStorage chose not to. Instead, the terms state explicitly: "TokiStorage is not responsible for balance loss due to browser data deletion or device changes." There is no device transfer feature either. QR code data lives within the QR codes themselves; deposited data lives on GitHub and at the National Diet Library. Because the design is device-independent, the choice not to implement device transfer holds together.

Section 7: Cancellation & Refunds

"There is no cancellation functionality." This is not a policy. It is a technical fact. The feature does not exist. Payments are designed as one-way transactions. When a refund is warranted, the equivalent amount is sent as a separate transaction. Writing "no cancellation functionality exists" rather than "refunds are not accepted." Writing "equivalent amount sent as a separate transaction" rather than "we refuse refunds." The expression changes, and so does the alignment with consumer protection law.

Section 8: Designed on Trust

Browser developer tools can modify credit balances. This is not a vulnerability to hide but a consequence of the design. Without server-side authentication, client-side data is inherently mutable. TokiStorage does not hide this fact. It writes it into the terms. And then adds: "A trust built to last a thousand years. Before you act, pause." Confessing a security opening and asking for trust. This is a structure that does not exist in conventional terms of service.

Three Perspectives

The Engineer's Perspective

Architecture determines terms of service. A serverless, offline-first service cannot collect, monitor, or delete data. When translating these technical constraints into the language of terms, conventional templates fail. "Service suspension," "account freezing," "content removal" — terms that cannot prescribe any of these measures require a different design principle. That principle is trust.

The Legal Perspective

From the standpoint of consumer protection law, "refunds not accepted" and "refund functionality does not exist" carry different legal weight. The former is a provider's refusal; the latter is a technical characteristic of the system. Similarly, "compliance with prohibited uses is entrusted to each user's conscience" is not an abdication of responsibility but a legal expression of the technical fact that monitoring is impossible. As privacy-first services proliferate, this kind of terms-writing becomes a new form of legal literacy.

The Executive's Perspective

Trust-based terms of service are also brand design. When a service whose technical architecture "does not collect data" writes that it "asks for trust," the document is simultaneously a legal instrument and a brand statement. A service built to last a thousand years writes "a trust built to last a thousand years" in its terms. This coherence transforms the choice of privacy-first into a marketing asset.

A Contrast with Convention

Mapping the domains conventional terms cover against TokiStorage's guidelines makes the structural difference vivid.

• Data management — Conventional: "We manage your data." TokiStorage: "Your data lives in your browser."
• Violation detection — Conventional: "We will take action if we detect violations." TokiStorage: "We have no means of detecting violations."
• Account suspension — Conventional: "Accounts may be suspended for violations." TokiStorage: Accounts do not exist.
• Deletion authority — Conventional: "Inappropriate content will be removed." TokiStorage: "Once inscribed, data cannot be erased."
• Refunds — Conventional: "Handled per our refund policy." TokiStorage: "No cancellation functionality. Equivalent amount sent as a separate transaction."
• Basis of trust — Conventional: Server-side authentication and verification. TokiStorage: A thousand-year relationship of trust.

As a New Pattern

TokiStorage's usage guidelines may look like a special case. But as more services adopt privacy-first architectures, demand for this "pattern" will inevitably emerge. End-to-end encryption, zero-knowledge proofs, local-first applications — all designs where servers cannot access user data. When these services write terms, conventional templates will not work as-is.

What is needed is a methodology for writing terms that starts from "we cannot control." Honestly document the constraints of the architecture. Clarify the division of responsibility as a consequence of those constraints. Then ask for trust. If TokiStorage's usage guidelines present one such pattern, it is not because they were intentionally designed that way. It is the result of honestly confronting technical facts.

When the era of template-driven terms ends, what will be needed are people who can derive terms of service from design philosophy. Not lawyers. Not engineers. People who hold both languages. Not translating architectural constraints into legal language, but finding the point where constraints themselves stand as legal documents. That capability is also a fundamental challenge to an era in which legal concepts have been commoditized.

Terms of service are not a document for legal defense. They are the design philosophy of a service, articulated as a contract with users.