After upgrading to OS X 10.10.x, I noticed that pushing the volume buttons didn’t produce a noise like they had before. I liked having that feedback sound, as it gave me an idea of how loud my volume was.

After some research, here’s how to get the volume button noise back:

1. Open System Preferences.

2. Go to the Sound preference pane

3. Click on the Sound Effects tab.

4. Check the Play feedback when volume is changed checkbox.

To test, tap a volume button on your keyboard and you should once again get a feedback noise.

Two weeks ago, The Omni Group announced an app called OmniKeyMaster aimed at letting customers migrate from Mac App Store licenses to standalone ones that supported upgrade pricing:

OmniKeyMaster is a simple app that finds App Store copies of Omni apps installed on your Mac, then generates equivalent licenses from our store – for free. This gives Mac App Store customers access to discounted pricing when upgrading from the Standard edition to Professional, or when upgrading from one major version to the next. Another benefit: since they don’t have to wait in an approval queue, our direct releases sometimes get earlier access to new features and bug fixes. OmniKeyMaster lets App Store customers access those builds, as well.

Today, The Omni Group had to remove the app, presumably after pressure from Apple:

My apologies: I’m afraid we will not be able to offer upgrade pricing to our Mac App Store customers after all. So long as we continue to sell our apps through the Mac App Store, we are not allowed to distribute updates through other channels to apps which were purchased from the App Store.

This is strange, because a number of similar tools (made by other independent developers) already exist on the Internet and they have been letting customers generate standalone licenses for several months. Perhaps Apple just didn't like that a name such as The Omni Group had found a way to make the process so easy? Was The Omni Group's tool built in such a way that it broke some Apple rules? Did The Omni Group think OmniKeyMaster would be okay because other solutions existed? Is Apple going after similar solutions as well?

Stephen Hackett argues that The Omni Group should have foreseen this, but that the Mac App Store is, overall, good for most third-party developers:

While The Omni Group is probably big enough to walk away from the Mac App Store, a lot of developers are enjoying a level of success in the Store that they couldn’t enjoy without it. Apple shouldn’t use that to strong-arm developers from trying to workaround the system. That puts both Apple and third-party developers in a pretty crappy spot.

I see both points. The Mac App Store is good for some developers and end customers, but it could be improved in so many ways. Is it a surprise that, after an initial rush to sell apps on the Mac App Store, more and more developers of apps above the $2.99 threshold (read: not games and utilities) have gone back to selling both App Store and “regular” versions?

The Omni Group wanted to do the right thing and offer upgrade pricing for customers who bought an app on the App Store. Apple doesn't like the idea and leads by example with a new version of Logic Pro sold as a new app, without upgrade pricing. If my assumption is right and Apple is behind OmniKeyMaster's premature demise – how could they not be? – that's really sad.

Apple shouldn't put pressure on developers who tried the Mac App Store model and didn't like some parts of it. Instead of burying their head in the sand and pretending that developers who want upgrade pricing don't exist, they should work with those developers to resolve their issues. The App Store launched in January 2011 and these aren't new problems. If Apple doesn't really care about upgrade pricing, it seems curious – to me, utterly wrong – that they're going after a clever tool like OmniKeyMaster.

And if you think that it's in Apple's right to shut down OmniKeyMaster¹, then I guess it won't be a surprise if more developers will keep offering standalone versions of their apps in the future, possibly even eschewing the Mac App Store if necessary.

Most people don't have time to care about these issues, because they like the convenience of the Mac App Store. But I do, and therefore, whenever possible, I try to buy Mac apps from a developer's website. It's worth the extra effort.

Ron Amadeo

Android 4.3 was released to Nexus devices a little over a month ago, but, as is usual with Android updates, it's taking much longer to roll out the general public. Right now, a little over six percent of Android users have the latest version. And if you pay attention to the various Android forums out there, you may have noticed something: no one cares.

4.3's headline features are a new camera UI, restricted user profiles, and support for new versions of Bluetooth and OpenGL ES. Other than the camera, these are all extremely dull, low-level enhancements. It's not that Google is out of ideas, or the Android team is slowing down. Google has purposefully made every effort to make Android OS updates as boring as possible.

