Trust, Security & Accessibility

How we think about security

The most reliable way to protect data is not to hold it. That principle shapes the product more than any control listed below: the widget sets no cookies, never stores an IP address, never receives the text of a typed question unless the site owner explicitly enables capture — in which case it is redacted at ingestion and deleted within 90 days — and drops events at ingestion whose identifier fields pattern-match an email address or a long number.

What we do hold, we hold deliberately, and we would rather tell you its limits than imply it is stronger than it is.

What we do

Infrastructure

• TLS for everything in transit; encryption at rest for data at rest.
• The event pipeline is architecturally separated from the application database, so visitor events never enter the system holding account data.
• Rate limiting and strict origin checks at the network edge.
• Backups with tested restores, and infrastructure defined as code so environments are reproducible.

Access

• Least-privilege access; production access is limited to the staff who need it and is logged.
• Two-factor authentication is available to every account and enforced for staff with production access. Enterprise SSO (SAML / OIDC) is on our roadmap and not yet available.
• Row-level authorisation: every query is scoped to the authenticated organisation, so one publisher can never read another's data.
• Passwords are stored only as a cryptographic hash. We cannot read your password, and neither can an attacker who takes a copy of our database.
• Sessions expire after 7 days and you can revoke them yourself at any time.

Application

• Every API input is validated against a shared schema before it reaches business logic.
• The widget uses no eval and works under a strict content security policy.
• Webhook signatures are verified in constant time, and handlers are idempotent.
• API keys and partner credentials are stored hashed, never in plaintext.
• Automated dependency scanning runs weekly and on every change; high-severity advisories fail the build.

What we have not done yet

A trust page that lists only strengths is not worth reading. Here is the current state of the things people ask us about.

Reporting a vulnerability

If you have found a security issue, please tell us at security@askthis.io. This is the address published in our security.txt, and it reaches an engineer.

Please include enough detail to reproduce the issue, and give us reasonable time to fix it before disclosing it publicly. We commit to:

• Acknowledging your report within 3 business days.
• Telling you our assessment, and our intended fix and timeline, within 10 business days.
• Keeping you updated until it is resolved, and crediting you when we ship the fix if you would like us to.

Safe harbour

If you make a good-faith effort to comply with this policy, we will not pursue legal action against you, and we will make it known that your research was authorised if a third party pursues you. Good faith means: testing only against your own account, not accessing or modifying other people's data, not degrading the service, not running denial-of-service or spam tests, and not using social engineering or physical attacks. Stop as soon as you have proved the issue and tell us.

We do not currently pay bounties. That is not a comment on the value of your work — we would rather be honest than imply a reward that does not exist.

If something goes wrong

No system is perfectly secure, and a page that claims otherwise is not being straight with you.

If a breach affects personal data we will notify affected publishers without undue delay, and regulators within the time our law requires — 72 hours to a supervisory authority under the GDPR, and without delay under India's DPDP Act. We will tell you what happened, what data was involved, what we have done, and what you should do, and we will not wait until we have every answer before telling you the ones we have.

Service incidents are posted on our status page.

Accessibility

We aim to meet Web Content Accessibility Guidelines 2.1 Level AA across our website, dashboard and the widget itself. The widget matters most here: it appears on other people's sites, so an inaccessible widget would make their pages inaccessible too.

What that means in practice

• Every widget control is reachable and operable by keyboard alone, with a visible focus indicator.
• Buttons carry accessible names, and state changes are announced to screen readers.
• Colour contrast meets AA, and colour is never the only way information is conveyed.
• Motion respects your reduced-motion setting.
• Automated accessibility tests run in our build pipeline on every change, and a build that introduces a violation fails.

Known limits

Automated testing catches a meaningful share of accessibility problems, not all of them. We have not yet completed a full manual audit with assistive-technology users, and we have not published a formal conformance report. The widget also renders inside pages we do not control, so a publisher's own styling or page structure can affect the experience in ways we cannot fix from our side.

If you hit a barrier anywhere in AskThis, email hello@askthis.io and tell us what you were trying to do. We treat accessibility bugs as bugs, not as feature requests, and we will tell you what we can do and when. If you need information from this site in another format, ask and we will provide it.

Contact