[with]

Pretty cool! Some questions about security, because the Github and website make a lot of claims about being fully "secure" by default:

1) What exactly does "encrypted" protect against if there's no passphrase being used? The key sits in IndexedDB right alongside the encrypted data.

2) Why can Claude POST any data it wants to any URL on the internet without any user confirmation?

3)Why is the Telegram bot token stored in plaintext when the Anthropic is protected by AES256? Telegram bot token isn't as sensitive, or what?

4) The javascript tool runs eval() in a Worker that has fetch(), so doesn't that make any fetch_url restriction pointless? The javascript tool can just do the fetch it wants inside of the eval.

[sachaa]

Thanks for the feedback. This is a proof of concept, not production-hardened software, and the README should be clearer about that.

To your questions:

- 1. The CryptoKey is extractable: false, so JS can't export the raw key material, it only exposes encrypt/decrypt operations. It won't stop a full XSS attack on the same origin, but it does prevent casual inspection of IndexedDB/DevTools. Defense in depth, not a silver bullet.

- 2 & 4. You're right, the fetch_url tool and javascript eval in the worker both have unrestricted network access. A confirmation step for outgoing requests is worth adding. Good callout.

- 3 Honest oversight, no reason the Telegram token shouldn't get the same treatment. Will fix.

Updating the security language in the README to be more accurate about the threat model. PRs welcome if anyone wants to tackle sandboxing the JS tool (iframe with a null origin is one approach).