Why make boring updates? Because getting Samsung and the other OEMs to actually update their devices to the latest version of Android is extremely difficult. By the time the OEMs get the new version, port their skins over, ship a build to carriers, and the carriers finally push out the OTA update, many months pass. If the device isn't popular enough, this process doesn't happen at all. Updating a phone is a massive project involving several companies, none of which seem to be very committed to the process or in much of a hurry to get it done.

Since it's really hard to push out an Android update, Google's solution is to sidestep the process completely. The company stopped putting all the good stuff in Android updates. It's not that good stuff isn't coming out at all, the exciting features are just not being included as part of a big Android release.

This year's Google I/O was a show of force for this new delivery concept. No new Android version was at the show, yet Google announced Google Hangouts, Google Play Games, cloud saving of game and app data, a complete redesign of Google Play Music and Google Maps, a new version of the Google Maps API, and new location and activity recognition APIs. Post I/O, we've seen seemingly OS-level features added like the Android Device Manager, a remote wipe and device tracking system, without needing to touch the base OS.

It's such a simple idea: Android updates roll out too slowly, so start releasing all the cool stuff separately. The hard part is making it actually work. But the first reason this is now possible is a little app that has finally come of age: "Google Play Services."

Google Play Services can do whatever it wants.

Calling Play Services an "app" doesn't really tell the whole story. For starters, it has an insane amount of permissions. It's basically a system-level process, and if the above list isn't enough for whatever it needs to do next, it can actually give itself more permissions without the user's consent. Play Services constantly runs in the background of every Android phone, and nearly every Google app relies on it to function. It's updatable, but it doesn't update through the Play Store like every other app. It has its own silent, automatic update mechanism that the user has no control over. In fact, most of the time the user never even knows an update has happened. The reason for the complete and absolute power this app has is simple: Google Play Services is Google's new platform.

What happens when you try living without Google Play Services.

Andrew Cunningham looked at this shortly after Google I/O, but now things are truly crystallizing. Google's strategy is clear. Play Services has system-level powers, but it's updatable. It's part of the Google apps package, so it's not open source. OEMs are not allowed to modify it, making it completely under Google's control. Play Services basically acts as a shim between the normal apps and the installed Android OS. Right now Play Services handles the Google Maps API, Google Account syncing, remote wipe, push messages, the Play Games back end, and many other duties. If you ever question the power of Google Play Services, try disabling it. Nearly every Google App on your device will break.

Play Services supports over the entire Android install base.

The reason for all the permissions and sneaky updates is best illustrated in that chart above. While the latest version of Android is on six percent of devices, Play Services rolls out to everyone in a week or two and works all the way back to Android 2.2. That means any phone that is three years old or newer has the latest version of Google Play Services. According to Google's current Android statistics, that's 98.7 percent of active devices. So at Google I/O, when Google announced their slew of new APIs, nearly every Android device was immediately compatible in a week. Play Services is a direct line from Google to the core of your phone, and, really, no one outside of Google is quite sure of just how powerful it can get.

Google Play Services takes care of lower-level APIs and background services, and the other part of Google's fragmentation takedown plan involves the Play Store. Google has been on a multi-year mission to decouple just about every non-system app from the OS for easy updating on the Play Store. Take a quick look at Google's Play Store account and you'll see a huge list of apps, many of which ship by default in Android. Gmail, Maps, Search, Chrome, Calendar, the keyboard, YouTube, and even the Play Store itself are all separately updatable.

The above list is a good representation of the current update situation in Android. Nearly everything that can be moved out of the main OS has been. The only features left that would require an OS update are things like hardware support, Application Frameworks APIs, and Apps that require a certain level of security or access (like the lock screen, Phone, and Settings apps).

This is how you beat software fragmentation. When you can update just about anything without having to push out a new Android version, you have fewer and fewer reasons to bother calling up Samsung and begging them to work on a new update. When the new version of Android brings nothing other than low-level future-proofing, users stop caring about the update.

