Privacy Policy for googlymaps

Version 1.0, effective 25 August 2026.

This version has not yet been reviewed by a lawyer. It is published so the app can work and so you can read it before you sign up, and it is written to describe what actually happens rather than to sound reassuring. It is not a finished legal document, and it will be reviewed before googlymaps is offered widely. If anything here matters to you, say so: [email protected].

The version number above is not decoration. When this policy changes materially you will be asked to accept the new version before you can post a pin or report one again, and the record of what you accepted is stored against that exact version number. A typo fix does not bump it, because being asked to re-accept for a typo trains people to tap through without reading, which is worse than the typo. Browsing needs none of this: no account, and nothing to accept, ever. Section 2.10 has the full detail, including what happens to this record if you delete your account.

This policy explains what personal data googlymaps ("we", "us", "the app") collects when you use googlymaps.net and the googlymaps mobile app, why we collect it, who we share it with, and what rights you have over it. We've tried to write it in plain language rather than legal boilerplate. If anything is unclear, email us at [email protected].

googlymaps is operated from Australia. This policy is written to meet the standards of the EU General Data Protection Regulation (GDPR), which applies to us under Art. 3(2) because we offer the service to people in the EU, and it applies to everyone who uses googlymaps, wherever you're located. Where Australian privacy law imposes an additional or different requirement, we meet that as well.

See also our Terms of Use and our plain-language guide, How googlymaps works.

1. Who we are

googlymaps is operated by Mr Luca Intini, an individual trading as a sole trader in Australia (ABN 55 717 595 882), of U 36 18 Wellington St, East Perth WA 6004, Australia. We are the data controller for the personal data described in this policy.

Contact us about anything privacy-related, including the data-subject requests described in Section 6, at:

[email protected]

This is the only address we publish, and it is monitored. It is also the address for reports, appeals, takedowns, and legal notices. There is one mailbox, not several.

We have not appointed a formal Data Protection Officer, as one is not mandatory at our current scale under GDPR Art. 37. [NEEDS DECISION: DPO, whether a DPO becomes required as processing scales; revisit before launch and annually.]

1.1 Which privacy laws we apply to ourselves

We are based in Australia and our users are worldwide, so more than one regime is in play.

• GDPR. Because we offer googlymaps to people in the European Union, the GDPR applies to us directly under Article 3(2), even though we are not established in the EU. Everything in this policy (the legal bases in Section 2, the retention periods in Section 5, and the rights in Section 6) is written to that standard. [NEEDS DECISION: EU-REPRESENTATIVE, whether a representative in the Union must be designated under GDPR Art. 27, and if so, who; the exemption in Art. 27(2)(a) turns on whether the processing is occasional and low-risk, which precise-location photo publishing may well not be.]
• Australian privacy law. The Privacy Act 1988 (Cth) and the Australian Privacy Principles contain a small-business exemption for businesses with an annual turnover at or below A$3 million. We have not concluded whether that exemption covers googlymaps, and we are not asserting that it does or that it does not. [NEEDS DECISION: AU-PRIVACY-ACT, counsel must determine whether the Privacy Act 1988 (Cth) binds this operator, including whether any of the exceptions to the small-business exemption apply.]

What that means in practice. Whichever way the Australian question is answered, the commitments in this policy are the ones we make to you, and we make them to every user in every country, not only to those a particular statute happens to cover:

• we collect only the data listed in Section 2, for the purposes stated there;
• we publish only what Section 2.6 says we publish, and we publish it anonymously. A pin on the public map does not carry your name, your picture, your account identifier, or any pseudonym that would let a stranger tie two of your pins together;
• a pin carries no text you wrote, because there is nowhere in the app to write any (Section 2.3);
• nobody but you can list your pins. Your score and rank are public, your movements are not (Section 2.8);
• we keep data only for the periods in Section 5, and we tell you plainly about the things that outlive an erasure request: a ban record and the one-way blocklist hash in Section 2.9, the tax transaction record in Section 2.7, content preserved for a severe-safety report, and the record that you accepted a version of these documents, unlinked from your account, in Section 2.10;
• we honour the access, correction, deletion, objection, portability, and consent-withdrawal rights in Section 6 for anyone who asks, regardless of where they live;
• we do not sell personal data, and we do not let any provider train its own models on your photos; and
• we notify affected users of a data breach as described in Section 8.

2. What data we collect, and why

googlymaps has two modes: browsing the map (no account needed) and posting a pin (account needed). We collect different data for each.

2.1 Browsing the map

You can view the public map, published pins, and photos without creating an account or giving us any personal data. We still collect basic technical data (see Section 2.5) for site operation, security, and advertising, and we ask for your consent before storing or reading anything non-essential on your device (see Section 4).

2.2 Creating an account and signing in

To post a pin, you need an account. We collect:

• Email address (and password, stored hashed, so we never see or store your plaintext password)

• If you sign in with a third-party provider (for example Apple or Google), the identifier and email address that provider returns to us. We do not receive your password for that provider.

• Your date of birth, momentarily and only to check it. We ask for it once, when you first try to post, to enforce the minimum age in Section 7. We check it, we store a timestamp recording that you were confirmed to meet the minimum age, and we discard the date without ever writing it to the database. We do not hold your date of birth. What we hold is min_age_confirmed_at, a moment in time, and nothing else. See Section 7 for when the check runs and what this costs us.

• An internal account name. Your account carries a name so our own records and moderation tools make sense. It is never published: not on a pin, not on the public chart, not anywhere another user can see it. It is not the account number described in Section 2.8, which we assign and which is the only account-level identifier that ever appears in public.

  Where that name comes from matters, so here it is exactly. If you signed up on our own form and typed a name, that is the name. Otherwise we generate one of the form googly_ plus eight characters. In particular, we do not take the name your sign-in provider offers us. Apple and Google hand over a full_name and a name field, which for most people is their real name, and we deliberately ignore both: we never asked for your real name and an app whose pins are anonymous should not be quietly collecting one because of which button you pressed to sign in. You can set or change your own account name at any time, and nothing public depends on it.

• Basic account metadata (signup date, account status, enforcement history)

• The IP address used at signup and sign-in, for fraud and abuse prevention

• If you enable push notifications, a push notification token issued by Apple or Google

We do not collect a profile picture or avatar. There is no avatar field on a googlymaps account, we do not import a picture from Apple, Google, or any other sign-in provider, and we do not store an avatar URL. Earlier drafts of this policy and earlier versions of the app provided for one; it has been removed entirely, because nothing in the app displays it.

Why: to create and secure your account, let you sign in, notify you about your submissions if you opt in, and enforce our minimum age policy.

