A Tech-Law Measurement and Analysis of Event Listeners for Wiretapping
Posted4 months agoActive4 months ago
arxiv.orgTechstory
calmnegative
Debate
40/100
PrivacyWeb SecurityEvent Listeners
Key topics
Privacy
Web Security
Event Listeners
A research paper analyzes the prevalence of third-party event listeners on websites that intercept keystrokes, potentially constituting wiretapping, and the discussion revolves around the implications and potential mitigations of this issue.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
52m
Peak period
3
2-3h
Avg / period
1.3
Key moments
- 01Story posted
Sep 11, 2025 at 12:46 PM EDT
4 months ago
Step 01 - 02First comment
Sep 11, 2025 at 1:37 PM EDT
52m after posting
Step 02 - 03Peak activity
3 comments in 2-3h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 11, 2025 at 7:51 PM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45213612Type: storyLast synced: 11/20/2025, 4:35:27 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
They say they autopopulate fields based on field type, but address fields are common to have an autocomplete feature enabled. That would require transmitting data before submitting the form. I didn't see anything about rating probabilities of the transmitted data being benign and useful or nefarious and malicious.
The article does talk about one example which is not considered wiretapping: a Google search field with autocomplete that's intentionally embedded in the web page.
You're not supposed to and everyone is in a gentleman's agreement not to, but you could if you really wanted to.
For example, the following code:
console.log("Foo");
console.log("Bar");
console.log("Baz");
Prints out the following to the console:
> Foo
> Bar
> Baz
But if I was to run this code first:
const originalLog = console.log; let logCounter = 0; console.log = function log(str) { logCounter++; originalLog(`${logCounter}: ${str}`); }
Then the original code will now output:
> 1: Foo
> 2: Bar
> 3: Baz
So if you wanted to stop people messing with keystroke/input/change/etc events, you could:
1. make backup variables that reference the original addEventListener, onChange, onTouch, onInput, etc... functions
2. make up your own man-in-the-middle functions that inspect the events getting passed to them
3. if you want the event passed to your man-in-the-middle function to go through, just pass it to your backup variable that points to the original function
4. and if you don't want it to go through, then just don't call the original function.
------------------------------------------------
Or, you could just use an adblocker like uBlock Origin on Firefox, so the third party tracking script isn't loaded in the first place
IIRC, this is what caused those huge payouts on the biometrics from Facebook and Google who didn't pay proper attention to per-state laws.
I'm assuming they are only tracking obvious third-party data escapes here (e.g. page includes off-domain JavaScript) rather than the less-obvious route here where the first-party receives the data and then shuffles it off to an outside party on the back-end.