AOL vs. Open Source AIM Clones

Cassivs writes: "The GAIM developers have posted an excellent document on the recent battles with AOL. It seems that upon receiving an OSCAR connection, the server requests an md5sum of some section of the aim.exe file. And recently, AOL has begun changing the section whose md5sum they request. This was always supported in the official clients, but never actually used until now, so they don't break the official clients. Quite a clever solution. Embedding aim.exe into the libfaim source has potential legal problems. Is this the end of the open-source AIM clones being able to use OSCAR?"

Another thought about MD5 checksums

This could also be used to prevent users from hacking the binary to make it not display advertising banners! The hacked binary wouldn't return the proper checksum, and you'd get kicked offline with a message saying you're using an unsupported client.

--

...or Jabber

People might instead rally around an open messenging service like those offered by Yahoo!.

Or like Jabber [jabber.org], where no single company controls all the servers.

Note that Jabber is decentralized like SMTP is decentralized, not like Gnutella is decentralized.

Also note that a lot of Jabber clients support encryption/digital signatures now too.

Re:Sega vs Accolade (1992)

In Sega v. Accolade, 977 F.2d 1510 (9th Cir. 1992), Sega did not allege that use of the initialization code was a copyright infringement. They only said that Accolade could not use it because it triggered the "SEGA" display on boot-up (an alleged trademark infringement).

But, I don't see why a whole copy of aim.exe could not be included for the sole purpose of acheiving interoperability under Sega and the more recent Sony v. Connectix, 203 F.3d 596 (9th Cir. 2000), cert. denied. To be sure, these cases do not directly say that you can copy a whole program for this purpose, but the reasoning is exactly the same!

Re:OSCAR protocol work arounds.

According to the document, ANY section of aim.exe, of ANY length can be checksummed on demand. Now, I don't know how long aim.exe is, but let's assume that it's at least 1 megabyte. Therefore, the checksum request can be for an offset of between 1 and a megabyte, and a length of between 1 and a megabyte. Each combination will resolve to a different checksum.

Therefore, it would be necessary to keep track of 1,000,000,000,000 different md5 checksums (well, technically it's a little bit less than that, but you get the idea). I'm not sure that there are hard drives big enough to store all that data.

How to work around this? Well, here's one possibility. Put up a server in Timbuktu, or some other place that can tell a US-based corporation to go and fuck itself. Install three items of interest on that web server:

1. A complete copy of aim.exe

2. A small CGI that calculates the checksum, appropriately.

2. A small patch for the aim transports that add the support for this packet, which would go out and run that CGI.

Now, there are some logistical problems that need to be solved (mainly, the expected load on the server, that something like this can certainly end up generating). But these are solvable issues, if it ever comes to this.

... Scrap that idea. Here's a better one. Instead of a web server, use DNS, which will solve the load problem due to natural load balancing in DNS. Say that AOL wants a checksum for starting byte 5000, 100 bytes length? Fine, issue a DNS request for 5000.100.fuckaol.int. Read the result in the response to your DNS lookup. Can be easily implemented pretty much on any OS/platform that already knows how to talk DNS.

Beautiful, isn't it? Just jury-rig a custom DNS server that is set as authoritative for the fuckaol.int zone, operated from a geographical location that doesn't care much for AOL's landsharks, and which calculates a checksum on the fly. The natural implementation of DNS will cache the checksum automatically, placing very little load on the server.

---

Re:So you need a download.

This is a legal problem, not a technical problem, you dumb cockbiter.

No, this is a technical problem. If you want to access AIM legally, you can do so easily. Unfortunantly, there is a rather large set of support files you need that are a bit less than stable; they are called MS Windows.

The technical problem that is being addressed is how to bypass the need for THOSE support files.

Everytime I watch a DVD on my computer, it's "illegal". At this point, I'm starting to get used to the concept that I will pay just as much money as the person down the street (yes, I buy boxed distros to support the company, and I pay the same amount for DVDs), and do the exact same tasks, and because I have not been "blessed" by the Pope of Redmond, I am a heretic and will rot in jail.

Bullshit. If I had a good, working AIM client that grabbed ads (why isn't there a clone (that I'm aware of) that had the option of downloading and viewing ads?), I would use it. I have no problem with that. I *do* have a problem with crappy, sixth tier support. If they won't do it for us, then we will make it work. (Apply those "us" and "we"s to whatever group you want).