Legal basis: performance of a contract with you (GDPR Art. 6(1)(b)), we need this data to provide the account-based features you're signing up for. Providing it is a contractual requirement: without an email address or a third-party sign-in we cannot create an account for you, and without passing the age check we cannot let you post (Section 7). Either way you can still browse the map, which needs no account at all.

We also check your sign-in identifier against the blocklist described in Section 2.9. That check happens at signup, it is a comparison of one-way hashes, and it is how a permanent ban survives account deletion.

2.3 Posting a pin: location and photo

When you submit a googly-eyes pin, we collect:

• Precise GPS coordinates, read from your device's satellite fix at the moment you take the photo. This is the only way a pin gets a location. There is no manual placement: you cannot tap the map, drag a pin, or type in coordinates, and no other route to a location exists in the app.
• The accuracy of that fix, in metres, as your device reported it. A fix worse than 50 metres is refused outright; the app keeps requesting a sharper fix and keeps the best one it obtains, and settles for 50m only when the device cannot do better. The accuracy is stored and published with the pin (Section 2.6), as a radius drawn on the map and as a line on the pin's detail page.
• A photograph you take of the googly eyes
• The submission timestamp

There is no free text on a pin. A pin has no title and no description, and the app contains no field in which to write one. This is deliberate: our automated check (Section 2.4) examines images and only images, so any text a user could write would be text nobody had reviewed, published on a public map. Removing the field removes the problem. We therefore collect no pin text, store none, and publish none.

From your photo, our automated verification step (Section 2.4) also generates data about the photo, which we store separately from the photo itself:

• a short, model-written description of the object the googly eyes are attached to
• confidence scores and content-safety flags
• the raw model response and the resulting verdict

Why: the coordinates and photo are the pin. Without them there's nothing to publish. We send the photo (see Section 3) to an automated verification step that checks it genuinely shows physical googly eyes and contains no explicit or prohibited content before it can go public.

Legal basis: consent (GDPR Art. 6(1)(a)), and, for the automated verification decision, your explicit consent under Art. 22(2)(c). Posting a pin is something you choose to do, not something necessary to give you a basic account, so we rely on your explicit, freely given consent each time you submit a photo and location for publication and for automated review. You can withdraw this consent at any time, and withdrawing it removes the pin from the map and deletes it; see Sections 2.6 and 6.

EXIF and precise metadata: photo files from phones often carry embedded metadata (EXIF) that is more precise than the location we intend to publish, and can include information you didn't mean to share. The photo is stripped of EXIF, rotated the right way up and resized on your own device, before it is ever sent to us. No file carrying EXIF leaves your phone.

To be exact about the sequence, because "we strip EXIF" is routinely written in a way that implies more than it delivers, and because an earlier version of this policy said less than this:

• What reaches us has already been stripped, straightened and resized, to at most 2560 pixels on its long edge, over an encrypted connection. The camera's own file, EXIF and all, is discarded on your phone and never transmitted. (The in-app camera never produces such a file to begin with: it draws the live frame to a canvas, which is pixels only and carries no metadata from the start. It's the fallback file picker, used only when the camera isn't available, that hands back a file with EXIF, and that file is stripped on your phone before anything is sent.)
• That stripped, 2560-pixel copy is stored as the private original-of-record. It is not public and it is not served to anyone browsing the map. You can reach your own; a moderator can reach one when they are reviewing or deciding an appeal on it; nobody else can. This is what an appeal is decided against, and what the published copy is made from. 2560 pixels is about 60% more detail on the long edge than the 1600-pixel copy anyone else ever sees, which is the margin a moderator needs to look closely.
• The copy published on the map is resized again, to 1600 pixels, and stripped a second time on our own servers, independently of what your device did. We do not trust the device's word for it: the on-device strip is a promise, the server-side strip is the guarantee. The same 1600-pixel copy is what goes to the verification service.
• The stored original-of-record is deleted 14 days after a rejection, and with the pin or with your account otherwise. See Section 5.
• A photo your phone can't open is refused before anything is uploaded. Nothing is sent in that case; you're asked to take the shot again.

An earlier version of this policy said we did not keep an unstripped original. That was wrong when it was written, and was corrected to say the file kept was your camera's own, EXIF intact, which was accurate at the time. Performing the strip on your device, so that a file carrying EXIF never leaves the phone at all, was then a decided design change that had not yet been built. It has since been built, which is what has overtaken that second version and made this one necessary. Both corrections are recorded here rather than quietly dropped.

We do not perform facial recognition or any biometric analysis. Our content rules ask you not to make a person the subject of a photo (see the Terms of Use, Section 3). If a person appears anyway, we only ever look for googly eyes and prohibited content; we do not identify, match, or analyse faces in any way.

The submission limit doesn't involve collecting anything new. Your account may submit at most 10 pins in any rolling 24 hours (Terms of Use, Section 3.4), counting rejected submissions and pins you later deleted yourself. We enforce this by counting the submission records we already hold against your account under the retention periods in Section 5; no separate tracking data is created to run this limit, and nothing about it is retained for longer than those records already are.

2.4 Automated photo verification

Every submitted photo goes through an automated check (see Section 3 for who performs this) that decides one of three outcomes: publish, reject, or send to human review if the result is uncertain.

This is a form of automated decision-making under GDPR Article 22: a rejection can stop your photo from being published, without a person having looked at it first. We rely on your explicit consent (Art. 22(2)(c)), given at submission, as the basis for that automated decision. Here's what you're entitled to know about it:

• The logic: the system looks at whether the photo genuinely shows physical googly eyes attached to a real object, and whether it contains nudity, sexual content, gore, or other explicit material. It produces confidence scores; scores above or below fixed thresholds decide the outcome, and everything in between goes to a human.
• The significance: a rejection means your pin isn't published, and it is recorded as a warning against your account. It does not, by itself, ban you. What does is set out under "Enforcement" below and in Section 2.9.
• Uncertain cases are never auto-rejected outright. They're queued for a human reviewer. Grey areas in particular always go to a person: googly eyes attached to the backside of a classical statue in a public square is the standard example, and it is exactly the case an image classifier gets wrong. Nothing in that zone is refused by a machine.
• Your safeguards under Art. 22(3): you can express your point of view, contest the decision, and obtain human intervention. Every rejection comes with a reason and an appeal option, and appeals are decided by a person. Use the in-app appeal flow, or email [email protected]. You have 7 days to appeal, and the rejected photo is retained long enough that it still exists when the appeal is reviewed (Section 5).
• If you don't want an automated decision, don't post a pin. Browsing the map involves no automated decision-making about you.

