Privacy policy

Burg's Eye View is an independent, resident-run project about St. Petersburg city government. It is built and edited by Brad Falbo, a St. Petersburg resident. This page says what this site collects, what it does not, and what happens to the little it does. Some of it is checked by machine: this site's tests compare particular sentences below with the code, the database and the built pages — which outside addresses the pages fetch from, whether anything sets a cookie, what the one entry in your browser holds, which fields the signup form sends, what the signup program stores, and what the removal tool leaves behind — and fail when the two disagree. They cannot tell whether every sentence here is true, and they cannot see settings at the company that hosts this site. Where a claim rests on something else, the page says what.

Last updated 22 September 2026 · Contact: info@burgseyeview.com

Sent here to see what changed? The four differences from the version you agreed to are at Changes to this policy, each pointing at the section that explains it.

Reading a page here

Until you answer the cookie question, we collect nothing when you read this site. No account, no cookie, no identifier, no analytics, no advertising, no tracker of any kind, and nothing at all is set or sent while that question is still on the screen. Answer no and that stays true, for as long as you keep that answer, and nothing on this site is withheld from you for giving it. Answer yes and this site counts your visit with Google Analytics; the cookie section below says exactly what that sets, what it sends and to whom. This site also does not ask your browser where you are, on any page, and there is no button anywhere on it that would.

One exception, and only on the pages carrying a form the check guards. Those pages run Cloudflare’s bot check, which contacts Cloudflare while the page is loading rather than when you press anything, and forms a judgement about whether a person or a program is there. That is something done about you, by somebody else, before you have done anything at all, and it is the only thing of its kind on this site. It is there to keep programs off the mailing list; what it is, what your browser sends it and what it may leave behind are set out under cookies above and under what your browser is asked to fetch below. No page without the form runs it.

There are three forms on this site, and each does a different thing. The newsletter signup takes an email address. The donation form starts a payment. The form beside it asks for your address in order to email you a link for managing a donation you are already making. There is no comment field, no contact form, and no other form of any kind on any page.

The signup is one form, not one copy of it: wherever it appears it is the same form, and it is not on every page. The home page draws it twice on its own — once as a band near the foot of the page, and once as a notice that opens over it — and those two are the same form as each other: the same single box, asking for the same one thing, sending it to the same place. The only thing that differs between one and another is a short label recording where it was filled in, and the mailing-list section below says what that label is for. The signup sends the address you type into it, and only when you press the button, together with the one-use token the bot check on that page produced; what happens to that address is set out under the mailing list below, and what the two forms on the support page send is set out under paying for this site.

That is partly a decision and partly a property of how the site is built. Every page here is written out as a finished file before anyone visits, and that file is what is sent to you, apart from two additions the company hosting this site makes on the way, described under Hosting. There is no program of ours running while you read, and nothing on our side sees the request. If you have not allowed analytics there is therefore no log of what you read for us to keep, lose, or be asked to hand over. If you have allowed it, that log exists: Google holds it and we can read it, and the cookie section above says what is in it. Four programs of ours exist and none of them runs while you read: one takes a newsletter signup, one starts a payment, one emails a link for managing a membership, and one is told by the payment company what happened to a payment. Each runs only when it is asked, three of them by a form you pressed and the fourth by the payment company itself. What each of them keeps is set out below — the first under the mailing list, the other three under paying for this site. If this site ever stops being built this way, this paragraph is the first thing that has to change.

Cookies

Nothing is set to count you until you answer one question. The first time you open this site it asks whether it may count your visit with Google Analytics. While that question is still on the screen nothing has run on its account: no program has been fetched from anybody, no request about you has been made to anybody, and no cookie has been set by it. The answer is yours and this site does not have a preferred one.

Say no, and the only cookie of ours you get is the one recording the no. It holds your answer and the day you gave it, and nothing else. It exists so that the question does not come back and so that your refusal survives closing the tab: a banner that cannot remember a refusal is a banner that asks again until you give in. Nothing is fetched from Google, nothing is set by Google, and this site adds nothing that reports what you read to us or to anybody else.