--
Evan

Well....

What's the deal? AOL owns the servers; AOL is allowed to say who can connect.

And be glad they are fighting this technically, not legally. I'm sure we'd all MUCH rather see a company simply spend effort doing somethign technical than going around suing everyone.

what about mac clients?

what does the macintosh client return when it receives this set of bytes? Obviously it doesn't have the windows aim.exe. Perhaps there is a set of possible return values that is valid that the server will accept? They would have to make this system work with every single existing aim client that supports oscar, right? so does this help libfaim?

Re:i thought this was a free service?

Actually, linux is a supported platform. You can get it from http://www.aol.com/aim/linux.html [aol.com]. It doesn't have all the features of the windows client, but it works.

YMMV though: rumor is that it was broken by the recent changes.

OSCAR protocol work arounds.

I've been compiling the latest AIM transports for Jabber lately and have been running into the same problems listed above. Could anyone comment on the potential workaround I've thought of here?

While we can't include the aim.exe with clients for legal reasons, I would doubt that the actual MD5 sums taken from that exe are protected under any copywright. Therefore, could we not have a server process as part of every jabber server that includes a request mechanism for getting the md5 sum for whatever version of aim.exe is current? Then, the server operator on his or her own downloads the aim.exe in question and stores it with their server. The server process can provide any needed MD5 sum to any of it's clients by directly examining this file.

Make sense?

Jabber AIM Transport and the FCC

Two points. First, the AIM Transport for Jabber will possibly have code put in so that the aim.exe can sit beside it and then have complete functionality again. I'm still debating the possible legal problems of that with some people, but I feel fairly sure that if the user downloads the aim.exe themselves, then it should be ok. Next, AOL has every right to protect their network, I even applaud them for doing it, and doing it in such an interesting way, but thinking the merger rulings will help is wrong. Go read the FCC document [fcc.gov] yourself, pay close attention to pages 4 and 5. Until the conditions are met, more power to them, but I will continue to help in decoding more of the protocol.

--temas
Jabber Developer

Re:Their right. Their servers. Their protocol.

Actually, you're dead wrong.

AOL has been ordered to open the protocol and their servers to either "server-to-server interoperability" or direct retrieval of information by competing clients. I wouldn't say their actions fall within "their rights," then, would you?

This is a part of their merger with Time Warner, and as a matter of fact, AOL has to file a report every 180 days "describing in technical depth, the actions it has taken to achieve interoperability of its IM offerings and others' IM offerings."

Even more interesting, section 129 of the FCC's order [fcc.gov] allows for complaints to be filed for non-compliance. These actions are clearly non-compliant, therefore, it would make sense for an interested party to file such a complaint...

---sig---

Workaraound exists

It would be possible, theoretically, to embed aim.exe inside of libfaim (encoded as a byte array or something similar)

seems like a pretty good workaround to me until AOL gets slapped on the wrists by the FCC.

Re:why embed?

You've probably hit the only really viable solution. An md5sum server (or several) could be set up so that you wouldn't even have to download the .exe unless you want to skip the sum request.

I can't see how you could precalculate the sums unless there are only a limited number of possible requests, and other approaches like including a derivative transform of the original (say reversing every byte in the original file) wouldn't really make it any more legal IIRC.

Re:OSCAR protocol work arounds.

