Secure Viewer: Controlled Disclosure Without Shipping Files to the Browser

Most document preview systems solve viewing by handing the browser the file. That is convenient, and it quietly makes the endpoint part of the data-handling system. Browser caches, local save paths, and ordinary file affordances all come along for the ride.

Secure Viewer takes a different line: Stellarbridge renders the approved document server-side in a short-lived isolated renderer, then sends the dashboard a pixel stream. For the normal in-browser preview path, the client sees the image of the document, not the underlying file.

The feature is in beta and available through controlled availability programs. Authorization follows the Stellarbridge model: RBAC first, then Drive policy on the object.

Secure Viewer streams a redacted server-side render to the browser.

The problem we designed against

Regulated workflows often need view access without easy local persistence. Browser preview fights that goal in boring, predictable ways:

Anything that stores, transmits, or processes content on the endpoint can inherit the obligations attached to that data class, including CUI, HIPAA, internal restricted labels, and similar programs.
Context menus, drag-and-drop, downloads, and cache artifacts are normal browser behavior. They are not bugs. They are the cost of moving file bytes across the trust boundary.
Once a file is local, downstream control depends on DLP and user discipline. Optical leakage is always possible; the system should still preserve useful attribution where it can.

Secure Viewer does not remove disclosure risk. It removes one common class of exposure by keeping the document out of the browser's local render-and-cache path.

What the user experiences

From Drive, an authorized user opens a supported file in Secure Viewer. The dashboard presents a full-screen reader. The viewing surface suppresses ordinary file gestures such as context menu and drag-start, while scrolling still feels like reading a normal document.

Closing the viewer ends the stream and cleans up the server-side resources for that session. Supported file types are checked up front. Objects outside configured limits are rejected before a renderer is created, which keeps memory, render time, and session cost bounded.

Architecture at a glance

The architecture has three roles. These names describe responsibilities, not deployment recipes.

  Browser (dashboard)          Control plane              Ephemeral renderer
  -------------------          -------------              ------------------
  Authenticated user    -->    Policy decision       -->  Isolated runtime
  Pixel stream only            Session coordination        Server-side render
  No file bytes                Bounded document access     Teardown on close

Control plane (Stellarbridge application)

The application owns the decision to open a viewer before any pixels move:

Confirm controlled availability and tenant eligibility.
Authorize the request with RBAC and Drive policy for the requested object.
Validate file type, object kind, and configured limits.
Apply abuse controls to session creation because each open allocates server-side work.
Create a non-sensitive session reference bound to the requesting user and organization.
Start a short-lived renderer isolated from the main application runtime.
Give the renderer only the bounded document access needed for the approved object.
Coordinate the browser and renderer after authorization succeeds.
Write audit events for successful opens and rate-limited attempts.

Authorization is not delegated to the stream. A viewer exists only after the control plane has checked entitlement, policy, session binding, and resource bounds.

Ephemeral renderer runtime

The renderer is created for one approved session. It does not accept arbitrary "open this file" requests. The control plane starts it with session-scoped inputs for the approved object and the authorized stream.

Inside the renderer runtime:

The runtime authenticates to the control plane for its approved session.
The object is handled in a memory-backed, non-durable working area rather than a persistent browser download.
The rendered viewport is encoded as a pixel stream for the dashboard.
Only constrained viewer input, such as scrolling, is forwarded to the renderer.
The runtime exits when the session ends or the rendering environment is cleaned up.

When the renderer terminates, rendered content and working-area state go with it. The viewer runtime does not provide a supported persistence path for document bytes.

Browser client

The dashboard requests a session from the control plane and opens an authorized stream. The browser displays the remote framebuffer. Pointer behavior is constrained on the viewing surface, so the user interacts with the reader controls rather than a local document object.

Infrastructure isolation (how we host it)

Production hosting treats the viewer as a separate failure domain per tenant. It is not folded into the primary application runtime.

