Use principles
These principles describe how we want Dovra to be used. They do not amend the toolkit's MIT license, replace the browser's component licenses, or grant permission to access another service.
Work with permission
Use automation on your own applications or where you have permission. Check the service's terms and relevant rules, respect rate limits and stop when access is refused. A robots.txt file is useful guidance, not a substitute for authorization.
Follow the normal process for sign-in, identity checks and human verification. Do not use the project for fraud, impersonation, harassment, unauthorized access or violations of other people's privacy.
Keep people in control
Review consequential actions before they happen. Sending messages, changing account settings, making purchases and deleting data need an appropriate decision by the responsible person. Repeating an action through automation also repeats its mistakes.
Treat browser control access as sensitive. A connected tool can interact with signed-in pages and read information available to that browser. Limit access to trusted tools and keep debugging endpoints off untrusted networks.
Handle records carefully
Keep enough task information to understand and correct an error, while collecting only what you need. Profiles, screenshots and page archives can contain personal information or active sessions. Do not publish them as routine bug-report attachments.
Check the exact data directory before removing it. Closing a browser, deleting an application and deleting a profile are different operations.
Describe adaptations honestly
If you build on the toolkit, preserve applicable license notices and explain your changes and limitations. Do not promise guaranteed access, undetectability, anonymity or legal compliance. The applicable laws and responsibilities depend on the specific activity and jurisdiction.
The project's own responsibilities remain with its operator; these principles do not transfer them all to users.
Support legitimate use
Dovra is a browser for agents: automation, compatibility testing, quality assurance and research. Marketing, documentation and support describe those capabilities and never promise to evade another service's security controls.
Capability, not circumvention
We expose environment controls (user-agent, timezone, screen and hardware parameters) so agents can run reproducible tests. Whether a particular use is lawful is the user's responsibility. We do not market, and support will not teach, bypassing a specific site's detection or verification.
No evasion guarantees
We do not promise undetectability, anonymity, or guaranteed access to any third-party service. Capabilities change as target sites change; no configuration of Dovra is a warranty of success.
Decline targeted evasion help
When a support or issue request asks how to get past a named service's checks, decline with a short explanation and point to legitimate automation topics instead. Do not provide step-by-step bypass instructions.
Keep a legitimate user base
We build for developers, QA engineers, researchers and agent builders. That audience is the point: UK Computer Misuse Act s.3A and similar statutes look at whether a tool serves a substantial lawful user base. Preserve it in product decisions and marketing.
These principles are operational guidance for product and support decisions. They do not replace the Terms of Use or grant permission to access another service.
← Back to Dovra