Yes, that's an excellent idea. libfaim could include an md5 sum from every possible segment of the aim executable that the server could request a sum of. Now, aim.exe is 24576 bytes in size (pretty small, but it uses lots of dll's). Given that the segment has to end at some point after it starts, the total number of possible segments is 24576 * 24575 / 2, or 301,077,600 possibilities. If each checksum is 32 bits (I don't know how big MD5's are, so correct me if I'm wrong), then the total size of the database will be 1,207,910,400 bytes, or about 1.12GB. I'm sure any AIM user would be willing to download that in order to allow their favorite open source AIM client to check people's away messages.

------

Why should AOL make their service open?

Probably a bit offtopic, but I do wish to ask.... for what reason, should AOL make any part of their AIM service, which they are the sole proprietors of, open to anyone else? As it is their IP, dont they have the right to guard it, change it as they see fit? Okay, it's not exactly helping competition and open statndards, but if AOL dont want that, it's their software to do it with. I guess us as the great unwashed can go ahead and find something open and better to use.

The Monthy Pyhton version:

RMS: There it is! The AOL Server of Death!
OSCAR: Oh, great.
AIM CLIENT: Look!
RMS: There's the server from 64.12.149.13!
ESR: What is he doing here?
RMS: He is the AOL Server of Death. He asks each client five questions -
AIM CLIENT: Three questions.
RMS: Three questions. He who answers the five questions -
AIM CLIENT: Three questions.
RMS: Three questions may chat in safety.
OSCAR: What if you get a question wrong?
RMS: Then you are cast into void.
OSCAR: Oh, I won't go.
???: Who's going to answer the questions?
RMS: Sir OSCAR!
OSCAR: Yes?
RMS: Brave Sir OSCAR, you go.
OSCAR: Hey! I've got a great idea. Why doesn't AIM CLIENT go?
AIM CLIENT: Yes, let me go, my liege. I will take him single-handed. I shall make a feint to the north-east -
RMS: No, no, hang on hang on hang on! Just answer the five questions -
AIM CLIENT: Three questions.
RMS: Three questions as best you can. And we shall watch... and pray.
AIM CLIENT: I understand, my liege.
RMS: Good luck, brave AIM CLIENT. God be with you.
AOL: Stop! Who would chat with the Server of Death must answer me these
questions three, 'ere the other side he see.
AIM CLIENT: Ask me the questions, bridge-AOL. I'm not afraid.
AOL: What is your name?
AIM CLIENT: My name is Sir AIM CLIENT of America Online.
AOL: What is your quest?
AIM CLIENT: To chat with Clueless People.
AOL: What is your favorite color?
AIM CLIENT: 42.
AOL: Right. Off you go.
AIM CLIENT: Oh, thank you. Thank you very much.
OSCAR: Oh that's easy!
AOL: Stop! Who approaches the Bridge of Death must answer me these questions three, 'ere the other side he see.
OSCAR: Ask me the questions, bridge-AOL. I'm not afraid.
AOL: What is your name?
OSCAR: Sir OSCAR of Open Source.
AOL: What is your quest?
OSCAR: To chat with Clueless People.
AOL: What is the MD5 of AIM.EXE ?
OSCAR: I don't know that! Auuuuuuuugh! (OSCAR get disconnected)

Re:Why dont they....

...intercept the checksum request and return the expected value that would correspond with the appropriate version?

I imagine because it asks for the response on different portions of aim.exe each time.

I don't think it's illegal to do checksums on a file, so why not just require the actual aim.exe to sit in the same directory as the clone, and just refer to it to get the checksum? Then you can still have your AIM without the sucky parts.

Bully for AOL

Open-source client users: "Oh no, we can't steal processor time and bandwidth from AOL's privately owned servers while bypassing the ads that fund the service anymore! It's so unfair!"

AOL is right on this one. Sorry.

Re:Why should AOL make their service open?

While I should reitterate that I think that our ultimate goal should be to compete with the AIM market, creating a truly open framwork for competitors (like Earthlink, etc.) to use to promote their access. We should be enticing independent ISPs to play the "take a byte out of AOL." Such a strategy would undoubtedly succeed, I think, in the long run.

However, the FCC has expressed some serious concerns regarding the impact of monopolizing this growing technology (see their press releases concerning the merger with Time/Warner). AIM should NOT be allowed to become the next MS Windows in their view, and I do think that they are right.

You are right, AOL does have a right to do whatever they are legally allowed to do re: IP and competition. Especially in terms of their servers, I think that they do have some right to control. However, they do not have the right to damage the economic system of this country (per Sherman and Clayton acts, as well as the concerns of the FTC and FCC).

I think, however, as open source, we can outcompete it and ensure that the FCC never has a reason to be woried about it....

why embed?

I am sure that people who use gaim could easily get a copy of aim.exe legally. If libfaim could figure out the right section of the bin to reply with than they could easily have an option to reply properly to AOL request. aim.exe wouldn't even have to be distributed with it, we could just go get it if we want to use OSCAR..

Re:OSCAR protocol work arounds.

I like the idea of 'serving' the MD5 checksum via DNS by calculating it on the fly. Something like

start.offset.version.neutral-domain-name.org

will work beautifully. (fuckaol.int won't as it can be reclaimed by AOL using a domain dispute policy, just as in the Guinness case [slashdot.org]).

I have a fully-operational DNS server written in Perl that can be configured to do exactly this, calculating the required checksum from images of the aim.exe binaries stored there. I don't think that storing all the possible MD5 hashes for the different versions can do the trick, as it will increase the ammount of "horsepower" we would need.

If someone volunteers the server + bandwidth (and someone gives me a hand with any required IM protocol details), I'll set this up.

I'm outside the US, so I couldn't care less about the copyright/trademarks/whatever there might be around the AOL-IM protocols/applications.

Regards.

-lem

It doesn't take a genius but...

Your not the first developers to face this dilemna

Wireless News Factor [wirelessnewsfactor.com]
C|NET [cnet.com]

And the list goes on and on. One of the measures you guys should try to take, is follow on AOL's steps to make money on their client and offer some sort of revenue generating scheme for AOL in an effort to have them allow you to use their services (bandwidth ,connection to their servers, etc.), maybe your team should code an exact replica and allow AOL to pay you for the revisional code to allow *nix based clients to use the IM, this way AOL could continue to spam people with their messages, (banner revenue generation bs), and since its open sourced the typical geek would know how to chop this up.

This way AOL is happy they continue to gain revenue by selling ad space via GAIM, FAIM, etc., while you guys continue to provide your products, and make some side money off of it. Don't expect however AOL to just sit by pay for your programs bandwidth, then lose money while they own the servers your clients to connect to. Its not feasbile in a business sense and downright stupid.

I'm a libfaim developer and...

(my qualifications: Hi, my name is Josh Myer. I have been working with Adam (mid) on libfaim for a couple of years now. Adam's the big guy for it, but i'm one of the people that knows the library best)

first and foremost, eric did a great job of describing the problem on the page referenced. we're being blocked by aol because we don't have the official aim client to checksum.

personally, i think this is a great move by aol, but it is a pain in our butt as developers. we cannot ship aim.exe legally, but adam already added a function to do the requisite checksums based on a copy of aim.exe that you specify. adding support to gaim for this, if not already done, will probably be done in the next couple of days).

note that when you log in to oscar, you send a bunch of gory detail about your client (major, minor, and build number). the checksum you send in your 0001/00020 reply has to be correct for the string you passed, we assume. fortunately, they haven't actually hit unique checksums yet (they're still at the beginning of WinMain() ).

