The short version
Watch Peak Party requests six Chrome API permissions and host access to eleven domains: the eight supported streaming services, its own website and API, and the two Google endpoints Firebase sign-in uses. It has no access to any other site you visit.
It does not request the <all_urls>, webRequest, cookies, history, bookmarks, downloads, geolocation, clipboardRead, debugger, management, proxy, scripting or declarativeNetRequest permissions. Microphone and camera are not manifest permissions at all: Chrome asks you for those on the page, at the moment you press the control.
API permissions
These are the six entries in the manifest's permissions array. Nothing else appears there.
Host permissions
Host access is the permission worth reading carefully, because it is the one that decides which pages an extension can see. Watch Peak Party lists individual domains. It does not request all-sites access.
Where code actually runs
A permission grants the possibility of access. The manifest's content-script rules decide where code is injected in practice, and they are narrower than people expect:
- The party scripts (
player-adapters.js,push-to-talk.js,content.js,social-ui.js) are injected only on the eleven streaming hosts above, atdocument_idle. - One additional script,
netflix-inject.js, runs in the page's main world on Netflix only. Netflix drives its player through its own internal API rather than a standard HTML video element, and reading playback position accurately requires being in the same world as that API. - The extension exposes seven files to those pages as web-accessible resources: three stylesheets, two font files, the logo, and the player adapter. That list is in the manifest and contains no other code.
- A content security policy restricts what extension pages may connect to: our own domain, the two Firebase endpoints, and localhost during development. No third-party script, analytics endpoint or ad network is reachable from extension pages.
Microphone and camera
Neither is a manifest permission. When you press the microphone, push-to-talk or camera control, Chrome shows its own permission prompt on the streaming page, and the browser controls it from there. If you never press those controls, nothing is captured.
Voice and video are sent directly to the other participant over WebRTC. They are not recorded, not stored, and not transcribed. When a direct connection cannot be established, the encrypted stream is relayed through Cloudflare's TURN service, which passes it through without being able to read it.
Why our store listing says we handle location and web history
If you read this page and then open our Chrome Web Store listing, you will find something that looks like a contradiction, and we would rather explain it than let you discover it on your own.
This page says the extension requests no geolocation permission and no history permission. That is true, and you can verify it in the manifest. Our store listing separately declares that the service handles personally identifiable information, authentication information, personal communications, location, web history and user activity. Both statements are accurate, because they answer two different questions.
A manifest permission is a capability the browser grants the extension. A store data disclosure is a statement about data the service handles by any route, including data a server sees simply because a request arrived over the internet. Google requires the second to be declared even when no permission was involved.
Here is every category we declared and the reason for it:
- Personally identifiable information — your name and email address, if you sign in with Google. If you never sign in, this does not apply to you.
- Authentication information — the Firebase session token that keeps you signed in.
- Personal communications — chat messages sent inside a party, and voice or video if you switch them on.
- Location — not device location and not the
geolocationAPI, which we do not use and cannot use. This covers the approximate location that any server can infer from an IP address, because our infrastructure necessarily sees the IP address your request arrived from. Every website you visit sees this. We declared it anyway. - Web history — the URL of the video page a party is watching, which has to be shared for the other participant's browser to open the same video. It is limited to the supported streaming sites listed above, and it is the only browsing information the extension can see at all. It is not a record of the other pages you visit.
- User activity — the play, pause and seek events that make synchronization work, and usage counts for the voice and video features.
We chose to over-declare. Chrome's categories are broad, and for several of these we could have argued our way out of ticking the box. We took the view that a reader who later discovers an undeclared category has been misled, while a reader who finds an explained one has been told the truth. This section exists because the honest version of a disclosure is the one that survives being checked.
For comparison, and stated as fact rather than as an accusation: the largest extension in this category declares three of these six categories. We are not suggesting their declaration is wrong — we cannot see their code, developers make their own good-faith reading of Google's definitions, and a shorter list is not evidence of anything. We mention it only because a reader comparing two listings will notice that ours is longer, and should know that a longer list can mean more caution rather than more collection.
The full detail of what is stored, for how long, and how to delete it is in the Privacy Policy.
What we never request
- No
<all_urls>or wildcard host access. The extension cannot see your bank, your mail, or any site not named on this page. - No
webRequestordeclarativeNetRequest. It does not read, block, redirect or modify your network traffic. - No
cookiespermission. It cannot read your streaming-service login cookies. - No
history,bookmarks,downloads,topSitesorgeolocation. - No
debugger,managementorproxy. It cannot inspect other extensions, disable them, or change your proxy settings. - No remote code. Every script the extension runs ships inside the package Chrome reviews. Nothing is fetched and executed at runtime, which Manifest V3 forbids and the content security policy above enforces.
- No advertising, analytics or session-replay SDK anywhere in the extension.
How to verify this yourself
Do not take our word for it. Chrome ships everything you need:
- Open
chrome://extensions, turn on Developer mode, and read the permission list Chrome itself displays for Watch Peak Party. It is generated from the manifest, not from us. - Click Details, then Site access, to see the exact domains Chrome has granted. You can restrict access further to on-click if you prefer.
- To read the manifest directly, find the extension's folder id under
chrome://version's profile path, openExtensions/<id>/<version>/manifest.json, and compare it with this page. - Open DevTools on a streaming page, go to the Network tab, and watch where the extension connects during a party. You will see our domain and the Firebase endpoints, and nothing else.
If you find any discrepancy between the shipped manifest and this page, tell us and we will correct the page or the extension. The Privacy Policy covers what is stored on our servers and for how long, and the changelog records what changed in each release.
Questions
Privacy and permission questions: privacy@watchpeakparty.fun. Anything else: help@watchpeakparty.fun or the support page.