This document describes what the shipped plugin actually does. If the code and this document ever disagree, that is a bug; please report it.

Sign-in happens in Playnite's embedded browser (CEF), pointed at Microsoft's real sign-in page at login.live.com. The plugin never renders a credential form of its own and never sees your password. The sign-in completion is recognised only on Microsoft's documented completion URL (https://login.live.com/oauth20_desktop.srf), not by scanning page content.

• One Microsoft access token is obtained per session.
• It is held in memory only. It is never written to disk, logged, or exported.
• There is no refresh token. When the token expires, the next detection run repeats the browser redirect, which is usually silent because the webview keeps its own cookies.
• The token is sent to exactly one host: collections.mp.microsoft.com, in the request body of the collections query, which is where that service expects it.

The plugin talks to two Microsoft hosts and nothing else:

• collections.mp.microsoft.com — your entitlements (requires the token)
• displaycatalog.mp.microsoft.com — public product catalog (no authentication)

There is no telemetry, no analytics, no update check, and no third-party service.

• Microsoft sign-in occurs in Playnite's embedded browser.
• The plugin does not collect, see, or handle the user's password.
• A Microsoft access token is held only in memory.
• No OAuth token is persisted to disk, in any form.
• The token is sent only to the Microsoft Store collections service.
• No telemetry is sent by this plugin.

Two options under Advanced in the manager window:

• Sign out discards the access token held in memory. Microsoft still has a session and the embedded browser still has its cookies, so the next detection run reconnects without asking.
• Sign out and forget account additionally visits Microsoft's sign-out endpoint and clears the sign-in cookies across every domain the flow touches. The next run asks which account to use. This is the one to use on a shared machine.

Neither affects your ownership data, and neither affects Playnite's own Xbox library plugin, which maintains its own separate sign-in.

Sign-in uses Microsoft's legacy implicit flow (response_type=token) against the login.live.com endpoints, with a legacy client id and the Store collections scope. This is the flow those Store services accept; the documented modern alternative, authorization code with PKCE, is not known to work against this particular client id and scope combination.

Microsoft generally recommends against implicit grant. The reasons it is discouraged mostly concern web applications, where a token in a URL fragment can leak through browser history, referrer headers, or shared address bars. This plugin runs the flow inside a private embedded browser on the user's own machine, reads the token from the fragment, and never writes it anywhere, which removes most of that exposure but not the underlying fragility.

Treat this as a dependency on a private Microsoft service contract rather than a stable public API. Migrating to authorization code with PKCE is desirable and is tracked as future work; it requires live testing against Microsoft's endpoints, since the behaviour of these legacy client ids is not publicly documented.

These are legacy Microsoft Store service endpoints, not a stable public API contract. Microsoft can change response fields or authentication behaviour at any time. The plugin is built so that the failure mode is inert: if detection cannot complete, the previous known good snapshot is kept and nothing in your library changes.

The plugin's data folder contains its ownership ledger, rolling backups, and three CSV reports. The reports describe your account's entitlements and play history. That is not credential material, but it is personal data: treat detection.csv and unmatched.csv as private when attaching them to bug reports, and redact anything you would rather not share.

Open an issue at https://github.com/ToMuchNeverEnuf/XboxOwnershipFilter/issues. For anything sensitive, say so in the issue and details can be handled privately.