Skip to content

Security: straff2002/OpenGlasses

Security

SECURITY.md

Security policy

Avenkin runs on a camera and a microphone you wear on your face. A defect here does not leak a database row; it leaks a room. Reports are welcome and taken seriously.

Reporting a vulnerability

Do not open a public issue for a security defect. Two private channels, either is fine:

  • GitHub private vulnerability reporting — the Report a vulnerability button under this repository's Security tab. Preferred: it keeps the report, the discussion and the eventual advisory in one place, and it is private until an advisory is published.
  • Email — g@skunkworks.kiwi. Use this if you would rather not have a GitHub account attached to the report, or if the finding concerns the published site rather than the code.

What helps, roughly in order of how much time it saves:

  • The version or commit, the device and iOS version, and which build channel (App Store, TestFlight, local build).
  • Steps to reproduce, or a proof of concept. A crash log or an .ips file is worth a paragraph of description.
  • What an attacker gets. "Reachable from the local network without pairing" and "reachable by someone holding the unlocked phone" are very different findings and are triaged differently.
  • Whether any data left the device, and where it went.

Please do not send us other people's data. If reproducing a finding captured someone's face, voice or health information, describe it — do not attach it. A report is not a good reason to create a second copy of a bystander's data.

What to expect, and when

These are the targets of a small team, stated so you know whether to chase. They are not a contractual commitment, and they are not an SLA anyone has bought.

Stage Target
Acknowledgement that a human has read it 3 business days
Triage: severity, scope, whether it reproduces, and what happens next 10 business days
Fix or a written mitigation plan — high and critical 30 days
Fix or a written mitigation plan — everything else 90 days

New Zealand business days, so allow for the summer holiday period around late December and January. If a target passes in silence, chase it — silence is a failure on our side, not a verdict on your report.

Once a fix ships we will publish an advisory and credit you by whatever name you prefer, including none. Tell us if you have a disclosure deadline of your own and we will work to it or tell you plainly that we cannot.

Scope

In scope

  • The iOS app in this repository: the app, its extensions, the watch app and the widgets. This includes the on-device data stores, the local network listeners, the tool-calling and agent surfaces, the skill-pack and vault-pack signature verification, and anything that decides what leaves the device.
  • The scripts and build configuration in this repository: Scripts/, ci_scripts/, the XcodeGen specs and the GitHub Actions workflows. A supply-chain finding here — an unverified download, a permission that is wider than it needs to be, a signing key reachable from a log — is a security finding, not a code-quality one.
  • The published site served from this repository (GitHub Pages) and the files it stages.

Out of scope

  • Meta's Wearables Device Access Toolkit and Meta's services. The SDK is a dependency; its defects belong to Meta, who run their own programme. Tell us anyway if the defect is only reachable because of how this app uses the SDK — that part is ours.
  • Third-party model and AI providers (Anthropic, Google, OpenAI, and any gateway or local server you point the app at), and the model hosts the app downloads weights from. Each has its own reporting channel. What is ours is the boundary: what we send, when, under what consent, and whether we verify what comes back.
  • Apple platform defects. Report those to Apple.
  • Findings that require an already-compromised device — a jailbroken phone, a passcode the attacker knows, a debugger attached to the process. Say so if you think the impact is worse than that framing suggests, and we will look again.
  • Reports generated by a scanner with no analysis attached, missing security headers with no demonstrated impact, and social-engineering or physical attacks on the maintainers.

Safe harbour

If you are researching in good faith and within the scope above, we will not pursue or support legal action against you, and we will say so to anyone who asks. Good faith means, concretely:

  • Use your own devices and your own accounts. Do not access, modify or retain anyone else's data, and stop as soon as you have proved the finding.
  • Do not degrade the service for anyone else — no denial of service, no automated scanning that amounts to one, no spam.
  • Report promptly, give us a reasonable chance to fix it, and do not publish before then.

This is our commitment, not a licence to break the law, and it cannot bind third parties: an attack on Meta's, Apple's or a model provider's infrastructure is covered by their programmes, not by this document.

Related

  • Building from source — how CI verifies its own tooling and freezes its dependency graph, and how to review a dependency update.
  • Privacy and control — what the app stores, what it sends and what you can turn off.
  • Compliance programme — the security and privacy engineering this repository is being held to, including the remediation roadmap findings are tracked against.

There aren't any published security advisories