What RTO Lock is
RTO Lock is a simple website-side policy concept for Remote Tab Opener. It lets a website publish a machine-readable file that says whether RTO automation should be allowed, denied or limited for that site. The purpose is to make boundaries explicit for website owners, not only for extension users.
This is especially important for sensitive services. A bank, healthcare portal, tax service, identity provider, insurance portal or payment area may not want any active browser automation, even if the user has installed an extension. RTO Lock gives those sites a clear way to say no.
The policy is designed to be readable and conservative. It should not contain executable code, hidden scripts or complicated rules. A simple deny policy is often the safest choice.
Why websites need a voice
Browser automation usually focuses on the person running the tool. That person matters, but the target website also has legitimate security expectations. Some workflows are harmless on public documentation pages but unacceptable on sensitive account pages.
RTO Lock adds another layer of respect to the model. The user controls the extension, but the website can publish its own automation boundary. If that boundary says automation should stop, RTO should stop.
This is consistent with the larger RTO philosophy: visible tabs, local execution, explicit allow-listing and no attempt to bypass security policy.
The safest policy for sensitive sites
For sensitive websites, the recommended policy is simple: block everything. A sensitive service does not need to reveal internal route structures, private account paths or detailed payment flows. Publishing a detailed list of protected paths may expose information that does not need to be public.
A universal block policy is easier to maintain and easier to explain. It says that this domain does not accept active RTO automation. That is enough for banks, insurance portals, healthcare systems, government services, identity providers and similar contexts.
Public websites can choose more nuanced policies, but high-risk services should prefer clear denial over clever path lists.
Where the file belongs
The preferred location is a well-known path, for example /.well-known/rto-lock.json. A root fallback such as /rto-lock.json can help simple hosting environments. The important point is that the policy must be reachable publicly over HTTPS.
After publishing the file, a site owner should use the RTO Lock audit page to verify that the file is found and valid. A policy that exists only in theory is not useful. It must be accessible to the extension or to tools that validate the installation.
This also helps security teams document their position. Instead of relying on vague statements, they can point to a small policy file and a public explanation page.
What RTO Lock is not
RTO Lock is not a magic firewall and not a replacement for server-side security. A website must still implement authentication, authorization, CSRF protections, rate limits and all normal controls. RTO Lock is a cooperation signal for a specific automation tool family.
It is also not a tracking mechanism. It should not identify users, store personal data or create a hidden analytics channel. The policy exists to express a boundary, not to monitor visitors.
The best RTO Lock file is boring: clear, small, stable and easy to audit.
Why this improves trust
Tools that control browsers need public limits. RTO Lock shows that Remote Tab Opener is not trying to force itself onto every site. It gives site owners a simple opt-out mechanism and gives users a clearer explanation when a workflow is refused.
This is good for adoption. Responsible users want to know that sensitive pages are treated differently from public documentation pages. Developers want predictable errors. Website owners want a way to express policy.
RTO Lock ties those needs together in a lightweight way: the site publishes a policy, the tool respects it, and the user sees a clear boundary.