Here is a simple routine for spotting it when you shop online at Lidl or Carrefour, plus a free tool that does the boring part for you.

1. Compare the price per kg or litre, not the pack price

EU shops must show a unit price next to the selling price (Directive 98/6/EC). On Lidl it usually appears under the price as "1 kg = 7.12 €". On Carrefour France it sits near the price as "€/kg" or "€/L".

The unit price is the only fair way to compare a 450 g pack with a 500 g one. If it is missing, divide the price by the pack size yourself: €2.49 / 0.45 kg = €5.53 per kg.

2. Watch multipacks

"6 x 1 l" or "4 x 125 g" packs are where mistakes happen. Check that the unit price uses the total size (6 l, 500 g), not a single item.

3. Remember what the pack used to be

This is the hard part. Neither shop tells you that the same product was bigger last month. You either remember it or you keep notes.

4. Let your browser remember for you

ShrinkWatch EU is a free, open-source extension for Chrome, Edge and Firefox. On a product page it:

• shows the unit price in a small badge, worked out from the price and pack size,
• cross-checks the shop's own unit price and shows it when the two disagree,
• saves the pack size locally and warns you if the same product comes back smaller.

It was checked in a real desktop Chrome on Lidl in Germany, France, Spain, Italy, Poland and the Netherlands, and on Carrefour in France, Spain, Belgium and Poland. Lidl Germany works right after install; for the other sites you click "Enable on this shop" once in the popup. Some examples from those checks:

• lidl.fr, olive oil 1.5 l: €5.66 / l, matching the shop's own figure
• lidl.it, butter 125 g: €7.12 / kg
• carrefour.fr, 1 l of milk: €1.26 / l
• carrefour.pl, 1 l of milk: 4.49 zł / l

If a page prints the pack size only on the product photo, the badge shows the price and says the pack size is missing, so you know to check the label.

Privacy

No account, no analytics, no network requests. Prices and pack sizes stay in your browser.

Try it

• Firefox: https://addons.mozilla.org/en-US/firefox/addon/shrinkwatch-eu/
• Chrome and Edge install steps: https://emirmrkaljevic.github.io/shrinkwatch-eu/#install
• Lidl guide: https://emirmrkaljevic.github.io/shrinkwatch-eu/shops/lidl.html
• Carrefour guide: https://emirmrkaljevic.github.io/shrinkwatch-eu/shops/carrefour.html
• Source and issues: https://github.com/emirmrkaljevic/shrinkwatch-eu

Found a product with a wrong figure? Open an issue with the link and it will be fixed.

This post was written with AI assistance and checked by me against the extension running on the shops.

Why that fillet is different

A fillet between two flat walls is a piece of a cylinder, and mesh2cad has rebuilt those for a while. A fillet between a plane and a coaxial cylinder is not. Think of the round at the base of a boss, the softened rim of a hole, or the rounded floor of a blind hole. That surface is a quarter of a torus, tangent to both neighbours.

There are two cases:

• Boss base and hole rim use the inner equator of the torus: major radius = cylinder radius + fillet radius.
• Blind hole floor uses the outer equator: major radius = cylinder radius minus fillet radius.

In 0.18.0 mesh2cad fits that band, builds one torus face in the B-rep, sews it to the plane and the cylinder, and checks that the result is still one valid solid. The fidelity report now counts torus faces and lists each major and minor radius.

pip install -U mesh2cad
mesh2cad convert boss_plate.stl -o boss_plate.step

Numbers, including the bad ones

All of these are synthetic parts, 3 random seeds each, from python benchmarks/run.py in the repo.

• Plate with an Ø16 boss and a 2 mm base fillet: exact on 3 of 3 seeds at 0 and at 0.05 mm noise. With no noise the minor radius error is 0.008 mm (major 10.012 mm, Hausdorff 0.026 mm). At 0.05 mm the worst minor error is 0.279 mm, Hausdorff 0.150 mm.
• Ø12 hole with a 1.5 mm top round: exact with no noise (minor error 0.068 mm) and on 2 of 3 seeds at 0.05 mm. The third seed is a valid faceted solid.
• Both rims rounded at 1.2 mm: exact with no noise (two tori, minor error 0.061 mm).
• Ø10 blind hole with a 1.5 mm floor fillet: exact with no noise (minor 1.463 mm, major 3.529 mm, Hausdorff 0.021 mm).