Say yes, and Google Analytics runs. The property is G-T6ZWN3JZY5, which ships in the source of every page so you can check it. It sets cookies of its own in your browser — _ga and _gid, which are Google’s rather than ours and which mark your browser so that Google can tell one visit from the next. This is the first thing of its kind this site has ever done, and it happens only because you said it could.

It reports more than which pages you opened. Google Analytics has a set of extra measurements switched on by default and they are on here: as well as each page view, it reports when you scroll down a page, when you press a link that leaves this site, when you download a file, when a video is played, and when you interact with a form. We would rather list those than let “we count visits” stand for all of them.

Your IP address is collected, and it is not anonymised. There is no setting in Google Analytics that hides it and this page will not pretend otherwise. What Google states is narrower and more specific: your IP address is used to filter out automated traffic and to work out a coarse location — city, region, country, and the latitude and longitude of the city rather than of you — that it never joins raw IP addresses to the identifiers that mark your browser, and that it discards the raw address after that use. That is what is claimed and by whom; it is Google’s account of Google’s systems, and nobody here can open them to check.

What is left on, which is the whole of it. Two things, and both are deliberate. Your city-level location and the details of the device you are reading on — the browser, the operating system, the screen — are collected; Google calls that granular location and device data, and it is permitted here in every region that setting lists. And the measurements listed further up are on. That, with the handling of your IP address described above, is everything this property collects and everything it permits. It is not nothing, and the reason for saying so plainly is that a reader deciding whether to answer yes should be deciding about this rather than about a shorter list.

Two months, and not two months with an exception in it. Both of the retention periods on this property are set to the shortest Google offers: two months for what happened, and two months for the identifier it happened under. The setting that extends that window every time a reader comes back is switched off, deliberately. Left on, a regular reader’s identifier would never age out, and “we keep two months” would be false for exactly the people who read this site most. Off, two months is a ceiling rather than a rolling start.

What Google is not permitted to do with it. Ads personalization is not permitted in any region — none of the 307 that setting lists. That is a permission rather than a switch, and this page describes it the way Google’s own controls do, because what it settles is not whether some feature is running but what the company may do with what it has. All four of the account-level sharing settings are off with it, including the two that would let Google use this data for its own modelling and for recommendations about this project. Google Signals, which would join what you do here to a signed-in Google account across devices, is off. No Google advertising account is linked to this property, and this project has none to link.

What that does and does not reach, in Google’s own terms. Withdrawing that permission stops new readers being shared to audience lists, marks any existing list inactive, and causes data that has already been exported to be designated as not for use in advertising. Designated, not deleted — and this page will not upgrade that word. In this case there were no audience lists and no advertising account to share them with, so what the withdrawal does here is shut a door that had not been used, which is worth saying plainly rather than dressed up as undoing something. If any of that changes it is a material change to this document and the date at the top moves with it.

What is taken out before Google sees it. A web address can carry extra information after a question mark, each piece of it under a name. One name, q, has its value replaced before this property reports the address, and so is anything shaped like an email address. That is a narrow thing and not a general one: Google applies the stripping only where it records an address, which is the page you are on, the page you came from, and the address of a link, a video or a form you interacted with. It is not a rule about everything Google receives, and this page will not describe it as one.

And what this site takes out before Google is asked. An address can also carry a part after a #. This site writes one on the development map, to remember where you had moved the map to so the view survives a reload — which means it records where you chose to look, and on a map about building work near you, people usually look at their own street first. The stripping described above cannot reach that part of an address, so this site removes it here instead: what gets reported is the site, the page, and the part after the question mark, and never the part after the #. That part stays in your browser. It is the same choice made about the payment page — the surest way to keep a value out of someone else's records is not to send it.

Saying no costs you nothing. Every page, every document, every table, every link and every search works exactly the same whichever way you answer. Nothing is withheld, nothing is slowed down, nothing is cut short, and you are not asked a second time. That is a promise about this site and not a description of the industry: if it ever stops being true, this page says so before it stops.

To change your mind, either way, at any time: the link marked “Cookie choices” in the footer of every page brings the question back, and whatever you answer there replaces what you answered before, from that moment on. That covers what happens next rather than what has already happened: to clear the cookies Google has set in your browser already, clear this site’s data, which the next section describes for the one entry it also clears.

