How Emberdesk handles your Firestore credentials

You're connecting a tool to your production Firestore. Before you do, you should know exactly what happens under the hood: who holds what, what we can access, and how to walk away if you change your mind.

This isn't a legal page. It's a plain-language breakdown of how Emberdesk works, written for developers who read code and ask hard questions.

Our trust model

Every tool that connects to your cloud resources creates a trust relationship. Here's ours, stated plainly:

If you use our app, you're trusting us the way you trust any OAuth-integrated SaaS product; we hold an encrypted credential that lets us act within the scopes you granted.

We think this is worth saying upfront because most tools bury it. We'd rather you make an informed decision than a fast one.

---

What happens when you connect

Emberdesk is designed to be stateless with respect to your data. We don't replicate your database, build internal copies, or run background processes against it. If you're not using Emberdesk, nothing is happening.

1. You sign in via Firebase Authentication, establishing your identity within Emberdesk.
2. You connect with Google OAuth. Google shows you exactly what access you're granting.
3. You approve, and Google sends an authorization code back to our server. The code is exchanged server-side, and your refresh token never touches the browser.
4. We encrypt your refresh token using industry-standard encryption and store it in our application database. Encryption keys are managed separately from application data.
5. Every API call you make is bound to your authenticated session. Requests are scoped to your session and resolved against credentials stored under your user ID. We design the system to prevent cross-user access through strict per-user credential isolation.

That's the full loop. No background syncing. No hidden processes.

---

What permissions we request and why

When you connect your Google account, you'll see two permission scopes on the consent screen:

Manage Firestore / Datastore data

This is required to list databases, browse collections, run queries, and edit documents you explicitly interact with in the Explorer.

We don't perform background writes or modify data you haven't touched. Any write operation only happens as a direct result of an action you trigger in the UI. Emberdesk does not perform autonomous writes.

View Google Cloud project metadata (read-only)

This is required to list your GCP projects, show available Firestore databases, and display the Google account you're connected with.

That's it. We request what's needed to make the product work and nothing beyond it.

What this means in practice: Emberdesk can only access projects and data that your Google account already has permission to access.

---

How we protect stored credentials

Your Google refresh token is the most sensitive thing we hold. Here's how we treat it:

• Encrypted and server-side only. Tokens are encrypted and never exposed to client code or the browser.
• Scoped to your identity. Credentials are stored under your unique user ID and retrieved only when you make authenticated requests.
• Isolated by design. We design the system to prevent cross-user access through strict per-user credential isolation.
• Not exposed to secondary systems. Credentials are not sent to logs, analytics platforms, or third-party tools.

If someone accessed our database, they would find encrypted data, not usable credentials.

Like any SaaS, security also depends on infrastructure. We restrict access to credentials to server-side services only and keep them isolated from logs, analytics, and external systems.

---

How to disconnect

We built disconnection as a first-class feature.

When you click Sign Out & Forget:

1. We attempt to revoke your Google token directly with Google's API.
2. We hard-delete your stored credentials and active connection data. After deletion, we have no technical ability to act on your behalf.
3. Your session ends.

As a backup, you can always visit Google's third-party app access settings and revoke Emberdesk manually.

You're never locked in. Once disconnected, there is nothing left that allows us to access your account.

---

What we don't do

• We don't copy or store your Firestore data.
• We don't replicate or index your database into our own systems.
• We don't run background jobs against your database.
• We don't access your projects unless you actively use the app.
• We don't share your credentials with third parties.
• We don't use your data to train models or feed AI systems.

---

Why this model is safer than typical tools

Many internal tools and admin dashboards work by copying or indexing your data into their own systems.

That creates a second surface area to secure.

Emberdesk avoids that entirely. We operate directly against your existing permissions, in real time, without building a parallel data store.

Less duplication means less risk.

---

The bottom line

Emberdesk follows a standard, defensible pattern for tools that integrate with Google Cloud: Firebase for identity, server-side OAuth for credential exchange, encrypted storage for tokens, and strict per-user scoping on every API call.

More importantly, we've intentionally limited what the system does: no background access, no data replication, no hidden processes.

Whether this is "safe enough" depends on your threat model and your comfort with the trust relationship, same as any tool you connect to production infrastructure.

We've tried to make that decision as informed as possible by showing you exactly how it works.