Privacy policy for fbrcm

Last updated: October 22, 2026

fbrcm is a local command-line and terminal application for managing Firebase Remote Config and reading Firebase apps that Remote Config conditions can reference. It has no developer-operated backend, does not include telemetry or advertising, and does not send Google user data to the fbrcm developer. Google API requests are made directly from the user's machine using credentials selected by the user.

This policy applies to the official fbrcm application. Forks, modified builds, and programs or publication hooks configured by a user may behave differently.

Data-handling summary

• Access: fbrcm accesses Google Cloud project metadata, Firebase Remote Config templates and history, registered Firebase app information and SDK configuration, and the permission and quota information needed for those operations.
• Use: this data supports the project discovery, configuration inspection, editing, validation, publication, and Firebase app inspection actions you request.
• Storage and protection: credentials, caches, drafts, and configuration remain on your machine, with private file permissions where supported. Google API traffic uses HTTPS. Local files are not encrypted by fbrcm.
• Sharing: fbrcm communicates directly with Google. The developer does not receive or sell your Google user data. Exports and optional hooks or other programs you configure can handle that data separately, as described below.
• Retention and deletion: local data remains until replaced or deleted by you. You can delete local credentials, caches, and drafts using fbrcm's commands and revoke Google authorization through your Google Account.

Google API data policy and Limited Use

fbrcm’s use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. Google user data is used only to provide the application features described in this policy. The developer does not use Google user data to develop, improve, or train AI or machine-learning models.

Google data fbrcm accesses

fbrcm requests the following OAuth scope:

• https://www.googleapis.com/auth/cloud-platform

This scope is broad, but fbrcm limits its Google API use to the functionality described below. The scope does not itself grant access to a project or action; the authenticated identity's Google Cloud IAM permissions continue to control which resources fbrcm can read or change.

fbrcm accesses:

• Google Cloud project metadata available to the authenticated identity, including project names, IDs, numbers, lifecycle state, ETags, and update times;
• quota project IDs configured by the user or obtained from Google Cloud CLI Application Default Credentials, and the result of checking whether the authenticated identity can use the selected quota project;
• the result of other permission checks for the project operations fbrcm needs;
• Firebase Remote Config client and server templates, including parameters, values, descriptions, groups, conditions, ETags, and version metadata;
• Firebase application metadata and downloaded Android, iOS, or Web SDK configuration, including application identifiers and Firebase API keys;
• Remote Config defaults and version history; and
• Remote Config managed-feature information exposed by the API, including experiments, rollouts, and personalization bindings.

fbrcm does not call Google profile APIs to retrieve a user's contacts, email, calendar, Drive files, or other unrelated Google Account data, and it does not access other Google Cloud services merely because the OAuth scope could permit them.

Why the broad OAuth scope is requested

Firebase Remote Config identifies https://www.googleapis.com/auth/firebase.remoteconfig as a narrower scope in some API responses and documentation, but Google's interactive OAuth consent flow rejects that scope with invalid_scope. The Remote Config API rejects the grantable https://www.googleapis.com/auth/firebase scope with insufficient_scope. Google Cloud CLI Application Default Credentials also require cloud-platform during user authorization. A public Firebase discussion reports the same narrower-scope problem.

fbrcm also uses the Google Cloud Resource Manager API to discover projects and check required permissions. Those operations require a compatible Google Cloud scope and are not covered by a Firebase-only scope. The Firebase Management API's app listing and SDK configuration methods accept cloud-platform. They also accept narrower read-only scopes for those operations alone, but those scopes do not cover fbrcm's Remote Config write commands.

fbrcm uses one credential for both read and write commands. As a result, cloud-platform is currently the only working scope for fbrcm's complete interactive OAuth and user Application Default Credentials workflows. The same scope covers the read-only Firebase app commands. fbrcm will move to a narrower usable scope if Google makes one available for the complete workflow.

How fbrcm uses Google data

fbrcm uses Google data only for actions invoked by the user. These actions include selecting a quota project for Google API requests; discovering and displaying projects; reading, searching, comparing, and exporting Remote Config data; creating local caches and drafts; validating candidate templates; and applying changes selected by the user. It also uses Google data to list Firebase apps, show their registered details, and download their SDK configuration when the user runs an apps command.

Depending on the command, an explicit user action can publish or restore a Remote Config template, roll back a version, or delete a selected Remote Config experiment or rollout. fbrcm does not perform these remote mutations for advertising, profiling, analytics, or any purpose unrelated to its visible Remote Config management features.

Local storage

fbrcm stores application state only on the user's machine unless the user explicitly sends or copies it elsewhere. The exact paths can be inspected with fbrcm doctor, fbrcm profile path <profile>, and fbrcm auth path <auth-id>. Use fbrcm cache path --kind apps for the active profile's Firebase app cache.

By default, fbrcm stores configuration under .config/fbrcm in the user's home directory, unless the user configures an XDG or fbrcm path override. fbrcm stores caches in the operating system's user-cache directory, such as ~/Library/Caches/fbrcm on macOS, ~/.cache/fbrcm on many Linux systems, or the local application-data directory on Windows. The FBRCM_CONFIG_DIR and FBRCM_CACHE_DIR environment variables can override these roots.

