Security

Security at Gradeshuttle

With no servers there’s no database to breach. Our security work therefore focuses on two things: what the extension can do in your browser, and making sure the code you install is the code we reviewed.

Design

  • Least privilege. No install-time site access, and no scripts on every page. Gradeshuttle injects its page script only when you press Grab or Fill. It does not request tabs, history, cookies, clipboard, downloads, identity or network-interception permissions.
  • No network. Extension pages run under a Content Security Policy with connect-src 'none'. The page script contains no network APIs. Both are enforced by a release gate and by a test in real Chrome that asserts zero requests during a grab and a fill.
  • No remote code. Manifest V3. No eval or remote scripts. Every rule ships in the package that Chrome Web Store reviews.
  • Untrusted page text. Text read from web pages is escaped before display and never executed. Spreadsheet formula characters are neutralized in receipts.
  • Short-lived data. Grabbed data lives in session memory only, is unavailable to web pages, and is erased on a timer.

Releases and updates

For an extension, a hijacked update is the most realistic risk. Here is how we guard against it:

  • In place now: every build passes the release gate and the real-Chrome test, builds are reproducible, and each release’s SHA-256 hash is published so IT teams can compare it.
  • Set up before the first public release: a group publisher account in the Chrome Web Store with at least two owners using hardware security keys, signed (verified) uploads with the key kept offline, two-person review of every release with permission changes called out in the notes, and staged rollouts so a bad update can be stopped before it reaches everyone.

If something goes wrong

If we suspect a compromised release, we:

  1. pull or roll back the release in the Chrome Web Store and rotate the affected credentials and keys;
  2. tell affected schools and districts promptly, with the versions involved and what to do;
  3. notify regulators and individuals as the law requires (for example Alberta’s PIPA, Canada’s PIPEDA and US state breach laws), and support schools with their own duties under POPA;
  4. publish a plain-language post-incident review.

Report a vulnerability

Email andreas.much@gmail.com with steps to reproduce. Please don’t include real student data. We acknowledge reports within 3 business days and aim to fix critical issues within 14 days.

If you act in good faith, test only against your own accounts or our demo pages, avoid privacy violations and service disruption, and give us reasonable time to fix the issue before disclosing it, we won’t pursue legal action and we’ll credit you if you’d like. Our /.well-known/security.txt has the same contact details.