Appealing is never held against you. An appeal made in good faith carries no penalty of any kind, whether it succeeds or fails. There is no strike, no warning, and no record counted against you for having disagreed with us and been wrong. We state this here, and in the appeal screen itself, because the opposite rule is self-defeating: if contesting a decision carried any risk, honest people would stop contesting decisions, and every false positive the classifier produced would become a user lost in silence. The appeal form therefore invites the awkward explanation rather than penalising it (tell us why this might look borderline), and an honest answer to that question is never evidence against you.

What is penalised is dishonesty, not error. The ladder is in Section 2.9.

Improving the classifier: we retain each verification verdict, the flags and confidence scores, the model-written object description, and the associated moderation metadata as labelled training and evaluation data, so we can measure how accurate the automated check is and improve it. We keep this even after the underlying photo has been deleted. This is a separate purpose from deciding whether to publish your pin, and it relies on our legitimate interest (Art. 6(1)(f)) in running a safe and accurate moderation system; you can object to it under Section 6. We do not send your photos to any provider for their own model training (see Section 3).

Severe safety findings: if the automated check or a human moderator finds content in a category involving a serious risk of harm, in particular suspected child sexual abuse material, we will suspend the account, preserve the material and the associated account and device data, and report it to the competent authorities and, where applicable, to bodies such as NCMEC or the relevant national hotline. We will not notify the account holder in advance where doing so would prejudice an investigation. See Section 3.

2.5 Technical and usage data

Like most web and mobile apps, we automatically collect some technical data when you use googlymaps: IP address, device/browser type, operating system, app version, approximate location derived from IP, pages and pins viewed, crash and error reports, and similar diagnostic information.

Why: to operate, secure, and improve the service, to detect and prevent abuse and rate-limit abuse of the submission flow, and to serve advertising (see Section 4).

Legal basis: legitimate interest (GDPR Art. 6(1)(f)) in running a secure and reliable service, and, for anything stored on or read from your device for advertising or analytics, and for any use of advertising identifiers, your consent, collected through the consent mechanism described in Section 4.

Reporting a pin without an account. You do not need an account to report a pin (Terms of Use, Section 5.1). Because that route is open to anyone on the internet, it is protected by a captcha and by a rate limit of five anonymous reports an hour from one source. Here is exactly what that costs you in data:

• We do not store the address a report came from. We store a one-way keyed hash of it, next to a counter and the clock hour. The hash cannot be turned back into an address, and the key it uses is held separately from it.
• The counter is not an event log. It records how many reports an hour a hashed source made. It holds no pin, no reason, no text, and nothing that joins a source to a report we received.
• It is deleted after 24 hours. That is the shortest retention period anywhere in this service, and it is deliberate: this is the only thing derived from an anonymous reporter that we hold at all.
• The report itself carries no reporter. Where a report is filed anonymously, the field that would name the reporter is simply empty, and it stays empty; a moderator cannot fill it in afterwards.

Legal basis: legitimate interest (Art. 6(1)(f)) in operating an abuse- resistant notice mechanism, and compliance with a legal obligation (Art. 6(1)(c)) in operating a notice and action mechanism at all under Art. 16 of the EU Digital Services Act, which requires that mechanism to be easy to access and not conditioned on holding an account.

2.6 Published pins on the public map, and why they are anonymous

Once a pin is published, three things are visible to anyone who views the map, with no account required:

1. the photo;
2. the precise coordinates; and
3. the accuracy of those coordinates, in metres, shown as a radius on the map and as a line on the pin's detail page.

That is the complete list. There is no description, because there is no description field (Section 2.3). A pin carries no text you wrote, no title, and no caption, anywhere, ever.

The coordinates are precise, not approximate: this is a map, and the point of a pin is to say exactly where the googly eyes are. Publishing the accuracy figure alongside them is a deliberate honesty measure: a pin good to 6 metres and a pin good to 48 metres are different things, and somebody walking out to find the eyes is entitled to know which they have. Think carefully before posting a pin at a location that would reveal where you live.

Pins are anonymous to the public. Nothing published alongside a pin identifies the person who posted it. Specifically, the public map does not show, and the public interfaces of the app and website do not return:

• your name, or any name your account carries internally;
• a profile picture or avatar, because we do not have one to show (Section 2.2);
• your account identifier or user id;
• your email address;
• the account number used on the public chart (Section 2.8), because that number appears on the chart and nowhere else, and never on a pin; or
• any other pseudonym, handle, initials, colour, badge, or per-user code that would let somebody work out that two different pins were posted by the same person.

That last point is the one that is easy to get wrong, so we state it deliberately: we do not publish a stable per-user token on a pin, of any kind. Two pins posted by you look exactly as unrelated to a stranger as two pins posted by two different people. The chart's account number is not an exception to this, because it is never attached to a pin and there is no way to get from it to one; see Section 2.8.

There is also no profile page: no screen, anywhere in the app or on the website, that shows one user's contributions to another user. Not a private one, not a partial one, not one you can reach by blocking, reporting, or ranking. The feature does not exist.

You can still see your own pins as yours. When you are signed in, your own pins are marked as yours in your own view of the map and in your account, so you can find them or delete them. That marking is computed against your own identity and is visible to you and not to anybody else.

Nobody else can list your pins. There is no screen in the app, and no address on the website, that returns the set of pins belonging to one account to anybody other than that account's owner. The public chart in Section 2.8 shows a score and a rank; it is not a doorway to a pin list, because no such doorway exists.

Blocking hides one photo, and that is deliberate. When you block from a pin (Section 6 of the Terms of Use), exactly that photo is hidden from you. The other pins posted by the same account stay where they are. We also record the block against the account, because an account that many different people block is a signal our moderators act on, but that record is never used to decide what you see and it is never shown to you.

This used to work the other way, and the change is the reason this paragraph exists. Hiding every pin belonging to a blocked account would have told the blocker which pins share an owner: exactly the cross-pin link this section promises the public cannot make, obtainable one block at a time and repeatable. An earlier version of this policy disclosed that as an unresolved leak. It is now resolved. The filter acts on the photo you named, a photo you had already been shown and already chosen, so what disappears tells you nothing you did not already know. Nothing in the block feature ever returns an identity: your hidden list shows you the photos you hid, not who posted them.

What that does not fix, stated in the same breath. When somebody deletes their account, every pin they posted disappears at once, so several entries can leave your hidden list in the same moment, which suggests those photos had one author. That is visible to anyone who records pin identifiers from the public map and watches for them to go, with no account and no block involved: it is a consequence of deleting content, not of blocking. We reduce it by carrying out account deletions in scheduled batches inside the 7-day window in Section 5, so several accounts go in one sweep. That mitigation gets stronger as the app grows, which means it is weakest now.