Where it does not work:

• At 0.2 mm of noise the boss fillet and the hole rim are not recovered. You get the sharp cylinder and its planes, still one valid solid, but the Hausdorff is the size of the missing round (0.864 mm on the boss).
• At 0.05 mm the blind floor and the double-rounded hole fall back too.
• A fillet that runs into a spherical corner (every edge of a box rounded) is still not rebuilt.
• The CadQuery, OpenSCAD and FreeCAD script exports refuse a torus for now. The torus lives in the STEP only; fillet_r in the scripts is still just the four vertical corners of a rectangular base.

I would rather have the tool fall back to a valid solid and say so in the report than invent a fillet that is not there, so that rule stays.

Try it

• Repo and README limits: github.com/emirmrkaljevic/mesh2cad
• Release notes: v0.18.0
• PyPI: mesh2cad

If you have an STL of a simple mechanical part where the rounds come back wrong, open an issue with the file. Those are the cases I want to fix next.

1. The theme is in a JSON object

Every Shopify storefront prints a Shopify.theme object in an inline script. One request is enough:

import json, re, requests

html = requests.get("https://www.deathwishcoffee.com/",
                    headers={"User-Agent": "Mozilla/5.0"}, timeout=20).text
m = re.search(r"Shopify\.theme\s*=\s*(\{.*?\});", html)
theme = json.loads(m.group(1)) if m else None
print(theme)

When I ran this today I got:

deathwishcoffee.com: name "deathwish-shopify-20/production", schema_name "Dawn", schema_version "10.0.0", theme_store_id null
allbirds.com:        name "[DNAM Theme July 2026]", schema_name "allbirds-theme", schema_version "1.231.12", theme_store_id null

schema_name is the useful field: it tells you the base theme (Dawn here, even though the store renamed its copy). theme_store_id is set when the theme was installed from the Theme Store and is null for custom or heavily forked themes, so it is also a decent hint that the store has a developer or agency.

2. Apps leave fingerprints

Apps inject scripts, app-embed blocks under cdn.shopify.com/extensions/..., or their own CDN domains. A small signature list goes a long way:

SIGNATURES = {
    "Klaviyo": ["klaviyo"],
    "Attentive": ["attn.tv", "attentive"],
    "Gorgias": ["gorgias"],
    "Rebuy": ["rebuyengine", "rebuy"],
    "Smile.io": ["smile.io"],
    "Yotpo": ["yotpo"],
    "Recharge": ["rechargecdn", "recharge"],
    "Judge.me": ["judge.me"],
    "Okendo": ["okendo"],
}
low = html.lower()
apps = [name for name, keys in SIGNATURES.items() if any(k in low for k in keys)]
print(apps)

On the two stores above: Death Wish showed Klaviyo, Rebuy, Gorgias, Smile.io and Recharge; Allbirds showed Attentive and Yotpo. Plain substring matching is crude (a blog post that mentions "klaviyo" would match), so in practice count only matches inside <script src>, <link href> and inline script blocks, and keep the signatures specific (domains beat brand words).

3. Catalog numbers come from products.json

Most stores also expose /products.json?limit=250&page=N, which gives product count, price range, vendors and how many products are new. Combined with the theme and apps, that is a pretty complete lead row from two or three requests per store, with no login and no JavaScript rendering.

Limits

• Headless stores (Hydrogen or a custom frontend) don't print Shopify.theme, so treat "no theme object" as a headless signal, not an error.
• Some apps load only after consent or on product pages, so homepage detection undercounts.
• Be polite: one homepage request per store, a real User-Agent, and no hammering.

If you'd rather not maintain the signature list

I built a Shopify Products Scraper on Apify that does exactly this in its "stores" mode: one row per store with theme (name, base theme, version, Theme Store ID), a headless flag, detected apps from about 75 signatures, plus catalog stats from products.json. It is pay-per-result (about $0.0035 per store) and stores that fail or aren't Shopify are not charged. Disclosure: it's mine. The code above is enough if you only need a handful of stores.

