Brolly — Privacy Policy

Last updated: 29 September 2026

Brolly has no accounts, no advertising, no analytics, and no trackers. Weather and city-search requests go to a single server of ours; this page explains each of them, and exactly what each one contains. The one exception is the optional one-time upgrade, which is handled by a payment service, ExtensionPay (extensionpay.com). The extension contacts ExtensionPay only after you have opened the upgrade's checkout page or its login page, and those requests are described under “The optional purchase” below. If you never open either page, nothing Brolly stores identifies your install. If you do, ExtensionPay issues a random key for this install, which is kept in your browser; if you then buy, the email address you paid with is kept there too. Those two are the only identifiers Brolly ever holds, and the email is the only personal information. Both are in the table below.

What the extension stores, and where

Everything is stored in your browser, using Chrome's own extension storage. No copy of it is uploaded to us. Two stored items do take part in requests to our server, and each is described where its request is: the coordinates of a city, which are rounded to two decimals before they leave your browser (see “On precision” below), and the publication time of the forecast you already hold, which is sent back exactly as it is stored (see “The requests it makes”). The only stored item Brolly sends to anyone other than us is the payment library's key, which goes to ExtensionPay and only to ExtensionPay, as described under “The optional purchase”. If Chrome Sync is on, Chrome copies whatever is in chrome.storage.sync to your Google account so your other computers receive it; that copy is handled by Google under its own privacy policy, not by us.

Data	Where	Why
The cities you chose — a home city, plus any extras you save — and your settings: units, badge appearance, clock format, notifications, Planner activities, which one-time hints you have dismissed, and which optional features are unlocked	`chrome.storage.sync`, mirrored to `chrome.storage.local`	So your settings survive a browser restart or a profile move. If you have Chrome Sync enabled, Chrome — not us — may sync this between your own devices.
The most recent weather data for each of those cities: the forecast, any official warnings, the next couple of hours of precipitation, and the temperatures behind the warmer-than-yesterday comparison. Also the planetary geomagnetic forecast, which is not tied to a city at all.	`chrome.storage.local`	So the toolbar badge and the popup are correct the instant you look at them, without waiting for the network.
A short weather memory for each saved city, kept since you added it: the warmest reading Brolly has seen there, the dates of the last two frosts, and the longest dry spell	`chrome.storage.local`	So the popup can say things like “first frost since March”. It stays on this device, is never sent anywhere, and is deleted when you remove the city.
The pressure mark you set by tapping the barometer	`chrome.storage.local`	So the dial can show which way pressure has moved since you set it. It is kept per city, on this device only, and is deliberately not synced.
If — and only if — you open the upgrade's checkout page or its login page: a random key that ExtensionPay issues for this install, held by the payment library (ExtensionPay)	`chrome.storage.sync`	It links this browser to the record ExtensionPay keeps of any purchase. It is created when you first open either page, whether or not you go on to buy, and it is sent only to extensionpay.com, as described under “The optional purchase”.
Once that key exists: ExtensionPay's last answer about it — whether it has been paid for and when, and, if and only if you bought, the email address you paid with — held by the payment library	`chrome.storage.sync`	So that the features you bought stay unlocked, and so you can restore them on another computer by asking for a login link. Your card details never reach this extension or us — payment happens on Stripe's own checkout page. If you never buy anything, no email is ever stored.
Brolly's own note of that answer: whether the upgrade was paid for, when that was last confirmed, when ExtensionPay was last asked and whether asking failed, and — for two hours after you open the checkout or login page — a reminder to ask again sooner	`chrome.storage.local`	So the upgrade keeps working for up to 30 days when ExtensionPay cannot be reached, so ExtensionPay is asked about once a day rather than on every refresh, and so a purchase you have just made is noticed within minutes. It holds no email and no key, and it stays on this device.
The date this extension was installed, written by the payment library (ExtensionPay) that handles the optional one-time purchase	`chrome.storage.sync`	The library records it so that, if a paid tier is offered, it can tell a new install from an old one. It is a date and nothing else — no identifier, no address. It is written whether or not anything is for sale, and whether or not you ever buy anything.
Bookkeeping that keeps the rest working: which city the badge is currently following, which warnings you have already been notified about and until when each was forecast to last, whether the last refresh for a city failed, when the last official-warning check for a city failed, when the last geomagnetic-forecast request failed, and whether a settings change is still waiting to be copied to `chrome.storage.sync`	`chrome.storage.local`	So a change of home city is noticed and refetched, rather than left showing the previous city's temperature; so a notification is not repeated; so the popup can tell you when a check failed instead of showing an old reading as though it were current; so a request that just failed is not repeated every time you open the popup; and so a settings change that could not reach Chrome Sync is kept and sent again rather than lost.

Nothing Brolly stores in your browser falls outside that table. Uninstalling the extension removes all of it, and no copy of it exists on any server of ours. ExtensionPay keeps its own record of any key it has issued and of any purchase, on its own servers.

