Privacy
Privacy policy.
Last updated:
This page explains what personal data the site collects, why, how long it is kept, who receives it, and what rights you have. Questions and privacy requests go tosupport@mikrotikfilters.com.
1. Who runs this site
The data controller is Brett Battiato, Australian sole trader (ABN 22 142 952 595), trading as mikrotikfilters.com. Postal address: PO Box 1213, Kelmscott WA 6997, Australia. Contact: support@mikrotikfilters.com. No data-protection officer has been appointed. The site is hosted on Cloudflare infrastructure (Workers, Pages, D1, R2, KV). Email goes through Resend. Payments — when you donate or subscribe as a supporter — are sold and processed by Paddle as Merchant of Record (the legal billing entity is Paddle.com Market Ltd), meaning Paddle is the seller of record for the transaction and collects and remits the applicable consumer taxes itself.
2. Jurisdictions
The operator follows the Privacy Act 1988 andAustralian Privacy Principles (APPs) as the Australian baseline, whether or not a particular small-business exemption applies. Visitors from the European Economic Area or the UK are additionally covered by the GDPR /UK GDPR; the operator does not actively target either region but accepts visitors from both, so we treat GDPR as binding for those visitors. California residents covered by CCPA/CPRA or another applicable US state privacy law can exercise the rights described in §8 below.
3. What we collect
Different surfaces collect different data. The list below is exhaustive — if a future feature collects something not listed here, it will be added before the feature ships.
3.1. Server logs (everyone)
Every HTTP request to the site goes through Cloudflare's edge. Cloudflare records the standard server-log fields (IP, User-Agent, request path, response code, timestamp) for its own abuse-prevention + caching purposes. The operator does not run any additional access log. Cloudflare's retention is governed by their privacy policy. We do not log requests ourselves, with three specific exceptions below.
3.2. Pull events (anonymous list pulls)
When a router fetches a list at /api/lists/<slug>.rsc, we record one row in pull_events with: list id, response status (ok / rate-limited / error), serve source (KV / rebuild / R2 fallback), a hashed IP cohort identifier, a hashed User-Agent, and a timestamp.
The IP cohort hash is critical. It is the SHA-256 of (a per-deploy salt, the IP truncated to /24 for IPv4 or /48 for IPv6). The salt is a protected deployment secret rotated only deliberately; truncation happens before hashing, so:
- We never store your individual IP — only an opaque identifier that buckets you with the rest of your /24 subnet (typically dozens to thousands of devices).
- The value is pseudonymous rather than anonymous: the application cannot read a raw IP from it, but it is still treated as personal data and used only for abuse prevention and aggregate operations.
- The hash exists so the operator can spot abuse patterns ("this cohort hammers the API") without identifying anyone in particular.
Pull-event rows are pruned after 30 days by a daily maintenance cron. The pruner runs automatically — there is no human in the loop.
3.3. Authentication
The site uses passwordless magic-link sign-in. To create an account or sign in, you give us your email address. We:
- Store the email address.
- Create a one-time magic-link token (random 32+ bytes, SHA-256 hashed at rest, 10-minute expiry) and email it to you via Resend.
- Once you click the link, we issue a session: a random session id stored only in your browser as an HttpOnly + SameSite cookie; we keep its SHA-256 hash + your role + timestamps in our database. We do not see the raw cookie value.
- We hash your IP and User-Agent (different namespace from the pull-events hash, separate salt) and store those hashes alongside the session row, for the "active sessions" view on /account so you can spot suspicious devices and revoke them.
Sessions use a rolling expiry of about two hours, or seven days when “remember me” is selected. Logging out revokes the row immediately; terminal session rows are pruned after a default 30-day retention window.
3.4. Submissions to community lists
If you submit an IP/CIDR to a community list, we store the address, your account id (for moderator visibility), the severity / classification you chose, your free-form comment and evidence URL, and the moderation outcome. Submissions are visible to moderators; approved submissions become public list entries.
3.5. Donations + supporter subscriptions
Paddle is the Merchant of Record and handles all payment processing through its in-page checkout overlay. We never see card numbers or other payment-instrument data — Paddle holds the card data and sends us a webhook with metadata only. We store:
- Paddle customer id, subscription id, and transaction id — opaque references, not card data.
- The amount, currency, and timestamps.
- Linkage to your account when you were signed in at checkout time.
Paddle's own privacy policy covers what they do with the card data on their end. We do not pass any of our other personal data to Paddle beyond what's needed for the checkout (your email, when signed in).
3.6. Submitted scripts (community-scripts library)
If you are a supporter and submit a script to the/scripts library, we store the script body, your title and description, the metadata you chose (category, risk level, RouterOS-version applicability), and your account id as the owner. After moderator approval the script becomes publicly readable + pullable. If you cancel your supporter subscription, your scripts get transferred to a system "community" account 30 days later — they stay live, but ownership is reattributed.
3.7. Audit log
Every state-changing action by an admin or moderator (approving a submission, suspending a user, rebuilding a list) writes an audit_log row. The row carries the actor's user id, the action name, target type/id, a hashed IP, a hashed User-Agent, free-form metadata, and a timestamp. The audit log is retained for at least 90 days and is admin-readable only.
3.8. Error reports (Sentry)
When the API hits an unexpected error, we send a redacted report to Sentry. The redaction policy strips: request bodies, query strings, all headers except a tiny allowlist (Content-Type, User-Agent, Accept), all user fields except the integer user id, all tags except a curated low-cardinality set (route name, list slug, etc.), and any string content matching Paddle id patterns, currency-amount patterns, email patterns, or magic-link token patterns. The error message + the stack trace go through; the route + method + status code go through.No payment amounts, no email addresses, no IPs, no Paddle identifiers reach Sentry.
4. What we explicitly do not collect
- No third-party tracking cookies. No Google Analytics, no Facebook pixel, no Plausible, no Mixpanel, no Hotjar, none. The site does not set a tracking cookie. Authentication, security, checkout, and user-requested preference storage is described in thecookie and storage notice.
- No browser-side analytics or error SDK. The only third-party browser code is Paddle.js, loaded when checkout starts; it is used for payment and fraud-prevention rather than audience tracking.
- No FLoC / Topics. The
Permissions-Policy: interest-cohort=()header opts out of Google's cohort-tracking scheme. - No advertising fingerprinting. Salted IP/UA hashes are used only for security, rate limits, session visibility, and audit integrity — never advertising or cross-site profiling.
5. Sub-processors
We rely on the following providers to run the site. Each is bound by their own contractual privacy obligations to us; their published privacy policies govern what they do with the data we send them.
- Cloudflare — hosting (Workers, Pages, D1, R2, KV), edge cache, abuse-prevention WAF.
- Paddle — Merchant of Record; payments + subscription billing + consumer-tax handling.
- Resend — transactional email (magic-link sign-in, mod-decision notifications).
- Sentry — error reporting (redacted, see §3.8).
6. Legal bases (GDPR)
For EU/UK visitors, the legal bases under GDPR Art. 6 are:
- Contract (Art. 6(1)(b)) — for delivering the supporter subscription and account features you signed up for.
- Legitimate interest (Art. 6(1)(f)) — for abuse prevention, security logging, and rate-limiting. Your interest in privacy was weighed against this; we believe the hashed-cohort approach in §3.2 minimises the intrusion.
- Legal obligation (Art. 6(1)(c)) — when we have to retain payment records for tax-law purposes (Australian business and tax records are generally retained for five years; the operator is not currently GST-registered).
7. Retention periods
| Data | Retention |
|---|---|
| Pull events (cohort hashes + status) | 30 days, then auto-pruned |
| Magic-link tokens | 10-minute validity; terminal rows pruned after 7 days by default |
| Sessions (terminal) | Pruned 30 days after expiry or revocation by default |
| Sessions (active) | Rolling two hours, or seven days with “remember me” |
| Submissions (any status) | Indefinite for audit; you can request deletion (§8) |
| Donations + subscriptions | 5 years (ATO requirement); then auto-pruned where lawful |
| Audit log | Minimum 90 days; longer in practice |
| Error reports (Sentry) | Subject to Sentry's retention; we set 90 days |
| Account email | Until you delete the account, then anonymised |
8. Your rights
You can ask us to:
- Access — give you a copy of all personal data we hold about you, in a portable format.
- Correct — fix any inaccurate data.
- Delete — remove your account and associated data. Some data we have to keep (tax records for 5 years; audit log for the integrity of the platform); we'll explain what stays and why.
- Restrict — pause processing while a complaint is being investigated.
- Object — to processing based on legitimate interest (§6).
- Port — receive your data in a structured machine-readable format you can send elsewhere.
To exercise any of these, emailsupport@mikrotikfilters.com. We aim to respond within 30 days; AU/EU/UK regulators allow up to 30 days under their respective laws and we don't promise faster than the statutory window. You'll get an acknowledgement within 7 days confirming how the request has been interpreted, and we'll ask you to confirm the request from the email address the account is registered under before any data is released. The operator follows a documented internal procedure for handling these requests.
9. US privacy, children, and automated decisions
The operator does not sell personal information, share it for cross-context behavioural advertising, or use it for targeted advertising. There is therefore no sale/share opt-out link. The site is not directed to children; accounts and paid features require age 16 or older. The operator does not use personal data for solely automated decisions that produce legal or similarly significant effects. Moderation and account enforcement remain subject to human review. Contact support to appeal or exercise an applicable US state right.
10. International data transfers
Cloudflare's edge serves your request from the closest of its global PoPs. Paddle processes payments through international infrastructure as Merchant of Record. Resend and Sentry process limited email-delivery or redacted error data in the United States. EU visitors' data therefore crosses borders; we rely on Cloudflare's, Paddle's, Resend's, and Sentry'sStandard Contractual Clauses (or successor mechanism) for those transfers. Data minimisation via the redaction + hashing policies in §3 limits what crosses regardless of mechanism.
11. Changes to this policy
Material changes (new sub-processor, new data type collected, retention extended) will be flagged at the top of this page for at least 30 days, and the date above moves forward on every change. Editorial fixes (typos, clarifications) update the date but don't get a banner.
12. Contact and complaints
Privacy questions, requests, and complaints:support@mikrotikfilters.com. State what happened and the outcome you want. The operator will acknowledge the complaint, investigate it, and explain the outcome. Australian residents who remain dissatisfied can contact the OAIC; EU/UK residents can contact their local data-protection authority; US residents may contact their state attorney general or other competent regulator. No EU or UK representative has been appointed; contact the controller directly using the details in §1.