One more can exist, and it is Cloudflare’s rather than ours. The pages carrying the newsletter signup, and the support page carrying the form that emails a membership link, run a check that you are a person; the section below on what your browser is asked to fetch from somebody else says what it is and why it is there. Cloudflare states that the check may keep a cookie in your browser so that a reader it has already satisfied itself about is not put through it again. What we have not established is which of our pages it is actually set on, how long it lasts, or what is in it: it is set by a program served from Cloudflare’s own address and run inside a frame we cannot see into, so nothing in this project can measure it, and we would rather write that down than describe something we have not looked at. It is governed by Cloudflare’s privacy policy. Beyond it there is no session storage, no device identifier and no cached profile of you; the one other thing this site keeps in your browser is the next section’s subject, and it is not a cookie.

The one thing this site keeps in your browser

This site stores one entry in your browser, and this is the whole of what is in it: how many days you have opened the home page, whether you have signed up from this browser, and the day your most recent visit was counted on. A number, a yes-or-no, and a day. Nothing else.

It is there so the signup notice on the home page can behave decently. Once you sign up from the home page in this browser, the notice stops appearing here for good; if you have not, it comes back every few visits instead of every time you open the home page. Both of those are promises about what happens on your NEXT visit, and keeping a promise across visits means remembering something between them. We would rather store a count than show you the same notice forever. It cannot know about a signup made in another browser, or one made with scripts turned off, so after either of those the notice may still appear here.

A day here is counted in Coordinated Universal Time rather than local time, so in St. Petersburg a new one begins at 8 p.m. while daylight saving time is in effect and at 7 p.m. otherwise. Opening the home page on either side of that hour counts as two visits.

It holds no identifier. There is no name, no address, no random number, and nothing derived from you or your device in it — only the three values above, which any other browser can hold too. It never leaves your device. A script in your own browser writes it and the same script reads it; no request this site makes carries it, and there is nothing on our side that could receive it if one did.

To clear it: clear this site’s data in your browser. Every browser offers that for one site at a time, usually from the icon beside the web address, and all of them offer it for every site at once under their privacy settings. The only consequence is that the counting starts again from zero and the signup notice may appear once more. Nothing you would miss is lost, because nothing about you was in there to lose.

What that entry does not change. There is no advertising, no fingerprinting, and nothing that follows you to another website. The count in it is never sent anywhere, whichever way you answered the cookie question: a script in your own browser writes it, the same script reads it, and no request this site makes carries it. If you refused analytics, this site adds nothing that reports your reading to us or to anyone else — not which pages you opened and not how long you stayed.

What your browser is asked to fetch from somebody else

Two addresses, and neither is on every page. This site asks your browser to contact two outside addresses. One is Cloudflare’s, challenges.cloudflare.com, on the pages that carry the newsletter signup and on the support page, and on no other page. The other is Google’s, www.googletagmanager.com, where the analytics program is fetched from, and it is fetched only if you allow analytics and never if you do not. There is no font service, no advertising network, no social embed, no video player, no comment system, and no content-delivery network holding our scripts. That is not a description of our intentions. The number in that sentence is read back out of it by a check that counts what the built site actually fetches, file by file, and that check fails if one more outside address appears in any of those files. It reads files, so it cannot see an instruction the company hosting this site adds to a response on its way to you; the one such instruction is described under Hosting.

What it is, and why it is there. It is Cloudflare Turnstile, a check that a person rather than a program is filling in the form. The signup writes to a list of real people’s addresses, and an address can be typed in by anyone — there is no confirmation step, as the mailing-list section below says in as many words. Without a check of this kind a program can put a thousand addresses on that list in a minute, none of which asked to be there, and every one of them a real person we would then have no honest way to reach. That is the whole of why it is here.