Who can still tell who posted a pin. We are not going to pretend the link does not exist, because it does, and we rely on it:

• We keep the link internally. Every pin is stored against the account that submitted it. That record is what lets us honour your deletion requests, answer an access request, and act on abuse.
• Our moderators and the operator can see it. When a pin is reported, when content is being reviewed or an appeal decided, when we are investigating abuse, evasion of a suspension, or repeated rule-breaking, and when we act on a takedown notice, the reviewer sees which account posted the pin and that account's enforcement history. Abuse handling does not work without it.
• We disclose it where the law requires, or in the severe-safety cases described in Sections 2.4 and 3.
• We do not tell a reporter who posted a pin. Reporting a pin gets you an outcome, where you gave us a way to reach you, and never an identity. See Sections 5.1A and 5.7 of the Terms of Use.

So the honest summary is: anonymous to the public, attributable to us. Anonymity here is a publishing decision, not a claim that nobody on earth could ever connect you to a pin.

Sponsored pins are the one exception. Sponsored pins are paid placements by businesses (Section 4, and Section 10.1 of the Terms of Use). They are labelled as sponsored and they are attributed to the sponsoring business, which is the whole point of what the sponsor is paying for. That attribution names an organisation, not a private individual, and it does not apply to any pin posted by a user.

Legal basis: your consent (Art. 6(1)(a)), given when you submitted the pin. This is the only basis on which we publish it. If you withdraw consent, or delete the pin, or delete your account, we stop publishing it and delete it, and we do not fall back on any other basis to keep it up. See Sections 5 and 6.

One thing anonymity does not do. A photograph and an exact location can identify you on their own, whatever name is or is not printed next to them, a pin outside your front door is a pin outside your front door. Publishing anonymously reduces what a stranger learns about you across your pins; it does not make any single pin safe to post from somewhere you would rather not be known to be.

2.7 Paying to remove advertising

googlymaps is free. You can also make a one-off payment that permanently removes advertising from your account: the "supporter tier". You never have to pay for anything, and paying changes nothing about the app except that the ads stop. The purchase terms are in Section 10 of the Terms of Use.

We never see or store your card, bank, or payment credentials. They are entered on a payment provider's own page or in your device's App Store or Google Play account, and they are never transmitted to us or stored on our systems. There is no circumstance in which googlymaps holds your card number.

What we receive and store depends on how you pay:

• On the web, payment is taken by Revolut. You enter your payment details with Revolut, not with us. Revolut tells us that a payment of a given amount and currency succeeded, and gives us a transaction identifier. We store that identifier, the amount, the currency, the date and time, and the fact that your account is now ad-free.
• In the iOS app, payment is taken by Apple; in the Android app, by Google. Apple and Google are the merchant of record for those purchases: they handle your payment details, your local currency, and any tax. What they pass to us is an opaque purchase token or transaction identifier and the identifier of the product you bought. They do not give us your name, your billing address, or your payment method.
• Across all three, we use RevenueCat to check that a purchase is genuine and to record that your account is entitled to an ad-free experience. RevenueCat receives the store purchase token or the web transaction identifier, an application-level identifier for your googlymaps account, and basic device and platform information such as your operating system and app version, so that buying on one device works on all of them.

We also receive, from Apple, Google and Revolut, aggregated payout and settlement reports covering money owed to us. Those reports are about transactions and totals, not about you individually.

Why: to take the payment, to prove the purchase is genuine, to give you the thing you paid for on every device you sign in on, to handle refunds, chargebacks, and support queries about a payment, and to keep the business and tax records we are required to keep.

Legal basis: performance of a contract with you (GDPR Art. 6(1)(b)) for taking the payment and delivering and maintaining the entitlement; compliance with a legal obligation (Art. 6(1)(c)) for keeping the transaction record for the period required by tax and business record-keeping law; and our legitimate interest (Art. 6(1)(f)) in detecting fraudulent or reversed payments.

Advertising identifiers are unaffected by paying, because there aren't any: once your account is ad-free we do not initialise the advertising SDK at all, so nothing ad-related is read from or written to your device. See Section 4.

Retention. See Section 5. The short version is that the entitlement lasts as long as the account, and deleting your account ends it permanently, we do not keep the payment identifiers that would be needed to restore a purchase to a re-registered account, because keeping them would undercut the erasure promise we make in Section 6. This is a deliberate trade, and Section 10 of the Terms of Use says so in the same words.

But the bare transaction record survives erasure, for five years. This is the one part of the supporter tier we cannot promise away, so we will not pretend otherwise. Australian tax and business record-keeping law requires the operator to retain records of transactions for five years, and a purchase is such a record. If you exercise your right to erasure under Section 6, we delete your account, your pins, your photos and the entitlement, and we retain the transaction record: the date, the amount, the currency, the payment rail, the transaction identifier, and any refund or chargeback against it. Its legal basis is compliance with a legal obligation (GDPR Art. 6(1)(c)), which is an express exception to the right to erasure under Art. 17(3)(b). It is never published, it is never used to restore a purchase to a new account, and it is held for that purpose and no other. If you would rather we hold nothing about you at all, do not buy the supporter tier, because the app is free either way.

2.8 Points, the public chart, and what stays private

Posting accepted pins earns points, and there is a public chart.

• 10 points for each different googly eye you post. Different is enforced, not assumed: each accepted photo is fingerprinted with a perceptual hash, a signature derived from what the image looks like rather than from the file's bytes, and compared with the photos already accepted from your account. A re-cropped, rotated, or recompressed photograph of the same googly eyes is recognised as the same googly eyes and scores once. The hashes are stored against your account for this purpose and are not published.
• Minus 1 point for a discarded photo. A photo that is rejected, or a pin that had already been published and is later taken down for breaching our content rules, is a discarded photo, and each one costs 1 point. Your score can go negative, deliberately. Nothing is deducted while a decision is still open: a photo waiting on its first review, or a rejection you are appealing, costs nothing until the outcome is final, so you are never penalised for a decision we have not yet made. Deleting your own published pin is a different action with a different cost, described in Section 2.8A.
• Public: your rank, your points, and an account number. The account number is a plain integer we assign, not a code and not something we generate to be unguessable. It starts at 0 for the first account ever created and counts up in the order accounts join, so your number is your place in that order. It is never reused: if an account is deleted, its number is retired, not handed to the next person who signs up.
• Private: your pins. Nobody but you can list the pins belonging to your account: not from the chart, not from the account number, not from a score, not through any interface of the app or the website. This is a design constraint, not a setting, and it is not something another user can be granted.

