Protected sharing routes

Protected sharing publishes a signed static package whose Scenario, cover, and media bytes remain encrypted until the participant’s browser receives the right password. The handoff, source-discovery policy, and origin boundary are separate decisions that can be composed.

Protected packages keep content confidential from the static host. They do not make requests invisible, turn a shared password into individual authorization, or erase copies that recipients have already saved.

Make three sequential decisions

1. Choose how participants open content

A targeted link is the shortest facilitator-to-participant handoff. It names the protected source and an entry identifier so Cynario can show the intended Scenario after the package unlocks. An unknown target fails closed rather than falling back to another Scenario.

Targeting is presentation filtering after unlock, not per-Scenario cryptographic isolation. If one package contains several Scenarios, anyone with that package’s password can unlock the catalog and may reach the other Scenarios through the package flow. Recipient isolation requires separate packages with separate password material and independently random root-key material. Different entry values do not create that boundary.

Cynario does not add the protected-package password to a participant link. However, the accepted protected source coordinate may contain its own query string, and Cynario copies that complete source URL into the participant link. Do not put a password, presigned bearer token, or other secret in the source URL. Every source-URL query parameter can reach recipients, browser history, and app or gate logs.

2. Choose how the source is discovered

A participant can receive a source coordinate directly, or an operator can put it in readable /config.json. Managed configuration records the source coordinate, publisher public key, and signature-required policy. It never includes a password, root key, or any unlock capability. Personal sources keep manual publisher-pin verification in advanced controls.

Managed configuration establishes a deployment default, not a user account or authorization decision. Every decrypted Scenario still passes Cynario’s normal import validation.

3. Choose who may reach the origin

An existing private network, VPN, or IP-admission layer can limit who reaches the app without giving Cynario a person, group, or assignment identity. This is origin admission, not in-app authorization. Package encryption still protects Scenario content from the static host and from anyone who obtains the ciphertext but lacks the password.

Cookie-authenticated package gates are not currently compatible with protected-source fetches. The bootstrap, catalog, Scenario, and media requests deliberately use credentials: 'omit'. A normal cookie-backed OIDC proxy can admit page navigation and then reject those object requests. Do not place protected-source objects behind a gate that requires browser cookies, an authorization header, or credentialed CORS. Gate the app separately, leave ciphertext objects reachable, or use network/IP admission that does not depend on fetch credentials.

Common combinations

• Direct campaign: targeted link + directly supplied source + reachable static package.
• Managed catalog: ordinary app entry + organization-managed source + reachable static package.
• Recommended workplace route: targeted link + organization-managed source + corporate-gated app origin. Put package objects on a reachable static origin, or behind network/IP admission that does not require browser credentials.
• Private-network deployment: targeted or ordinary entry + managed source + app and package reachable only inside the same private network.

Keep the handoff artifacts separate

• Participant link: carries the source coordinate and optional Scenario target. Cynario does not add the package password, but any query parameters already present in the source URL are copied with it.
• Password: unlocks the encrypted catalog. Send it through a channel appropriate to the audience, separate from the link when practical.
• Publisher pin: verifies that the fetched package was signed by the intended publisher. Managed sources can provide the publisher public key and require signatures; personal setup keeps manual pinning behind advanced verification controls.

A signature proves that the holder of a signing key signed the bytes. It does not prove a legal name, employment relationship, or human identity. Encryption protects package content; it does not prove who used the password.

Publish and verify the static directory

1. Open My scenarios, then choose Protect & share.
2. Select the Scenarios, set the package password, and download the package ZIP.
3. Extract the ZIP. Do not upload the ZIP as a single object.
4. Upload the extracted directory intact. Keep index.json and every opaque encrypted object in the same relative layout produced by Cynario.
5. Copy the public URL that ends in index.json, paste it into Hosted index.json URL, and complete the hosted-source verification in Protect & share.
6. Use that verified index.json URL in the participant link or managed deployment configuration.

Same-origin storage

Host the extracted directory under the app origin, for example https://app.example/sources/campaign/index.json. This avoids CORS. It is compatible with public object paths and network/IP admission, but not with cookie-authenticated protection on those paths because protected fetches omit credentials.

Separate static origin

Host the directory at a reserved origin such as https://content.example/campaign/index.json. Allow the app origin through a deliberately narrow CORS policy and serve the required security and MIME behavior. The current consumer does not define a credentialed-CORS contract, so the static origin must not require browser cookies or authorization headers.

What infrastructure can learn

Protected publication encrypts Scenario files, catalog listings, covers, and media objects. Infrastructure can still observe more than transport timing:

• App and gate requests to /campaign?source=…&entry=… reveal the complete protected-source coordinate and targeted entry identifier in the request URL. This includes any nested source-URL query parameters.
• The source hostname, object paths, client and network addresses, request timing, response and ciphertext sizes, and aggregate access patterns remain observable to the relevant hosts, proxies, and logs.
• The public index.json contains bounded bootstrap metadata: sourceId, revision, Argon2 parameters and salt, the wrapped-root-key slot, catalog path, plaintext and ciphertext sizes, ciphertext hash, chunk metadata, and signature or key ID. The wrapped-root-key slot is an encrypted root-key wrap, not an exposed root key.
• A gate can record whether a session was admitted, while the static host stores or relays ciphertext.

Use opaque entry IDs and package object paths, query-aware log minimization, short retention, and a private network or access proxy when metadata is sensitive. These controls reduce exposure; they do not change the claim that decryption, signature verification, and import validation happen in the browser.

A practical default

For a workplace campaign, compose a targeted link, an organization-managed source, and a corporate-gated app origin. Deliver the password separately. Host the extracted protected directory at a stable index.json URL that participants can fetch without browser credentials; use a private-network or IP-admission boundary when ciphertext reachability must also be restricted.

See Sharing & collaboration for every sharing mode and Self-hosting for the static app, container, and access-gate deployment model.