Privacy Policy

MUGA: Clean URLs, tracking removed  ·  Effective date: 2026-05-25  ·  Version 3.1.0  ·  Source code

What data does MUGA handle?

MUGA receives URLs when you click links or right-click to copy a clean link. These URLs are cleaned inside your browser. MUGA never sends your URLs or browsing data anywhere. MUGA makes very few external requests, and every one of them is disclosed on this page. The only one enabled by default is a weekly signed rule list (see "Remote rule updates" below), which you can turn off in Settings.

MUGA's data lives in two places, deliberately separated:

• Per-device, on this machine only (chrome.storage.local): your acceptance of these terms and the version of the policy you agreed to (onboardingDone, consentVersion, consentDate); per-device decisions you made about behaviours your other devices may have enabled (remoteRulesEnabled overrides; see Per-device consent below); usage counters (URLs cleaned, parameters removed, referrals spotted); and three activity records, each with its own switch in Settings > Advanced: Recent activity (attributionLedger), the last 10 URLs MUGA cleaned for you, full addresses included, with the oldest replaced as new ones arrive; Cross-site identifier detection (crossSiteFreq), the names of parameters seen on each site, with their values stored only as one-way hashes; and Record per-domain statistics (domainStats), per-site counts of removed parameters for up to 50 sites. These three records survive a browser restart. Turning a switch off stops new entries, and uninstalling MUGA removes them.
• Across your own devices, via your browser account (chrome.storage.sync): behavioural preferences you would expect to follow you between devices, namely language, blacklist, whitelist, custom tracking parameters, the affiliate toggle's default value, the remote-rule-updates default value. Sync happens through your browser, never through MUGA.

Neither bucket is ever visible to MUGA. Short-lived session data (debug logs, per-tab badge counts, this session's list of cleaned URLs) lives in chrome.storage.session and is automatically cleared when the browser restarts. Usage counters and activity records are never transmitted anywhere.

Per-device consent

Acceptance of these terms is recorded per device, not per browser account. Installing and using MUGA is what constitutes acceptance, and that record is made on each device separately rather than inherited from another one. The reasoning is captured in our architectural decision record ADR-0001: consent is an act between you and the device you are using; inheriting it across devices silently would deny each device's user the chance to read and decide. The terms are linked from onboarding, from the popup and from the Settings footer on every device, so reading them never depends on having caught a prompt.

Behavioural preferences (toggles like "Enable remote rule updates", "Remove all affiliate tags from other sources", and others) follow your browser account through sync. But on a fresh device, if any of those preferences arrives enabled from another device, MUGA shows you an explicit confirmation prompt during onboarding before acting on them. If you decline a preference on this device, the override is recorded locally and your other devices' settings are left untouched.

Updating these terms does not re-prompt you and does not gate any feature. MUGA follows the model uBlock Origin uses: the documents are permanently reachable rather than announced once, and continuing to use the extension after an update means you accept the updated terms. See ADR-0007 for why the versioned re-acceptance engine was removed.

Migration on upgrade

If you previously installed MUGA before this version and your acceptance was stored across devices via sync, MUGA will migrate that acceptance to local storage on the first run after upgrade. The migration is one-way (sync → local) and idempotent: you keep your acceptance state without re-onboarding. The migration is implemented in src/lib/sync-migration.js in the source.

Tracking parameters

MUGA strips tracking parameters (UTMs, fbclid, gclid, and others) from URLs automatically. This happens locally. The removed parameters are not logged, transmitted, or stored anywhere.

Additional features

The following features are enabled by default and can be individually toggled in Settings:

• AMP redirect: Redirects AMP pages to the original canonical URL. On Chrome, this happens at the network layer via the browser's built-in declarativeNetRequest engine, before the AMP page is loaded. On Firefox, it happens locally via the content script.
• Ping blocking: Removes <a ping> attributes from links so the browser does not send tracking beacons when you click.
• Link-share unwrapping: Detects link-share wrappers where the destination URL is embedded directly in the redirect URL's query string (Facebook's l.facebook.com/?u=, Instagram's l.instagram.com/?u=, Twitter's t.co in some templates) and navigates straight to the embedded destination. This is not an affiliate-attribution event. These wrappers are share-link tracking, not commission-bearing redirects. Affiliate-redirect networks (Awin, CJ, AliExpress Portals, etc.) are deliberately NOT unwrapped, see "Affiliate networks" below.
• Right-click "Copy clean link": Cleans URLs when you copy them via context menu. On browsers and platforms that support keyboard shortcuts, also available via Alt+Shift+C.

All of these operate entirely within your browser. No external requests are made.