"Rewrite it in Rust" is easy to say. The hard part is proving the rewrite does what the old tool did, including on input nobody thought about: an empty stdin, a file without a trailing newline, --output-delimiter -1, a directory where a file should be.

So I built behave, a small Go tool that treats a command-line program as a black box:

1. probe: read --help and the man page, find the flags, and generate cases: each flag alone, flag pairs, value edge cases (0, -1, abc, empty, missing), stdin samples (empty, unicode, CRLF, 5,000-character line, no trailing newline), the same samples as file arguments, unknown flags and missing files.
2. record: run each case three times in a fresh temp directory with a fixed environment. If the runs disagree, the case is marked flaky (hello sort --random-sort).
3. diff: replay every case against another binary and show what changed, per case and per flag.

behave probe sort                       # ~290 cases into ./behave-sort/
behave diff behave-sort --impl ~/uu/sort --skip-tag meta --ignore-stderr

What it found: GNU coreutils vs uutils 0.12.0

That's a strong result for uutils: four tools fully match on everything generated. The rest are small and some are likely deliberate, but you would want to know about them before swapping binaries in a script that checks $? -eq 2.

jq vs gojq

gojq is a well-known Go implementation of jq that documents its differences. behave finds them quickly: 331 of 596 cases match (ignoring error wording). The per-flag table shows the reasons: gojq drops --seq, --ascii-output, --sort-keys (it always sorts keys) and a few others, and formats huge numbers differently (1e1000 vs 1E+1000).

Making output comparable

Raw byte comparison doesn't work across implementations, so behave normalizes before comparing:

• the program name (jq: error vs gojq: error)
• temp directory paths, timestamps, ANSI colors, hex addresses
• your own regex rules in behave.yaml

Specs are plain YAML, one file per case, so you can commit them next to your port and review changes in PRs. behave run / behave diff exit non-zero on failures, so they work in CI.

For porting with a coding assistant

behave mcp exposes behave_exec, behave_probe, behave_add_case, behave_list_cases and behave_diff over MCP, so an assistant porting a tool can check its work after each change instead of guessing.

Limits

The flag parser is heuristic (tested so far on GNU coreutils and jq help output), interactive/TTY programs aren't supported yet, and tools that need a meaningful positional argument (a jq filter, a sed script) need a few samples via --arg.

It's MIT and a single binary for Linux and macOS: https://github.com/emirmrkaljevic/behave. If you're porting a CLI, I'd like to hear what it gets wrong.

More of my projects: github.com/emirmrkaljevic

The rule: Omnibus 30-day lowest price

Since 2022 the EU Omnibus Directive (Article 6a of the Price Indication Directive) says that when a shop announces a price reduction, the "before" price must be the lowest price it charged in the previous 30 days. Not the RRP, not a price from last spring. Many shops now print this "lowest price in the last 30 days" somewhere on the page, often in small grey text far from the big red percentage.

So the honest discount is: (30-day lowest price minus current price) divided by the 30-day lowest price. Sometimes that number is much smaller than the badge. Sometimes it is zero or negative.

What truediscount does

• Finds the current price, the advertised "was" price and the 30-day lowest price on a product page
• Recalculates the discount against the 30-day lowest price and shows it next to the shop's claim
• Keeps a small local price history so you can see a graph of prices you have already seen, plus a watchlist with price alerts
• Stores everything locally in the browser. No account, no server, no tracking

Three ways to install

Userscript (Greasy Fork). If you already use Tampermonkey, Violentmonkey or similar, this is the fastest option: https://greasyfork.org/en/scripts/602599-truediscount-is-this-discount-real

Firefox add-on. Version 0.13.0 is now live on addons.mozilla.org: https://addons.mozilla.org/en-US/firefox/addon/truediscount/ . The Firefox zip is also on the GitHub releases if you prefer a manual install.

Chrome-based browsers. Load the Chrome zip from the releases page as an unpacked extension.

A few things I learned

• Price parsing is the hard part. "1.299,00 €", "€1,299.00" and "1 299,00 zł" all need to end up as the same number. I normalise by locale and treat the last separator followed by exactly two digits as the decimal mark.
• Shops phrase the 30-day price differently in every language. "Niedrigster Preis der letzten 30 Tage", "prix le plus bas des 30 derniers jours", "najniższa cena z 30 dni" and so on. The extension keeps a list of phrases per language and searches near the price block.
• One codebase, several targets. The MV3 extension and the userscript share the detection code. A small build script produces the Firefox zip, the Chrome zip and the .user.js from the same source.
• Local-only is a feature. Not having a backend made the privacy policy short and the review process simple.