Why the split. A score is a number. A pin list is a movement history with timestamps, and precise coordinates attached to each entry. Publishing the first produces a scoreboard; publishing the second would hand any stranger a reconstruction of where a named person goes, and the location somebody posts from most often in the evening is usually their home. The chart is therefore deliberately a dead end: it ranks, and it leads nowhere.

What the account number honestly reveals, and what it does not. We moved from a code generated for its own sake to a plain sequential number, and we should be exact about the difference rather than write this section as if the number told a stranger no more than the code it replaced did. It does not lead to a pin list, exactly as before: nobody can turn an account number into a list of that account's pins, and every guarantee above is unchanged. It does tell a stranger roughly how many accounts have ever been created, and roughly the order they joined in. The highest number in use is close to the total number of accounts ever created, not the number currently active, because a deleted account's number is never reissued; a lower number simply joined before a higher one. That is a real, if coarse, piece of information about our user base as a whole, and we would rather disclose it plainly than let this policy imply the number is as opaque as what it replaced. It does not, on its own, identify which individual holds a given number, and it carries none of your other account data with it.

Legal basis: legitimate interest (GDPR Art. 6(1)(f)) in operating the game mechanic that makes the map worth contributing to, balanced against the information described above, which is limited to an approximate count and ordering of accounts and does not identify any individual or their pins. You can object under Section 6, and we will remove you from the chart on request, though your account number, once assigned, is not reassigned to preserve the ordering for everyone else.

2.8A Deleting a pin you posted

You can delete, at any time, a pin your account posted, and only that one. Deleting a pin withdraws your consent for it, in the same way described in Section 6, and reverses the 10 points it earned, because a pin no longer on the map is no longer earning its keep. This is a different mechanism from the minus-1 discard penalty in Section 2.8, and the two are never applied together to the same pin.

We refuse the request in three cases, set out in full in Section 9.4A of the Terms of Use: the pin has not yet been published and is still awaiting its first review; the pin has already been rejected, in which case its minus-1 penalty stands and deletion would change nothing; or the pin has an open report against it, until that report is resolved.

The pin leaves the public map immediately. Nobody sees it again after you confirm the deletion, not even you. The photo is retained for 14 days after deletion before it is permanently removed from storage, the same period we retain a rejected photo (Section 5), for legal and safety reasons: both need to still exist for that window in case something is disputed. It is not visible to anyone, including you, during those 14 days. The App tells you about this 14-day retention and asks you to confirm before the deletion goes ahead.

2.8B Country flags: derived data, not a new collection

Every accepted, non-duplicate pin also earns the flag of the country it was taken in, shown next to your account number on the public chart (Section 2.8). We are describing this here, rather than only in the product manual, because it is worth being precise about what it does and does not mean for your data.

This is not a new category of personal data and not a new processor. The country is calculated by our own database, on our own infrastructure, from the coordinate your pin already carries and that Section 2.6 already describes as published. No coordinate, IP address, or any other data about you is sent to any outside geocoding, mapping, or "reverse geocode" API to work this out: the lookup runs entirely offline, against a public-domain map boundary dataset (Natural Earth) that we store and query ourselves. Because nothing leaves our infrastructure to compute a flag, no new row appears in the processor table in Section 3 on account of this feature. Legal basis: the same consent that publishes the pin's coordinates in the first place (Section 2.6); the flag is a derivation of data you already consented to publish, not a separate collection.

We are honest that this is a real disclosure, and not a purely cosmetic one. Your set of flags, not just your points total, is published next to your account number on the chart. For most people this is an unremarkable handful of common countries. For someone with one or two unusual flags, having a distinctive combination is a smaller crowd to blend into than a points total is, and that is worth knowing before you post from somewhere you would not want to be singled out for having visited. The chart still carries no user id and no pin id (Section 2.8), and a flag is never shown on a pin, so this does not create a route from a flag back to a specific pin or to any of your other data; it is a disclosure about the shape of your account on a page that is, by design, public.

A flag is not always exact, and it is never a claim about a place's political status. The boundary data we use is detailed enough to place a photo in the right country in the overwhelming majority of cases, including a 12 km allowance along coastlines so that real coastal locations are not missed by an oversimplified coastline. It is not perfect: a small number of very small territories resolve to the country around them, and where a border is genuinely disputed, our data reflects one particular view of it. Neither is a statement of position by us. A photo whose location cannot be placed in any country, including one taken in international waters, simply receives no flag, and this never affects whether the photo is published. See the manual for the specific, current list of known cases, which we keep up to date there rather than duplicating here.

Retention follows the pin. We do not keep a separate "flags earned" record: your flags are derived from the countries of your own published pins, the same way your points are derived from the count of them (Section 2.8), and on the same refresh schedule for the public chart. Delete a pin, or your account, and any flag that pin alone supported drops out of that calculation the next time it runs. There is nothing about your flags kept separately from the pins themselves, and nothing left behind that Section 5 does not already account for.

2.9 Enforcement, permanent bans, and the blocklist hash

The escalation ladder. We publish it because a rule nobody can see is not a rule:

The penalty is for lying, not for being wrong. The distance between the third row and the fourth is the whole design: the third is a user who misjudged, the fourth is a user who knew and asserted otherwise anyway. See the note on appeals in Section 2.4 for why we will not blur that line.

A ban is permanent, and it survives deletion of the account. A ban that ends when the banned person deletes their account and registers again is not a ban at all. So, disclosed plainly as GDPR Art. 13 requires:

• We store a one-way cryptographic hash of the sign-in identifier under which an account was banned, and we keep it indefinitely. The identifier itself, your email address, or the identifier your sign-in provider issued, is not stored on the blocklist. Only the hash is.
• At signup, we hash the identifier being presented and compare it against that list. A match refuses the registration. This lets us recognise a returning banned user without holding, or being able to reconstruct, who that user was.
• The trade-off, stated rather than hidden. For the comparison to work at all, the hashing must be deterministic, so it uses a single fixed application-wide salt rather than a per-record one. The consequence is that the same email address always produces the same hash, which is exactly what makes the check possible, and which also means the list is more susceptible to a guessing attack by anyone who obtained both the list and the salt than a per-record salt would be. We chose the design that works, deliberately, and we are recording the choice here rather than describing the protection as stronger than it is.
• This is the single thing an erasure request does not erase, other than the tax record in Section 2.7. Your pins, photos, account data and entitlement are deleted; the ban record and its hash remain.
• Legal basis: legitimate interest (GDPR Art. 6(1)(f)) in preventing a banned user from evading enforcement and returning to a service they have been removed from, and in protecting other users and the operator from repeated abuse. We consider a keyed, one-way digest with no plaintext identifier to be the least intrusive means of achieving that. You may object under Section 6, and you may complain to your supervisory authority; erasure of a ban record is refused under Art. 17(3)(e) and (1)(c) where the legitimate grounds for the processing override the request, and we will tell you that is what we have decided and why.

