The new preview version of AOL Instant Messenger raised privacy concerns for us when it was first introduced, first because it started storing more logs of communications and second, because it apparently scanned all private IMs for URLs and pre-fetched any URLs found in them. We met with AOL to discuss how these features work and why the company should take greater care with your data, and we’re happy to say that AOL is promising to make some important changes as a result, especially in response to our second concern.
However, we still recommend that AIM users do not switch to the new version, as it introduces important privacy-unfriendly features. Unfortunately, AOL's moves are in keeping with a general trend toward more pervasive cloud-based services in which your personal chat data is centrally stored in plain text and an easy target for law enforcement and criminals. This shift toward central logging is troubling in many situations, including in chat.
Chat Logging and the One-Way Toggle: More Change Needed
When you first sign into the new AIM, a flag is permanently set on your account to begin storing all of your conversations on AOL’s servers for up to two months, and perhaps indefinitely. AOL's intent is to make it easy to see the same messaging history even if you sign in from a different device, but the danger is that your private conversations are now available to, for instance, law enforcement agents with a warrant or a national security letter, or to criminals in the event of a data breach. In the case of government access AOL might not even be required (or allowed) to inform you that your private communications are no longer private. Because this concern will arise whenever your data is stored with cloud services or other kinds of third-party servers, EFF has long argued that whenever possible, no logs are good logs.
One important and good step AOL took was the inclusion of an "off the record" mode which disables logging of conversations on a per-contact basis. (Note: this mode should not be confused with Off The Record Messaging, or OTR, discussed below). However, we think they should go further. You cannot go "off the record" if you are using an alternative client like iChat or Pidgin, or if you switch back to an earlier version of AIM. And if the other participant in the chat is not using the new AIM, that person cannot toggle the conversation off the record, such that it is not stored by AOL. Finally, there is no off the record mode for the new group chat feature at all. All group chats on AIM will be logged.
All of these should change. AOL should not set logging as the default and it should not be permanent. Instead, logging should be opt-in and "off-the-record" mode should be robust and prominent in the user interface. Until AOL has either made this change or, better yet, worked to encrypt all of your logged conversations in such a way that only you can read them—a much harder solution, we admit, but doable—current AIM users who are worried about other parties accessing their data should think twice about upgrading.
AOL Downloading Private Message URLs: Improvement
Another new feature of the new AIM is the ability to embed an image or a video in a conversation simply by pasting a link. While this is a reasonable goal, AOL first implemented it in a massively overbroad manner: AOL has been scanning the text of all your messages for links and then having their servers follow that link to see if it refers to displayable media1. The goal is to have the central server render the image or video for you, with a possible speed gain, but this approach meant that all of your chats were scanned and links followed and fetched to AOL's servers in Virginia.
While we were pleased to hear that AOL was not planning to log, cache or store any of the data pulled down by this scanning and fetching, the approach was still tremendously overbroad. It was also likely to cause privacy and security issues for AOL's users. It meant scraping all the links out of private chats, even when no one in the chat is using the new AIM and even when the links did not go to embedded photos or video (which is of course likely to be only a small number of links shared). We pointed out that this implementation would reach private server links, links that might contain authentication data in the URL, or even one-time use pages like unsubscribe links, all of which were problematic.
But good news: after meeting with us, AOL agreed to limit the types of sites and URLs crawled by this technology, and to provide better notices to its users about how the links it sends will be used. The company also agreed to disable this "scan and pre-fetch" functionality for conversations that have been marked "off the record." We appreciate AOL’s willingness to discuss this with us and their openness to changing course in response to our concerns and will continue to watch to see how they implement what they've promised.
And bad news: unfortunately, it does not look like there will be a way to permanently opt out of the link downloading behavior. Since conversations can only be marked "off the record" from inside the new AIM, users of older versions or alternate clients will always be prone to having some of the links they send scraped, even though they won’t see them rendered. AOL’s planned changes limit the scope of the privacy concerns around this a great deal, but the only way to prevent it completely is to use end-to-end message encryption like OTR Messaging—a good idea in any case if you don't want your IM provider to record your conversations.
Notice and Opt-In
As Facebook recently learned, failing to be up-front with your users about what you’re doing with their private data can create big problems. Happily, AOL now says that it will give clear notice to its users2. We look forward to that, and will be watching to see that users are clearly told that AOL will be parsing their private communications over AIM, following certain types of links transmitted in those private communications (with a clear statement of which kinds of links or to which websites), and downloading the content on those links to AOL servers in the United States, something that may matter to AOL's international customers who did not intend for any part of their communications to be subject to U.S. law and legal processes.
But notice isn't enough. AOL should also give users who upgrade initial notice with an opt-in check box, as well as an explanation in the terms of service that is clear and specific.
AOL and OTR Messaging Plugin: Cause for Concern
Many alternate clients such as Pidgin and Adium include the OTR messaging plugin, keeping anyone but your intended recipient from reading your IMs. Because we think the ability to have a secret conversation is vital to human rights activists, whistleblowers, businesses in "stealth mode" and many others, we gave a Pioneer Award to Ian Goldberg, one of OTR’s creators in 2011. Sadly, AOL has indicated to us that these clients may not always be able to operate with AIM, which is unfortunate since we viewed that option as one of AIM’s key features and we urge the company to reconsider. Luckily, OTR works with a number of other messaging protocols.
We appreciate AOL's willingness to discuss these changes with us and we're extremely pleased to see AOL taking some steps to safeguard their users' privacy and give better notice, which only becomes more important as the company moves toward providing more cloud-based services. Nevertheless, we think there’s more AOL should do to respect its customers' privacy and to fully inform them about, and get opt-in agreement to, these significant changes.
Bottom line: Because signing onto the new version of AIM permanently changes your account settings to log all conversations to AOL’s servers by default, we recommend that existing AIM users do not upgrade. As always, we recommend users stay safer online by using chat clients that are compatible with OTR.
- 1. If you’re a sysadmin or a webmaster, you might already have seen this behavior in your site logs:
220.127.116.11 - - [15/Dec/2011:11:08:20 -0800] "GET /example.png HTTP/1.1" 200 200 "-" "Java/1.6.0_22"
18.104.22.168 - - [15/Dec/2011:11:08:21 -0800] "GET /example.png HTTP/1.1" 200 200 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20101203 Firefox/3.6.13"
126.96.36.199 - - [15/Dec/2011:11:16:40 -0800] "GET /example.php HTTP/1.1" 200 200 "-" "Java/1.6.0_22"
188.8.131.52 - - [15/Dec/2011:11:16:40 -0800] "GET /example.php HTTP/1.1" 200 200 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:184.108.40.206) Gecko/20101203 Firefox/3.6.13"
220.127.116.11 - - [15/Dec/2011:11:17:03 -0800] "GET /example.avi HTTP/1.1" 200 200 "-" "Java/1.6.0_22"
18.104.22.168 - - [15/Dec/2011:11:17:04 -0800] "GET /example.avi HTTP/1.1" 200 200 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:22.214.171.124) Gecko/20101203 Firefox/3.6.13"
126.96.36.199 - - [15/Dec/2011:11:21:45 -0800] "GET /example.jpg HTTP/1.1" 200 200 "-" "Java/1.6.0_22"
188.8.131.52 - - [15/Dec/2011:11:21:45 -0800] "GET /example.jpg HTTP/1.1" 200 200 "-" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:184.108.40.206) Gecko/20101203 Firefox/3.6.13"
These are just a few of the possible requester IP addresses, but the pattern of two sequential requests by first a Java and then a Mozilla user agent is consistent. The IP addresses map to hostnames like the following:
220.127.116.11.in-addr.arpa name = picnicapi-d02.blue.aol.com.
18.104.22.168.in-addr.arpa name = picnicapi-d03.blue.aol.com.
22.214.171.124.in-addr.arpa name = picnicapi-d02.blue.aol.com.
126.96.36.199.in-addr.arpa name = picnicapi-d01.blue.aol.com.
188.8.131.52.in-addr.arpa name = picnicapi-m02.blue.aol.com.
- 2. AOL maintains that it always gave sufficiently robust notice. We respectfully disagree.