Going back to extensions: a look at Piwaa

Hey everyone!

I've been alternating between different types of tools here, and while there are still extensions worth looking at, I'm going back to one today. Piwaa was a LinkedIn messaging inbox and CRM extension, and its final shipped build had some interesting code around LinkedIn's own reporting.

Its store copy said, "Piwaa behaves exactly like the standard LinkedIn messaging, the difference is in the interface and additional functionality that does not generate suspicious behavior with LinkedIn." The build I reviewed contained code that cancelled LinkedIn Content Security Policy violation reports.

This is a post mortem. chrome-stats logs the extension as gone from the Chrome Web Store on 2026-08-31, while Extpose puts the delisting four days earlier, on 2026-08-27, with a stated status of "Minor Policy Violation." Mirrors still carry the old listing.

The LinkedIn session handling was clean. In background.js:51967-51980, Piwaa reacted when the LinkedIn li_at cookie appeared or disappeared but never read its value. background.js:52134-52144 reduced the cookie lookup to a boolean, so the token never left the browser. I found no path in the build that could send it elsewhere.

The more unusual part was a function literally named initProtection. It registered a blocking listener with webRequestBlocking (background.js:82205-82227) and cancelled several reporting requests. That included Sales Navigator CSP reports when the body contained an sn field (background.js:82206-82213), plus four endpoint patterns handled by unconditional cancellation branches (background.js:82214-82226). The four patterns had not been touched since 2021.

I also found a remote command bridge, but not a cookie bridge. The background page defined eight fixed actions (background.js:51560-51603) and accepted external messages (background.js:51606-51607), while a socket channel could deliver an action (background.js:12543-12570). That could allow server-dispatched profile or conversation actions through the user's account, but the build had no pacing controls beyond one settings entry. I can see which commands the extension accepted, not which ones the server actually pushed, and none of the eight exposed li_at or another cookie.

My scope matters here. I statically audited v1.0.30, Manifest V2, during May to June 2026. It was last updated on 2021-09-03 and no later build exists, so there is no newer release to compare against. I ran public DNS and HTTP probes on 2026-09-07, but did not observe runtime behavior or collect account restriction data myself.

The listing had 4.35 out of 5 across 26 votes. Nobody in that set described being detected, restricted, or banned. The complaints were about the extension breaking.

chrome-stats counted 1,000 installs as of 2026-08-31. Delisting did not remove those copies, so browsers that still have Piwaa retain the reporting listener and command channel, even though the vendor's infrastructure stopped resolving after the hosting disappeared. The extension has not been maintained since 2021, which makes that remaining local code and its old infrastructure connection worth noting.

There is nothing to clean up on the LinkedIn account side because the session was never exposed in the build I reviewed. Removing the extension under chrome://extensions is the practical fix. I would not sideload it from a mirror.

The part I found most interesting was how quickly old defensive code can become stale. Four reporting patterns were frozen in 2021 while the platform continued changing its reporting surface. I can tell you what the code cancelled, but I cannot tell you how much of that traffic was still being sent by 2026, and neither could the extension.

The full line-by-line write-up is here if anyone wants to check the references: safe-outreach[.]com/is-piwaa-safe

Have you ever looked at an old extension after its service disappeared? I’d be interested to hear what you found still running locally.