SoylentNews is people
SoylentNews
from the only-show-me-what-I-wanna-see dept.
[Ed Note: This reads a little like a Soylvertisement, but the concept that the blog is talking about regarding using WebSocket to send the advertising (and the tool he uses to see the traffic) is interesting. The "How It Works" section of the blog article (not posted here) is worth a read.]
Pornhub Bypasses Ad Blockers With WebSockets
TLDR: Watch the BugReplay Recording of Pornhub dodging AdBlock
(NSFW level: medium)
We tried to find the most PG page on MindGeek's network to use as an example- it wasn't easy.
When I was building the prototype for BugReplay, I was evaluating different methods of capturing and analyzing network traffic from Chrome. One of the first things I saw that looked promising was the chrome.webRequest API.
From the docs: "Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight."
That seemed to be exactly what I needed.
After experimenting with the Chrome webRequest API, I quickly realized there was a big problem. It didn't allow me to analyze any WebSocket traffic, something I really wanted to support.
As I was searching the web trying to see if I was misreading the documentation or was looking in the wrong spot, I found a relevant bug report from 2012: "chrome.webRequest.onBeforeRequest doesn't intercept WebSocket requests." In the bug report, users were complaining that without the ability to block WebSockets, websites could get around ad blockers fairly easily. If WebSocket data was not visible to Chrome extensions via the webRequest API, they could not be blocked without some heavy duty hacks.
Initially, the risks to ad blockers seemed theoretical; the examples of sites that were employing this technique were very obscure. Then in August 2016, an employee of the company that owns Pornhub.com (MindGeek) started arguing against adding the WebSocket blocking capabilities to the Chrome API. Pornhub is the 63rd most visited site on the Internet according to Alexa. I checked out a few of MindGeek's sites and sure enough, I could see ads coming through even though I had Adblock Plus on. The ads on Pornhub are marked 'By Traffic Junky,' which is an ad network owned by MindGeek.
In the screenshot below, you can see a banner at the top of the page announcing that the site is aware that the user is using an Ad Blocker, with an invitation to subscribe to a premium ads free version of the site. On the right side of the page you can see an advertisement.
http://blog.bugreplay.com/post/152579164219/pornhubdodgesadblockersusingwebsockets
-- submitted from IRC
(Score: 3, Interesting) by edIII on Sunday November 06 2016, @06:07PM
It occurred to me that websockets is an actual transmission protocol, and not some framework like javascript and AJAX.
As it requires an upgrade, and the entire connection is considered switched to websockets...... all browsers should be forced to instantly swap out the http/https in the url with websockets://site.name as good policy.
Everybody can see right away that the connection switched, and we should be able to be notified with the ability to block it, accept it, or whitelist it.
Filtering it comes after all of that.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 3, Interesting) by jdavidb on Sunday November 06 2016, @08:32PM
ⓋⒶ☮✝🕊 Secession is the right of all sentient beings
(Score: 2) by darkfeline on Sunday November 06 2016, @08:33PM
Wait, I thought WebSocket upgrade only happens when initiated from JS. Why the hell would a browser allow upgrading the initial HTTP/S request to WebSocket? That doesn't even make sense; why/how do you request an HTML file via a full-duplex pipe? I mean, I guess you could use only one direction of the pipe and just unload the HTML file data, but...
From TFA, it sounds like they're doing it the sensible way, opening a WebSocket via JS if ad-blocking is detected to load the ads dynamically. In which case, the solution is quite obvious; block the offending JS.
Join the SDF Public Access UNIX System today!
(Score: 2) by tibman on Monday November 07 2016, @04:12PM
Yes, it's a transmission protocol but it is used like ajax. JavaScript on the page you are currently on initiates a websocket connection. If you leave that page the socket is destroyed because the socket is attached to a javascript object on that page.
I have some good experience with it. Wrote a custom websocket server in php from the RFC. Web socket upgrade from http is there in the protocol but mostly worthless. It's just a nice way to do a hand off that is really unneeded. My server for example just eats the upgrade request and starts the websocket connection because it isn't even capable of serving http.
SN won't survive on lurkers alone. Write comments.