URL cleaning (and the click, copy, page-load self-clean paths) runs as a local computation inside your browser. It does not round-trip through any extension service worker or external server. The cleaning logic ships in the extension package as a small bundled file (src/content/cleaner-bundle.js) generated from the ES module source under src/lib/ via tools/bundle-content.mjs; the bundle is committed to the repository so reviewers can verify it matches the unbundled source.

Affiliate tags

MUGA does not add any affiliate tag of its own. By default, it respects the original referral: if a creator you follow earned an affiliate tag on a link, MUGA leaves it in place, so they keep their credit.

If you enable "Remove all affiliate tags from other sources" in Settings, the third-party affiliate tags MUGA recognises are removed from the URL. This is an optional extra, off by default: MUGA never adds its own tag in their place. All of this happens locally, with no external request.

What MUGA never does

• Does not send your URLs, browsing history, or any personal data to any server. The one request MUGA makes on its own is a download of a public, signed rule list (see "Remote rule updates" below); it carries nothing about you and can be turned off in Settings.
• Does not collect your browsing history.
• Does not add any affiliate tag of its own.
• Does not silently replace other people's affiliate tags. The default is always "keep the original".
• Does not strip affiliate-redirect networks (Awin, CJ Affiliate, AliExpress Portals, Impact, Partnerize, Admitad, A8.net, Rakuten, TradeTracker) from URLs. Their redirect IS the attribution event and MUGA respects it, so MUGA does not break the creator's commission.
• Does not collect, store, or transmit any personally identifiable information.
• Does not use analytics, telemetry, or crash reporting services.

One carve-out, and it is yours to make. MUGA's "Report a problem with this URL" button opens a prefilled GitHub issue in your browser. By default it carries only the hostname of the page, never the full address. Next to it is an unticked box, "Include the full URL", with the note "I confirm it has no personal or sensitive data". If you tick it, the full page URL is written into the issue you are about to submit, so read it before you post. Nothing is sent anywhere until you submit that issue yourself, and MUGA has no server that receives it: the report goes to GitHub, under GitHub's own privacy terms. The gating is implemented in src/lib/broken-site-report.js.

Affiliate networks: redirect-tolerant

MUGA recognises both styles of affiliate attribution and respects both. Some programs (Amazon, eBay, Vercel, DigitalOcean, Lemon Squeezy, Apple Performance Partners, Bookshop.org, Steam Curator) carry the creator's referral as a query parameter or path segment on the merchant's own URL. Other programs (Awin, CJ Affiliate, AliExpress Portals, Impact, Partnerize, Admitad, A8.net, Rakuten, TradeTracker) carry it as a redirect through the network's own servers, where the network's 30x sets a first-party cookie on the merchant's domain at landing. MUGA does not pick winners by attribution model.

Practically: when MUGA sees an affiliate-redirect URL, the redirect passes through your browser unchanged. The network's servers see your click (that's the entire point, without it the creator's commission cannot be paid) and the merchant's first-party cookie gets populated normally. MUGA does not interpose, does not log the redirect anywhere outside your device, and does not rewrite the URL beyond removing well-known tracking parameters (utm_*, fbclid, gclid, and the rest) from the merchant's landing page once you arrive. The matrix that drives this is published in docs/affiliate-networks-matrix.md on each release.

Independently of any affiliate model, MUGA offers a "Follow shortener redirects" feature that resolves the 19 generic URL shorteners listed below so you can see where a short link actually leads before clicking. When enabled, the extension itself fetches the short link with credentials: "omit" (no cookies, no identifying headers) and lets the browser follow its redirect chain to the final address, the same requests your browser makes when you click the link. That means the shortener host and every hop it redirects through, including the destination, are contacted directly from your browser. MUGA reads only the final URL and discards the page body. No MUGA server is involved.

It is two independent switches, split by privacy cost. Resolving a short link when you open it is on by default, since you were navigating to that link anyway. Resolving one when you merely hover over it is off by default and opt-in, because it would tell a third party you never chose to visit that you looked at a link. The toggle is the gate: MUGA's manifest already carries broad host access on both browsers, so no separate permission prompt stands between the switch and the first resolution. You can turn either half off in Settings at any time.

The complete list of hosts MUGA can contact this way is: bit.ly, tinyurl.com, t.co, link.medium.com, lnkd.in, fb.me, ebay.to, is.gd, v.gd, cutt.ly, rebrand.ly, ow.ly, buff.ly, rb.gy, tiny.cc, dlvr.it, ift.tt, qr.ae, t.ly. Affiliate redirect networks are NEVER followed. See the Permissions section below.

Third-party affiliate programs