This gets even more interesting when you consider the implications for future versions of Android. What will the next version of Android have? Well, what is left for it to have? Android is now on more of a steady, continual improvement track than an all-at-once opening of the floodgates like we last saw with Android 4.1. It seems like Google has been slowly moving down this path for some time; the last three releases have all kept the name "Jelly Bean." Huge, monolithic Android OS updates are probably over—"extinct" may be a more appropriate term.

Not having to package everything into a major OS update means Google can get features out to more users much faster and more frequently than before. Android feature releases can now work just like Google's Web app updates: silent, continual improvement that happens in the background. Your device is constantly getting better without your having to do anything or wait for a third party, and developers can take advantage of new APIs without having to wait for the install base to catch up. This should all lead to a more unified, less fragmented, healthier Android ecosystem.

Read Comments

That the growth in iOS has been phenomenal hardly needs to be stated any more. To people like me, though, who have been Apple users since the Mac Classic, it's been an amazing ride.

In 2008, after the launch of the iPhone 3G, I wrote:

If you haven't got it already, it's time to move your head to this place: iPhone OS is Apple's mainstream platform for 2012 and beyond.

That's the world we now live in.

I am and have always been obsessed with software. While the media obsess over new hardware, I've always been far more interested in the capabilities of software. Better hardware - generally - just saves me time. A faster iPad will be great, but what shall we do with it?

What iOS Hath Wrought

Three times in my career, Apple has shipped software that conventional wisdom said basically couldn't be done. The first was the Carbon layer of Mac OS X: most of the Mac toolbox running on a preemptively multitasking, protected memory Unix kernel. The second was Rosetta: PowerPC apps running unmodified and, for the most part, perfectly well on Intel processors.

iOS was the third. Conventional wisdom said that you couldn't possibly get a desktop OS running on a phone. Conventional wisdom said that you couldn't get rid of a user-visible filesystem. Conventional wisdom said you couldn't require all software on the platform to come through a first-party app store.

Right now, just before WWDC 2013, I think it's important to take time to appreciate exactly what iOS has achieved.

iOS broke the tyranny of the hierarchical filesystem as a user interface. A concept so complex that possibly the majority of computer users never achieved any level of real competence in its use. A far larger proportion certainly never achieved any kind of mastery.

iOS turned the purchase and installation of third-party software from a great opportunity to destroy your computer into something that people do for fun. People of very low technical ability are now perfectly safely and competently administering their own computers. This is a revelation and, in my opinion, a big part of the IT backlash against iOS.

iOS solved the virus problem. The conventional wisdom of the PC years was that Windows got viruses because it was vastly more popular than the Mac. In the post-PC years, we have hundreds of millions of people using iOS and, so far as I know, zero viruses.

There are other achievements I could list, but the point is that iOS broke through a lot of conventional wisdom about how computers should appear and operate.

The State of the iOS Union

If I were running Apple, I would milk the Macintosh for all it's worth — and get busy on the next great thing. The PC wars are over. Done. Microsoft won a long time ago. - Steve Jobs, February 1996

So where are we today with iOS? We have a powerful mobile operating system with excellent APIs that enable a broad range of powerful applications to be developed. Despite that, Yet, some of the fundamental design choices in iOS are limiting the growth of the platform.

The chart that I use to explain the appropriate deployment of smartphones, iPads and desktop computers uses two axes: task duration and task complexity.

iOS does a wonderful job in the lower-left corner of the chart. Right now, though, I think iOS needs to attack the upper-right corner of this chart. There is an opportunity to completely eliminate the desktop computer for some and drastically reduce its importance for many more.

What does such an attack look like? Well, there are various sources of complexity in the use of a computer for a task and some of them still either overwhelm iOS or simply become too awkward to tolerate.

Let's look at some of them.

Moving Data and Documents Between Apps

One source of complexity is having to use multiple tools to achieve the result you want. On the desktop, the common transport for doing this is the filesystem: save a file from one app, open it in another. iOS needs to support the user in that task without breaking the filesystem abstraction that has been so valuable in making iOS approachable for less technical users.

The current mechanism of "Open In...", which allows an app to copy a file to another app, is enabling some decent workflows but has the drawback of littering each app's sandbox with a copy of the file. It's also difficult to move large files this way.

