Privacy Policy

Last Updated: October 2, 2026

The Simple Version

I respect your privacy. Any data collected through services I offer will not be sold, shared, or otherwise provided to anyone unless legally required to do so. Where a feature genuinely cannot work without passing something to a third party - mobile push notifications being the one real example - I spell that out under Data Sharing below rather than burying it.

Data Collection

If you use any services I provide, I may collect minimal data necessary for the operation of those services. This could include:

Data Usage

Your data is used solely for:

Data Sharing

I will not:

What that doesn’t mean is that nothing ever leaves my infrastructure. Operating a service sometimes requires handing something to someone else to make it work at all - the Fluxer push relay below is the clearest example of that. Where it happens, it’s limited to what the feature actually needs, it’s described on this page, and it isn’t marketing, profiling, or a sale.

Embedded Content

Some posts embed third-party content, usually videos. Where I do that, I use privacy-enhanced embeds that don’t set tracking cookies unless you actually press play.

Loading the page does still contact the provider, which tells them your IP address and which browser you’re using - the same thing that happens when you visit any website. I don’t see any of that, I don’t receive it, and I don’t collect it. It goes from your browser to them without passing through me.

Where it’s logically possible, I’ll put a plain link next to an embed, so if you’d rather it didn’t happen at all you can go and view the thing on your own terms instead.

I did consider going further, and having the page load nothing at all until you click a placeholder. I decided against it. That’s more moving parts on a site maintained by one person in his spare time, and a privacy control that quietly stops working is worse than a simple one you can see and reason about - it looks like protection while doing nothing. So you get a plain embed, described honestly above, with a link beside it. If that trade stops being a fair one, say if these ever start appearing on every page rather than the occasional post, I’ll revisit it.

I should be honest about the wider version of this, too. I run a lot of software I didn’t write - the site generator, the mail stack, the various pieces underneath them - and that software can carry its own embeds, outbound calls and logging that I never asked for and am not necessarily aware of. I don’t go looking for ways to track anyone, and I turn this stuff off where I find it. But “I didn’t intend it” is not the same as “it isn’t happening,” and I’d rather say that plainly than imply a personal compute lab has been audited line by line.

Push Notifications (Fluxer)

If you use the official Fluxer app against my instance and you turn push notifications on, those notifications travel through Fluxer’s push relay - a service operated by the Fluxer project, not by me.

That isn’t a design choice I made. It’s how mobile push works: Apple and Google only deliver notifications through credentials held by whoever signed the app, and I didn’t sign the Fluxer app. My server has no way to wake your phone on its own. So the delivery chain is my server, then Fluxer’s relay, then Apple or Google, then your device.

What the relay can see. Per Fluxer’s description of it, your device generates a key pair and keeps the private half locally. My server encrypts each notification to your device’s public key, and the relay passes the sealed block to Apple or Google unopened. Every notification is padded to the same size, so its length doesn’t leak anything either. On that account, Fluxer cannot read your notifications, and neither can Apple or Google - what they handle is an opaque, fixed-size block.

What the relay does record. Fluxer logs, per notification: a salted digest of the device identifier, app and environment information, the encrypted payload’s size, its priority and expiry, how long it took to process, and a timestamp. The network address of the sending instance is recorded at the edge - that’s my server’s address, not yours. Apple or Google receive the device identifier, app information, priority, expiry, and the encrypted block.

Where that lives, and for how long. The relay and its logs run on the same infrastructure as the hosted Fluxer service - at the time of writing, Vultr in Piscataway, New Jersey - and Fluxer’s stated retention for security and usage logs is up to 90 days. Their Privacy Policy is the authoritative word on all of it, and it governs what they do with what they hold. I’m not a party to that relationship beyond handing them a sealed envelope addressed to your phone.

One thing worth knowing. The relay address for a device is a capability: anyone holding it can push to that device. As the instance operator, I hold yours, because that is precisely what makes notifications work.

Turning it off. This switch cuts both ways, deliberately. You can disable relay use for your device, and I can disable it for the whole instance, independently and at any time. If you’d rather no third party sat in the delivery path at all, turn push off in the app - the chain above then doesn’t happen, and you’ll see your messages when you open it.

If you don’t agree to the relay, don’t use the mobile app. Use the web client or the desktop app instead: neither one needs the push relay, so none of the above applies to them. That is the clean, complete opt-out, and I’d rather point you at it than pretend the mobile path can be made relay-free.

Because it can’t, not by me. The relay is only necessary because of Apple’s and Google’s own policies about who may send a push to a signed app, and the fix on my end would be building, signing, and maintaining my own iOS and Android builds of Fluxer - two app-store accounts, two review processes, two release treadmills, forever. I am not doing that for a free personal compute lab. If somebody wants to pay me a lot of money to do it, my inbox is at the bottom of this page.

And the honest caveat, consistent with the rest of this page: I am describing Fluxer’s encryption as Fluxer documents it. I haven’t audited their relay code or their logging, and I’m not realistically in a position to. What I can speak to is the part I control - my server seals the payload before it leaves here, so there’s no version of this where I’m the one handing your message text to somebody else.

DMARC Reporting

To be a good internet citizen while hosting my own mail server, I participate in DMARC aggregate (RUA) reporting. This means I send and receive standard DMARC reports to and from other mail providers to help fight email spoofing and abuse.

These reports contain only summary information — such as sending IP addresses, authentication results (SPF/DKIM/DMARC pass or fail), and message counts. They do not include the content, subject lines, or recipients of any email message. This data is used solely to combat abuse and improve mail security and deliverability.

Your Rights

You have the right to:

Security

I make reasonable efforts to protect your data, but let’s be honest - this is a personal compute lab. See the main page for my track record on uptime and reliability.

Changes to This Policy

I may update this privacy policy from time to time. Any changes will be posted on this page.

Contact

If you have questions about this privacy policy or your data:

This privacy policy applies to all services offered by The Fat Hacker.

Disclaimer, as ever: this policy was written with the help of Claude Opus, and as ever I’ve read and approved every word. I am not a lawyer, this is not legal advice, and it’s a plain-language description of how a personal compute lab handles data - not an airtight legal contract. If you need the real thing, go pay someone who passed the bar.