On precision. A saved city is held at the coordinates the place list gives for it, to four decimal places, and each stored item is filed under those same coordinates so that one city's data is told apart from another's. That is finer than the two decimals a request carries, and the difference is deliberate: these coordinates identify a town in a public place list rather than a position of yours. Brolly never sends them to us or to any weather service: every request rounds to two decimals first, as described below. If Chrome Sync is on, Chrome copies your settings, including these coordinates, to your Google account, as described above.

What we never ask for

Your device location. Brolly does not request the geolocation permission. You type a city name; that is the only location it knows.
Your browsing. It does not request access to the pages you visit, your history, your tabs, or your bookmarks, and it runs no code on any website.
Your identity. There is no account and no sign-in. If you open the upgrade's checkout or login page, our payment provider issues a random key for this install. If you buy Brolly Pro, it also stores the email address you used at checkout, so the purchase can be restored on another computer. Those are the only identifiers involved, and both are listed in the table above. If you never open either page, no identifier exists.

The requests it makes

To show a forecast, the extension asks our own server for the weather at the coordinates of the city you picked. That request contains:

A latitude and longitude, rounded to two decimals — about a one-kilometre grid square. This is deliberately imprecise: it is the centre of the town you chose, not a position, and rounding also lets everyone in the same town share one cached answer.
Your IP address, because every internet request necessarily includes one.
The publication time of the forecast already on your machine, once there is one — so the server can answer “that one is still current” rather than send it again. It is the weather model's own timestamp, the same for everyone holding that forecast, and it describes the data rather than you.

That is everything Brolly puts in a forecast request. Your browser also adds the standard headers it attaches to every request: its name and version and your operating system (User-Agent), your preferred languages (Accept-Language), and Brolly's extension id (Origin), which is the same for every Brolly user. There is no identifier, no cookie, and nothing linking one request to another.

We keep no logs of it. The server stores cached forecasts keyed by rounded coordinates — never by IP, and never by user. It sets no cookies. The same request from a hundred people in one town is indistinguishable, because it is literally the same request. The one thing the server counts is how often its cache was hit or missed since it last restarted: running totals, held in memory, with nothing in them about who asked.

The extension makes four other kinds of request, all to that same server:

Official weather warnings — the same rounded coordinates. Where an official warning service can be asked about a point, our server asks it; for most of the world there is none to ask, and the request goes no further than our server.
Precipitation for the next couple of hours, where weather radar reaches — again the same rounded coordinates.
Geomagnetic activity, for the northern-lights forecast — no coordinates, and no parameters of any kind. What comes back is planetary: one set of figures that is the same everywhere on earth. So this is one fixed address, identical for every user. It is requested only if you turn that activity on and the city you chose is far enough north or south for an aurora to be possible there.
A city search — the term you typed, answered from a city list the server already holds. Search terms are not logged either.

Those answers are cached the way forecasts are: under the rounded coordinates, under the search term, or — for the planetary figures — under a single fixed address that carries nothing about you. Never under an IP address, and never under a user.

The optional purchase

The one-time upgrade is sold through ExtensionPay (extensionpay.com), a payment service for browser extensions; the payment itself is taken by Stripe on its own checkout page. These are the only requests Brolly makes to anyone other than our own server, and none of them happens until you start it:

When you click to buy the upgrade, or to restore one you already bought, and this install has no key yet, the extension asks extensionpay.com for one. That request carries nothing else, except that a developer's test copy of the extension says it is one. The key that comes back is random, and is kept in chrome.storage.sync as listed in the table. The page you asked for then opens on extensionpay.com with that key in its address.
Once a key exists, the extension asks extensionpay.com whether it has been paid for. That request carries the key. It is made about once a day; at most every two minutes during the two hours after you open the checkout or login page, so that a purchase is noticed quickly; when you press Refresh in the popup while nothing on record unlocks the paid tier (no purchase, a refund, or a purchase not confirmed for 30 days); and, after an attempt that failed, again three hours later. The answer is stored as listed in the table.
Without a key, nothing is asked. The payment library answers “not paid” from inside your browser, and no request is sent.

These requests go from your browser straight to ExtensionPay, not through our server, so ExtensionPay receives your IP address and the standard headers your browser adds, as well as the key. ExtensionPay keeps its own record of the keys it issues and of purchases. The checkout and login pages are ExtensionPay's and Stripe's own websites, and what you enter there is handled under their own privacy policies.

Who else is involved

Our server fetches forecasts from the Norwegian Meteorological Institute (MET Norway), passing along only the rounded coordinates. The short-range precipitation series comes from the same institute, requested the same way. So do official warnings, for coordinates in a broad band of northern Europe: that band decides only whether the request is worth making, and MET's warning service issues warnings for Norway, so a point elsewhere in the band is sent to it but has no warning to receive back. Since 31 July 2026 a warning request also carries the language code no when your browser's language is Norwegian, so MET can answer in Norwegian; nothing is sent for any other language. Apart from that code and the rounded coordinate, MET receives nothing about you — not your IP, not anything else — because the request comes from our server, not your browser. Its data is used under CC BY 4.0.