If I want to take a PDF stored in Evernote, edit it with PDF Expert and save a modified version back into the same Evernote note, I simply can't do it today. The fact that so many iOS apps have built in direct support for Dropbox is testament to how weak the Dropbox app itself is. This is no criticism of Dropbox; they're doing all they can, given the design of iOS sandboxing.

This also applies to chunks of data that are not files: URLs, strings, photos. A great recent example: I like to use Flipboard and Flipboard recently introduced a new feature where you can create "magazines" from web pages. I normally use Instapaper for caching stuff to read that passes by on Twitter, which I read with Tweetbot. Tweetbot supports a few read later services, including Instapaper, Pocket and Pinboard. It doesn't support Flipboard, and there's nothing I can do to make it support posting links to Flipboard apart from begging the Tweetbot developers to add it. The burden of inter-app integration should lie with the destination app, not the originating app.

If iOS had a generalised "send this piece of data to apps that claim to handle it" service - yes, like Android does - all the work to allow posting a link to Flipboard from Tweetbot would be in the hands of Flipboard and not Tweetbot. Similarly, the common workflow of saving an image to the Camera Roll and later extracting it in another app leaves behind data detritus that could be avoided if direct communication were easier.

Moving Data and Documents Between Devices

The TL;DR of this section is: iOS should support AirDrop, and it should be available as an "Open In..." target. Moving data between two iOS devices without using a Dropbox-like service, email or, worse, a Mac has always been annoying. Apps like iFiles leverage Open In... to work around the problem but, again, you end up with a copy of your data in iFiles' sandbox as well as the originating app.

There is another compelling argument for supporting WiFi Direct: Apple TV. The challenge of mass deployment of Apple TV on networks are well documented. What if a future Apple TV could receive AirPlay streams without the need to even be on the network? That would be a Very Big Deal.

Of course, this requires additional support in the WiFi chipsets built into iOS devices but there's no inherent reason it can't quickly become a standard capability.

Dealing with Big Personal Data

One of the bigger limitations of iOS has always been that, every so often, you'll try and do something that's "too big" for an iOS device to do. As the hardware itself becomes more powerful, these situations grow fewer but they still remain. In particular, they tend to persist in areas that involve handling a large chunk of data.

Examples include: trying to import a video from the Camera Roll into an app, opening a large Keynote file, applying a complex set of adjustments in iPhoto. Using Open In... can sometimes fall over if the file is large.

To some extent, these things are hardware-dependent. As CPU, memory and storage levels increase, these issues should diminish but there are clearly some aspects of these that are OS-dependent.

More Granular iCloud Restore

iCloud backup is really great. You set it and you forget it but, increasingly, I see a need for more granular access to the backup. Restoring your entire device just to get one missing file back is quite a drastic step, particularly when you have made other changes to data on the device since the file was lost.

Right now, iCloud backup is a brilliant disaster recovery mechanism. You lose or destroy your iOS device and you can be back up and running in a very short time. What it is not, currently, is a great user-error-recovery mechanism. If you screw up, you're staring a whole-device restore in the face.

Password Management

The current situation with internet passwords on iOS is, put simply, crazy-making. I use 1Password and, short of making it my main browser, it is maddening to have to keep switching between Safari and 1Password to get logged into a site.

The fact that I have a bookmarklet bookmarket on my Safari toolbar whose sole purpose is to open the current URL in 1Password tells its own story.

I don't know exactly what the solution to this is. Giving mobile Safari the ability to run extensions isn't quite enough unless those extensions can communicate with an app also installed on the system. Regardless, though, this is becoming highly frustrating. The entire mechanism of usernames and passwords is out of date. It'd be great if Apple could lead the way on building in platform level support for 2-factor authentication. I'm not enough of an expert on this to comment much further but this needs to get easier.

Typing Enhancements

The iOS keyboard is good, but it could be better. I haven't spent a lot of time with the alternative keyboards on other platforms but they are said to be ahead of iOS. I think more work could be done to make autocorrect more predictable.

My main complaint though is about the text selection interface. We now know from some experience with gestural interfaces that interactions requiring tap-and-hold just plain feel slow, whether they actually are or not. The iOS text selection gestures depend heavily on tap-and-hold to precisely place the insertion point loupe.

