Legal
Privacy Policy
What we do with personal data, on what legal ground, and what you can ask us for. Written against the code, including where the code is less comfortable than a template would be.
1. The short version
- Your private plans are private. We do not sell personal data, give it to advertising networks, or train machine-learning models on your designs.
- Analytics is off until you accept the banner, and the core service works if you never do.
- Declining the banner does not stop everything. Authentication, hosting, maps and checkout still involve the providers listed below, because the service does not run without them.
- Anything you publish or submit is public or goes to the body you sent it to. That is the feature, and it is not undone by deleting the original.
- You can ask for a copy, a correction or a deletion at hello@streetshape.org, without a form and without giving a reason.
2. Who is responsible
Daniel Halabi, Sole trader (Einzelunternehmen), at [serviceable postal address — the address the Impressum, the Terms and the withdrawal notice are all served at] in Germany, is the controller for the processing where StreetShape decides the purposes and the means. Write to hello@streetshape.org.
There is no data protection officer. The statutory trigger in §38 BDSG is twenty people constantly engaged in automated processing and we are nowhere near it — and an operator cannot be their own officer in any case, because the role exists to be able to audit the controller. That is not the whole test, though: an activity that requires a data protection impact assessment obliges an appointment however few people there are, and whether the civic features reach that threshold is one of the open questions listed at the top of this page. The address above is monitored either way.
Art. 27 GDPR — the EU representative a non-EU controller has to name — does not apply, because the controller is established in Germany.
3. What this policy covers
The website, the editor, accounts, collaboration, public participation, street reports, support and the administration behind all of it. It also explains where an institution or another provider is responsible for its own processing — which does not remove our responsibility for what is done on our behalf.
4. What we collect, and why
Each row below is an activity rather than a category of person, because the lawful ground follows the activity. Where a municipality or another organization decides the purpose, the row says so: their ground is theirs to identify, and ours does not cover it.
| Activity | What is involved | Purpose and ground |
|---|---|---|
| Accounts and sign-in | Email, user id, profile name or picture, the linked sign-in method, authentication and security events. Clerk holds passwords and authentication secrets, not us | Running your account — Art. 6(1)(b). Keeping access secure — Art. 6(1)(f) |
| Plans and collaboration | Geometry, coordinates, titles, descriptions, saved versions, thumbnails, generated files, preferences, collaborator addresses and permissions | Providing the editor, storage, export and sharing you ask for — Art. 6(1)(b) |
| Subscriptions and grants | Tier, entitlements, usage counts, billing identifiers, purchase status, academic email, institution and application details, sponsored-access links | Supplying the access you asked for — Art. 6(1)(b). Administering authorized organizational use where the organization is the customer — Art. 6(1)(f) |
| Billing records | Transaction references, invoice and tax information, payment status, and the limited information Paddle passes back. Card details never reach us | Administering the contract — Art. 6(1)(b). Accounting and tax duties — Art. 6(1)(c) |
| Civic participation | Proposal snapshots, comments, support actions, survey responses, location, visibility choices, moderation reports and decision records | Providing the participation you asked for — Art. 6(1)(b). Protecting the service and the people in it — Art. 6(1)(f). Specific legal duties — Art. 6(1)(c). An institution running the process has its own ground |
| Residency verification | Email, municipality, verification or matching status, the account link, and administrative records supplied by authorized municipal staff | Administering eligibility to take part. Our own matching rests on Art. 6(1)(b) or (f); the municipality identifies the ground on which it collected and supplied its register |
| Street reports | Description, coordinates, photographs, contact details if you give them, handling history and related messages | Recording and routing the report you asked us to send — Art. 6(1)(b), or Art. 6(1)(f) for correspondence outside a contract. A receiving authority's own purposes need its own ground |
| Enquiries and applications | Contact details, role, organization, message and attachments in support, demo, student or funding enquiries | Answering a pre-contractual enquiry you made — Art. 6(1)(b) — or other correspondence — Art. 6(1)(f) |
| Running the service securely | IP addresses in infrastructure logs, user agent, requested URL, error details, session and access records, rate-limit events and pseudonymous abuse identifiers | Our interest in a secure, reliable service that is not being abused — Art. 6(1)(f) |
| Optional analytics | A short list of named product events, your account id when signed in, the page you landed on, the referring hostname, campaign tags and the time to signup | Consent — Art. 6(1)(a) — together with consent to the device storage where that is required |
| The country a signup came from | A country inferred from the request, including a country code written onto the signup record | Currency presentation. The stored country code is a separate question: it is written whether or not the banner was accepted, and its purpose and ground have not been settled. It is listed in the open items at the top of this page rather than given a ground it may not have |
| Updates you asked for | Address and preferences for a waiting list, digest or update you signed up to | Consent where consent is required. Essential service notices go out on the contractual or legitimate-interest ground instead |
| Funding administration | Nomination, assessor, recipient and contributor details, conflict declarations, contribution and ledger records, and authorized public disclosures | Programme administration and transparency. The purpose-specific grounds are not documented yet and are in the open items; contributors are told more before any payment or publication |
Where we rely on a legitimate interest, we weigh what is necessary against the effect on the people involved, and you can object — see your rights. We do not use that ground as a way around consent where consent is what is required.
Anything marked as required is needed to provide the feature or to meet a stated legal requirement. Optional information, analytics and updates are optional, and declining analytics does not restrict the core service.
5. Where the information comes from, and what it can reveal
Most of it comes from you, or from your use of the service. Some reaches us from elsewhere: the sign-in provider you chose, Paddle, a collaborator who invited you, an organization administrator, a municipality supplying authorized residency information, or somebody reporting content. We use it for the purpose it came for. Where we get personal information indirectly we provide the required information within the statutory period, unless a lawful exception applies.
Civic content can be sensitive, and the old wording denied it
This page used to say we do not collect information about politics, health or anything else sensitive. A consultation response about a school crossing, a survey answer about why you cannot cycle to work, a comment tied to a point on a map — any of these can reveal a political opinion, a health condition or something else that Art. 9 treats specially, and saying otherwise did not make it so.
So: please do not include personal information about yourself or anybody else that a submission does not need, identity documents, or private matters unconnected to it. Processing identifiable sensitive data needs both an ordinary ground and one of the Art. 9(2) conditions on top of it, and an account agreement is not a blanket permission for it.
6. Who can see your plans, and institutional access
Private plans are private as against other users. Authorized staff and the providers below process them where that is necessary to run, secure or support the service.
- A collaborator gets the permissions you grant.
- A share-link holder can open the content until the link expires or is revoked.
- A public plan or civic submission can be seen by anyone, may be indexed, and may be reachable through public interfaces where those are enabled. An unlisted page is not a promise of confidentiality.
- Submitting to a consultation or board can create a separate snapshot held by that organization, and public if the setting says so.
Whose responsibility an institutional feature is
Where a municipality or institution decides the purposes of a consultation, a register or a report-handling process, it is responsible for its own role and for giving you its own privacy information. We act as its processor only for what we actually do on its documented instructions under the arrangement in place. We stay the controller for our own account, billing, security and platform administration. Whether any of it amounts to joint control is a question to be answered per feature, and it is in the open items rather than assumed away.
Before an institutional feature collects anything, its own notice should identify the responsible organization, the recipients, the public visibility and the retention rules. If that is missing, please tell us.
A municipality funding your account does not thereby get your unrelated private plans. Its authorized staff can reach its residency register and the submissions and organizational information for the services it administers.
7. Maps, address search and analytics
Maps
Map tiles are normally requested by your browser directly from MapTiler, which exposes your IP address, your user agent and the area and zoom you are looking at to them.
Address search
Our server forwards the text you type to Photon, and to Nominatim when it has to. The integration does not forward your IP address to either — but the query itself can contain personal information, because an address usually is one.
Searches and results are cached by our server for ten minutes, and responses may be cached by your browser for five. Request information can also appear in infrastructure logs. This page used to say search text is never stored anywhere; that was wrong, and the caches are what it was wrong about.
Analytics
If you accept the banner, we record campaign attribution and send a short list of named product events from our servers to PostHog, where that integration is enabled. A signed-in event carries your account id. Your browser never contacts PostHog, so no session replay, no heatmaps and no unrestricted capture of what you type.
We also keep aggregate counts of how many people reached each step. The stored totals are designed not to identify anybody — but the requests they are counted from still pass through our systems, and producing an anonymous total at the end does not make the collection before it exempt. Whether that collection needs consent is in the open items.
What declining actually stops
Declining stops the attribution cookie and the events sent to PostHog. It does not stop Clerk from authenticating you, Vercel from serving the page, MapTiler from receiving a tile request, Paddle from running a checkout, or our own servers from logging a request. The old wording — that nothing reaches any outside provider if you decline — was not accurate.
We do not sell personal data, pass it to advertising networks, or use your plans to train machine-learning models.
9. Where it is processed
Processing or remote access outside the EEA needs a transfer ground — an adequacy decision, or standard contractual clauses with whatever supplementary measures are required. Relying on the EU–US Data Privacy Framework means checking that the recipient’s certification is current and that it covers the transfer, which is a thing to look up rather than a thing to state, and the table above now marks it as unchecked rather than claiming it.
An EU server region is not the same as EU-only access. Support, administration and logging can reach a project from elsewhere, and that is what the transfer ground has to cover.
Ask us at hello@streetshape.org about the safeguards for your data, or for a copy of the relevant ones, subject to protecting what is genuinely confidential in them.
10. How long it is kept
We keep identifiable information for the purpose it is for, for a legal obligation, or for a claim period that is actually necessary. Several rows below are open questions rather than periods, and they are shown that way on purpose: a category that nothing expires from is over-retention, and calling it “until you ask” does not make it a retention period.
| Data | Kept for | Why |
|---|---|---|
| Your account, your plans, their versions and your preferences | While your account exists | It is the service. All of it is removed by the database when the account row goes |
| Plan thumbnails and generated files in file storage | While your account exists | Deleted by the account-deletion webhook, because storage objects have no foreign key to cascade along. A file attached to a submission a municipality holds separately is on that submission's schedule instead |
| Subscription and entitlement records | While your account exists | They are what your account is allowed to do |
| Payment, invoice and tax records | [which accounting records fall in the 10, 8 and 6-year tiers of §147 AO — the periods differ by document class and run from the end of the calendar year, and the old ten-years-for-everything line was over-retention] | German accounting law, which does not leave us a choice. It is why deleting your account does not delete your invoices, and the only category where that is true |
| Collaboration invites you sent or received | [when an invitation that is never accepted expires — it is an access grant sitting open, and "until somebody revokes it" is not a period] | An invite is how somebody else has access to a plan. A revoked, deleted or accepted one goes with the thing it was attached to |
| The email delivery log | 90 days, then deleted | So "the invite never arrived" can be answered from our own records rather than a provider dashboard. An erasure request removes yours sooner |
| Municipality demo requests, support messages and unsuccessful applications | [a period per category for correspondence — handling, then a justified follow-up or claims window. "Until somebody asks us to remove it" is not a retention period, it is the absence of one] | They are not tied to an account and are not deleted with one. An erasure request scrubs the address, name and message, but nothing expires on its own today |
| Student Pro applications | While your account exists | Deleted with the account, and needed while a grant is running. The supporting evidence behind an approved application is a separate question, below |
| Evidence supplied to verify a grant or an eligibility claim | [how long verification evidence is kept after the thing it verified is decided — the decision has to outlast it, the document usually does not] | Keeping the decision is necessary. Keeping the screenshot of a student card that produced it, indefinitely, is not |
| Waiting-list email addresses | [when a waiting-list subscription expires if the list is never used — it survives account deletion, because it was left without needing an account] | It is an address held against a thing that may not happen. Withdrawal removes it at any time, and a suppression record may remain so a withdrawal is not silently undone |
| Stored payment-provider webhook payloads | 30 days, then the payload is removed | Kept so a failed webhook can be replayed. The record that it arrived stays, so a repeat is still recognized; the body, which carries billing details, does not |
| The event identifiers left behind after a payload is removed | [how long the identifiers that survive a webhook payload are kept — they are what stops a duplicate, and they are still linkable to a transaction] | Removing the body and keeping the reference is the right trade. It does not make what is left anonymous |
| The record of what our staff did to your account | Indefinitely; the staff member's IP address and browser are removed after 180 days | Every action a member of staff takes on an account is logged, including the ones that were refused. It is how a mistake or a misuse is found afterwards, so it deliberately outlives the account it names — with the account id replaced by a one-way alias when the account is erased Still to decide: [a justified maximum for the staff audit log, and the rule that reviews it. The 180-day expiry of the identifying half is enforced; the row itself has no end] |
| Support sessions opened on your account | Indefinitely; the staff member's IP address and browser are removed after 180 days | You are emailed every time one happens; the row is what makes that promise checkable. A session is read-only and expires after thirty minutes Still to decide: [a justified maximum for the record of a support session — somebody here opening your account to help — on the same footing as the staff audit log above] |
| A copy of your data, once you have asked for one | 7 days, then it is deleted from storage | A permanent link to a complete copy of your account is a worse risk than the request it answers. The download link itself lasts fifteen minutes |
| Records of requests we refused for rate limiting or abuse | 30 days, then deleted | So a burst can be recognized while it is happening and acted on. The address is never stored — what is kept is a keyed hash of it that changes every quarter, which makes a pattern visible and the stored value useless on its own. While it is still linkable it is still personal data, and it is listed here for that reason |
| Where you first arrived from, if you accepted the cookie banner | [whether attribution should expire before the account does — it answers a question about a signup that stops being asked long before the account closes] | One row, written the first time you sign in: the page you landed on, the site that linked you, any campaign tags in the address, and how many days passed before you made an account. No IP address, no device fingerprint, no advertising identifier. Deleted with the account |
| The country a signup was made from | [the purpose and lawful ground for keeping a country code on the signup record. It is written whether or not attribution was accepted, which the privacy policy used to deny, and currency presentation does not need it stored] | Stated as a question rather than a row, because the honest answer is that it is recorded and the reason has not been written down |
| The cookie holding that information before you sign up | 90 days, or until it is read | It only exists on your own device, only if you accepted, and its whole job is to survive the gap between reading something we wrote and deciding to make an account |
| Named product events sent to PostHog, if you accepted | [the retention configured on the analytics project, and whether an erasure here propagates to it] | Our own copy goes with your account. Theirs is governed by a setting in their dashboard, and a policy cannot state a number that nobody has looked up |
| Counts of how many people reached each step | Kept indefinitely | Six numbers a week — how many landed, opened the editor, drew a road, saved a plan, signed up, paid. There is no row per visit and nothing in the stored totals is attached to anybody. That is a statement about what is kept, not about the requests it is counted from, which reach our servers either way |
| A nightly count of what your account holds | 90 days of daily figures, then one figure a month | How many plans, how much file storage, how many collaborators — so we can answer "is this account about to hit a limit" without opening it. Deleted with the account |
| The record that you asked for an export or a deletion | [how long the evidence of a rights request is kept after it is met — a justified period, rather than "kept"] | It is our proof that we did what you asked, and it is required for that. Once a deletion is carried out the row no longer names you: what is left is that a request was made and met, and a keyed hash that lets you ask us later what happened to yours |
| Photographs attached to a street report | 12 months after the report is closed, then the image is deleted | A photograph of a pothole in a residential street routinely contains parked cars with legible plates, house numbers, front windows and people. That the pothole was filled in is worth keeping; the picture of somebody’s front door is not, so the report, its text and its marks survive and the image does not. Every photograph also has its metadata, including its GPS tag, stripped on upload before it is written |
| A street report in a place where no municipality is receiving | 24 months, then the report and everything attached to it is deleted | Holding photographs of the public realm indefinitely against a customer relationship that may never exist is not defensible. You are told this when you send the report and reminded three months before it happens, and if a council starts receiving reports there in the meantime yours is handed to them and nothing is deleted |
| Consultations, surveys, public proposals, moderation decisions, residency registers and funding records | [a schedule per civic feature, and the controller each one belongs to. A municipality running a consultation sets its own period; where we set it, it has to be written down] | Each of these is kept for the process it belongs to and any legal obligation on the body running it, which is not one period and not always ours to set |
| Provider logs, and backups | [each provider's own log retention, and the maximum age of a backup before it expires] | Deletion reaches our active systems immediately. A backup expires on its own schedule and is protected from ordinary use, and a restore has to preserve an erasure that was already carried out — which is only true if somebody has tested that it does |
| Irreversibly anonymous statistical totals | Kept without a retention limit | Once a figure cannot reasonably identify anybody it is no longer personal data and there is nothing left to expire. The test is whether it can be re-identified, not whether a name was removed |
Statutory periods generally run from the end of the calendar year the record belongs to. A record kept for one remaining purpose is restricted to it. A legal hold covers only the records and the time actually needed.
Deletion is a process, not an instant
Deleting reaches our live systems immediately. Backups expire on their own schedule and are protected from ordinary use, and a restore has to preserve an erasure that had already been carried out — which is only actually true if somebody has tested that it is. That test is one of the open items.
Recipients acting on their own account — Paddle, a municipality — decide their own lawful retention. We help with a request that concerns them, within what is ours to do.
11. Staff access
Authorized staff can reach what they need for support, security, administration or a legal obligation, limited by what their role is. A support session opened on your account is designed to be read-only, to expire after no more than thirty minutes, to record who opened it and why, and to email you that it happened.
Those controls are real and they are not a guarantee that no administrator or provider can ever reach production data, or that a bug cannot expose something. The security page sets out what is in place and what it does not cover.
12. Your rights
Access, correction, erasure, restriction, portability, objection, withdrawal of consent and a complaint to a regulator — the data protection and your rights page explains each one and how to use it. Write to hello@streetshape.org; there is no mandatory form.
You can complain to a supervisory authority, including the one where you live, where you work or where you think the infringement happened. For a private-sector controller established in Bavaria that is the Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) (https://www.lda.bayern.de). You do not have to come to us first. Which authority it is follows the establishment, which is one reason the address at the top of this page matters.
Automated decisions
Technical limits, eligibility checks and abuse controls run automatically. We do not believe any of them produces a legal or similarly significant effect within the meaning of Art. 22, and confirming that is in the open items rather than asserted here as settled. If a decision affecting you looks wrong, write to us and a person will look at it.
14. Children
Individual accounts are for people aged 16 or over, which is Germany’s figure under Art. 8 GDPR. If we find an account that does not meet that, we assess it and act — restricting or deleting it where we have to, without destroying anything we are lawfully required to keep. Classroom use is not supported and is not invited.
15. Security and breaches
What protects this data, and what those protections do not promise, is on the security page — including what happens if there is a personal-data breach, who we notify and within what deadline.
16. Changes to this policy
We update this page when the processing changes, and bring a material change to affected users’ attention. A revised privacy notice does not by itself authorize a new purpose or stand in for consent that is required.
Daniel Halabi, [serviceable postal address — the address the Impressum, the Terms and the withdrawal notice are all served at] · hello@streetshape.org