What your browser sends, and to whom. Loading the check is an ordinary web request to Cloudflare, so Cloudflare receives the ordinary technical details of it: your IP address, your browser and its version, the time, and that the request came from this site. The check then works out whether it is satisfied you are a person — by what your browser is, how it behaves, and what Cloudflare already knows of it — and hands the page a one-use token. Cloudflare states that it may keep a cookie in your browser as part of that; the cookie section above says what we have and have not been able to establish about it. When you press the button, that token is sent to us with your address, and we ask Cloudflare whether it is good before we store anything. We keep nothing the check sends back, and Cloudflare’s use of what it receives is under Cloudflare’s own privacy policy and not ours.

It needs JavaScript, and that has a consequence worth saying plainly. The check is a script, so with scripts turned off it never runs, no token is produced, and a signup made that way is refused — you are sent to a page that says it did not go through and how to reach us. Every other page on this site works with scripts off and always has. The signup no longer does, and that is the price of the check rather than an oversight. Write to us and we will add you by hand.

There is a second Google address, and it is not in the count above. The analytics program, once fetched, sends what it measures to www.google-analytics.com. That address appears in no file this site ships — the program asks for it while it runs — so the check described above cannot see it and the count does not include it. It is named here because a reader is entitled to know where the measurements go, and because a number that cannot see something is a worse guide on its own than a number with this sentence beside it.

A link is not a request. This site links out to two other websites, and they are the two candidates’ own campaign sites, printed beside their names on the District 6 questionnaire so you can read what each of them says in their own place rather than only here. Those are ordinary links: your browser contacts neither of them unless you click, and when you do you are on somebody else’s site under their rules, not ours. Every other link on every page here goes somewhere else on this site. This paragraph says how many and which because a link you have not clicked is still something you are entitled to see coming.

Hosting

This site is served by Cloudflare Pages. Like effectively all web infrastructure, Cloudflare handles visitors' IP addresses and request details in order to deliver pages and to absorb attacks, under its own privacy policy. That is unavoidable for any website; what is avoidable is everything we have not added on top of it, and we have added two things: the bot check on the pages carrying a form it guards, set out above, and Google Analytics, which is served only to a reader who allowed it. Apart from those two, no script that reports your reading back to us or to anybody else is served with these pages.

Cloudflare also runs the four programs of ours described above and the database they write to, which holds the mailing list and the record of who is paying for this site. The mailing-list section below says what is in the first; the section on paying for this site says what is in the rest.

Two things Cloudflare adds on the way to you. When this version was written, the responses we checked from this site's address all carried an instruction, added by Cloudflare, asking browsers that support it to report failures in loading this site to a Cloudflare address, a.nel.cloudflare.com. A browser sends such a report only when loading something here fails. It goes to Cloudflare, which already handles every request you make to this site, and it says what failed to load and how.

The second changes the pages themselves. Cloudflare was set to disguise the email addresses in this site's pages as they are sent, so that programs collecting addresses from web pages cannot read them: each address is replaced with the words “[email protected]”, and a small script, served from this site's own address, puts it back in your browser. With scripts turned off you will see those words instead of our contact address, which is info at burgseyeview dot com.

The mailing list

The one form on this site that takes an address is the newsletter signup. Typing your address into that box and pressing the button adds your address to the mailing list. That is the whole of what the form does, wherever on this site you meet it; it is the only thing here that does anything of the kind, and nothing else you do here has that effect — not reading a page, not following a link.

There are two other ways onto the list, and neither is this form. The first is to ask us. When a signup fails, the message the form shows can ask you to write to info@burgseyeview.com so that we can add you by hand. An address added that way goes into the same list, put there by a person here rather than by the form, and the email that asked for it reaches our mailbox with your address in it. Adding you to the list does not delete that email.

The second is the box on the donation form. It is unticked to begin with; ticking it adds the address you end up giving Stripe, and only once the payment has gone through. The section on paying for this site sets out exactly what that does and what it does not, because it does less than ticking a box normally implies. An address arriving that way goes into the same list with the same four things kept about it, labelled as having come from a donation.

There is no confirmation step. An address is added the moment the button is pressed, and nothing checks that the person who typed it is the person it belongs to, so somebody else could put your address on the list. Somebody put on this list by another person finds out when a message arrives, and every message carries a link that takes the address off the list. If your address is on it and you did not put it there, use that link or write to us, and it will be removed.

