Sprint Mobile Broadband Injecting 3rd-party JavaScript

Problem

At In-Touch, we often have to use cell cards to get internet to our on-site events. When operating in the United States, we use Sprint Mobile Broadband. For years, it was a great service that had saved the company a lot of time, effort and money.


… until recently …


At a recent event, we started having some problems. We didn’t immediately connect it to Sprint, as the problem only arose when we took the apps offline (removed the cell cards from the units) and were relying on running from the appCache. The problem we started seeing was, when resetting a unit, the application would freeze in the browser with the status text message of Waiting on 1.2.3.4 ... Hmm, 1.2.3.4? That’s a very strange address. A quick grep of the source shows nobody managed to slip a typo in there, nothing at all references 1.2.3.4, so where’s that coming from?


Ok, view source …


1
2
3
<html>
<script src="http://1.2.3.4/bmi-int-js/bmi.js"></script>
...

Where did that come from? The very first line after <html>, that’s definitely not in the application source.

As it turns out, Sprint uses software called ByteMobile from Citrix, that tries to redirect all images and javascript through their proxies to resize / re-compress the images and strip whitespace from scripts in order to save on your (and obviously their) bandwidth.

Yes, that’s right – they strip whitespace from javascript files. Without forethought. A few weeks ago we had just fixed a “bug” where some regexs weren’t working because, for some reason, whitespace ended up missing from the pattern on the loaded devices. Instantly we realized these units had been loaded via Sprint cards.

So not only does their injection not work with the HTML5 appCache, causing offline apps to fail outright – but they just plainly inject bugs by indiscriminately stripping whitespace from source files.

Solution

So it turns out, through some Googling and testing, that ByteMobile actually respects the Cache-Control directive no-transform. So using the Apache Header module, we have added the following line to our application virtual host files:

1
Header merge Cache-Control "no-transform"

This merges no-transform into any existing Cache-Control header, allowing apps to still add their own Cache-Control directives but making sure no-transform is always there.

Note

After some more research, it turns out AT&T, Vodafone and Orange also use the same software – so take care if using their mobile broadband services, too!

Comments

Copyright ©2014 Patrick Leckey
Powered by Octopress