2.10 Accepting these Terms and this Privacy Policy

Before you post your first pin, or report somebody else's for the first time, we ask you to accept the current version of the Terms of Use and the current version of this Privacy Policy. Browsing needs neither: nothing in this section applies to you unless and until you try to post or report.

What we record, and only this: which document you accepted (the Terms, or this Policy), which version, and the timestamp. No IP address, no device identifier, no free text: nothing else is attached to this specific record.

Why we keep it, and for how long. This is evidence that you agreed, not a feature for you, so we keep it as evidence rather than deleting it on a schedule: it is not one of the rows in the retention table in Section 5 with a countdown attached. It is one of the small number of things that outlive an erasure request, alongside the ban record and its hash (Section 2.9), the transaction record (Section 2.7), and content preserved for a severe-safety report; see Section 5 for the full list.

When you have to do this again. When either document changes in a way that matters, a material change, we publish a new version and ask you to accept it before your next pin or your next report. A change that does not alter what the document actually promises or requires, a typo, a formatting fix, a clarification that changes nothing in substance, does not bump the version and does not ask you to accept anything twice. Asking you to re-agree to something that has not really changed would teach you to stop reading the ask when it does matter, which is worse than the typo.

Legal basis: the acceptance itself is how you give informed consent (Art. 6(1)(a)) to be bound by these documents; keeping the record of it is our legitimate interest (Art. 6(1)(f)) in being able to show, if it is ever disputed, that you agreed, to which version, and when.

If you hold an account, this record is stored against it, the same as any other account data, until you delete the account. If you delete your account, the acceptance record is not deleted along with everything else: it survives, but the link between it and your account is removed. What is left afterwards is a document, a version number, and a timestamp; nothing in the record itself points back to you. This is a genuine, deliberate exception to the promise that deleting your account erases your data, and we would rather say so plainly here, next to the other exceptions, than let you find it in the retention table with no explanation.

If you do not hold an account, because you reported a pin without signing in, there was never anything to unlink: the same acceptance is asked of you at the report form, and the record it produces is anonymous from the moment it is made, because there is no account for it to be tied to in the first place.

3. Who we share data with

We use a small number of service providers ("processors") to run googlymaps. We don't sell your personal data, ever.

Apple and Google act as the seller for in-app purchases, so for those transactions they are not simply processing data on our instructions; they are handling your payment as merchant of record under their own terms and privacy policies, which apply to that transaction alongside this one.