The form writes to the same list as the signup form on the earlier version of this site, so there is one list and not two, and anyone who signed up there is already on it.

What is kept when you sign up is four things: the email address you typed, the date and time you pressed the button, a short label saying which page you were on and which of the forms there you used, and which version of this policy was published when you signed up. The database also gives each row a number. That is the whole record about a person, and the list has no place to keep anything more about anybody on it. An address we add by hand is dated the day we add it rather than the day you asked, and nothing yet decides which page label or policy version such an entry carries. Nothing else from the request that carries a signup is stored: not your IP address, not your browser or its version, not the page you came from. There is no name attached unless it is part of the address itself, no phone number, no location, no browsing history, no advertising or behavioural profile, and no password or login of any kind.

What happens to the rest of that request. The program writes short notes as it works, into a log Cloudflare runs for it — that a signup arrived without a bot check, for instance, or that one could not be saved — and none of those notes contains your address or your IP address. When we read Cloudflare’s documentation for this kind of program in September 2026, it said such logs are not stored and do not persist. The program can also be set to ask Cloudflare’s bot-check service, Turnstile, whether a person rather than a script sent the form. When it is, it passes that service your IP address for the check, and it stores nothing the service sends back. That setting lives at our host rather than in the code, so the code cannot tell you whether it is on; the form on this site carries that check, so a signup arrives with a one-use token beside the address, and the token is thrown away once the answer comes back rather than written down with the four things listed above.

Where the list is kept. The list is stored by Cloudflare, in the database the signup program writes to. On 1 September 2026 the addresses then on it, apart from one test entry of our own, were also copied into a second database, which Neon hosts for this project. Signups made since then are only in the first, and nothing keeps the two in step. There is now a third holder, and it is the company that sends the mail: to send you a message, Resend has to be given your address, so the addresses a message goes to are handed to Resend and Resend keeps its own record of what it was asked to send and to whom, under its own privacy policy. The list is for one thing: sending updates about this project. We do not sell it, rent it, or use it for advertising, and the only company it is given to is the one that carries the mail.

In that copy each address also has a consent record: that somebody agreed to be emailed, under which version of this policy, on what date, and the date that agreement ended if it has. That record holds no address, no name, and no IP address — that database refuses to store an IP address or a browser string against it — and the row holding the address carries two settings, a time zone and a delivery day, at defaults nobody chose. Every entry that was copied was made under the version of this policy published on burgseyeview.com before this one. A signup made here is recorded against this version instead, under the name “beta-v1”. Because nothing confirms who typed an address, what these records show is which policy was on the page when an address was entered, not that its owner was the one who agreed.

This list can be sent to, and any message is carried by a company called Resend. Until this version of this page there was no mail service at all and nothing had ever been sent, which is what the previous version said and what was true when it said it. The rest of this section is what changed with that.

Nothing is sent to this list unless Brad Falbo has approved that particular message. There is no schedule, no automatic message, and nothing that goes out because a date arrived or because you did something here. That is a rule this project has adopted rather than a description of how busy we are, and it is the reason this page has no sending timetable to tell you about.

Every message carries a link that takes you off the list. Pressing it is enough. There is nothing to log into, no form to fill in beyond confirming, and nobody here has to act on it for it to work. The page that link opens is one Resend runs, because Resend is what records the unsubscribe. Writing to us still works too, as the next section describes, and either way the address comes off.

Resend records who opens a message and which links they press, and that is switched on. It is two mechanisms. A message carries a small invisible image, and your mail program fetching it is what records that the message was opened, and when. And the links in a message are rewritten, so that instead of going straight where they say they go, they go first to a tracking address, which notes the press and then sends you on. What exists afterwards is therefore a record, message by message and person by person, of who opened it, when, and what they pressed. Not a total — a list.

The tracking address looks like ours and is not. It is email.burgseyeview.com, which is a name inside our own domain pointed at a machine Resend runs. That is the ordinary way this is arranged and it is also the confusing part, so it is written here rather than left to be found: if you hover over a link in one of our emails and see that address instead of the place the link says it goes, that is this, and the press is recorded by Resend before you are sent on. It is the one thing on this page that a reader is more likely to meet in their mail program than on this site.