Try it, break it

The code is MIT licensed: https://github.com/emirmrkaljevic/truediscount

If you find a shop where detection fails, an issue with the product URL is the most helpful thing you can send. Happy (honest) Black Friday shopping.

This is the fifth post about usb-rea, an open-source tool I built that diffs USB captures per labelled click in a vendor app and writes a pyusb driver. The first one covered commands, the second one naming what the device reports back, the third one handshakes and session tokens, the fourth one video streams to case LCDs. This one is about what happened when the tool met hardware I don't own.

The capture

On liquidctl issue 936 the owner of an ASUS TUF Gaming LC III AIO (the one with an LCD on the pump) shared a USBPcap capture from Windows while changing the screen brightness in the vendor app. The full capture is big: about 76,000 packets, nearly all of them a 320x320 JPEG video the app streams to the screen at around 70 frames per second, plus four tiny brightness writes hidden in between.

That capture is what pushed me to add image stream detection in v0.7.4 (the fourth post). After that, the full capture gave the right answer: brightness is byte 4 of a 440-byte message on interrupt EP 0x01, the video goes to EP 0x03 with a 08 nn 00 80 header, and the device acks each frame with 08 81 on EP 0x84. That matched what the owner had worked out by hand.

Then I asked if I could keep a trimmed copy as a regression test. They said yes, and turning it into a test is where the two bugs showed up.

Making a fixture you can publish

A raw capture is not something to commit to a public repo. It has other devices on the same bus, and the video frames are literally whatever was on the screen. So the stored copy:

• keeps only this device's packets: the setup, the first 8 frames and two frames on each side of each brightness change (589 packets, 6.5 KB gzipped)
• zeroes the image data in every frame, keeping only the JPEG headers and the end marker, so nothing that was on the screen is in the file
• shifts the timestamps to a fixed date and replaces the IRP ids with counters

The test in tests/test_user_capture_lc3.py then checks the VID:PID, the brightness command and the stream end to end. The first run failed twice.

Bug 1: USBPcap puts the control reply in the "complete" record

usb-rea finds the vendor and product id from the GET_DESCRIPTOR reply at the start of a capture. On this file it said there wasn't one. Here is what v0.7.5 printed at the top of the report:

Device: `unknown (no GET_DESCRIPTOR in capture)`

But the reply is right there. This is the real output of usb-rea transfers on the fixture (first two lines):

     1 dev   2 ep 0x80 control   IN  8006000100001200 |
     2 dev   2 ep 0x80 control   IN  12 01 10 01 00 00 00 40 05 0b 7b 1c 51 00 01 02 03 01

USBPcap logs a control transfer in stages. Frame 1 is the setup stage (80 06 00 01 ..., GET_DESCRIPTOR for the device descriptor). The descriptor itself (12 01 ..., with 05 0b 7b 1c being 0B05:1C7B little-endian) arrives in a separate record for the "complete" stage, stage 3. My parser only took control IN data from the stage it expected, so on captures where the data comes in stage 3 the descriptor was simply dropped. My own synthetic USBPcap files never did that, which is exactly why the tests never caught it.

v0.7.6 reads control IN data from the complete record too. Same file, new report:

Device: `0b05:1c7b`

Bug 2: counting the ack over the whole capture

The second failure was quieter. v0.7.5 found the video stream and the brightness command, but no frame ack. Worse, the 08 81 acks didn't just disappear: they ended up in the report as a "reply to brightness", because a couple of them happened to arrive a few milliseconds after a brightness write.

The old rule was: a fixed device-to-host message is the ack if it shows up about once per frame over the whole capture (between 0.5x and 1.2x the number of frames). On the full capture that held. On the trimmed one it didn't: the fixture keeps the acks for frames I cut out, so it has 66 acks for 24 frames. That's an artefact of trimming, but the same thing happens on a real capture whenever the app keeps polling while it pauses the video, and a global ratio can't tell the difference.