Wrist Protection APIs

I do not think that iOS needs to embed deep stylus support. Nonetheless, the are increasingly good digital ink apps for various applications: art, drawing, PDF annotation and so on.

Many of these apps have built their own wrist protection systems. Some are better than others and none of them behave exactly alike. In addition, none of them play particularly well with the iOS four-finger multitasking gestures.

Some system level mechanism for doing wrist protection alongside the multitasking gestures would go a long way to easing this problem.

Remove 50MB Limits on Cellular

Power users are often also highly mobile users. One of the main reasons I use a third-party app over the Apple Podcasts app is that, with Instacast, I can download a podcast of any size but Apple's app continues to enforce the 50MB download limit on cellular networks.

This limitation made sense in the early days of iOS, where everyone was on unlimited data connections. Today, most people are on metered connections. We pay for every byte, so we should be allowed to choose exactly how we spend those bytes.

Of course, a warning would still be useful. Some people are on metered contracts which, after a cap is reached, impose astronomical charges. Along with this change, I think a system-wide governor on mobile data usage would be useful. You can imagine, though, how Apple might be reluctant to build in such a feature and then undoubtedly face a rash of "Waah! Apple cost me thousands in data charges!" headlines every time someone doesn't understand how the feature works.

Choose Default Apps

The question of changing default apps has been a contentious one at times in the life of iOS. Until recently, I had not seen many examples of compelling replacements for Safari and Mail. Today, though, that's vastly different.

There are really good alternative browsers now, in the form of Chrome, Dolphin and others. The official Gmail app is lacking in some ways but its a perfectly good alternative for Gmail users. On the iPhone, I have been using Mailbox since the day I got to the head of the queue and would love to set it as my default mail app.

I don't think a generalised UI for changing every protocol handler in the system is necessary at this point. However taking two baby steps by allowing the user to choose their browser and mail client (and perhaps a third in choosing their maps app) would be a good start.

I would like to see some policy around preventing apps from setting themselves as default handlers. The user needs to remain in control of this.

Deeper Keyboard Support

I'm not a regular Bluetooth keyboard user but I do use one occasionally. The apparently increasing popularity of Bluetooth keyboard cases suggests that people do like to regularly use a keyboard with their iPad.

To better support this, I would like to see a few enhancements to the Bluetooth keyboard support in iOS. In particular, a method of keyboard-navigating the multitasking bar would be very welcome. I imagine this as a Command-Tab keystroke opening the bar and subsequent strokes highlighting successive apps which can be chosen by hitting return.

The Way Ahead

That's all I have for now. There are certainly more things that could be added. I have focused here specifically on the issues that are limiting deeper adoption and utilisation of the iOS platform for the 'power user'. There are certainly other concerns that a casual user or a beginner would have.

My broader point, though, is that iOS does NOT need a ground-up rethink, nor does it need to become more like our existing desktop OSes, in order to satisfy more of the needs of the power user. This conceptually small set of changes would go a long way to pushing iOS deeper into that high complexity/long duration section of my chart above.

The ghost of Steve Jobs will not be pleased to see this.

Zack Henkel

Robert Silvie returned to his parents' home for a Mardi Gras visit this year and immediately noticed something strange: common websites like those beloning to Apple, Walmart, Target, Bing, and eBay were displaying unusual ads. Silvie knew that Bing, for instance, didn't run commodity banner ads along the bottom of its pristine home page—and yet, there they were. Somewhere between Silvie's computer and the Bing servers, something was injecting ads into the data passing through the tubes. Were his parents suffering from some kind of ad-serving malware infection? And if so, what else might the malware be watching—or stealing?

Around the same time, computer science PhD student Zack Henkel also returned to his parents' home for a spring break visit. After several hours of traveling, Henkel settled in with his computer to look up the specs for a Mac mini before bedtime. And then he saw the ads. On his personal blog, Henkel described the moment:

