Take the send-message path first, because it is the only one of the three that has a permission check at all. A page calls `chrome.runtime.sendMessage` with an explicit extension ID and a payload, and a reply means the extension is there and answered [2]. The browser will only deliver that message if the extension's manifest lists the calling page's origin under `externally_connectable` [2]. So this probe reaches exactly the extensions whose authors opted in, and no others [4]. The opt-in usually exists for a defensible reason. The author of the post maintains an extension that accepts page messages so a customer's bug-report button can tell whether the extension is installed [7]. The defect is in the match list, not the feature: `"matches": ["<all_urls>"]` does not mean the author's own customers, it means every origin on the internet may open a channel and ping [3]. That is one line of manifest, which is roughly the amount of review it tends to get.
The asset probe needs no opt-in. Web-accessible extension files resolve at a URL built from the extension ID, such as `chrome-extension://<extension-id>/icon-128.png`, and a page can point an `Image` at it and read `onload` as installed, `onerror` as absent [5]. Nothing in that sequence involves the extension author's consent beyond having published a web-accessible file, which the author says almost all extensions do [5][8]. Three inputs make it work: the ID, which is public and stable and readable off the store listing [6]; the path, which is whatever the author published; and the load event, which belongs to the browser. Only one of those three is under the author's control [15]. You cannot unpublish your ID and you cannot ask the browser to stop firing `onerror`. You can decide which files are reachable.
That asymmetry is the part worth carrying into a design review. Declining to accept page messages does not make an extension quieter, because the asset probe covers almost every extension while the messaging probe covers only the subset that listed an origin [16].
The bait techniques trade precision for coverage. A div classed `ad-banner ad-slot sponsored`, pushed offscreen at ten pixels high, then checked for `offsetHeight === 0` or a computed `display: none`, tells the page that something on this machine hides ad-like elements [10]. A hidden password input, watched for injected DOM around it, tells the page a password manager is present [11]. Neither says which one, and the author's position is that the category is often the fact that mattered [12].
The load-bearing claim here is a durability claim, and it is single-sourced: the author states that the asset technique is old, was demonstrated at scale by security researchers years ago, and still works today [9]. Treat that as a report about the browsers and extensions the author tested, not about yours. For it to transfer to your users, all three inputs have to hold at once for the extensions you care about: the `chrome-extension` URL scheme resolving in their browser, the ID being derivable from a store listing, and at least one web-accessible file in the package [17]. Two of those you can check for your own extension in about a minute.
In my context I now read `externally_connectable` as a published API surface and the web-accessible resource list as an index someone else can enumerate. If an extension needs a presence check to support a bug-report flow, the origin list can be the specific hostnames that flow actually runs on rather than the wildcard [3]. The cost of that choice is real and small: someone has to remember to update the manifest when the support site moves domains.