Stored data can include:

• user-imported OAuth client configuration and service-account key files in the profile configuration directory;
• OAuth access and refresh tokens in a profile cache file named token.json;
• the local authentication registry and project metadata, including quota project IDs explicitly configured for an authentication identity or project;
• complete Remote Config template caches and historical version snapshots;
• complete base and edited Remote Config templates in local drafts; and
• cached Firebase app inventories, platform-specific app details, and downloaded SDK configuration files.

OAuth tokens are stored as plaintext JSON files, not in an operating-system keychain. fbrcm creates credential, configuration, cache, and draft files with private permissions where the operating system supports them. Google Cloud CLI Application Default Credentials remain managed by Google Cloud CLI; fbrcm uses them through Google's authentication library and does not copy them into an fbrcm credential file. A token supplied to stateless mode through FBRCM_GOOGLE_ACCESS_TOKEN is used in memory and is not persisted by fbrcm.

Official release binaries include fbrcm's built-in OAuth Desktop client. fbrcm does not store this client in the user's profile configuration.

The separate bring-your-own oauth method stores the client JSON selected by the user.

fbrcm uses a quota project ID from GOOGLE_CLOUD_QUOTA_PROJECT or Google Cloud CLI Application Default Credentials at runtime. It does not copy the ID into fbrcm configuration unless the user explicitly saves it as an authentication identity or project setting.

Command output, HTTP logs, and files written to an explicitly selected export destination may contain Google data. This can include configured or effective quota project IDs and information about how a quota project was selected. Terminal software, shell history, CI systems, backups, or other programs chosen by the user may retain that output independently of fbrcm.

Network transfers and sharing

For its Google integration, fbrcm sends OAuth credentials and Google data only to Google's OAuth services, the Google Cloud Resource Manager API, the Firebase Management API, and the Firebase Remote Config API as needed for the requested operation. Google handles these transfers under its own terms and privacy policies. fbrcm does not sell Google user data, share it with advertisers or data brokers, or transfer it to the fbrcm developer or a developer-operated service.

Authenticated requests to the Google Cloud Resource Manager, Firebase Management, and Firebase Remote Config APIs include the effective quota project ID in the X-Goog-User-Project request header. Google uses this project as the consumer for request quota and billing. fbrcm may also ask Google Cloud Resource Manager whether the authenticated identity has the serviceusage.services.use permission on that quota project.

fbrcm does not transmit Google user data through publication hooks by default. Hooks are opt-in, disabled unless configured, and execute only local commands supplied or explicitly trusted by the user. When a hook is configured, fbrcm provides it with temporary files containing the current, candidate, and, after publication, published Remote Config templates. A hook can transmit that data wherever its author programmed it to do so. Repository hooks require explicit trust, but global hooks are controlled by the user and are trusted automatically. Users are responsible for the privacy behavior of hooks, proxies, scripts, pipes, and other programs they configure around fbrcm.

Security

fbrcm uses HTTPS for Google API and OAuth traffic, requests only the Google data needed by its implemented features, applies IAM authorization at Google, uses private local file permissions where supported, and redacts known credential fields from application error output and HTTP logs. Because locally stored tokens and templates are not encrypted by fbrcm, users should protect their account, device, backups, configuration directory, and cache directory against unauthorized access.

Retention and deletion

The fbrcm developer does not retain Google user data because fbrcm does not send that data to a developer-operated system. Local data remains until it is replaced or the user deletes it. A credential may expire or be revoked without its local file being removed. In particular, cached historical templates and drafts do not have an automatic retention deadline and can remain after Firebase no longer retains the corresponding version.

Users can remove local data with the following commands:

• fbrcm auth delete <auth-id> removes an fbrcm identity and its locally stored imported OAuth client, token, or service-account key files;
• fbrcm cache clear removes cached Remote Config snapshots and Firebase app data, including downloaded SDK configuration;
• fbrcm draft discard --all removes all drafts in the active profile;
• fbrcm projects forget removes tracked projects and their associated template caches, version snapshots, drafts, and Firebase app caches; and
• fbrcm profile delete <profile> removes a non-active profile's complete configuration and cache directories.

Users can also inspect the paths listed above and delete the fbrcm configuration and cache roots manually. Removing local credentials does not revoke an OAuth grant at Google. To revoke the grant, visit Google Account third-party access. Service-account keys and Google Cloud CLI credentials must also be revoked or removed through the corresponding Google Cloud or Google Cloud CLI controls.

Deleting local fbrcm data does not delete Firebase projects, registered Firebase apps, downloaded configuration stored elsewhere, or Remote Config data already published to Google. Remote data can be changed or deleted only through the applicable Firebase or Google Cloud controls and APIs. fbrcm does not provide a command to create, change, or delete a Firebase app.

Changes to this policy

Changes to fbrcm's handling of Google user data will be reflected in this policy. When required, fbrcm will also update its OAuth disclosures and request new consent before using Google user data for a materially different purpose.

Contact

For privacy questions, email yumaa.verdin@gmail.com or open an issue in the fbrcm issue tracker.