Copyable bytes. Constrained usable authority.
Digital scarcity does not require pretending that a file cannot be copied. Ciphertext, identifiers, signed messages and network packets can all be duplicated. The harder and more useful question is whether copying those bytes also creates a second valid right to obtain a new use of the information.
INTEGYRS separates the stored representation from the authority to use it. A system-recognised possession names the currently accepted controller and endpoint. A fresh request must satisfy the applicable state, identity and policy rules. Transfer changes that recognised authority, so the previous holder should not continue obtaining new authorised uses merely because it kept the encrypted file.
A capability is also copyable as bytes. Its validity need not be freely duplicable: recipient binding, operation scope, expiry, single-use state and an authorization fence can stop a copied capability from multiplying successful fresh operations inside the enforcing system. These checks only provide their intended protection while the relevant trust boundaries hold.
The paradigm: possession becomes a controlled relationship among current authority, a particular information unit and a permitted operation. File storage and distribution can remain widely replicated while usable access follows an explicit lifecycle.
The alpha demonstrates a bounded version of this relationship in software. The longer-term device architecture seeks to enforce it even when the ordinary host is malicious. Until that protected boundary is demonstrated, the host can inspect current keys and plaintext and undermine the stronger scarcity objective.
Sending a copy does not remove the sender’s use.
Ordinary file transfer reproduces information at a destination. The sender may retain an identical usable copy. Encryption can protect a transfer in transit, but after both endpoints possess a reusable decryption key, changing a database label from one owner to another does not stop either endpoint using the work.
A controlled possession transfer instead changes which authority the system recognises for future operations. The encrypted payload need not move at the same moment; the recipient may already have cached it. What moves is the accepted ability to obtain a fresh, correctly bound use.
| Operation | What changes | What remains unresolved |
|---|---|---|
| Copy a file | Another location receives the same bytes. | Both locations may retain full usable copies. |
| Move an ownership token | The ledger or registry recognises a new controller. | Old plaintext, reusable keys and endpoint behavior need a separate policy. |
| Change fresh-access authority | The current possession governs new permitted operations; the old holder is refused after the defined cut-off. | Already committed operations and prior disclosures have explicit boundaries. |
| Enforce the use in protected hardware | The proposed device admits only authorised bounded processing/output, without giving protected material to the host. | Hardware assurance, recovery, physical capture and permitted output leakage still require explicit treatment. |
This is why the transfer state machine matters. Preparation, durable freeze, chain uncertainty and successor activation cannot be collapsed into one optimistic “send” button. A signed transition may confirm later even if a network request appeared to fail. Allowing both parties to resume freely during uncertainty would defeat the single-recognised-possession rule.
The current alpha’s exact cut-off is a durable authorization boundary: freeze-first denies a new receipt; an earlier committed receipt may be delivered later. It does not retroactively undo information already disclosed. Read the two race orders for the precise distinction.
Grant a use, not an unrestricted plaintext export.
Traditional least privilege asks which user or process may access which resource. The proposed device model makes the resource and operation smaller: this authenticated unit, this endpoint, this ownership state, this time window, and this permitted display or computation.
A page reader does not need to give the operating system the entire book. A controlled analysis does not necessarily need to export every input record to the application that requested it. A frame presentation does not need to create a permanent, unprotected copy of the media stream. Each workflow can be designed around the minimum protected working set and a specific output.
The future goal is that no whole-work plaintext object is assembled anywhere in the reader. Only the authorised unit and a strictly bounded protected working set exist. For reflowable text, authorisation should identify authenticated content ranges rather than assume that a visual page has a fixed byte position. For video, the protected bound must include necessary codec reference frames and decoding surfaces.
Smaller authority limits the amount of information exposed by a single authorised operation. It also gives transfer, expiry and revocation more meaningful points of control. It is not sufficient by itself: an unrestricted series of queries or a permissive export operation may reconstruct the full work over time. The cumulative behavior of the API belongs in the threat model.
Reduce the places where a usable secret can exist.
Confidentiality is often lost at an endpoint after transport and storage encryption have done their jobs. Malware reads an application buffer, a crash dump retains a document, a thumbnail store survives revocation, or a reusable key allows later decryption of retained ciphertext. The proposed architecture aims to reduce those host-visible extraction routes.
Its potential security value has several dimensions: restrict the amount of plaintext processed at once, bind usable authority to an assessed endpoint, avoid broadly reusable decryption material in the host, retire transient state, and make changes of authority visible to later access decisions.
This can reduce an exfiltration blast radius under a stated threat model. It must not be marketed as a measured reduction until the selected implementation has been tested. A small access unit does not help if a master key is exposed, the parser permits arbitrary memory reads, the graphics path leaks pixels or a recovery service bypasses the policy.
Encrypted work
Copies can be transported, cached and backed up without granting a new plaintext export.
Current permitted use
Owner state, unit, endpoint, operation and freshness constrain the request.
Protected output
A permitted display or computation result, with transient internal state retired afterward.
The architecture also makes availability and governance more important. Fresh access may depend on a state service, a threshold of providers and functioning hardware. Their outage or mistaken refusal can prevent legitimate use. A secure product must document those dependencies and build a recovery process that does not quietly introduce a universal override.
New product rules, subject to rights and implementation.
| Use case | Potential value | Additional work needed |
|---|---|---|
| Transferable publications | A recognised possession could move to another eligible reader while future access by the prior holder is refused. | Publisher permission, transfer terms, protected text/display handling, recovery and consumer usability. |
| Lending and time-limited access | A policy could define a temporary authorised holder or a bounded interval of use. | Explicit lease state, expiry, offline behavior, transfer restrictions and dispute/recovery rules. |
| Enterprise information | A controlled viewer or computation could expose only the permitted records or results rather than an unrestricted document export. | Administrative authority, audit/privacy requirements, emergency access and an output policy that does not enable reconstruction. |
| Licensed data and AI inputs | Protected processing could govern a defined analysis or model operation over licensed inputs. | Rights to the operation and outputs, query limits, model/weight handling, memorisation and derivative-information risks; no current AI enforcement product is claimed. |
| Device-bound software entitlements | Fresh authority could be connected to a particular approved device and permitted software operation. | Platform integration, licensing terms, attestation, update compatibility and safe migration. |
The common thread is a controlled lifecycle of usable authority. These applications are not interchangeable. A publication reader, a video decoder and an AI computation have different exposure paths and different meanings of a legitimate output. A single broad “DRM” label would hide the engineering and rights choices that actually matter.
A technical state is not the complete rights contract.
The system can recognise who controls a signing authority and whether an operation satisfies a protocol. That does not, by itself, establish legal title to a work, transfer copyright, or create permission to distribute it. The relevant content owner, licence terms and applicable law remain part of the product design.
The current alpha does not implement copyright management or copyright transfer. Its purpose is to exercise recognised possession and access transitions. A future commercial system would need explicit terms for resale, lending, revocation, refund, inheritance, enterprise administration and recovery where those features are offered.
Patent protection is another distinct question. The published-invention register links related technical records and identifies their stated inventors/assignees. It does not assert INTEGYRS ownership or licensing of those rights, or that a patent proves an endpoint secure.
More control creates more obligations.
- Availability: requiring fresh state and a threshold of providers introduces dependencies. Refusing on uncertainty can be the correct security behavior and still a poor user experience that must be addressed.
- Cost: hardware isolation, protected memory/display, cryptographic work, service operation and per-unit checks need an honest budget. No device or per-page price is established here.
- Trust: a malicious quorum, compromised device, dishonest observer or abusive recovery authority can threaten the intended boundary. Provider competition does not eliminate these assumptions.
- Privacy: possession histories, request timing and recovery metadata can reveal behavior. A design must minimise and govern that information rather than equate cryptographic control with anonymity.
- Interoperability: unsupported hardware or an unavailable protected output path may need to fail closed, limiting compatibility until another validated profile exists.
- Human output: an authorised person can learn what is displayed. External photography, transcription and information recoverable from permitted results remain outside an absolute no-copy promise.
Digital scarcity is useful when these constraints serve a legitimate product requirement and the supported claim is narrow enough to test. It is not a reason to obscure user rights, create an unaccountable lockout mechanism or pretend that every kind of information can be recalled after use.
A precise software rule is the beginning.
The current software evidence gives INTEGYRS a way to test lifecycle rules and adversarial orderings. The next step is to preserve those rules across independent services, scalable transaction infrastructure and a hardware boundary that does not export protected keys or plaintext to the host.
The planned architecture brings together competing eligible remote providers, threshold-controlled computation and a mandatory protected-device factor. Those requirements must be joined by a separately reviewed construction; encrypting ordinary threshold responses to a recipient does not automatically stop a malicious quorum bypassing that recipient. The current alpha explicitly demonstrates the colluding-quorum limitation.
The beta target is early 2027, with staged live rollout planned by April 2028. These are development goals subject to the engineering roadmap. The ambition is substantial: move from files whose use follows whoever copied a key toward defined uses of information that follow recognised authority at the device itself.