But as Apple.com rendered in my browser, I realized I was in for a long night. What I saw was something that would make both designers and computer programmers wince with great displeasure. At the bottom of the carefully designed white and grey webpage, appeared a bright neon green banner advertisement proclaiming: “File For Free Online, H&R Block.” I quickly deduced that either Apple had entered in to the worst cross-promotional deal ever, or my computer was infected with some type of malware. Unfortunately, I would soon discover there was a third possibility, something much worse.

The ads unnerved both Silvie and Henkel, though neither set of parents had really noticed the issue. Silvie's parents "mostly use Facebook and their employers' e-mail," Silvie told me, and both those services use encrypted HTTPS connections—which are much harder to interfere with in transit. His parents probably saw no ads, therefore, and Silvie didn't bring it up because "I didn't want [them] to worry about it or ask me a lot of questions."

Henkel's parents had noticed the ads but assumed that companies like Apple and Walmart had put them there on purpose. "They were very surprised" to find out that the truth, Henkel told me.

Neither Silvie and Henkel were going to let a mystery like this go without solving it. Each embarked on a separate investigation and each came to the same conclusion: their parents' Internet provider was somehow involved in slapping ads onto webpages as they moved over the network.

How did that ad get there?

Zack Henkel

Paging Sherlock

Both homes subscribed to Internet access from CMA Communications, a rural cable TV, Internet, and phone provider serving southern states like Texas and Louisiana. (CMA is owned by ETAN Industries; according to Bloomberg Businessweek, ETAN does business as "Credit Protection Association, LP" and "provides collection services.") But it was possible that CMA wasn't involved with the ads; locally installed adware might have been responsible, or the two sets of parents might have had their routers infected by a rare breed of malware.

To rule out the various options, Henkel isolated each link in the chain between his devices and the remote Web servers he was contacting. After seeing the ads appear on multiple websites, Henkel switched to his Android-powered phone to see if some kind of malware was affecting his personal Mac; the ads also appeared on the phone. He accessed websites from a Surface tablet; the ads were there. "I am not great at statistics, but I was fairly certain the probability of identical malware on all of these devices was low," he wrote on his blog.

He turned off Wi-Fi on his phone in order to force its data connection to route through the separate cellular network; the ads went away. He turned Wi-Fi back on and the ads reappeared. Local malware wasn't causing them, and they didn't exist when accessed through a different network, so they certainly weren't meant to be on the sites at all. The ads appeared to be injected either by his parents' router or by their ISP.

"I pulled up the Web inspector in Chrome and examined the source of a page which had the ad," Henkel wrote. "Appended to the very end of the HTML file for the webpage was a single line which called to r66t.com for a JavaScript file."

That single line of code read <script type="text/javascript" src="http://nodes.r66t.com/node_api/eeb77492-852f-11e2-af82-12313d316a64/entry/main.js"></script> and appeared to be the source of the issue. And it turned out that the R66T code didn't just add banner ads to sites that had none; it even overwrote its own ads onto high profile sites like the Huffington Post, which had plenty of ads of their own.

To see if his parents' router had somehow been compromised, Henkel plugged in a spare router and ran his connection through it. Same result. He then ran a series of traceroutes to see every hop his packets took on the way to sites like Bing.com. He was able to compare the results to traceroutes he had run before, since "poor performance has been a recurring issue" with the connection, he said. He found an extra hop in the connections now, one that passed Web requests through a Squid proxy server run by a R66T, where they were apparently altered to include the extra ad code.

"Wow, this is really wrong and crazy," Henkel told me, since it suggested that companies felt free to operate as a "man in the middle," one free to inject code of their own choosing into webpage requests that were—so users believed—simply between themselves and the websites they were trying to reach.

Silvie had a similar reaction. He used the traffic inspection tool Fiddler to examine his packets and "saw that the ads were coming from r66t.com only when the website was not being served over [the encrypted] HTTPS," he told me. But who or what was R66T?

HuffPo with (more) ads

Note the "R66T advertisement" text.

Zack Henkel

4 more images in gallery

Get your kicks on R66T

R66T, pronounced "Root 66" and intended as a play on the famous American highway Route 66, describes itself as "one of the nation's leading publisher of targeted content, information and advertising to private Wi-Fi and High-Speed Internet Access (HSIA) networks, conducting tens of millions of individual user sessions—approaching one-billion user-minutes per month." The company says that it supports Wi-Fi networks at places like airports, hotels, coffee shops, and malls, often providing free access in exchange for showing "hyperlocal" advertisements.

