Security and data handling

Signing in with GitHub requests the narrowest scope that covers public repositories: read:user, user:email, public_repo.

Here is the uncomfortable part, stated plainly: GitHub bundles write access into public_repo. There is no narrower scope that still allows reading a public repository, so the token you grant at sign-in could push a branch or open a pull request. Orviqa’s analysis never does — it only ever reads. That restraint is a property of the code rather than of the credential, which is exactly why it is written down here instead of being implied.

Analysing a private repository would need the broader repo scope. That is not requested unless whoever operates the deployment opts in.

Publishing — posting a release, opening a pull request against your README — uses a separate credential you connect per channel, not your sign-in token. Keeping them distinct means revoking the ability to publish does not also end analysis, and revoking sign-in does not silently disarm a channel you forgot about.

Drafts stay drafts. Nothing is scheduled, nothing goes out on a timer, and there is no setting that turns autonomous posting on, because the gate is in the publish path rather than in a preference. Every publish records who approved the draft and who sent it, and a workspace can require a second approver before anything leaves.

• Tokens are encrypted at rest with AES-256-GCM and are never sent to the browser. No page, API response or client bundle contains one.
• Passwords — for accounts that use one rather than OAuth — are hashed with scrypt, which is memory-hard. Changing a password invalidates sessions created before the change, so a reset signs out every other device.

A published project page never calls a language model and never calls GitHub. Its content was composed once, when you generated it, and is read from a single row — so a page that gets a lot of traffic costs you nothing, and a crawler cannot spend your tokens.

Content on those pages originates in repositories we do not control, so it is treated as untrusted: Markdown is rendered with raw HTML inert, and every outbound link resolves through a validated redirect rather than becoming whatever href a repository supplied.

Public project pages record views and outbound clicks so that maintainers can see whether the page is working. Visitors get an anonymous identifier in a cookie, used to avoid counting one person twice. It is issued only on public pages — if you are signed in and using the product, you are not given a tracking identifier.

Signed-in accounts have a personalisation switch that genuinely changes behaviour rather than only changing a settings page. Turned off, browsing stops contributing to your recommendations entirely and only your explicit follows are used.

Orviqa holds no third-party security certification, and this page deliberately does not imply one. If you need a formal compliance answer, ask and you will get the real status rather than a badge.