Limits and open work

What LayerT is not

• Not a content scanner. Rules act on form submissions, pastes, typed text and files given to a page, by name or by the text inside a plain-text file. LayerT reads plain text only. It doesn’t look inside PDFs, Office files or images, has no library of ready-made detectors, doesn’t classify data, and doesn’t read or control the clipboard.
• Not a network control. It works inside the browser. Traffic from other apps, other browsers or the command line isn’t its concern.
• Not a zero-knowledge vault. LayerT’s servers can decrypt shared-account passwords and recordings, for approved and logged purposes.
• Not without a record. When a rule matches, LayerT records what matched, and for a typing rule the text of the field, so an auditor can check the decision. A rule can mask or hide its values.
• Not device attestation. Each browser’s credential is tied to a key made in that browser that can’t be exported. The key is protected by software, not by a TPM or Secure Enclave, and approving a browser doesn’t prove the device is company-owned or managed.
• Not certified. LayerT is pre-launch and holds no SOC 2, ISO 27001 or similar certification. It produces evidence for your own audits.

Coverage

Limits of what LayerT does

Rules

• Rules read plain text only. A rule about a file’s text reads plain-text files of up to 1 MB. It doesn’t look inside PDFs, Office documents, images or archives. It stops those instead, and says it couldn’t check them.
• A site’s own background uploads aren’t checked. Data a page sends by itself, without a form, a paste, a typed field or a file given through a file box, a drop or a paste, is outside every rule.
• A typing rule can’t keep text out of the page. The text is in the page from the first keystroke, and a page that sends as you type (search suggestions, autosaved drafts) already has it. A typing rule tells the person and stops the text being sent with a form, a submit button or Enter.
• Paste rules aren’t clipboard control. They act on pastes into the single-line text boxes a rule names. LayerT doesn’t read or control the clipboard.
• There’s no library of detectors. Rules use the patterns an administrator writes. LayerT doesn’t ship ready-made checks for card numbers or ID numbers.
• File and typing rules can’t be excused. Asking for an exception, and continuing with a reason, aren’t offered on them. Such a rule is a plain block.
• Continuing with a reason needs LayerT’s servers. Offline, the action stays blocked. Nobody is notified when someone continues: the reason is in Rule matches, the audit log and exports.
• A group rule follows your directory with a delay. A change reaches a running browser within about 15 minutes. An offline browser keeps its last answer about its person’s groups for up to 24 hours.
• An open page keeps the rules it loaded with until it’s reloaded or its address changes.
• The newest rule features haven’t run in the test environment. Rules for typed text, files and directory groups, and continuing with a reason, are built and tested end to end in a real browser. They haven’t yet run in LayerT’s test environment.

What rules record

• What a rule matches is recorded, readable by default. A typing rule keeps the whole field, up to 10,000 characters, not only the part that matched. On a chat box, that is what the person wrote around the match. Treat it as monitoring of your staff: tell your people and assess it.
• Values aren’t masked in the browser. The browser always sends the matched value. A rule’s setting to mask or hide it is applied on LayerT’s servers, before anything is stored.
• A form or paste rule can read a password a person typed. These rules read the fields they name, and that can include a password box someone typed into themselves. The value is recorded readable unless the rule is set to mask or hide its values. A typing rule never reads a password box.
• LayerT knows its own fill by the box and by the exact value. No rule reads a password, a code or a secret sign-in field that LayerT filled. If a site’s page changes a filled password and puts the result in a box that isn’t a password box, that is a new value, and a form rule that names that box reads it.
• The user name LayerT fills is still judged, and recorded. A sign-in rule that covers the page sees the user name LayerT filled for a shared account, lets the sign-in through and records that as an exception, with the user name.
• Unsent events sit in the browser. The extension’s storage can hold events that haven’t been delivered yet, including matched values.

New browsers and their keys

• Approval is a person’s decision, not proof about the device. What a browser reports about how it was installed is its own word. LayerT doesn’t attest devices, and approving a browser doesn’t prove it’s company-owned or managed.
• An Owner or IT Admin can approve their own browser. The audit log names the approver.
• The person whose account set a browser up isn’t told by email. Owners and IT Admins are told, and the Inbox lists every waiting browser.
• A registration token delivered by device policy isn’t built. It would tie set-up to your device management, and is the more durable check.
• A browser’s key is protected by software, not hardware. It can’t be exported through the browser, which stops a web page and another extension. It doesn’t stop software running as the person from using the key on that machine. Scheduled rotation of the key isn’t built.

Shared accounts and sessions