v0.7.6 counts the ack per frame instead: a fixed device-to-host message between one frame's start and the next (and no more than 1 s after the frame's last packet). It's the ack when at least half of the frames have one and most of those have exactly one. The new frames_acked field says how many frames it was seen for. The report now has this line in the stream section (real output on the fixture):

- Ack: `08 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00` on EP 0x84, 66x (frames 30, 52, 94, 116, 138)

And because the acks are set aside with the stream, the bogus "Reply to brightness" section is gone. Summarised from the usb-rea infer JSON of both versions on the fixture, same labels:

0.7.5  vid/pid None None   ack None                     responses 1
0.7.6  vid/pid 2821 7291   ack EP 0x84, frames_acked 18 responses 0

(2821 and 7291 are 0x0B05 and 0x1C7B.)

What the trimmed copy can't tell you

Some numbers in the fixture report are about the trimming, not the device, and I'd rather say so:

• The frame rate shows as about 0.2 frames per second, because most frames were cut out. The full capture is around 70.
• The brightness command comes out at 60% confidence from two clean samples (brightness 0 and brightness 50); the third action is ignored because it sent a differently shaped transaction. On the full capture it's 100%.
• The image content is zeros, so the fixture can't test anything that depends on the pixels.

What it does test is everything the bugs were about: the device descriptor in a USBPcap complete record, the stream headers, the per-frame ack, and the brightness byte on its own endpoint.

Try it

pip install -U usb-rea          # 0.7.6
usb-rea demo --device lcd

To run it on the same fixture from a clone of the repo:

gunzip -c tests/data/asus-tuf-lc3-lcd.pcap.gz > lc3.pcap
usb-rea report lc3.pcap -l "brightness 0;brightness 50;brightness 100" -o lc3.md

The lesson for me: synthetic captures test the inference, real captures test the assumptions about how capture tools write files. If you have a USB device whose app only runs on Windows, one USBPcap capture while you change one setting is the most useful thing you can send. Device requests are open: https://github.com/emirmrkaljevic/usb-rea

Thanks to the owner of the LC III who shared the capture and agreed to the trimmed copy being kept as a test.

I built usb-rea with help from AI coding tools; the inference itself is deterministic and every claim in its reports points at captured frames.

How to try it

pipx install iotaudit
sudo iotaudit auto

iotaudit auto asks for consent, finds the devices on your own network, runs the safe checks, captures passively and writes a one-page HTML report with an A to F grade per device. You can also feed it a pcap from Wireshark, your router or PCAPdroid on Android.

What the feeder actually did

• Telnet (port 23) was open on the LAN, and the app has no setting to turn it off.
• It hardcodes public DNS, so it skips the router and any Pi-hole you run.
• It talks to US cloud servers over TLS and MQTT, plus a STUN/TURN handshake, which is the usual pattern for peer to peer video.
• No idle uploads. With the app closed it only sent a tiny heartbeat about once a minute.

The honest part: I couldn't capture the video

When I opened the live stream, almost no video showed up in my capture. Live video from these devices often goes straight from the camera to the phone over Wi-Fi, so it never passes through the laptop doing the capture, or it rides IPv6 link-local addresses that an IPv4 capture never sees.

So the tool now captures IPv6 and NDP too, and when a peer to peer session is set up but no stream is observed, the report says so in plain English instead of pretending:

Live video set up but not observed here: it most likely went straight to your phone over Wi-Fi. Not observed does not mean it did not happen.

I think that matters. A privacy tool that overclaims is worse than no tool.

What the report covers

• Who each device talks to: domains, IPs, countries and organisations
• Encryption: plaintext HTTP, old TLS, or custom high entropy protocols
• Open ports with short risk notes (telnet, RTSP, UPnP, ADB)
• UPnP port forwards your router opened, read only
• Idle upload check and a traffic timeline
• iotaudit diff to see what changed since the last audit
• HTML, PDF, CSV and a Home Assistant summary

Findings are indicators from observed traffic, not proof of anything about a vendor. Only audit networks and devices you own.

Code and a sample report: github.com/emirmrkaljevic/iotaudit. There is also a small library of device pages (what each type of device is expected to contact) at emirmrkaljevic.github.io/iotaudit. Feedback and new device profiles are very welcome.