Privacy Policy
This policy describes how AI Media OS handles Google user data and OAuth credentials.
AI Media OS is a single-operator system that is not offered to the public. It has no users other than its owner, no sign-up, no accounts, and no hosted service. It connects to exactly one Google Account — the owner's own — and uploads only to the owner's own YouTube channel. If you are reading this and you are not the owner, none of your data is or can be processed by this system.
1. Who operates this system
AI Media OS is operated by a private individual (“the owner”) for their own use. It runs on hardware the owner controls. There is no company, no staff, no contractors, and no third party with access to the system or to the data it handles.
Contact: 4317anahabedian@gmail.com
2. What Google user data is accessed
AI Media OS accesses only the following, and only from the owner's own Google Account:
| Data | Source | Why |
|---|---|---|
| The channel ID and channel title of the authorized account | channels.list(mine=true) |
To verify, before any upload, that the authorized account is the intended destination channel. If the ID does not match the configured one, the upload is refused. |
| Metadata for videos this system itself uploaded — video ID, privacy status, upload and processing status, and the title/description/tags it supplied | videos.list |
To confirm an upload completed correctly and landed on the right channel with the right privacy setting. |
| An OAuth refresh token and short-lived access tokens | Google OAuth 2.0 | To authenticate the above calls without re-prompting the owner each time. |
What is never accessed
AI Media OS does not request, receive, or process: subscriber lists or subscriber identities; audience, viewer or analytics data; comments or community posts; private messages; contacts; email; calendar; Google Drive or any other file storage; location data; payment information; or any data belonging to any person other than the owner. It uses no Google API other than the YouTube Data API v3.
3. OAuth scopes requested
Two scopes, both requested in a single authorization because Google's installed-application flow does not permit adding a scope incrementally afterwards:
https://www.googleapis.com/auth/youtube.upload— uploads the finished video file to the owner's own channel. This is the system's purpose.https://www.googleapis.com/auth/youtube.readonly— required bychannels.list(mine=true)so the destination channel can be verified before any upload begins, and so an upload's own resulting status can be read back afterwards. It is used as a safety check. No broader read access is exercised.
The system verifies at runtime that both scopes were actually granted, and refuses to proceed if either is missing, rather than continuing with an unverifiable destination.
4. How the data is used
Google user data is used for one purpose only: operating the owner's own video production and upload workflow on the owner's own channel. Specifically, to confirm the upload destination, to upload the video, and to confirm the upload succeeded.
It is not used to build profiles, not used for advertising, not used to train any machine-learning model, and not used for any analytics, research, or measurement purpose. It is never sold, rented, or shared.
5. Limited Use
AI Media OS's use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
In particular:
- Google user data is used only to provide and improve the owner's own single-user workflow described above.
- It is not transferred to any other party, except as necessary to provide that workflow, to comply with applicable law, or as part of a merger or acquisition with the owner's explicit consent — none of which currently applies, as there is no other party involved.
- It is not used for serving advertisements of any kind.
- It is not sold, and it is not used to train generalized or personalized artificial-intelligence or machine-learning models.
- No human other than the owner reads it. The owner is the only person with access to the machine, the credential store, and the logs.
6. How credentials are obtained and stored
Authorization uses Google's OAuth 2.0 flow for installed applications, with PKCE (RFC 7636, S256 challenge method). The consent screen opens in the owner's own system browser, and the authorization code is returned to a loopback listener on 127.0.0.1 on an OS-assigned random port. A CSRF state parameter is validated on return. No credential is ever entered into, or passed through, this system's own interface.
| Item | Where it lives | Protection |
|---|---|---|
| Google OAuth client configuration (client ID and client secret) | A file in the owner's user profile, outside the source repository | Protected by the operating system's file permissions for that user account. It is not in version control and is excluded from it. |
| Refresh token | Windows Credential Manager | Encrypted at rest by Windows DPAPI under the owner's user account. The system checks at runtime that the credential store in use is the real Windows one and refuses to run against a null, plaintext, or unavailable backend rather than storing a token insecurely. |
| Access tokens | Process memory only | Held for the life of the running process, never written to disk, and discarded when the process exits. |
Tokens and secrets are never written to log files. The system's logging records only non-sensitive identifiers — internal video and render IDs, the destination channel ID, and privacy status — and never token values, authorization codes, or client secrets.
7. Where data is stored
All data stays on the owner's own machine. Video metadata, production records and operational logs are held in a local database on that machine. Rendered video files are stored on that machine's local disk. Nothing is stored on a server operated by the owner, because there isn't one, and there is no cloud backend, no hosted API, and no third-party analytics service.
The only outbound transmission of Google user data is the direct, encrypted (HTTPS/TLS) connection between the owner's machine and Google's own API endpoints.
8. Retention
- Refresh token — retained in Windows Credential Manager until the owner revokes or deletes it, or until Google expires it.
- Access tokens — retained in memory only, for minutes; discarded when the process ends.
- Channel ID and title — the channel ID is retained in the local database alongside each upload record, as the audit trail of where that video was sent. The channel title is used transiently for the verification check and is not retained as a separate record.
- Uploaded-video metadata — retained locally for as long as the owner keeps the production record, as a record of their own work.
9. Deletion and revocation
The owner can end this system's access at any time, by either or both of:
- Revoking at Google. Removing the application's access at myaccount.google.com/permissions immediately invalidates the refresh token. The system then cannot authenticate at all.
- Deleting the stored credential locally. The system provides a function that deletes the stored refresh token from Windows Credential Manager; it can also be removed by hand from Credential Manager. Deleting the OAuth client file from the owner's profile additionally prevents any new authorization.
Locally held records — the database rows and any rendered files — can be deleted by the owner directly, as they are files and rows on their own machine.
10. Security
- All API traffic uses HTTPS/TLS to Google's endpoints.
- Authorization uses PKCE and a validated CSRF state parameter, on a loopback-only redirect.
- The refresh token is encrypted at rest by the operating system, and the system refuses to start if it cannot confirm a secure credential backend.
- Secrets are excluded from version control, and the repository is scanned for credential-shaped values before changes are committed.
- The destination channel is verified by a live API call before every upload; a mismatch, or an inability to verify, blocks the upload and is recorded.
- Access to the machine is limited to the owner.
11. Children
AI Media OS is not directed to children and does not knowingly process any data relating to children. It processes only the owner's own account data. Uploads are declared as not made for children.
12. Changes to this policy
If this policy changes, the revised version will be posted at this address with an updated effective date. Because the system has no users other than the owner, there is no one else to notify.