So my ISP (Smartfren; Indonesia) has decided to start injecting all non-SSL pages with an iframing script that allows them to insert ads into pages. Here's what's happening:

1. My browser sends a request to the server. ISP intercepts it and instead returns a javascript that loads the requested page inside an iframe.

2. Aside being annoying in principle, this injection also breaks any number of standard page functionality; and presents possible security hazards.

What I've tried to do so far:

1. Using a GreaseMonkey script to nix away the injected code and redirect to the original URL. Result: Breaks some legitimate iframes. Also, the ISP's code gets executed, because GreaseMonkey only kicks in after the page is loaded.

2. Using Privoxy for a local proxy and setting up a filter to clean up the injection and replace it with a plain javascript redirect to the original URL. Result: Breaks some legitimate iframes. ISP's code never gets to the browser.

You can view the GreaseMonkey and Privoxy fixes I've been working on at the following paste: ... along with a sample of the ISP's injection.

Ideally I could configure Privoxy to immediately resend the request when the alteration is detected, instead of filtering out the injected JS and replacing it with a JS redirection to the original URL. (The ISP-injection gets switched off when the same request is resent without delay.) I'm yet to figure out how to acplish that. I believe it'd fix the iframe-breaking problem.

I know I could switch to a VPN or use the Tor browser. (Or change the ISP.) I'm hoping there's another way around. Any suggestions on how to eliminate this nuisance?

So my ISP (Smartfren; Indonesia) has decided to start injecting all non-SSL pages with an iframing script that allows them to insert ads into pages. Here's what's happening:

1. My browser sends a request to the server. ISP intercepts it and instead returns a javascript that loads the requested page inside an iframe.

2. Aside being annoying in principle, this injection also breaks any number of standard page functionality; and presents possible security hazards.

What I've tried to do so far:

1. Using a GreaseMonkey script to nix away the injected code and redirect to the original URL. Result: Breaks some legitimate iframes. Also, the ISP's code gets executed, because GreaseMonkey only kicks in after the page is loaded.

2. Using Privoxy for a local proxy and setting up a filter to clean up the injection and replace it with a plain javascript redirect to the original URL. Result: Breaks some legitimate iframes. ISP's code never gets to the browser.

You can view the GreaseMonkey and Privoxy fixes I've been working on at the following paste: http://pastebin./sKQTvgY2 ... along with a sample of the ISP's injection.

Ideally I could configure Privoxy to immediately resend the request when the alteration is detected, instead of filtering out the injected JS and replacing it with a JS redirection to the original URL. (The ISP-injection gets switched off when the same request is resent without delay.) I'm yet to figure out how to acplish that. I believe it'd fix the iframe-breaking problem.

I know I could switch to a VPN or use the Tor browser. (Or change the ISP.) I'm hoping there's another way around. Any suggestions on how to eliminate this nuisance?

• javascript
• iframe
• proxy
• code-injection
• network-security

• 1 What annoys me perhaps more than the rest of the page quirks is that their injection breaks StackOverflow functionality. While on a page-load SO gives me an alert and breaks out of their iframe... The ISP also injects e.g. into the AJAX content that's loaded when I click "view more ments"; resulting in just the ments loaded into a blank page. !! How bloody stupid can you get... If you inject, then at least do it damned clean and transparent. (The AJAX fail happens without any of these fixes applied.) – Markus AO Commented May 28, 2015 at 11:45
• Oh and only port :80 gets injected. Unencrypted HTTP connections to any other port are untouched. I notice they also block port 53 to disable third-party DNS, likely a part of their injection scheme... – Markus AO Commented May 28, 2015 at 12:07
• So I was wondering why Google Fonts were loading awkwardly. Then I browse to a Google Fonts URL such as; fonts.googleapis./css?family=Roboto+Slab:400; and lo, they also try to inject Google Fonts stylesheets into an iframe. They don't even check for the MIME type. (Google Fonts CSS headers have 'text/css' of course.) The only thing their injector checks, it seems, is the file extension of the requested URL! No verification of any context whatever. Then, AJAX calls and SocNet plugins linking to *.php files get caught into the same crazy mesh. Oi vey. SmartFren. Y U so brilliant. – Markus AO Commented May 28, 2015 at 16:37

2 Answers 2

Actually now I have a solution: The ISP proxy react on the Accept: header that the browser sends.

So this is the default for firefox:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

Now we are going to change this default:

And set it to: Accept: */*

Here is how to setup header hacker for google chrome

Set the title to anything you like:NO IFRAME

Append/replace select replace with

String */*

And Match string to .* and then click add.

In the permanent header switches Set domain to .* and select the rule you just created

PS: changing it in the firefox settings does not work 100% because some request like ajax seem to bypass it so a plugin is the only way as it literally intercepts every outgoing browser request

That's it no more iframes!!!

Hope this helps!

UPDATE: Use DNSCrypt is the best solution