ListeningKitREA and the Facebook web client
REA (rea-agents) is an open-source reverse-engineering tool that reads a program and returns evidence about what it does. This folder records how log decided to use it on Facebook's web client, the Marketplace create page that log's browser already loads, without letting REA touch a live account. The answer: save the page's scripts and a network recording (HAR) from a normal gated run, and let REA read those files offline. Read this if you want to know why log reads recordings with REA rather than attaching it to a browser.
This research was written on 2026-10-18 with rea-agents 6.7.0 installed globally. It changed no Marketplace code.
What REA is for here
REA isn't a search command for log, and it isn't pointed at log's own code. It's pointed at the Facebook web client: the Marketplace create page and the scripts and responses that page itself fetches.
The aim is to compare three things:
- how log and two earlier projects drive that page;
- the identity-leak study in
docs/identityLeaks/(what a page can observe about the machine, the proxy and the account); - what the client actually does, once REA can read a saved copy of it.
The way log posts doesn't change: a visible Camoufox window, the account's proxy, one device, the pinned locale, and log facebook publish. REA doesn't open Facebook and doesn't replace that path.
The pages
| Page | What it decides |
|---|---|
| The spec | The question: REA on log's Playwright Camoufox session, humanize, and the 22 identity-leak surfaces |
| The Facebook client | The three drivers, and the only way REA can see the client |
| Comparison | What's already built, what REA adds, and what it must not do |
| Public examples | Public REA investigations since 14 April 2026 |
| Research reports | The three research reports, stored as returned |
| The ranking | SubQ's ranking of the options. Winner: a HAR plus the scripts, read by REA offline |
| Roadmap | The order of work, and what's blocked |
| Sources | The GitHub, local, research and SubQ evidence |
Related studies stay where they are:
- How a listing is posted: How a Marketplace listing gets posted
- What can leak the machine or link accounts:
docs/identityLeaks/ - Proxy, device and hours: proxies, accounts and listings
- Where to host later:
docs/deviceIsolation/,docs/scaleArchitecture/
The decision
Research found no verified public REA investigation of a Meta product. SubQ, given those reports, ranked eight ways to connect REA to this session. The winner is a HAR plus the page's scripts, read offline by the standard REA CLI. Forking REA, exposing the Chrome DevTools Protocol (CDP) from Camoufox, and switching the Facebook window to Chrome all lost. The numbers are in the ranking.
What to do
- Don't attach REA to the live Camoufox window.
- Keep
humanizeat1.5inpython/browser/visibleBrowser.py. Upstream also allowsTrue, but a comment in this build says a boolean hangsmouse.move. The ranking didn't justify a change. - Prove a HAR works before using a real account. Check one fixture HAR with
rea inspect-web-network-capturefirst; that compatibility claim was the weakest one (p 0.62). This study planned to strip cookies before writing a HAR. log later chose to keep HARs raw for analysis, only in the local run folder, and never commit them. - Diff saved scripts against the create form. Change a selector only when the saved client shows the current one is wrong.
Setup notes
rea-agents6.7.0 is installed globally (rea --versionprints6.7.0). It isn't a dependency of log, andrea setupwasn't run.- npm skipped
frida's install script (allow-scripts). That only blocks native instrumentation; HAR and static JavaScript inspection don't need Frida.