Last week there was some discussion about in-flight internet and the alteration of content between the server and the end-user. As part of that there was a claim lobbied by one user that the Row44 provider was perhaps taking things a bit too far, including changing cache-timeouts and also injecting javascript code into pages as they were rendered. Not surprisingly this touched off a bit of concern in some circles. I had the opportunity to speak with Doug Walner, Row44’s Chief Commercial Officer about the issue and hear the company’s side of the story.
On the subject of cache-timeout alteration, the company maintains that they are absolutely not altering those settings for pages which are loaded through the service. Moreover, when there is content being loaded which they serve directly they are setting the cache option to a "no-cache; must-revalidate" setting which should force all modern browsers to pull a fresh copy of the data every time. Because the claims about the cache alteration came from a 3rd party which they haven’t been able to validate there isn’t a lot more to go on here as to what actually happened. We are left with something of a he said, she said sort of situation. Still, knowing that the service shouldn’t be altering the cache setting is somewhat reassuring.
Somewhat more disconcerting than the cache aging issue was that of actual page content alteration. There are many ways such alterations can manifest themselves, from image compression to HTML code changes to javascript injections in the pages. We spent a good amount of time talking about the different types of content alteration and how they affect the user experience and when they are or are not appropriate. Altering images with lossy compression, for example, is something that Row44 doesn’t do (competitor gogo does). This means you’ll see the original image that the content provider intended you to see. That’s generally a good thing, though it can mean more bandwidth consumed. And pages loaded via a secured protocol (HTTPS) won’t be altered at all between the server and the end-user.
But Row44 will alter other pages that users browse to. This alteration comes in the form of the "Flying Adapter" bar which appears at the top of every web page. This "Flying Adapter" is the result of the javascript injections referenced in the previous reports.
The Flying Adapter provides information about the flight, destination and other things that Row44 feels will be useful to passengers during the trip. The javascript injection happens on the network gateway on the plane and the original HTML is still all there; it is just augmented with the additional javascript which adds the bar on top. The bar can be disabled if the user chooses to. And, as noted above, secured pages aren’t modified to include the bar.
So there clearly was something amiss in the previous report versus what Row44 expects to happen. The caching is most notable, with the company saying they set everything to be not cached and the report suggesting the cache headers were actually extended. And the javascript injection definitely happens, though what it is actually doing doesn’t seem to be all that onerous, particularly in that it doesn’t affect SSL-encoded pages and it can be shut off if desired. I personally find those bars annoying as a general rule, but not so much that I’d bail on the product completely.
Related Posts:
Never miss another post: Sign up for email alerts and get only the content you want direct to your inbox.
I’d rephrase “And pages loaded via a secured protocol (HTTPS) won’t be altered at all between the server and the end-user” somewhat: even if they wanted to, they cannot look into and change the SSL traffic, so they cannot modify/”enhance” the pages.
It seems pretty clear where that “Flying Adapter” is likely going to be used for. Today they show you weather and flight info. Tomorrow… “useful” ads.
Saying they cannot do it is slightly disputable, Oliver. It depends on whether they wanted to play the man-in-the-middle attack game or not. I wouldn’t ever expect any legitimate company to do that but I figured it was worth noting that they aren’t.
As for the space becoming a platform for advertising, that wouldn’t surprise me. It also wouldn’t disappoint me if that meant the product was free. If I’m paying for it I’d be less welcoming of the ads.
A man-in-the-middle attack over HTTPS would be very difficult because they would not be able to provide a valid SSL certificate. Even if they were able to hijack the public key, un-encrypt, inject additional code, and re-encrypt, your web-browser would be throwing up major warnings over the lack of authentication from a certification authority.