Security at SaysHere, and the audits we are scheduling
SaysHere listens to calls, so people ask us what happens to what they say. This post sets out what protects your account today and what we will have checked from outside. It covers the protections running now, the outside reviews we have planned, and how to report a problem you find.
What is in place
These protections are in place on SaysHere today, and each one is on our security page.
- Encrypted connections. Every page and request goes over HTTPS. A visit by plain HTTP is sent to HTTPS, and browsers are told to use HTTPS for six months. Someone on the same network can see that you reached SaysHere, and cannot read what you send.
- Strict browser rules. Each page sets a content security policy, refuses to be framed by other sites, sends no referrer beyond the site's own address to Google's file picker, and asks for the microphone only on SaysHere itself. The policy limits a page to the scripts SaysHere sends with it, and the framing rule stops another site from showing a SaysHere page inside its own.
- Sign-in without a password. Sign in with a code sent to your email, or with Google or GitHub. With no SaysHere password, there is none to guess, reuse or lose in another site's breach.
- Your notes stay on your device. Notes are kept in your browser, not on our server. They stay on the device you wrote them on.
- Payments through Stripe. Card details go to Stripe's checkout page and never reach our server. Stripe takes the card number on its own page.
- Little logged. Our server logs record events and counts, never what anyone said or wrote. A log line holds the kind of event and a few numbers or single words from a fixed list, and the code refuses anything else.
The privacy page lists what we keep, where your audio goes and who processes it.
What is planned
We wrote SaysHere's code, which makes us the wrong people to be its only testers. We are scheduling two reviews by people outside the company:
- An outside penetration test of the web app and its sign-in, by a tester who tries to break in the way an attacker would.
- An independent review of the code that handles audio, notes and payments, read by someone who did not write it.
The two look from different sides. A penetration test shows how the running app holds up against someone trying to get in. A code review finds the mistakes a test can miss, such as a check that one path through the code skips.
When they are done, we will publish a summary of what they find and what we changed, here on the blog. Until those reports are out, the audits are planned, and the list above is what protects your account.
Tell us what you find
If you find a security problem in SaysHere, email team@sayshere.com with the steps to reproduce it. Please give us a chance to fix it before you share it publicly.
Security researchers can also find the address in our security.txt file.