ActivityWatch / ActivityWatch/aw-server-rust

Extension pairing / code exchange for browser-watcher origins

Open
#638 0 comments 1 reaction 0 assignees View on GitHub
Dominant language
Rust
Stars
315
Forks
96
Avg merge
2d 21h
Merged PRs (30d)
14

Description

Follow-up to #637, which narrows the blanket `moz-extension://.*` CORS trust to the three endpoints `aw-watcher-web` needs. That closes the read/exfiltration half of the problem with no client change, but the underlying design issue remains: **any installed Firefox extension can still write into its own bucket**, because extension origins are random per install and cannot be allowlisted up front.

Background and the negative result that makes this necessary are in #637 — briefly: deleting the wildcard does *not* work, because host permissions do not exempt a Firefox background script from CORS (verified in Firefox 152; the server's ACAO header is the sole gate). So consent has to be captured at runtime instead.

## Proposed design

1. Extension `POST`s its origin to `/api/0/pair/request` (reachable under the wildcard).
2. Server mints a short code and surfaces a pending-pairing prompt in aw-webui (same-origin, trusted) and/or the tray.
3. User approves. Server persists `{origin, token}`.
4. Extension polls `/api/0/pair/status`, receives the token, and sends `Authorization: Bearer ` from then on. The server reflects ACAO for that origin only once paired, and enforces the token.

Reuses the existing api_key fairing (`aw-server/src/endpoints/apikey.rs`, #585) rather than adding a second auth path. Ship behind `[auth] require_extension_pairing`, default `false` for one release with a loud warning, then flip.

Needs matching `aw-watcher-web` work, so it is a coordinated change across repos rather than a server-only fix.

## Also outstanding

- **`aw-server` (Python) has the same wildcard** (`aw_server/server.py`, `cors_origins.append("moz-extension://*")`) and needs the endpoint scoping from #637, and later the pairing flow.

## Credit

Original report by pal0x, privately to @ErikBjare, disclosed publicly with @ErikBjare's approval.

Related: #585 (api_key support), #588 / #636 (api_key bypasses), ActivityWatch/activitywatch#1199 (authentication generally).

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.