WipeTokWipeTok research · Study 01
What 13 controlled extension checks show
We ran WipeTok's actual extension code against synthetic data to examine scanning, removal controls, and exported results. Here is what happened, including the limits we observed.
Reviewed
The result, with its scope
13 checks passed · 0 failedAll 13 checks behaved as recorded below. Two of those checks deliberately reproduce limitations: an unreadable button state can be reported as removed, and an item already in progress can finish after Stop is pressed. A passing check means the observation matched the expectation; it does not mean every removal was successful.
This is a controlled source study. It uses synthetic page elements and messages, with no live TikTok account or real repost removal. It does not measure cleanup speed, prove current Chrome compatibility, or guarantee how TikTok treats automated activity.
Two behaviors to understand
Reported removal is not always an independently confirmed result
When a repost button has a readable on/off state, the code checks for a change. If the state is unreadable, the inspected version can still report a removal after clicking, even if no change can be observed. A count or exported row is therefore a record of the extension's report, not proof of TikTok's final state.
Stop can finish the current item
The removal loop checks Pause and Stop between items. Our fixture reproduced a Stop command arriving while an item was opening; that item still completed before the loop stopped. Do not treat the button as an instant cancellation of an action already underway.
All 13 observations
| Check | Observed behavior | Outcome |
|---|---|---|
| 1. Missing Reposts tab | A missing Reposts tab reports zero found; no removal button is clicked. | As expected |
| 2. Counting without removal | Three synthetic tiles with two unique video IDs produce a count of two. Scanning does not invoke removal. | As expected |
| 3. Scan before cleanup | A remove message before a nonempty scan does not start cleanup. | As expected |
| 4. Readable state changes | An active repost button that visibly flips off is counted once, with one click. | As expected |
| 5. Readable state unchanged | An active button that stays on is skipped, with no second toggle attempt. | As expected |
| 6. Already removed | A readable already-off button is not clicked. | As expected |
| 7. Unreadable state | An unreadable button state can still be reported removed without a visible state flip. This documents a limitation, not verified removal. | Limitation reproduced |
| 8. Stop before the next item | Stop after the first item prevents clicking the next item. | As expected |
| 9. Stop during the current item | Stop during the current item's open/wait stage may still allow that item's removal before the loop stops. | Limitation reproduced |
| 10. Pause, then stop | Pause waits at the next item boundary. Stop exits that wait without removing the next item. | As expected |
| 11. Missing repost buttons | Three consecutive missing repost buttons end the removal loop. | As expected |
| 12. Pacing and other waits | The first successful synthetic item schedules separate opening, verification, closing, and pacing waits. A 2800ms pacing constant is not a measured per-item duration. | As expected |
| 13. CSV export | The actual panel code exports reported removed-event captions and URLs and escapes caption quotes. The fixture captures the Blob without writing a download. | As expected |
How the checks were run
The harness loads the full, unmodified content.js and sidepanel.js from the product source. It runs them in Node's VM with synthetic DOM elements and Chrome message interfaces. The checks invoke the scripts through their existing message and button interfaces, rather than copying their removal logic into a second implementation.
Fixtures control visible button states, duplicate video IDs, missing selectors, and when Pause or Stop arrives. CSV output is captured as an in-memory Blob; no file download or real-account operation occurs.
Timers advance asynchronously without waiting the requested real duration. They let us inspect control order. They cannot establish elapsed removal times: the extension's separate opening, verification, closing, and pacing waits must not be presented as a measured “seconds per repost” figure.
These are checks of the inspected source revision. A store release, another revision, or TikTok's live page can behave differently.
Source and reproducibility record
- Executed: .
- Runtime: Node
v24.14.1. - Extension source version:
1.0.2. - Product commit:
f208dbdc2a410dd87c060ad018b985ab9eb9d6c7; clean working tree at the time of the run.
Source file SHA-256 fingerprints:
- extension/content.js
55ebe44304376836ef1c2952c755b31a10a398eac4b2c7ac0a3b3b13d68d6d65 - extension/sidepanel.js
48edc9aaeeba3c92b582e956728882e699a8cf0fa9b025fee3e5eee6f1741e12 - extension/manifest.json
588cefd3fd47e82da33cc710f54e658721c8c2640fcf3990797d8a5aee86f3cf
The harness is maintained with the website source. For maintainers with the matching product checkout alongside it, the reproduction command is:
node scripts/check-product-evidence.mjs ../wipetokThe download publishes the observations, conditions, and source fingerprints. It is not a copy of the product source or an independently commissioned audit.
Who performed this study?
WipeTok's publisher performed these checks on its own product. We publish the scope and limitations so you can judge the evidence without treating it as an independent endorsement.