Concern	Design choice
Blast radius	The viewer runs apart from the primary tenant application.
Network	Network paths are constrained to the services required for rendering and media delivery.
Runtime privilege	The renderer uses least-privilege execution settings and no broad tenant credentials.
Resource bounds	Tenant and session limits cap concurrent viewers and aggregate compute consumption.
Media relay	Encrypted relay transport is required for Secure Viewer media.
Session credentials	Ephemeral credentials are scoped to a single session and expire automatically.
Cleanup	Automatic cleanup removes stale sessions and rendering environments.

Secure Viewer media requires encrypted relay transport. Insecure relay downgrade is not allowed. Session credentials are ephemeral, scoped to one session, and not shared across viewers.

The useful point for a security review is structural: isolation comes from separated failure domains, constrained network paths, least-privilege runtime settings, ephemeral credentials, and non-durable working areas. Documentation describes the design; it is not the control.

Security properties you can rely on

Secure Viewer is enforced through policy, not observation after the fact. Opening a session is denied unless RBAC and Drive policy both allow it. There is no "preview anyway" path parallel to policy.

The renderer can reach only what it needs to render one approved object: the control plane, the bounded document access path, and the authorized stream. It does not receive tenant database credentials or broad storage access.

Session activity is bound to the authenticated user and organization that requested the secure view. Other principals cannot attach to that session.

Document access is session-scoped. It expires with the session and is not reusable for unrelated content.

Session creation is capped per user and organization to reduce provisioning abuse and cost exposure.

Teardown removes the rendering environment. Non-durable working areas are removed when the session ends, so the viewer runtime does not leave a supported persistence path for the document.

Successful secure-view opens and rate-limited attempts are logged with object correlation and a non-sensitive session reference for SIEM correlation alongside other Drive actions.

Accountability and residual risk

Secure Viewer narrows technical exfiltration tied to file handles and browser document caches. Some risks remain:

Screen capture through OS screenshots, screen recorders, or a camera pointed at the monitor.
Insider misuse by a user who is allowed to view the content.
Endpoint compromise. Malware on the workstation operates outside Stellarbridge's boundary. Pixel streaming reduces browser-local file exposure; it does not secure the endpoint.

Our product direction for accountability includes viewer-attributed overlays, such as identity and timestamp on the streamed image, so optical leakage can carry forensic signal. Treat overlays as a complement to policy and training.

Operational teams should pair Secure Viewer with least privilege, acceptable-use expectations, and existing monitoring.

Known boundaries (honest limits)

We publish limits because reviewers need to map the feature to their own threat model:

Authorized users can still see content. This is controlled disclosure with reduced local persistence.
Each open creates isolated rendering work. Abuse controls and quotas exist because this costs more than static preview.
Unsupported formats and objects outside configured limits fail before rendering starts.
The feature is still in beta. Metrics, alerting, and tenant enablement are staged accordingly.
Secure Viewer assumes the broader Stellarbridge platform controls, operational monitoring, and incident response remain in force.

We do not claim "zero download" in the absolute sense. Users can still attempt other channels. The claim is narrower and more useful: the default preview path does not deliver the file to the browser for local rendering.

How this fits Stellarbridge

Stellarbridge governs how sensitive data is allowed to move across boundaries. Secure Viewer applies that model to in-place reading. The same policy language that governs Drive actions governs whether secure view is permitted. The same audit pipeline records usage. Controlled availability governs rollout.

In compliance conversations, position Secure Viewer as subtraction: fewer places where the document exists, shorter lifetime for render artifacts, narrower network paths, and explicit session scope. That is a better control story than sending bytes to the client and watching the aftermath.

Evaluation checklist for security reviewers

Use this when assessing fit for your environment:

Decide which data classes need view-without-local-file and map them to secure-view permissions, Drive policy, and RBAC roles.
Confirm that viewers are authenticated workforce users or equivalents covered by your IdP and Stellarbridge RBAC.
Check whether your workflows rely on formats outside the supported set.
Check whether typical objects are within your configured limits.
Address screen capture and training for authorized viewers.
Confirm secure-view audit events fit your SIEM use cases.
Confirm controlled availability and production-readiness expectations with your account team before production reliance.