• An authorised person can read a filled password from the vendor’s field with DevTools. LayerT’s protection is approval, time limits, audit and offboarding, not secrecy from the person signed in.
• LayerT never presses the sign-in button in a frame. It fills a sign-in form inside a frame of the same site, and the person submits.
• Signing out of a shared account clears the whole site’s cookies, including the person’s own session there, if any.
• On some sites, signing out also signs the person out of their other accounts there. When a vendor shares cookies across a parent domain with its other services, clearing the shared account’s cookies clears theirs too. LayerT says so once, before the first sign-in.
• Reading a shared mailbox is powerful. Anyone reading the whole inbox could use “forgot password” on any service registered to that address. That’s why full access needs approval, is time-limited, watermarked and logged email by email. It can’t be made impossible.
• Spotting a sign-in email is a best guess until an account’s owner writes a rule for that vendor’s sender. Until then, some codes may not be recognised.
• A connected mailbox means LayerT keeps a copy of that mail, for 30 days by default (365 at most). Your data-processing terms with LayerT need to cover it.
• A remote sign-out takes up to about a minute to reach the browser. Until then the vendor’s session cookie still works there.
• Recordings show page text unless text masking is on for that account, and they’re evidence rather than tamper-proof proof.
• A recording shows what the page shows back. What people type is masked where they type it, in form fields and rich-text editors, on every account. When the site then displays it as its own content (a sent message in a thread, a “results for …” heading, a preview), that is page text, and it’s recorded unless text masking is on for that account. Some pages also keep a copy of what was typed out of sight in their own markup, and text masking doesn’t reach every such copy.
• A recording holds addresses as they are. The addresses of pages and of requests are recorded unmasked, whatever the text-masking setting. A site that puts typed text in an address, such as a search term, puts it in the recording.
• A recording shows ticks, choices and file names. Which boxes were ticked, which radio option was chosen and the name of a chosen file are recorded. A file’s contents aren’t, and nor is the option picked in a drop-down list.
• Terminals aren’t masked in a recording. LayerT doesn’t treat a terminal emulator as an editor, so commands typed into a web terminal are recorded as page text unless text masking is on. The same goes for a region made editable by styling alone, and for an editor that draws its own text and isn’t one LayerT knows.
• Recording hasn’t run in the test environment. Recording and its masking are built and tested in development only.
• A watermark deters and attributes. DevTools, switching off the extension or a phone camera defeat it.
• Sign-in outcomes are inferred. LayerT reports a shared-account sign-in as successful from what the page does next, not from the vendor.

Gateways Early access

• Gateways have run in our test environment only, on test servers with practice-site accounts.
• An open connection isn’t cut. When a session ends or is revoked, the gateway refuses new connections at once. A connection that is already open is not cut.
• A typed vendor address loads its first page direct. A person who types the vendor’s address themselves loads that first page from their own address. LayerT can’t route before there is a session.
• Go direct shows the person’s own address. By default a routed sign-in isn’t opened when its gateway can’t be reached. An account set to go direct opens from the person’s own address instead, by its own choice.
• A browser whose proxy is managed elsewhere can’t use a refusing account. Where a policy, a VPN client or another extension controls the browser’s proxy settings, an account set to refuse isn’t opened at all.
• A backup gateway takes over at the next sign-in, not in the middle of a session.
• The gateway sees which host is reached and when. TLS stays end to end, so it doesn’t see the content.
• WebRTC isn’t handled, and other browsers and other Chrome profiles aren’t routed.
• It’s one address per account, per site. It isn’t a single address for everything your company does.

Policy, devices and the audit log

• Emergency stop and new policy reach browsers on their next sync, within 15 minutes, sooner after navigation.
• Extension updates aren’t instant. Chrome picks up a new version within hours or at its next restart, and there’s no emergency push. Rolling back means releasing a newer version. Updates reach a managed browser through Chrome’s own updater, which hasn’t yet been seen on a managed machine.
• Someone with administrator rights on the laptop can defeat enforcement. The extension runs inside a browser the device owner controls. LayerT relies on your MDM to keep people from having local admin rights and to keep the policy in place.
• The policy stored on the device can be read by someone with access to that browser profile. It’s signed, so nobody can alter it on its way to the browser, but it isn’t secret, and it isn’t checked again after it’s saved: someone who can write to that storage can change it on that laptop. It includes your rules and the per-person settings they need, so treat it as internal to your organisation.
• Whoever can push Chrome policy is inside the trust boundary. An administrator of your MDM could change which extension is installed and which keys it trusts.
• A Slack approval is only as strong as the Slack account that clicked it. That’s why password requests, permanent exceptions and rule changes can be decided only in the console.
• Keys are shared across organisations in the key service, not held separately per organisation. Each secret still has its own data key. LayerT’s cloud administrators could use the keys, and the key service’s logs record every use.
• The policy signing key is software-protected. The key service offers that type of key in software only, so it isn’t held in a hardware security module. It can’t be exported.
• The audit log isn’t tamper-evident. Entries can’t be edited through LayerT once written, and exports carry checksums, but the stored log isn’t signed or chained.

Still being built