Microsoft Reward V2

Microsoft Rewards gives points for Bing searches, quizzes and daily activities, which you then exchange for gift cards. Doing those chores every day is repetitive, exactly the kind of task you want to automate. This project is my exploration of that idea, across three successive versions.

The framing, first

I'd rather say it up front: I don't recommend using this tool. Automating Microsoft Rewards goes against Microsoft's terms of service, and I built it to learn, not to farm points. I don't use it myself. The code stays public for anyone interested, but the project is fairly abandoned now and may already have stopped working, since Bing's interface changes without warning.

That said, it's one of the projects I'm proudest of, for the problems it forced me to solve.

Three versions, one lesson that keeps coming back

The first, a background bot. A Puppeteer script that launched a headless Edge instance and ran the searches on its own. It worked, but poorly: a lot of setup before you could even start, cases it didn't handle, and in the end I barely used it. An invisible bot you don't watch, running against an interface that moves, breaks in silence.

The second, a script driving the real browser. Instead of a ghost Edge in the background, this one drove the normal, visible browser, the one you already use. The real progress was elsewhere: rather than waiting with fixed delays ("wait 3 seconds, click"), the script waited for concrete signals from the page, an element appearing, a navigation finishing, a loading indicator disappearing. A fixed delay is a bet on network speed, and that bet eventually loses. Waiting on a signal means slowing down when the network slows down instead of breaking.

The third, a browser extension. This is the finished version. I rewrote everything as an Edge extension (Manifest V3): no more external script to run from the command line, everything is driven from a small popup in the browser toolbar. You tick the tasks you want, click Start, follow the progress and the live activity log, and stop whenever you like. The split a modern extension imposes, between the background service, the popup UI and the code acting inside the tab, was new ground for me.

The lesson that returns with every version: in browser automation, writing what you want to do is simple, knowing when to do it is the whole problem. The program interacts with a system I don't control, and it has to be written assuming anything can vanish or move.

Not looking like a robot

This is the most interesting difficulty in the project. Sites can spot automation, and on two fronts.

First the gestures themselves: the events produced by ordinary JavaScript carry a mark that sets them apart from a real click or a real keystroke. So the extension goes through the browser's debugging protocol to produce events indistinguishable from a human's. On top of that, it mimics a real presence: typing happens character by character with variable delays, the mouse moves in small jumps, the page scrolls with reading-like pauses, and clicking a result isn't instant.

Then the browser itself: as soon as you attach it to a debugging tool, it announces the fact by setting a flag any page can read. That property had to be redefined, before every page even loads, so it no longer gives anything away. It's a one-line detail, and without it none of the rest matters.

I'm keeping to the principle here, because the point of this text is to describe the difficulty, not to be a how-to.

Queries that hold up

An automation that types the same search a hundred times gets spotted immediately. So it needed real topics, varied and current. The extension pulls them from Google's trending feeds for several countries, queried in parallel, topped up by search autocomplete and by a built-in fallback list when those sources don't answer. Aggregating several origins rather than relying on one makes the tool less fragile, and the queries more believable.

What I ended up removing

The early versions also chased the points for mobile searches, by passing the desktop browser off as a phone: altered browser identity, emulated screen size, simulated touch events. It worked, but it was stacking pretences for a few extra points, and just as much fragile code that could break without warning.

I eventually deleted all of it and focused the tool on regular searches. The code came out noticeably shorter and easier to maintain. Removing a feature that works is rarely satisfying in the moment, but it's often the right call.

Installable without a build step

An extension you have to compile yourself before trying it will never be installed by many people. So I set up continuous integration that, on every change, rebuilds the extension, packages it and automatically updates a downloadable release on GitHub. All that's left is to grab the archive and load it into the browser.

What the project taught me, and its audience

Technically, it's the project that taught me robustness best: coping with an interface that changes without warning, defeating detection, aggregating fallible sources, and building a browser extension end to end, publishing included.

It's also one of the few projects where I saw it met a real need: I got user feedback and a few GitHub stars. People were genuinely looking for this, which is gratifying on something that started as plain curiosity.

I didn't get there by accident: my first browser extension was a small Cookie Clicker tool, written much earlier, that clicked the game's golden cookies on its own. That's where I picked up the reflexes I reused here, at a different scale.

The final rewrite, the one that turned the script into an extension, was done with Claude Code. Microsoft Reward itself stops at a tool I no longer maintain, but it was an excellent learning ground.