Asking to be removed

Write to info@burgseyeview.com and ask. You do not have to give a reason, and there is nothing to log into.

If somebody else put your address on the list, the same request removes it.

Removal deletes your address rather than hiding it. In the list Cloudflare stores, your entry is deleted outright, and nothing of it is left there. If your address was one of those copied on 1 September 2026, it is erased from the copy Neon hosts as well. Neither of those two keeps a suppression list: neither holds your address as a note that you asked to leave. The company that carries the mail does, and that is the one place it is unavoidable — an unsubscribe is a standing instruction not to send to an address, and the only way to keep such an instruction is to keep the address it is about. The tool that erases an address from the copy will not run unless the person running it gives their name and confirms that the entry in the first list has already been deleted, because deleting one copy of a thing is not deleting it. That is a promise about the two databases the list is kept in. It is not a promise that your address has stopped existing anywhere, and the three limits set out below say exactly where it can outlive the removal.

Erasing an address there does not delete its entry. The address is removed from it, and so is the label saying which page it came from. The entry is marked as deleted, and what stays in it is the date it was made, the date it was erased, which version of this policy it was recorded under, and a few settings and a random code that describe nobody. In the copy, three things are left afterwards: that emptied entry; the consent record described above, which then points only at the emptied entry; and a record of the removal itself, saying when it was done, which of a short list of reasons it was done for, how many related records were kept or cleared, and the name of the person at this project who did it. None of the three holds your address, your name, or where you live. They are kept because they are the evidence of what we were permitted to do and of the fact that the removal happened.

Removing your address from the list is not the same as erasing it everywhere, and there are four places it can outlive the removal. None of them is the list, and none of them is something we can fix by running the tool again.

The company that carries the mail. Resend is given your address in order to deliver a message to it, and it keeps its own record of having been asked to — and, because opens and presses are recorded, of what you did with the message afterwards. If you unsubscribe, that record is also what stops the next message reaching you, so asking Resend to forget you entirely and asking it never to write to you again are opposite requests. How long it keeps either, we have not established, and the same sentence applies here as to everything else below: we would rather say so than tell you it is gone.

Our mailbox, and what is behind it. Anything you write to us arrives as an email with your address in it — a request to be removed, or one to be added — and deleting you from the list does not delete that email. We can delete it from our mailbox and will if you ask. What we cannot do is account for what is behind the mailbox: this project’s mail is Gmail, so Google receives and stores every message sent to us under its own terms, and deleting one is an instruction to that company rather than something we carry out ourselves. How long a deleted message survives there, in backups or anywhere else, we have not established, and we would rather write that down than tell you it is gone.

Anything already sent. A reply we send you sits in our sent mail and in your inbox with your address on it, and the same is true of any message sent to the list. Deleting a row in a database does not reach an email that has already left, and it does not reach the record the company that carried it keeps of having carried it.

Backups. Whether either company holding the list can restore what was deleted or erased from its own backups, and for how long, we have not established either. We will not promise that nothing survives anywhere, because we have not checked.

So what we can promise is exact, and it is narrower than “erased everywhere”: your address comes off the list, it is deleted rather than suppressed, and nothing here will send to it again. Where it can persist regardless is the three places above, and we would rather you knew that than be told something tidier.

Removal is not reversible. If you later want updates again you sign up again, as a new person, because as far as this system is concerned that is what you are.

Paying for this site

Card details never reach this site. Pressing a support button hands you to Stripe, the payment company, on a page that is Stripe’s own and not ours: the web address changes to theirs and the card number is typed there. No card number, expiry date or security code passes through this site, is processed by any program of ours, or is stored in any database of ours, and none ever has. That is the single most useful thing to know about this arrangement and it is a property of how it is built rather than a promise about our care.

What the donation form sends us on the way, and it is a short list. Five things: whether you chose to give once or every month, a short label saying which form you used, the amount you chose, your email address, and whether you ticked the box offering the newsletter. That is the whole of what leaves this page when you press it. We turn it into a request to Stripe and send you there; there is no card detail in that list because the card is not typed here, and there is nothing else in it either.