we have talked about several options:

1.) ship with aim.exe the file
2.) ship with aim.exe the very-large-array
3.) add support for aim.exe-sniffing.
4.) add support for a server that you request bytes of aim.exe from.

here's our findings on all of the above:
1.) not legal, not to mention annoying for us

2.) also not legal, and even more annoying

3.) adam added this today, but we have to worry about the cases where users don't have the same version of aim.exe as their clientstring advertises. therefore we have to fingerprint the aim.exe you supply us, in order to base the client string we send on that.

4.) this is a bit more interesting, but a lot of overhead we don't like to add. you would send a request for a byte range as well as the client string you specified, and the server would know which bytes (or the hash) to send you. you would then use this.

we have problems with that due to latency, and server load. md5 isn't exactly cheap, and doing it a lot would be noticable. if you don't reply to the 0001/001f quickly enough, you get the boot. so if the server gets bogged down, nobody can log in, so everyone starts trying harder, bogging the server down further... ad nauseum.

it's also questionably legal.

we try our damnedest to keep libfaim legal -- it's basically the only way to get on AIM without using an AOL client. and don't tell me TOC is an alternative, it's not. TOC has _lost_ features since AOL stopped officially supporting it. TOC also doesn't support full rendezvous (file transfer, directim, etc), which libfaim at least partially implements (I have done a partial implementation in libfaim; faimtest can request and serve up getfiles. sendfile still needs done; directim has been around for awhile now).

i'll keep up with the threads here, and i can be reached for comment at josh at joshisanerd.com. make sure you mention "AIM" in the subject.

i'll shut up now and let the other guys involved post some =)

-josh