Privacy

What a request here records.

getedge is a private preview operated by Floom. Private means unlisted and told to every crawler not to index it. It does not mean locked: there is no password on this deployment, so anyone who has the address can open any page on it. This page describes what a request actually leaves behind, including the ordinary parts that are easy to forget.

You are not asked who you are.

No account is needed to browse the catalog, to open a skill page, or to install a skill. The endpoint that serves a bundle is unauthenticated on purpose. The one thing on the public surface that does need an account is publishing a stack, and it says so when you try.

Nothing watches how you browse.

This deployment refuses behavioural analytics outright, on both sides. One environment variable turns capture off in the browser and on the server, both capture paths read it before an analytics client is constructed, and a test fails the build if any other file in the app imports an analytics SDK at all. The deploy script refuses to ship a build without that variable set. So there is no analytics script on any page, no tag manager, no pixel, and no third-party request made on your behalf.

Cookies.

Browsing signed out, this app sets none of its own. Signing in sets the session cookies our authentication provider issues, which is several cookies rather than one, and the middleware can rewrite them on a later request to keep the session fresh. There is no analytics cookie and no advertising cookie, because there is no analytics and no advertising.

When an install link is fetched.

A row is written that records exactly that: a link was fetched. It is not an install, and the column that would claim otherwise is fixed to false by a database constraint. The row holds a one-way digest computed from the skill’s share token, a server-side secret, and the network address the reverse proxy in front of this deployment observed. The first time a given digest is seen, two more rows are created beside it, a client identity and the digest itself, so that a repeat fetch can be recognised as a repeat. Your address is not part of any of the three.

The row also holds the user-agent string your client sent, up to 256 characters, kept as a claim rather than used as a key. One row is written per digest per release per 24 hours, and the rows are kept for at least 24 months, which a database constraint enforces. If no trusted address is available, nothing is written.

What that buys is coarse, and it is described as coarse everywhere it is shown: two clients behind one network address collapse into one row, and one client whose address changes counts more than once. A tracking link, if you followed one to get here, records an HTTP request the same way and under the same rules, and an HTTP request is not a reader: a crawler, a scanner, a link unfurler and a browser prefetch all look identical to it.

Where your address does get stored.

In the rate limiters, and this is the part a careful description of the digests above would hide. Most of them key on the observed address as it is, and that key is written into a database row: the sign-in limiter stores auth:email: followed by your address, and the install endpoint stores its own equivalent. Only the catalog search limiter hashes the address first, under a secret re-derived daily. The rows hold a key, a count and a window, and no request content. The web server in front of the deployment also writes an ordinary access log, and an access log contains addresses.

Nothing is recorded after you install.

An installed skill is a file your agent reads off a local disk. Nothing reaches this deployment when it does, and no client we ship reports it. There is an endpoint anyone can call to report an install, and every row it writes is marked self-reported, because that is all such a report can ever be.

If you sign in.

Sign-in is an email link and nothing else. You give an address, our authentication provider sends the link, and what is stored is what it stores for a link-based account: the address, the account it belongs to, and the session. There is no password to store. The response to a sign-in request is the same whether or not the address already has an account, so nobody can use the form to learn who has one.

Who else touches a request.

Floom, as the operator. One hosted service, which is both the database and the authentication provider. The web server in front of the deployment, which terminates TLS, writes the access log and is what observes the address described above. And the content network in front of that, whose own header the code trusts for the client address when a request arrives through it. Nothing is sold and nothing is shared for advertising; those are commitments rather than things a line of code enforces, and they are written here so they can be held to.

Asking for a copy, or a deletion.

Write to [email protected]. There is no self-service deletion in this preview and no automated flow behind that address: a request is handled by hand. If you have an account, the address and its sessions are what there is. The fetch and click rows cannot be found from an address at all, because they are keyed on a digest of one that was never stored, so those are the rows nobody can retrieve for you and nobody can retrieve about you. The rate-limit rows and the access log are the opposite case, and they expire on their own.

This page describes today.

Last reviewed 7 September 2026, against the deployed code and the deployed web-server configuration. It is a preview, so it changes; when what is recorded changes, this page changes in the same commit.