Privacy
Your car’s data is yours. Here’s exactly how we keep it that way — in plain English, no fine-print surprises.
The short version
It’s the part no other Tesla logger offers. We designed BlackCurrent so that holding your data and reading your data are two different things: we hold it, you hold the key. You stay in control of the key, so you stay in control of the data — and we never have to ask you to just trust us.
What this means for you
- A breach of our database hands the attacker ciphertext — useless without your passphrase.
- Our own team only ever sees ciphertext in storage. There is no internal “view this user’s drives” switch.
- If we’re ever acquired, or handed a request for your history, we can only pass along ciphertext. We can’t decrypt what we don’t hold the key for.
- No analytics, ad-targeting, or data-brokering on your content — the architecture doesn’t allow it, even if we wanted to.
- Our only business model is your subscription. That’s the deal.
How it works
When you sign up, your passphrase produces a private key on our server. We lock that key with your passphrase — using a deliberately slow password-strengthening process designed to make brute force impractical — and store only the locked blob. Your passphrase is discarded before the signup request returns.
When you log in, we briefly re-derive the key, unlock your encryption key, re-lock it with a short-lived session secret, store the session-locked version in our cache, and forget the passphrase again. Each page you load decrypts only as much data as needed to render that page, in memory, then discards it.
When your Tesla sends us new telemetry, we can only write — we seal each batch to your public key so that we can’t read it back until you log in.
What we see, and what we don’t
| We see (always) | We see (only while logged in) | We never see |
|---|---|---|
| Your email and a locked copy of your encryption key | The decrypted contents of whatever page you’re loading | Your data when you’re logged out |
| Your subscription status | Your drives, charges, or battery history in backups | |
| Your car’s identifier (so we know where to route the data) | Exported data you download to your own device | |
| Your public key (cannot decrypt anything) | Analytics aggregates across users | |
| Timestamps, byte-counts, error rates | Your passphrase (after login completes) |
What we subscribe to from your Tesla
Tesla’s Fleet Telemetry lets us pick a precise list of signals the car streams to us. We pick broadly across signal categories that drive existing features and ones we expect to ship in the next 6-12 months. The reasoning: adding a signal later costs months of historical accumulation before any feature built on it has data to render. The cheaper direction is “collect now, build later”. Every signal is encrypted with your key before it lands in our storage, so breadth of collection does not change who can read it (still only you).
The full signal list — every category we receive, and what each one powers
| Category | What it powers |
|---|---|
| Vehicle state (awake / asleep / driving / charging) | The dashboard knows whether your car is talking; session detection (drives, charges) reads from this authoritative signal rather than guessing from speed or charge state |
| Energy & battery (state of charge, range estimates, pack voltage / current, brick voltages, module temps) | Battery-health view; range planning; long-term degradation tracking |
| Charging (state, amps, power, energy in, time to full, charge limit, charger phases) | Charging log with kWh / km / cost summaries; fast charger vs home detection |
| Driving (speed, gear, location, heading, GPS state, odometer, drive rail) | Live drive tracking; per-trip distance and average speed; map traces |
| Climate / thermal (inside / outside temperature, battery heater state, preconditioning, low-power-to-heat warning) | Cabin temperature history; cold-weather range adjustment; preconditioning trigger detection |
| Tires (pressure x 4 and last-seen-pressure timestamp x 4) | Tire pressure log; gradual leak detection |
| Scheduling / planning (scheduled charging start / mode / pending, departure time, Supercharger trip planner) | Confirm your settings match what the car is actually doing; trip planning history |
| Vehicle metadata (firmware version, vehicle name, vehicle config: model, trim, color, wheels, regional flags) | Firmware-update history; correlate behavior changes with updates; range modeling defaults match your car |
| Cruise control state (set speed, follow distance) | Adaptive-cruise pref history; “you set 130 km/h on this autobahn stretch”. Doesn’t add disclosure risk: your speed at any point in space is already covered by the driving signals above |
| Sentry mode state | Power-drain insights: cross-correlate sentry-on duration with state-of-charge delta to compute “your sentry cost 0.8 kWh overnight at the airport” |
| Self-driving stats (lifetime miles, FSD miles since reset; HW4 cars on firmware 2025.44.25.5+) | Aggregate counters only (not per-event records), so they describe usage totals without reconstructing individual FSD episodes |
| Trip context (destination name + ETA, miles / minutes to arrival, expected SoC at arrival, traffic delay, located- at-home / work / favorite flags) | “You arrived home at 18:42 with 32% SoC”; geofence-aware features |
| Software update progress (version, download %, install %, scheduled start) | “Update available / installing now” affordance; firmware-version history |
| Powertrain thermals (heatsink / inverter / stator temps, high-voltage interlock state; front + rear) | Drive-unit degradation tracking; correlate hot-day performance loss |
| Powershare / V2X (status, hours left, instantaneous power, type, stop reason) | “Your house drew 4.2 kW from the car overnight” for users with Powershare |
| Now playing media (status, source, title, artist, album, station; no playback position or volume) | “Soundtrack of this drive”. Position + volume excluded as low-value and high-frequency |
| User preferences (24-hour time, charge / distance / temperature / tire-pressure units) | Drives how we render every numeric on the dashboard. Without these we have to guess |
What we deliberately don’t subscribe to, and why
Tesla emits many more signals than we pick up. The exclusions below are not arbitrary — they are a brand promise. Encryption protects the data from us, but the simple existence of evidentiary data in your account invites third-party subpoena in crash / insurance / law-enforcement disputes. At that point you would be the one compelled to produce your key. Not collecting it sidesteps the conversation entirely.
| What we don’t collect | Why not |
|---|---|
ADAS / collision warnings (BlindSpotCollisionWarning,
ForwardCollisionWarning,
LaneDepartureAvoidance,
EmergencyLaneDepartureAvoidance,
SpeedLimitWarning,
AutomaticEmergencyBrakingOff)
|
Insurance and litigation discovery target |
Pedal positions (BrakePedal,
BrakePedalPos, PedalPosition)
|
Collision-fault reconstruction target |
Seat occupancy and seatbelts (DriverSeatBelt,
PassengerSeatBelt, DriverSeatOccupied)
|
Identifies who was in the car; civil discovery target |
Cabin surveillance (DoorState, Locked,
FdWindow, FpWindow,
RdWindow, RpWindow,
SeatHeaterLeft, SeatHeaterRight,
SeatHeaterRear*,
GuestModeMobileAccessState)
|
Establishes physical presence and access timeline that nothing else we collect can derive |
None of these are precluded by Tesla’s API; we simply do not ask for them. If a future feature genuinely needs one we will explain why on this page and ship a per-vehicle opt-in rather than flipping it on for everyone.
Historical accuracy and the “quiet car” case
Tesla’s telemetry only emits a signal when its value changes. A car parked for a month emits very little. To make sure that scrolling back to last month’s view of (say) state of charge still shows a chart instead of an empty band, we ask Tesla to re-send key signals at a fixed cadence even when nothing changed. The re-send is rate-limited and only kicks in on firmware 2024.44.32 or later; older firmware still works, the chart just thins out in quiet periods.
How cloud encryption fits in
Three layers of encryption sit between an outside attacker and your vehicle data. Each defends a different threat. Only one of them makes the privacy claim hold. We want to be precise about which is which because saying “we encrypt everything” without distinguishing who holds which key is the easy way to mislead.
| Layer | What’s encrypted | Who holds the key | What this defends |
|---|---|---|---|
| 1. Infrastructure | The underlying disks and storage | Our cloud provider, automatically | Lost, stolen, or decommissioned hardware. The disk is unreadable to anyone outside the provider without a valid request. |
| 2. Platform | Audit logs, Tesla’s permission tokens, your session-locked encryption key | The cloud provider, on our account | Compromise of our application code or operator credentials. An attacker with our credentials still has to call the provider’s key service to unlock anything; those calls leave an audit record we can review. |
| 3. Your vehicle data | Every drive, charge, GPS point, battery cycle in our storage | You alone, derived from your passphrase | Everything else. The cloud provider can read Layers 1 and 2 under lawful compulsion. They cannot read Layer 3 because the key never reaches their hardware. |
What this means concretely:
- A lawful warrant served on the cloud provider can compel them to decrypt at Layers 1 and 2. They will hand over audit logs, Tesla’s permission tokens (giving the requester the same view of your Tesla that we have — Tesla’s live channel, not your historical data), and the ciphertext blobs that store your vehicle data. They cannot decrypt the blobs themselves; that needs your passphrase, which the provider has never seen and we discard immediately after login.
- A compromise of our code or operator credentials is bounded by the same architecture. Layer 2 is auditable — we can see who unlocked what session and when. Layer 3 is unreadable to us regardless of whether we’re compromised, because the unlocked encryption key only exists in memory while you’re actively using the app.
- A compromise of you (your passphrase, your device) is the one thing this architecture cannot defend against. That’s the inherent cost of holding the key yourself: nobody else can lose it, and nobody else can recover it for you. Write it down.
Where this all lives
All BlackCurrent infrastructure runs inside the European Union, on a well-known cloud provider, in a region governed by EU data-protection law. Your encrypted data never leaves it. We do not use third-party analytics, advertising networks, or data brokers.
The honest limits
No security design is absolute, and we would rather show you the edges than pretend there are none. Here they are in plain language, each with what we do about it — roughly in order of who should care. Most people will never touch any of them.
1. While you’re logged in, your key is briefly in our memory
Your encryption key lives in our memory during active requests. If our servers were compromised during your session, an attacker with access to that memory could read your data for as long as your session stayed open. Strict end-to-end encryption like Signal’s would rule this out; ours does not.
Mitigations we have in place:
- Aggressive idle session timeouts (default: log out after 30 minutes of inactivity).
- No plain readable copies ever written to disk or logs — enforced by a structured logger with an allow-list of safe fields.
- Production access is audited; every time the key service unlocks a session, that call is logged and reviewable.
If this specific threat is your primary concern, a self-hosted alternative like TeslaMate is a better fit.
2. A future, targeted court order is the one thing we can’t engineer away
If a government orders us to intercept a specific user’s future sessions, we cannot technically refuse. The data we already have at rest is useless to them (we can’t decrypt it without your key), but we cannot guarantee that a future session couldn’t be subject to a compelled intercept. We will publish a transparency report.
3. Tesla permission tokens are held with our key, not yours
Tesla’s permission tokens (what Tesla gives us to receive your data on your behalf) have to be usable while you’re offline — otherwise we couldn’t stream new telemetry into your account. These tokens are encrypted with our key, not with yours. We treat them as credentials to Tesla, not as your vehicle data. You can revoke them at any time from your Tesla account, and we delete them when you cancel.
4. New telemetry is readable for a moment as it arrives
When your car streams new data to our ingest server, that data exists in memory for a few hundred milliseconds before we seal it to your public key. It’s never written to disk or logs in that form. The piece of our code that does this sealing will be published as open source so you can verify the claim.
What this means in practice
If we get hacked — the stolen database, storage, or backups contain ciphertext only. The attacker needs every user’s passphrase, independently, to read anything.
If we receive a subpoena for your historical data — we hand over ciphertext. We cannot produce plaintext. We’ll tell you the subpoena happened if legally permitted.
If you want your data out — the “Export” function rebuilds a full copy of your data inside your live session and hands it to your browser as a file. Your browser receives plain readable data; our servers never persist it.
If you lose your passphrase — the data is gone for good. That’s the flip side of nobody else being able to read it: there is no “reset password” button that could decrypt your history, because no such button can exist without breaking the whole promise. Pick a passphrase you can remember and keep it in a password manager; that’s the one key to everything.
Verification
We encourage you to not trust our marketing. Three things help you verify the claim:
- The piece of code where plain readable data briefly lives (the live-stream sealer) will be published as open source at launch.
- The full architecture document is published alongside the code.
- A third-party security audit will be published before general availability.
This page is the plain-English privacy description. A separate legal privacy policy covering GDPR data-controller details, cookie information, and regional compliance language will be published before public launch. Questions: hello@blackcurrent.app.