The address is required on that form, and it is there for the receipt. It is passed to Stripe so that Stripe can send you one and so you do not have to type it again. You can change it on Stripe’s page, and if you do, the address you type there is the one that counts for everything described below.

The box offering the newsletter does less than it looks like. It is unticked to begin with, and ticking it does not add you to anything by itself. What it does is attach a note to the payment saying you asked; the address that is then added is the one on Stripe’s page, not the one you typed here, and it is added only once the payment actually goes through. Tick the box and then abandon the payment, and you are not added to anything — nothing was written down here while you were deciding.

What is kept when you arrive that way is what is kept when you sign up any other way: the address, the date, a short label saying you came from a donation, and which version of this policy was published. Nothing about the payment is attached to your place on the list, and nothing new is kept about anybody. If your address is already on the list, it is left exactly as it was — the label and the policy version it first arrived under are not overwritten by a donation.

What we are told afterwards, and keep. Stripe tells one of our programs what happened, and that program writes it down. For a donation every month: an identifier Stripe uses for you, the email address you gave Stripe, whether it is still running or has lapsed, an identifier for the arrangement itself, the amount, how often it repeats, the date the paid-up period ends, whether it is set to stop at the end of that period, and a marker saying whether the payment was real or one of our own tests. For a donation given once: an identifier for the payment, the same identifier for you, the email address, the amount, whether it succeeded or was refunded, and the same real-or-test marker. That is the whole of it. There is no card number in that list because we never have one.

Nothing you land on decides whether any of that is recorded. Only the program Stripe talks to writes any of it down, and it is talked to by Stripe rather than by your browser. So a reader who pays and closes the tab before the thank-you page appears is recorded exactly the same as one who waits, and the page you land on is not doing any of the work. It is also why that page cannot tell you more than that the payment went through.

The form for managing a donation answers the same way whoever asks. Type an address into it and we email a link to that address; the link is never shown in your browser, because typing an address is not proof of anything. The reply on screen is the same whether or not the address is donating — identical words, for a stranger’s address as for your own. That is deliberate and it is a privacy property rather than a detail: it means the form cannot be used to find out whether some named person gives money to this site. The only thing that can tell you is the mailbox of the address you typed.

What Stripe itself collects is Stripe’s to describe. Stripe receives whatever you type on Stripe’s page, under Stripe’s own privacy policy, and this page does not set that out: we can see what we send and what we are told, and we have not looked inside Stripe. If something is not working, there is an address on the donation page to write to, and writing to it reaches our mailbox in the ordinary way.

If you allowed analytics, Google is told you used these forms. The measurement listed further up that reports form interactions does not know the donation form from the newsletter signup, so starting a payment is reported as an interaction like any other. It carries no amount, no address and no card details — those never go to Google — but the fact that you engaged with the donation form on this site is reported. If you answered no to analytics, none of that happens.

There is still no account and no login. Donating does not create one. There is no password, no session, and nothing to sign in to; the emailed link goes to Stripe’s own page for managing a payment, and it is the nearest thing to a login on this site precisely because it is not one — it is a link sent to an address, not a session held here. Nothing on this site behaves differently for somebody who donates, and no page here can tell whether the person reading it has.

How long things are kept

Your email address is kept until you ask us to remove it, and then it is deleted as the section above describes. There is no automatic expiry and no scheduled purge, and we would rather write that plainly than imply a tidiness we have not built. If a retention rule is ever added, this section will say what it is before it starts deleting anything.

A payment record is kept as the evidence that the payment happened, which is what it is for. Asking to be removed from the mailing list does not delete one, because they answer different questions, and a membership is cancelled through Stripe rather than by deleting our note of it. If you want to know what is held about your payments, or want it corrected, write to us and we will tell you.

The rest of what this site publishes comes from public records, and it is kept permanently on purpose: a publication that quietly drops old material cannot be checked against itself, and being checkable is the point of it. None of that material comes from readers.

Asking what we hold about you

You can ask what we have stored about you and we will tell you, and you can ask for it to be corrected or deleted. Today that answer is put together by hand and sent by email; the list is small enough that this is honest rather than evasive, and this page will say so differently on the day it stops being true. Write to info@burgseyeview.com.