We may also disclose data where required by law, to protect the rights, property or safety of googlymaps, our users, or the public, or in connection with a merger, acquisition, or sale of assets (in which case we'll tell you before your data becomes subject to a different policy).

Separately, and as described in Section 2.4, we proactively report content and the associated account data to law enforcement and to child-safety reporting bodies where we identify material in a severe safety category. This is a disclosure we initiate, not one we wait to be compelled into.

Anthropic: training and retention

Anthropic does not use data submitted through its API to train its models. Anthropic retains API inputs and outputs for a limited period for trust-and-safety purposes and then deletes them; content flagged by its safety systems may be retained longer. [NEEDS DECISION: ANTHROPIC-RETENTION, state the exact retention period and any zero-data-retention arrangement, taken from the Anthropic Data Processing Addendum and commercial terms in force at publication, and confirm whether a zero-data-retention or reduced- retention agreement will be requested.]

Payment providers: what they never get

Two limits are worth stating flatly, because they are the whole basis on which we can promise your payment details are safe with us:

1. Card and bank credentials never reach googlymaps. Not our servers, not our database, not our logs. They go from you to Revolut, Apple, or Google. We could not disclose them if we were asked to, because we do not have them.
2. We do not send payment providers your pins, your photos, your coordinates, or your age confirmation. A payment provider learns that somebody bought a US$3 ad-free upgrade. It does not learn anything about what you have posted or where you have been. (We could not send them your date of birth in any event, since we do not hold one; see Section 2.2.)

[NEEDS DECISION: PAYMENT-PROCESSOR-TERMS, before publication, confirm against each provider's data processing terms in force on that day: the role each one takes (processor, independent controller, or merchant of record), the exact fields passed to and returned from us, whether a data processing agreement or addendum is executed, and their retention period for transaction data. Do not publish the table above without that confirmation.]

International data transfers

We are in Australia. googlymaps is run by a sole trader based in Perth, Western Australia, so the person administering the service accesses it from Australia. Australia is not covered by an adequacy decision of the European Commission. [NEEDS DECISION: AU-TRANSFER-ANALYSIS, counsel must confirm how data reaching a non-EU controller directly from the data subject is to be treated under Chapter V of the GDPR and the EDPB's guidance on the concept of a transfer, and what safeguard, if any, is required for administrative access from Australia.]

Anthropic's photo-verification service processes data on infrastructure located in the United States. Because this involves transferring personal data outside the EU/EEA, we rely on Standard Contractual Clauses (Module 2, controller-to-processor, under EU Commission Implementing Decision (EU) 2021/914) as the legal safeguard for that transfer, as set out in Anthropic's Data Processing Addendum.

[NEEDS DECISION: ANTHROPIC-EU-REGION, Anthropic also offers an EU-region processing option that would avoid this transfer entirely. Decide before publication; if the EU region is used, this paragraph must be rewritten, because as drafted it would be factually wrong.]

Our other processors may also process personal data outside the EU/EEA. For each of them we rely either on an adequacy decision of the European Commission, or on the Standard Contractual Clauses referred to above. [NEEDS DECISION: PROCESSOR-LOCATIONS, for each processor, confirm whether a transfer outside the EU/EEA actually occurs, the destination country, and the specific safeguard relied on. Do not publish this section with the question open.]

Obtaining a copy of the safeguards. You have the right under Art. 13(1)(f) to obtain a copy of the safeguards we rely on for these transfers. Email [email protected] and we will send you the relevant Standard Contractual Clauses and processor data-processing terms, with commercially confidential terms redacted.

Changes to our processors. If we add or replace a processor in a way that meaningfully affects your personal data, we will update this page and give at least 30 days' notice before the change takes effect, either by email or by in-app notice, so that you have time to object or to delete your data.

4. Advertising

googlymaps is free, and funded by advertising rather than by selling your data.

• You can pay to switch ads off. A one-off payment permanently removes advertising from your account (Section 2.7, and Section 10 of the Terms of Use). Once your account is ad-free, we do not load the advertising SDK at all, so no ad-related identifier is generated, and nothing is read from or written to your device for advertising. In the EEA, the UK and Switzerland this means the consent prompt described below has nothing left to ask you about, and we stop showing it. Paying does not change anything else in this policy: we collect the same data described in Section 2 for everything other than advertising, and paying buys no different treatment of your pins.
• Consent comes first. Before we serve any ads at all to users in the EEA, the UK, or Switzerland, whether personalised or not, we present a Google-certified Consent Management Platform (CMP) and ask for your consent under the IAB Transparency & Consent Framework. This is required because ad SDKs read from and write to your device's storage even when ads are non-personalised, and consent for that is required under the ePrivacy Directive and Google's EU User Consent Policy regardless of whether the ads are personalised. If you decline, we do not serve ads that require that access.
• What we run. We serve non-personalised advertising by default. Non-personalised ads are chosen based on the context of the page, not on a profile built from your behaviour, identifiers, or account data. If we ever introduce personalised advertising, we will ask separately for that consent through the same CMP before enabling it.
• Minors. Every account holder is at least 16 (Section 7), but people under 16 can still browse the map without an account and we cannot know their age. We therefore treat the logged-out audience as potentially including minors and do not enable personalised or behaviourally targeted advertising for it.
• Ad placement and the map. No advertisement ever overlays the map viewport. The map itself is never covered by a banner, an interstitial, or a video. However, sponsored pins are paid placements shown on the map itself. They are always clearly labelled as sponsored and visually distinguishable from user-submitted pins, and, unlike user pins, which are anonymous under Section 2.6, a sponsored pin is attributed to the business that paid for it. Other ads appear on content pages and at specific, clearly separated moments, including one full-screen interstitial after a successful submission, and optional rewarded video that you choose to watch.
• Cookies and device storage. Beyond the ad SDK, we use storage on your device only for things that are strictly necessary to provide the service you asked for: keeping you signed in, remembering your consent choices, and basic security. Strictly necessary storage does not require consent; everything else is covered by the CMP prompt above, where you can change or withdraw your choices at any time.

5. How long we keep your data

We keep personal data only as long as we need it. Every period below is a maximum, measured from the trigger described.

The four things that outlive everything else, gathered here so they are not discovered later: a ban record and its hash (indefinitely, Section 2.9), a transaction record if you bought the supporter tier (5 years, Section 2.7), content preserved for a severe-safety report (for as long as the law governing that report requires), and the record that you accepted a version of these documents (indefinitely, Section 2.10, though deleting your account removes the link between that record and you). Nothing else survives an erasure request.

Deleting your account deletes your pins. If you delete your account, we also unpublish and delete every pin you posted, along with its photo and coordinates, and we purge the account itself, within 7 days. You can also delete individual pins at any time without deleting your account. Records we are required or entitled to keep (moderation and enforcement history for its 6 months, a ban record indefinitely, and anything preserved for a legal obligation) are retained for the periods above, and are not public.

Deleting your account also ends the supporter tier, permanently. We could only restore an ad-free purchase to a new account by keeping the payment identifiers that link you to it, and keeping personal identifiers after you have asked us to erase your data is exactly what the erasure right in Section 6 forbids. We have chosen the erasure promise. So the entitlement is deleted with the account and cannot be recovered, and if you sign up again later it is a new account with no purchase attached. If you want to keep the ad-free upgrade, do not delete the account. Section 10 of the Terms of Use says the same thing before you pay, not after. The bare transaction record survives for the tax-record period in the table above because the law requires it; it is not used to restore anything, and it is not public.

6. Your rights, and how to use them

Under GDPR, you have the right to:

• Access: get a copy of the personal data we hold about you.

• Rectification: correct inaccurate data.

• Erasure ("right to be forgotten"): ask us to delete your data. This includes the right to have a specific published pin taken down, not only your whole account. If you have bought the ad-free supporter tier, please read the note at the end of Section 5 first: erasing your account ends that purchase and we cannot bring it back. Four limits, stated up front rather than in a refusal letter. (a) A ban record and the one-way hash in Section 2.9 are not erased, because a ban that could be erased on request would not be a ban, and Art. 17(3)(e) and the overriding-grounds test in Art. 17(1)(c) are what we rely on. (b) A transaction record for a supporter purchase is kept for 5 years under Art. 17(3)(b), because Australian tax law obliges us to keep it. (c) Content preserved for a severe-safety report is kept for as long as the law governing that report requires. (d) The record that you accepted a version of the Terms of Use or this Policy is not deleted, but erasure removes the link between that record and your account, leaving only which document, which version, and when: nothing that identifies you. See Section 2.10. Everything else goes.

  Deleting a single pin has its own rules, set out in Section 2.8A. You can delete one of your published pins directly in the App without deleting your whole account, and doing so is itself an exercise of this erasure right for that pin. We refuse it in three cases: the pin is still awaiting its first review, the pin has already been rejected, or the pin has an open report against it, until the report is resolved (Terms of Use, Section 9.4A). Where it goes ahead, the pin leaves the public map immediately, and, exactly as with a rejected photo, we retain the underlying photo for a further 14 days before it is permanently deleted from storage, for legal and safety reasons, invisible to anyone, including you, in the meantime.

• Restriction: ask us to limit how we use your data in certain circumstances.

• Portability: get your data in a portable format, or have it transferred to another provider where technically feasible.

• Object: object to processing based on legitimate interest, including the retention of verification metadata as training data (Section 2.4), the technical/usage processing in Section 2.5, your appearance on the public chart (Section 2.8; ask and we will remove you from it), and the blocklist hash (Section 2.9, where we will weigh your objection and tell you the outcome, but where the grounds for keeping a ban effective will normally override it).

• Withdraw consent: for anything based on consent, withdraw it at any time, as easily as you gave it. Consent for a pin is given by a tap when you submit it, and is withdrawn by a tap: deleting a pin in the app withdraws your consent for it and takes it off the map immediately, and the underlying photo and coordinates are then deleted on the schedule in Section 5. Deleting your account in the app withdraws consent for all of your pins at once and removes them all. Withdrawal doesn't undo processing that already happened, and it can't un-see a pin somebody already looked at, but nothing we publish survives your withdrawal. Advertising consent can be withdrawn at any time from the consent settings described in Section 4.

• Human review of an automated decision, as described in Section 2.4: express your point of view, contest the decision, and get a human to look at it.

In-app self-service. Deleting a pin, deleting your account, and changing your consent choices are all available in the app without contacting us. Access, export, rectification, restriction, and objection are handled by email.

To exercise any of these rights by email, write to [email protected] with what you'd like us to do. We'll respond within the timeframes GDPR requires (generally one month, extendable by two further months for complex requests, in which case we'll tell you within the first month). We may need to verify your identity first.

If you're not a googlymaps user but you appear in a published photo, or your shopfront, property, or vehicle does, you can ask us to take it down. Use the Report button on the pin (no account needed), or email [email protected]. We'll confirm we received your report and review it within the timescales in Section 5 of the Terms of Use. If you want to be told the outcome, use email or leave an address in the report form: a report filed anonymously leaves us nothing to reply to, and the on-screen confirmation is deliberately the same whatever we find, so that the report button cannot be used to work out what has been taken down (Terms of Use, Section 5.1A).

Right to complain. Please come to us first, at [email protected], because we can usually fix things faster than a regulator can. But you do not have to, and you can complain to a regulator at any time.

• If you are in the EU or EEA, the GDPR applies to us under Art. 3(2) and you may lodge a complaint with the data protection supervisory authority of the Member State where you live, where you work, or where the problem happened (GDPR Art. 77). You do not have to complain to an authority in our country, and you do not need our agreement to do it. The list of national authorities is published by the European Data Protection Board at edpb.europa.eu. If you are in the UK, the equivalent body is the Information Commissioner's Office (ico.org.uk).
• If you are in Australia, the privacy regulator is the Office of the Australian Information Commissioner (OAIC), oaic.gov.au. As explained in Section 1.1, whether the Privacy Act 1988 (Cth), and therefore the OAIC's complaints jurisdiction, extends to an operator of our size is a question we have not resolved, so we cannot promise you that the OAIC will accept a complaint about us. That does not affect anything we have committed to in this policy, and it does not affect your right to complain to your own authority if you are in the EU, the EEA, or the UK.
• We are not established in Italy and the Italian Garante is not our supervisory authority. An earlier draft of this policy said otherwise; that was wrong.
• Anywhere else, you may complain to whichever data protection or consumer authority has jurisdiction where you live, and we will cooperate with it.

7. Minimum age

You must be at least 16 years old to post a pin on googlymaps. This applies everywhere in the world, with no exceptions.

Where the check actually happens. The 16+ rule is enforced at the point you post your first pin. The pin is refused unless your account carries a confirmation that you are at least 16. It is not enforced by blocking account creation, and an earlier version of this policy that said it was, was wrong. The reason is practical: when you sign in with Apple or Google we are not given a date of birth at all, so a hard block at signup would have made those sign-in routes impossible to use. So an account can exist before we know your age; it cannot post until we do. If you give us a date of birth showing you are under 16, it is rejected there and then.

The check runs in the database, not in the app. The minimum age is enforced server-side, as a condition on writing a pin at all, so it cannot be bypassed by a modified client, a direct API call, or an old version of the app.

We do not keep your date of birth. You give it once; we check it; we record a timestamp, min_age_confirmed_at, meaning "this account was confirmed to meet the minimum age at this moment"; and the date itself is never written to the database. There is no birth-date field holding your birthday, so there is nothing there to breach, correlate, or hand over.

We record the reasoning, because there is a genuine cost on both sides. A date of birth is precise, permanent, unchangeable identity data with no further use once the check has passed, and GDPR Art. 5(1)(c) data minimisation and Art. 5(1)(e) storage limitation both point at keeping the smallest possible derived fact instead. Against that: a confirmation timestamp is a record of our own assertion rather than of yours, so if an age claim is later disputed we can show that we checked and when, but not the value we checked. We have decided that the reduction in what we hold about you is worth that, and we would rather hold less and say so than hold a birthdate for years against a dispute that may never come.

Legal basis for the confirmation timestamp: compliance with our obligations and our legitimate interest in operating an age-restricted service lawfully; it is the minimum record that lets us demonstrate the check was performed.

There is no lower age anywhere, for any country, and there is no parental-consent pathway: a parent or guardian cannot consent on behalf of someone under 16 to let them post.

Browsing the public map does not require an account and has no age gate. Anyone can look at the map. We do not knowingly collect personal data from a child in connection with an account, and we do not serve personalised or behaviourally targeted advertising to logged-out visitors, whose age we cannot know (see Section 4).

If we learn that an account holder is under 16, we will:

1. suspend the account immediately;
2. unpublish and delete every pin that account has posted, including the photos and coordinates. We do not leave a minor's photos or precise locations public;
3. delete the associated account data, retaining only the minimum record needed to prevent the same person immediately re-registering and to evidence that we acted; and
4. where the person contacts us, confirm what we have deleted.

8. Security

We take reasonable technical and organisational measures to protect your data, including EXIF stripping on your device and again on ours before a photo is published (Section 2.3), hashed passwords, encrypted connections (HTTPS/TLS), row-level access controls on our database, and private storage for original-of-record photos and for photos that have not been published. No system is 100% secure, and we can't guarantee absolute security, but we work to keep your data safe and will notify affected users and relevant authorities as required by law if a breach occurs.

9. Data protection impact assessment

Because googlymaps combines precise geolocation, photographs, automated decision-making, and an audience that is likely to include young people, we treat it as requiring a Data Protection Impact Assessment under GDPR Art. 35, which applies to us under Art. 3(2). [NEEDS DECISION: DPIA, the DPIA must be completed, and reviewed by counsel, before launch; this section should then state its date and summarise its conclusions. Counsel should check the Art. 35(4) mandatory-DPIA list of the supervisory authority most relevant to our EU user base, not Italy's, and should note that the OAIC likewise expects a privacy impact assessment for high-risk processing of this kind.]

10. Changes to this policy

We may update this policy as the app or the law changes. A material change publishes a new version number, as the top of this page describes, and you will be asked to accept it again, in the way Section 2.10 describes, before you can post a pin or report one; browsing is never affected. A non-material change, a typo fix or a clarification that changes nothing in substance, does not bump the version and does not ask you to accept anything again. Where appropriate, we also notify users directly (e.g. by email or in-app notice).

11. Contact us

Questions, requests, or complaints about your data:

[email protected]

To report a pin or request a takedown, use the Report button on the pin (no account needed), or email [email protected].

Last update: 2026-08-25 AWST