One of their product pitches, for instance, describes a hotel Wi-Fi system that creates an "ever-present toolbar or frame around the page that can display relevant content and information" and can handle "insertion of property related ads and promotional messages, as well as blacklisting competitors' ads throughout the entire Web session." A further item says that property managers can "feel secure in knowing that your competitors are not able to poach your customers while they are at your property."

This sounded similar to, but importantly different from, what Silvie and Henkel were seeing. For one thing, both of their parents were paying for Internet access and had for some time. For another, the ads they were seeing actual sat right on top of actual content, not in a frame or toolbar.

In its privacy policy, R66T says that it partners with Internet providers and that end users should love the service it provides. "This greatly enhances each user's online activity by providing an enhanced Internet services experience with advertisement overlays," says the policy.

Silvie quickly blocked all access to R66T domains on his machine and the ads disappeared; Henkel did likewise, but his anger drove him further. He suspected that CMA had partnered with R66T in an attempt to make more money from each Internet connection, but he couldn't prove it.

Part of R66T's pitch to Internet providers.

Henkel called CMA tech support and talked to several people. "None of them really believed what I was saying," he told me. CMA's privacy policies do give the company broad latitude to collect information such as "Web sites you view," the time that you view them, and "other information about your 'electronic browsing.'" They do not appear to say anything explicit about altering Internet traffic in flight, however.

Henkel filed a complaint with the Federal Communications Commission (FCC). On March 19, he received a polite note back from the agency, telling him that the issue "does not come under the jurisdiction of the FCC" and that he might want to contact the Federal Trade Commission instead.

Frustrated, he took to his personal blog and then to reddit to generate interest in the story, but even on reddit he could only find three other people who had noticed the ad issue and had Internet access through CMA.

On CMA's "About us" page, the company helpfully provides an e-mail address for comments and says that each message "is routed directly to CMA’s Vice President for initial review. Yes, we do read every email received." I reached out to them for comment; they have not responded.

In response to some direct questions about whether R66T was working with CMA to inject ads over common websites, R66T boss Mick Hall replied by e-mail that he was currently in Mexico City, had a heavy meeting schedule, and had to deal with a "current poor Internet and telecommunications infrastructure" that made getting me more information impossible at the moment. However, he promised to speak more next week.

R66T's logo... with a pretty girl.

A question of trust

ISP-sanctioned ad injection directly into webpages—if that's what this is—has a long history, but it has been fairly rare to find it happening on pay connections in the US.

Back in 2008, computer scientists at the University of Washington built a "Web tripwire" that could detect in-flight changes to content served over HTTP, and they recruited 50,000 unique users to help them test it out. At the time, 1.3 percent of the connections altered webpages in some way, though most of these were caused by local software, such as popup blocking tools. Only 46 of the 50,000 IP addresses showed modifications that appeared to be "intentionally caused by their ISP." A mere 16 of these were actually performed by an "ad injector" like NebuAd somewhere in the network path. (Notably, systems like NebuAd proved so unpopular with both government and consumers that the company went out of business.)

The practice of code injection attained new public prominence in January 2011 when it it became apparent that the Tunisian government, facing a countrywide revolt, was injecting a bit of password-grabbing code onto Facebook's login page whenever it was requested by a user inside the country. Facebook eventually addressed the issue by making the site accessible over HTTPS—though, as the authors of the 2008 paper note, HTTPS can be a "rigid and costly" solution.

Early this year, one angry Comcast customer claimed that the giant Internet provider was injecting its own code into webpages—but only for the purpose of displaying a "courtesy notice" that a data usage threshold was near.

Are CMA and R66T reviving ad injection on pay connections to residential users? Only those two companies can explain exactly what the situation is, and neither has been over-anxious to respond immediately to questions.

Whatever is happening, the situation has caused a bit of concern for Henkel's parents. "They were surprised that this could even be done," he told me. "They don't know who's sending them what now."

Read Comments