Where your address is not

The published pages of this site are built by a program that has no access to the mailing list at all. It has no connection to the database the signup form writes to. Its account on the database the site is built from, which holds the copy described above, is refused on every table holding subscriber information — refused, not filtered — so no page here can print a reader's address even by mistake. That is a property of the database rather than a promise about our care, and this site's own tests prove it by trying it and being refused.

The signup form is handled by a separate program again, and it is worth being exact about how separate. It runs only when the form is submitted; it is not part of building any page, and no page on this site is ever built from anything it wrote. It makes one instruction to the list — add this address — and it asks the list nothing. That last part is a property of what the code does rather than of what it is permitted to do, which is a weaker guarantee than the one in the paragraph above and is stated as the weaker one deliberately. The code is short, it is the only thing on this site that touches the list, and a test reads it and fails if it grows a second instruction.

Locations

This site does not hold anybody's home address or location, and nothing on it asks for one. If that ever changes, this page will say what is collected, and why, before anything is.

Reader accounts

There are no reader accounts. Nothing on this site has a login, a password, a session, or a way to tell one visitor from another, and the fact that every page is a finished file written out before anyone visits is part of why. Paying does not create one, which is worth saying because paying for a thing usually does; the section on paying for this site says what happens instead. If that ever changes, this page will be rewritten before the first account is opened, and it will say what a session stores, how long it lasts, and what a reader can delete.

Children

This site is about municipal government and is not directed at children under 13. We do not knowingly collect information from children. If you believe a child has submitted an email address, write to info@burgseyeview.com and it will be deleted.

People named in public records

What is published under Reports quotes and links public records of the City of St. Petersburg — among them its general ledger, its administrative policies, and its acknowledgments of public records requests made under Chapter 119, Florida Statutes. Those records are public by law, and public records can name people — city staff acting in their public roles, and sometimes members of the public.

If you believe something published here contains personal information that should be redacted, email info@burgseyeview.com and it will be reviewed promptly. Records we hold but have not cleared for publication are not published, and the distinction is enforced in the database rather than by editorial habit: an uncleared document cannot be linked from a public page, and the site's build is tested against it.

Changes to this policy

If you were sent here to see what changed, it is these four. Each has a section of its own above, and the short version is here so that you can stop after it.

One: this site can now count visits, and only if you let it. It asks you once, before anything is loaded from Google and before any cookie is set. Saying no costs you nothing and is remembered. Saying yes reports your reading to Google, including your IP address. The previous policy promised no analytics at all, so this is the change that most deserves your attention — Cookies has all of it, including what is switched off and how long Google keeps what it gets.

Two: there is now a way to send you email, and the sending company records what you do with it. Who opened a message, when, and which links they pressed. Your address is held by a third company as a result. Nothing is sent without being approved one message at a time — The mailing list.

Three: you can now pay for this site, and that brings a payment company into it. Card details never reach this site — the card is typed on the payment company’s own page — and what we are told afterwards and keep is listed in full. Paying creates no account and no login — Paying for this site.

Four: removal now has four limits rather than three. The new one is the sending company, which has to keep your address in order to obey an instruction never to write to you again — Asking to be removed.

If this policy changes again, the new version is posted on this page with a new date, and that date is the record that something changed. A change can be sent to the mailing list as well, because there is now a way to send to it. This page does not promise that every change will be: a promise to announce is worth exactly what somebody keeps, and the version of this page that made one could not keep it.

This version replaces the policy published at this address and marked effective August 2026. That policy said this site used Cloudflare Web Analytics to count visits in aggregate, and that the signup form was protected by Cloudflare Turnstile, which could set a cookie on the page carrying the form. That visit counter is not part of this version of the site. Visits are counted by Google Analytics instead, and only for a reader who has allowed it, which the old policy never asked anybody. The bot check is part of this version, and this document says more about it than that one did: which pages run it, what your browser sends, what it may leave behind, and what happens if you have scripts turned off.

Contact

Questions, removal requests, corrections, or anything else about privacy: info@burgseyeview.com.

Postal address. Burg’s Eye View, PO Box 511, St. Petersburg, FL 33711.