When you navigate to a store via a link that already carries a creator's affiliate tag, the store's own analytics may record the visit as originating from an affiliate link. This is standard affiliate behaviour and is governed by the store's own privacy policy, not MUGA's. MUGA does not add any affiliate tag of its own and is not a party to these programs.

Permissions

MUGA requests the following browser permissions:

• storage: to save your preferences, statistics, and session data locally.
• activeTab: to access the current tab's URL when you use the popup, keyboard shortcut, or context menu. Only activates on your explicit action.
• contextMenus: to add the "Copy clean link" and "Copy clean selection" right-click options.
• clipboardWrite: to copy clean URLs to your clipboard (fallback for pages where the Clipboard API is blocked).
• declarativeNetRequestWithHostAccess (Chrome) / declarativeNetRequest (Firefox): to strip tracking parameters from URLs before the page loads, using the browser's built-in rule engine.
• webRequest, webRequestBlocking (Firefox only): Firefox needs a blocking network listener to strip tracking parameters at the network layer before a request is sent, which is how MUGA does on Firefox what declarativeNetRequest does on Chrome. This runs locally in your browser and sends nothing anywhere. These permissions are not requested on Chrome.
• host_permissions: all_urls: required for content scripts to run on every page (URL cleaning, ping blocking, AMP redirect, link-share unwrapping) and for declarativeNetRequest redirect rules to apply on all sites.

Optional host permissions (declared so the list stays explicit; MUGA's broad host access already covers them, so the Settings switches, not these grants, decide whether a request happens):

• bit.ly/*, tinyurl.com/*, t.co/*, link.medium.com/*, lnkd.in/*, fb.me/*, ebay.to/*, is.gd/*, v.gd/*, cutt.ly/*, rebrand.ly/*, ow.ly/*, buff.ly/*, rb.gy/*, tiny.cc/*, dlvr.it/*, ift.tt/*, qr.ae/*, t.ly/*, "Follow shortener redirects". Declared as optional host permissions so the list stays explicit. MUGA's broad host access already covers them, so the Settings switches, not this grant, decide whether resolution happens. Resolving links you open is on by default; resolving links you only hover over is off by default. When a switch is on, the extension performs fetch(url, { redirect: "follow", credentials: "omit", cache: "no-store" }) on the short link, lets the browser follow the whole redirect chain (so every hop, including the destination, is contacted), reads the final address from the response URL and discards the body. No cookies are sent, no identifying headers are attached, and no MUGA server is contacted. Affiliate-redirect networks are NEVER followed.

Remote rule updates

This is the one thing MUGA fetches on its own, and it is on by default. You can turn it off in Settings at any time. At most once every 7 days, piggybacked on a natural service-worker wake event, MUGA makes a single HTTPS GET to rules.muga.app for an updated tracking-parameter list. The response is an Ed25519-signed payload verified against a public key shipped inside the extension; an unsigned, tampered, or older payload is rejected and your existing rules are kept.

The request is sent with credentials: "omit" and cache: "no-store": no cookies, no account, no identifiers, and nothing about you or your browsing goes with it. It is a plain download of a public file. Like any request to any website, it does reveal your IP address and the time of the request to whoever serves that file. MUGA neither logs nor stores this, but we would rather say it plainly than imply the request is invisible. The fetch will not happen until you have accepted the onboarding disclosure that describes it, and it never fires while remote rules are turned off.

What a website can tell about MUGA

MUGA cleans tracking parameters out of the URLs you visit, so it is worth being straight about what a site can still work out.

• On Chrome: MUGA's rule files are declared as web-accessible so its own content scripts can read them. They use a per-session dynamic address, so a page cannot simply guess a fixed URL and probe for it to detect that MUGA is installed.
• On Firefox: the extension platform there has no equivalent of that dynamic address, and a Firefox add-on carries a fixed identifier in any case. A determined site can therefore still detect MUGA on Firefox. We would rather say so than imply a protection that is not there.
• Why it matters: this is about how well MUGA can do its job, not about your data. Nothing about you is exposed either way. A site that knows MUGA is present could switch to a tracking method MUGA does not yet clean.
• Following a short link: when you turn on "Follow shortener redirects", MUGA follows the short link's redirect chain to its destination and checks that destination before using it. Because of a browser limitation, that check happens after the redirect chain has been followed rather than at each hop, so a short link pointing at a private or local network address would have been contacted before MUGA rejects it. MUGA never navigates you there, and nothing is sent to any MUGA server.

Open source

MUGA is licensed under the GNU General Public License v3 (GPL v3). The complete source code is public. If you want to verify that this privacy policy accurately describes the extension's behaviour, read the code. It's all there.

Contact

Questions or concerns: open an issue at github.com/yocreoquesi/muga/issues.