Blocking a sales software popup impacting billing counter computer

8-minute read • homemadesoftware.net

Managing workstations for a retail shop requires clean, predictable startup routines. That broke down the moment our customer installed their mandatory sales software. Every laptop on every platform began forcing a browser popup survey open on every boot.

What made it worse: closing the popup without filling it out flagged the account as "Viewed" on the vendor's backend, which led to unwanted follow-up from their team. Deleting the startup trigger locally didn't help either. The software kept reinstalling it.

The problem in detail

• Forced on every boot: Windows, macOS, and Linux machines all launched a browser straight into the survey on login.
• Irrelevant questions: The form asked for data that had nothing to do with running a retail shop.
• The "Viewed" trap: Closing without submitting still registered as viewed and triggered follow-ups from the vendor.

How the software hooks into startup

• Windows: Task Scheduler entries and Run registry keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) told the browser to open the survey URL at login.
• macOS: A LaunchAgent plist in ~/Library/LaunchAgents/ launched Safari or Chrome with the form URL on session start.
• Linux: A .desktop file in ~/.config/autostart/ fired the browser when the desktop environment loaded.

Why removing it didn't work

Our customer had already tried deleting the startup entries. Every time, the software's background service detected the missing entry on reboot and silently put it back. IT support couldn't break the loop either.

The fix: block the domain at the network level

Instead of fighting the application, we went below it. The browser can't open the survey if the domain doesn't resolve. We added one line to the system hosts file on each machine:

This redirects the popup's domain to localhost. The browser connects, gets nothing back, and the window stays blank or closes immediately. The startup trigger still fires. We just don't care, because the destination is dead.

How to apply it on each OS

Why this works so well

• The self-healing loop doesn't matter anymore. Even if the startup trigger comes back, it opens a dead domain.
• Nothing else breaks. Only the specific survey domain is blocked, not the whole sales app.
• Takes under two minutes per machine, no admin escalation needed beyond editing the hosts file.

Since this hosts-file fix worked well. Then the customer asked for the same protection across every laptop, in every one of their stores. That's when a one-line hosts-file edit stopped being a solution and started being a chore and our solution mitm-dns solved this too!