For coordinates in the Americas, and in the US Pacific territories, official warnings come from the US National Weather Service (api.weather.gov). Our server sends it the same rounded coordinates and nothing else. As with MET, your IP address never reaches it, because the request is made by our server rather than by your browser. The service answers for the United States and its territories and refuses points outside them, which is how our server learns there is nothing to ask about a place and stops asking for a day. Its data is a US government work, in the public domain.

Geomagnetic activity, used only for the northern-lights forecast, comes from NOAA's Space Weather Prediction Center (services.swpc.noaa.gov). That request carries no coordinates and no parameters at all — it is one fixed address, and what it returns is the same everywhere on earth — so nothing about you or your city reaches it. It is named here for completeness, not because it receives anything.

The city list is built from GeoNames, also used under CC BY 4.0. It is stored on our server; no request is made to GeoNames when you search.

The server runs on Cloudflare Workers. Cloudflare processes the request as our infrastructure provider and may retain transient network-level logs under their own privacy policy.

Notifications

If you leave severe-condition alerts on, notifications are generated on your own machine from the forecast and the official warnings already stored there. Nothing is sent anywhere to produce them, and no push service is involved.

Clicking a notification about an official warning opens that warning's own page on the issuing service's website (MET Norway's or the US National Weather Service's) in a new tab, when the warning came with one. That is an ordinary visit to their website from your browser. Clicking a notification about Brolly's own estimate only dismisses it.

Children

Brolly is not directed at children. It collects no personal information from anyone, of any age, who does not buy the upgrade. The only personal information that can ever appear — a buyer's email, held in the browser by the payment library — comes from an optional purchase a parent or guardian would have to make.

Changes

If this policy ever changes in a way that affects what leaves your browser, the change will be described here with a new date. The dated notes below are the record.

29 September 2026 — corrections, and two changes to what the extension does. Corrections. This policy said that every request goes to our own server and that no identifier exists unless you buy. Neither was accurate while the upgrade was on sale: opening its checkout or login page makes the extension contact ExtensionPay directly, and ExtensionPay issues a random key for the install whether or not you buy. A new section, “The optional purchase”, describes those requests, and the table now lists that key, Brolly's own note of the purchase status, and the weather memory kept for each city, none of which it listed before. The paragraph on precision no longer says a saved city's coordinates are never sent anywhere: if Chrome Sync is on, Chrome copies them to your Google account. And the section on requests now names the standard headers your browser adds to every request, which the 31 July note below wrongly said were not sent. The section on what the extension stores said that none of it is sent to us; that was not exact, because two stored items take part in requests to our server. It now says which: the coordinates of a city, rounded to two decimals before they are sent, and the publication time of the forecast you already hold, which is sent back as stored. Both were already listed under “The requests it makes”, and neither is new. Changes. ExtensionPay is now asked about a purchase about once a day, or more often only for two hours after you open its pages or when you press Refresh while nothing on record unlocks the paid tier; before, an install that had opened checkout without buying asked on every refresh. “Nothing on record unlocks the paid tier” means no purchase, a refund, or a purchase that has not been confirmed for 30 days; the last case is a buyer whose confirmation has lapsed, who is asked again on Refresh and on the two-minute schedule after opening the login page, so that a restored purchase is noticed. That is the same request as before and it sends nothing new; what changed is only that such a buyer is now included on those occasions. And clicking an official warning's notification now opens the issuer's page for that warning.
31 July 2026 — something small did change about what leaves your browser, so it is recorded here. Brolly now shows official MET Norway warnings in Norwegian to people whose browser is set to Norwegian, which it does by sending the language code no along with the rounded coordinate when it asks for warnings. Nothing is sent for any other language, and nothing else about your browser is sent in any case. The same release added the ability to search for a city by its name in your own language, which changed no request at all — the names are a list inside our own server.
28 July 2026 — wording only, and nothing about what leaves your browser changed. One bullet still said there was no identifier of any kind, which the previous day's entry had already contradicted: buyers of the optional upgrade have an email held by the payment provider. That bullet now says so and points at the table. Recorded here because a policy that disagrees with itself is worth a dated note even when the behaviour it describes has not moved.
27 July 2026 — Brolly gained official weather warnings, short-range precipitation and a northern-lights forecast. Each is a further request to the same server, carrying the same rounded coordinates as a forecast or, for the northern lights, no parameters at all. Two upstream services are named here for the first time: the US National Weather Service, which receives those rounded coordinates from our server, and NOAA's Space Weather Prediction Center, which receives nothing. The same day, the optional paid upgrade began storing the buyer's email via ExtensionPay; the opening paragraphs were rewritten so they no longer claimed Brolly holds no personal information at all.

Contact

Questions or concerns: andreas.nelvik.engebretsen@gmail.com.