Data residency and compliance
How Based stores campaign data, isolates electoral registers, and applies regional data safeguards.
Overview
This document explains where Based stores and processes information, which service providers are involved, and what technical safeguards apply. It supplements our Privacy Policy and is intended for campaigns, their advisors, and election and privacy authorities reviewing the platform. It describes technical and operational controls. It is not legal advice and does not replace a campaign's own obligations under the election and privacy laws of its jurisdiction.
Platform infrastructure
Based runs on Google Cloud and Firebase. The primary campaign database is Cloud SQL for PostgreSQL, hosted in Google Cloud's Canadian region (Toronto). It holds campaign contacts, canvassing records, volunteers, donations, events, expenses, and account records. The application runs on Firebase App Hosting backed by Google Cloud Run, currently in the United States. Campaign information is transmitted to and processed by these servers while requests are served. Connections between the application and the Canadian database are encrypted and travel over a private network path. Files uploaded to Based, such as campaign images, fonts, and other assets, are stored in Google Cloud Storage in the United States. Account creation and sign-in are handled by Firebase Authentication, and Based does not receive or store passwords in readable form. Credentials and encryption keys are kept in Google Secret Manager rather than in source code or the database. Information is encrypted in transit using TLS and at rest by the underlying storage platform. Certain sensitive information, including electoral register records, domain registrant details, and credentials for campaign-connected services, is encrypted with additional application-level keys before it is written.
Electoral register clean rooms
Where enabled, a campaign that is lawfully entitled to an official voter list may upload it to Based. This information is held under a separate control regime. There is one clean room per jurisdiction, and they are independent of each other. Electoral register files, the records parsed from them, official identifiers, derived indexes, and matches to campaign contacts exist only inside the clean room for their jurisdiction. The primary Based database holds no records from the list, only non-identifying control information such as which campaign uploaded the list, when it was uploaded, its retention deadline, status, and audit events with no personal information. The clean room is isolated by default. That means no matching, no display, no canvassing overlay, and no export unless a campaign explicitly enables the feature. When enabled, it allows only isolated matching and read-only display. It never permits writes into contact records, canvassing data, validated address data, email marketing, analytics, AI tooling, or any commercial dataset. Canadian lists are uploaded directly from the campaign's browser over TLS to infrastructure located in Canada and operated by a Canadian-owned and operated provider. The file is held only as an encrypted queue file and is deleted once processing finishes, whether successful or failed. United States lists are processed through the application and stored in a dedicated United States database instance, separate from the primary campaign database and reachable only over a private network path. Electoral register information never leaves the jurisdiction it originated in.
Encryption, keys, and matching
The complete original record supplied by the election authority is encrypted in memory before storage using AES-256-GCM with a data key unique to that list. The official elector identifier is never stored in readable form. Only a keyed one-way value derived from it is stored so duplicates can be recognized without retaining the identifier itself. Name, address, locality, province or state, postal code, and derived household and street keys are stored in readable form inside the clean room because matching a list to a canvassing area, route, or campaign contact requires exact key joins and name search. Date of birth, telephone number, email address, and every other supplied field remain inside the encrypted record. The readable fields are protected by the boundary around the clean room rather than by per-record encryption: a separate regional host, full-volume encryption, mandatory per-campaign row-level security, explicit per-list grants, deny-by-default reads, and an append-only audit entry for every read. The Canadian database's data directory is required to sit on a LUKS2 encrypted volume, and the installation refuses to proceed otherwise. The volume key is managed off the server and outside its snapshots. A snapshot, backup, or recovered disk therefore yields only sealed data.
Access control and auditing
Access is denied by default. A user must be authenticated, must belong to the campaign that uploaded the list, and that campaign must hold an explicit grant on that specific list. Row-level security is enforced at the database level and applies to every connection, including privileged ones. What is displayed against a campaign contact or a canvassing door is a read-only summary: name, address, and a masked elector identifier. Displaying it never decrypts the underlying record. The full record for an individual is released only on an explicit per-record request, which decrypts once and writes an access entry to both the clean-room audit log and the platform audit log. Every ingestion attempt is recorded, whether it succeeded or failed, with a row count and error code. That record contains no personal information and outlives the data, so there is an auditable history of every file a campaign attempted to load even after the data itself is gone. Request-body tracing, session recording, analytics capture, and error-payload capture are disabled on all routes that handle electoral register information.
Retention and purge
Each list is given a retention deadline when uploaded. Purge runs on that deadline or earlier at the campaign's request. Purge first sets the list's status so all reads are blocked. It then destroys the wrapped encryption key for that list and deletes the root record; cascading deletion removes the records, matches, indexes, grants, and clean-room audit entries. The uploaded file name is cleared. What remains in the primary database is a purge certificate and ingestion history, both of which contain no personal information. The campaign remains responsible for setting a retention deadline consistent with the rules of its jurisdiction and for destroying the list when required. Based does not retain electoral register information beyond its configured purge deadline.
Service providers
Google Cloud and Firebase provide hosting, database, file storage, authentication, and secrets management. Stripe processes payment and subscription information. Mailgun handles transactional email. Google Maps Platform, Canada Post, Smarty, Esri ArcGIS hosted layers, and OpenStreetMap/Nominatim provide address validation, geocoding, and map data. A domain registrar is used for campaigns that buy a domain. Address and mapping providers receive addresses and map geometry only; they do not receive names, supporter details, voter-identification data, or any electoral register information. The authoritative list of providers approved to process electoral register information is maintained in the signed data processing agreement. No provider other than those listed there may process it. Providers marked as campaign-connected are used only if a campaign chooses to connect them, such as Mailchimp or Klaviyo for email marketing at the campaign's direction.
Cross-border transfer and incident response
Information stored in the United States, or processed by providers outside Canada, may be subject to the laws of those jurisdictions, including lawful access by courts, law enforcement, and government authorities. This applies to uploaded files, authentication records, payment records, transactional email, and campaign information while it is processed by the application servers. It does not apply to Canadian electoral register information, which is stored and processed only in Canada on Canadian-owned and operated infrastructure and is not transferred out of that environment. If a security incident affecting electoral register information is identified, the response is to disable the feature immediately, revoke clean-room service identities, preserve only evidence containing no personal information, identify affected campaigns and lists, notify the privacy and election compliance leads, meet the notification deadlines of the applicable jurisdiction, rotate credentials and keys, validate purge, and record the response without copying any record from the list. For other incidents, we investigate, contain, and notify affected campaigns, individuals, and regulators where required by law.
Campaign responsibilities
Based provides the technology. Campaigns remain responsible for being lawfully entitled to any voter list they upload and using it only for purposes the issuing authority permits; setting a retention deadline consistent with their jurisdiction; ensuring the lawfulness of the information they collect and enter into Based and any notice or consent their jurisdiction requires; meeting their own campaign finance, reporting, and recordkeeping obligations; managing who on their team has access; and reviewing anything they export or connect to the platform. Based cannot replace a campaign's legal obligations under election and privacy law.