Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
America Online

AOL vs. Open Source AIM Clones 401

Posted by michael from the finger-in-the-dam dept.
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?"
This discussion has been archived. No new comments can be posted.

AOL vs. Open Source AIM Clones More

AOL vs. Open Source AIM Clones

Comments Filter:
  • IIRC, you can't change your password, can't see someone's away message in their profile, and of course no file transfers, IM images, voice chat, etc. Probably no buddy icons. None of this is important to a lot of people, but to some people, it is.

    --

  • 1) you can already bypass the ads with aim.

    Not without hacking the client, which I'm sure AOL doesn't like either.

    2) aol agreed to make their im service available to other clients as part of their agreement with the ftc. as a condition of their merger with time warner.

    Their service is available. Just use the TOC protocol, like TiK does (and Gaim can).

    --

  • Why do people HAVE to interoperate with AOL AIM clients/servers ??? Just build your own, and better yet, use some standard and ignore AIM.

    If you can get everyone you want to talk to to use your client, great, you do that.

    You want to talk to me. I'm already running AIM to keep in contact with around a hundred people - what incentive do I have to install your client on my system, running alongside AIM and consuming system resources? I don't want to talk to you that badly.

    After all, it's AOL people, I find it strange that Slashdot geeks want to interact with clueless AOL minions !!!

    I have to point out that despite appearances, AIM and AOL are NOT the same thing. The vast majority of AIM users are not AOL users. I frequent Computing Chat [aim] on AIM, and many of the "regulars" there are running FreeBSD or Linux - the AOL users almost never go into AIM chats.

    --

  • It's been done. Many times. By many different people.

    If you can get everyone you want to talk to to use one of those other clients and protocols, great! Go for it. You no longer have a problem.

    For the rest of us, it's an issue. If I stop using AIM, I lose contact with over a hundred people, and suggesting that I should just tell all of them to install some other chat client is absurd.

    --

  • Presumably the Mac clients send an MD5 checksum of the application ("AOL Instant Messenger (SM)"), after first giving the information about their version.

    --

  • 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 they wont and you will just cut off a line of communication with your friends.

    Why are all these people assuming that as soon as they switch all of their freinds will immediatly switch as well? I'm not the only one on their contact list and they are going to want to lose all of their other contacts just to talk to me. Fortunatly, I lucked out and most of my friends are in the ICQ crowd (also owned by AOL however), so we havn't had these problems (yet).

    Down that path lies madness. On the other hand, the road to hell is paved with melting snowballs.
  • too many possibilities you'd need more memory than there are atoms, unless i'm severely overestimating how many possible chunks of n bytes there are in aim.exe. Isn't it actually at least (the file size)! factorial, since they can start anywhere and go for any length?

    Fuzzy math. :) The memory required would be 8n(n-1), where n is the file size in bytes. There are n 1-byte strings, n-1 2-byte strings, ..., 1 n byte string. Thus there are n(n-1)/2 different contiguous strings available. Each sum costs 16 bytes, thus 8n(n-1) bytes total cost. It's high (1-10TB), but not nearly so large as you suggest.

    It can be performed at somewhere between 20 and 40 megabytes per second on 16 byte strings

    Far faster than the proposed server's network connection -- MD5ing on the fly isn't the bottleneck.

  • XOR aim.exe with the libfaim library file and save the result as a data file. When AOL requests a checksum, XOR the section of the data file with the library file to calculate the checksum and send the back result to AOL. Simple.

    But all you're doing is encrypting aim.exe with libfaim.so as the one-time-pad. If you send this encrypted aim.exe.xor with instructions (in code) to use libfaim.so as the pad, then this is no different to gzip'ing aim.exe and sending copies of aim.exe.gz around along with the (implied) instructions to gunzip it. You're still going to be infringing copyright if you do this.

  • The more clients using their service, the more *useful* the service becomes. This is a fundamental truth about networks and p2p services. AOL is actually benefitting from the FREE work of the Gaim developers. Does AOL really think that instant messaging alone is selling its (questionable) ISP services? This is madness. Does *anyone* in today's business world look beyond his nose?

    This story is much the same with the Napster. For all the "music theft," CD sales are up. In the early days of MS Windows, theft *HELPED* spread the damn OS to more machines than Microsoft's marketing department. Does this mean that while companies take a short-term "hit" from missed sales opportunities, they actually benefit in the long run from a certain level of "service theft"?

    Yes.

    The only reason for AOL/Microsoft/MPAA to get squirrelly about freeloading is unfettered, short-term greed (and possibly repressed a Calvinist rearing.) And, apologies to Gordon Geeko, greed is not good for long term business.

  • Actually, it does benefit them. Their network only has value because it connects a lot of people; if they have a reduced number of users, the other users get less value from their product, which means they are more likely to defect to other services like MSN. So, long term, it is probably better for them to accept a small number of ad-free "moochers" in return for better overall stability for their users. Now... they /do/ have every right to shoot themselves in the foot by forcing me to ask my friends to use something other than AIM. But it would be nice if they didn't.

  • ...or Jabber (Score:5)

    by MenTaLguY ( 5483 ) on Wednesday March 28, 2001 @09:32PM (#331542) Homepage

    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.

  • Maybe this is a dumb question, and I assume that the whole POINT of md5sum is to verify _exactly_ the bits you have ... but on the off chance that binary:md5sum is not a one to one, unique mapping, could you come up with a meg or so of bits that will always yield the exact same md5sum as if you had operated on aim.exe?

    At first glance, that's a pretty dumb question, I suppose... but I was thinking that doing an md5sum is used to detect random errors - so maybe it's possible to carefully craft a string of bits that md5sums just like another, different string of bits?

    ---

  • According to the MD5 homepage [umbc.edu],

    It is conjectured that it is computationally infeasible to produce two messages having the same message digest [output], or to produce any message having a given prespecified target message digest.

    Hm... computationally infeasable... perhaps it's time for a new distributed.net contest? :)

    ---

  • All the more reason to use & promote Jabber, no?

    ---

  • > In theory, yes, but if you'd read the article, that's not what they're doing.

    I read the article and I understand that that's not what they're doing. You made an assumption about what I meant...

    I meant, can you make a string of bits that will always yield the exact same md5sum as if you had operated on aim.exe in the same way that the challenge does i.e. work on any substring.

    I know, probably not. But I guess I'm looking for mathematical proof. :)

    ---

  • This is very easy to fix. First we run in a public server (or a network of servers) a service that can return the checksum for the executable on demand. So just a single executable is required. Then the service provides this data on demand to clients.

    The client would typically check whether it has the checksum being requested on its cache, if it does not, then it contacts the checksum.aim-provider.com server with the appropiate arguments, gets the value, and provides this back to AOL.

    It is nothing but a 10 minute hack.

    Miguel.
  • 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."

    Ehh? Get your facts straight. AOLTW was never ordered to open up their current protocols. They are required to open up future protocols that involve video conferencing and broadband. Instant messaging is not covered by the merger conditions.

    http://www.fcc.gov/Bureaus/Cable/Public_Notices/20 01/fcc01011.pdf [fcc.gov]

    Given AOL Time Warner's likely domination of the potentially competitive business of new, IM-based services, especially advanced, IM-based high-speed services ("AIHS") 5 applications such as videoconferencing, the Commission concluded that a condition to prevent that merger-specific harm was merited. AOL Time Warner may not offer an AIHS application that includes the transmission and reception, utilizing a names and presence directory ("NPD") 6 over the Internet Protocol path of AOL Time Warner broadband facilities, of one- or two-way streaming video communication using NPD protocols - including live images or tape -
    that are new features, functions, and enhancements beyond those offered in current offerings such as AIM 4.1 or ICQ 2000b, unless and until AOL Time Warner has successfully demonstrated it has complied with one of the following grounds for relief.
    (Bolding is mine.)

    --


  • Someone stated that the file in question is only 25KB
    . Let's do some calculations.

    If the file was only 1 byte how many possibilities were there for MD5 checksums ?
    Well, 1 actually
    If the file was 2 bytes, we have 3 possibile sums.
    If the file was 3 bytes, we have 6 possibile sums.
    If the file was 4 bytes, we have 10 possibile sums.
    Extrapolating this to 25000 we get 312512500 possible MD5 sums for 25KB file, but wait, in theory you can ask for sums to be calculated "cackwards" for any length of buffer except 1 byte. (Just specify buffer A-B where A>B)
    So we have 312512500+312512500-25000=625000000 possible 16 byte md5 checksums.

    That makes for 10,000,000,000 bytes
    Quite possible to put all that in a database.

    But of course AOL will make sure the next version will be hundreds of K's, blocking this approach in the future.


    --
    Why pay for drugs when you can get Linux for free ?

  • Of course the case is a copyright case. It held that it was fair use to make intermediate copies of Sega games in the process of reverse engineering. But, with respect to the wholesale copying and use of the initialization code, there was no copyright claim, only a trademark claim.

    From the opinion: "In this appeal, Sega does not raise a separate claim of copyright infringement with respect to the header file." Sega v. Accolade, 977 F.2d 1510, 1516 (9th Cir. 1992).

  • Re:Sega vs Accolade (1992) (Score:4)

    by troyboy ( 9890 ) on Wednesday March 28, 2001 @10:47PM (#331563)
    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!

  • Creating a private, non-interoperable network is silly. The value of a network is proportional to the square of its size (Metcalfe's Law). Correspondingly, dividing a network into n partitions makes the value of the network 1/nth its original value.

    Interoperable IM clients is inevitable. The right thing to do it make it happen, however it needs to be make to happen.

  • I posted a comment on this, that got labelled "troll" by an overzealous moderator. Anyways, here it goes : Why do people HAVE to interoperate with AOL AIM clients/servers ??? Just build your own, and better yet, use some standard and ignore AIM. This is just absurd, MS trying to connect to them, Open Source people trying to get it too, why ? If AOL wishes to only allow their clients to be able to use their servers, I don't see why people should complain about this. After all, it's AOL people, I find it strange that Slashdot geeks want to interact with clueless AOL minions !!!

  • Re:OSCAR protocol work arounds. (Score:5)

    by mrsam ( 12205 ) on Wednesday March 28, 2001 @09:18PM (#331584) Homepage
    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.

    ---

  • Thoughts? Yeah.

    • Some of us warned you guys about this exact hypocrisy a long time ago.
    • You should've been able to see the logical implications of such a stance without needing Eric Raymond, the pauper of VA Lnux, to send the word from on high down to you. Moral: Letting ESR either do your thinking for you, or invest your money for you, is asking for some seriously bad mojo.
    • AOL is well within their rights to do this to Microsoft or the open source efforts.
    • AOL doesn't have a near-monopoly on internet chat. There's IRC, which I hate, but there you go. MSN Messenger has passed AIM in users. Yahoo! Messenger isn't all that far behind AIM. ICQ is still the big dog, but the other services have too many users for anyone to think that ICQ can dicate to everybody.

    Why do so many of your friends use AIM, anyway? Are you friends with that many AOLers, or did they accidently install it when they installed Nutscrape? AIM has always been lacking in features compared to the competition until fairly recently, anyway. Better to wean yourself and your friends off it now (and if they're really that interested in chatting with you, and you explain the predicament, they shouldn't mind installing a second IM, since most of the competition offer nice and lightweight IMs), than have to deal with this every couple of months when articles like this rear their heads.


    Cheers,

  • This is about AOL's approach to the internet

    I don't see how this is any different from people who configure their mail servers to not be open relays. I only want authorized people using my smtpd. AOL only wants authorized people using their IM servers.
  • Ok, so combining several people's suggestions here, and asking some questions of my own:

    How often does the AIM server change what it asks for? Every time? Once per day? If it's once per day, then adding caching to the equation helps eliminate the disconnect problem. Sure your first try to connect might not get the md5 from the web server or dns server or what have you in time, but it'll come back eventually and be cached for the second try. I think having a chance of not connecting the first try is an acceptable workaround.

    Given that, what we need is a server (whether web or dns or what have you) that can be fed a start and length and will spit back the appropriate md5 key. Preferably multiple servers mirrored appropriately, of course. These servers wouldn't even have to have aim.exe, just a db of all possible keys from aim.exe (which I come out with, using 24K aim.exe and 128-bit md5 keys, to be about 4.5G). Generating this db should be legal from fair use if you have aim.exe already, but IANAL so I can't tell you whether distributing this db is legal. But it'd be easy enough to distribute code that generates that db given aim.exe, so there are workarounds.

    So what's missing from this picture? Sounds like an acceptable workaround to me overall. Not a pleasant one, but doable.

    ---
  • Great idea in concept, but in practice, well...

    Q: Who operates the only major competitor to AOL's various IM services?
    A: Microsoft, via MSN
    Q: What has MS's policy regarding 'open architectures' been and still seems to be?
    A: 'Embrace and extend'. The only competitor to the closed system in this case is another closed system with a known propensity for perverting open architectures for its own ends. Just creating OpenIM in and of itself won't do anything, as it's not in -anyone's- interests (anyone being the service providers) to allow it to stay open.

    "If ignorance is bliss, may I never be happy.
  • I think this is how the Dreamcast CD boot system works [mc.pp.se]-- to get the thing to boot a CDR, you have to copy a magic 32K header called IP.BIN into the top of an ISO image, part of which it runs, but before running it, it checks it byte-for-byte against a copy held in the Dreamcast's ROM. This code naturally displays a screen saying `Licensed and endorsed by Sega Enterprises' which of course ain't so for homebrew developers. Having said this, Sega don't seem to have batted an eyelid that copies of this code are floating around on the various DC development sites... somebody else mentioned on this thread that Sega tried to claim (c) on three bytes which were needed to authenticate a Genesis cart after Acclaim reverse-engineered them. Maybe they're not so bothered about it these days?
  • 2) aol agreed to make their im service available to other clients as part of their agreement with the ftc. as a condition of their merger with time warner.


    No they didn't. Many other industry groups/lawmakers worked with the FTC/FCC to try to get that stipulation in there. AOL did not volunteer to do it.


    In the end though, it didn't happen. You should go read the ruling before you talk about it. The FTC/FCC said that AOL has to open up their AIM service for "future technologies" (e.g. voice and video). There is nothing in the ruling that says AOL has to open up AIM as it currently functions.

  • That makes for 10,000,000,000 bytes
    Quite possible to put all that in a database.

    And serve it from where? Because, quite honestly, even with a T1 line, ~10 GB is going to take an AWFUL long time to download, not to mention, it would fill up one of my hard drives. :)

    The problem is *serving* it. I like the guy who had the DNS idea. It's BEAUTIFUL. Just like the DeCSS code. :) AOL couldn't do a damn thing to stop it, either. :)

  • Evil mode on.

    Oh, what a shame. You trialled a new beta of the software. But it had a bug in it that sent the MD5 sum continuously in a flood when it received the checksum request. This bug crashed the AOL server. The bug is proving so hard to find, but with 10,000 beta testers, you can't contact them all to get rid of the bug. Oh, you didn't put the bug in there intentionally, did you? Oh, of course you didn't, no programmer would do that ....

    Evil mode off.

    --
  • A better idea would be to cache recent requests. If there's a lot of requests for X bytes starting at Y, then this can be cached. I can see *cough* evil-monopolistic-corporation *cough* AOL thwarting this approach with random X and Y. This would also break prehashing.

    Let's assume that the md5 server is up and running and happily providing the correct bytes. What's the next step that AOL will take? Will they figure out which version of AIM is being used and compel all users of that version to upgrade? Will they block that version? Will it be necessary to store multiple versions of AIM to combat this? Will they put another buffer overflow hack into AIM?

    --
  • What about 4. put aim.exe in freenet, and have build in a freenet client along with its identifier?

  • Ok, so you need to have a data file (a la BIOS files for many emulators) that you have to get as well as the package. Thoughtful programming could even automagically fetch the program from AIM.com if it doesn't exist.

    Basically, it's not an executable, it's a large key. So you need the key to run a program. Oh, well.

    --
    Evan

  • 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.... (Score:3)

    by mindstrm ( 20013 ) on Thursday March 29, 2001 @04:10AM (#331605)
    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? (Score:5)

    by ywwg ( 20925 ) on Wednesday March 28, 2001 @09:05PM (#331606) Homepage
    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?
  • Oscar. It's default settings are to connect to login.oscar.aol.com on port 5190.

  • Re:i thought this was a free service? (Score:5)

    by AT ( 21754 ) on Wednesday March 28, 2001 @10:20PM (#331608)
    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.
  • perhaps with any luck this kind of behaviour will force many AIM users to switch over other IM networks like Jabber.


    Umm... as the article said, this doesn't affect current AIM users, as it uses an existing (but until now unused) ability of the AIM client. The only people who are going to be in an uproar are the ones who are already in an uproar... the rest of the IM users probably won't even notice.

    In order for people to switch from AIM, we need a killer app to draw people away from AIM. Currently AIM offers, IM'ing, File Sharing, Personalized pictures, and Voice Communication. If it weren't for the legal issues, I would suggest embedding a Napster client into the competing IM client.

  • OSCAR protocol work arounds. (Score:5)

    by Matt2000 ( 29624 ) on Wednesday March 28, 2001 @08:43PM (#331624) Homepage

    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?
  • Is it legal for the user to download aim.exe?

    If so, then all you need to do is have the user download the file during installation.

  • Jabber AIM Transport and the FCC (Score:4)

    by Temas ( 30015 ) on Wednesday March 28, 2001 @08:59PM (#331628) Homepage
    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. (Score:5)

    by RaveX ( 30152 ) on Thursday March 29, 2001 @12:27AM (#331629)
    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---
  • 1) Install the rpm/deb/what-have-you as you normall would.

    2) Go pull that AOL CD out of the trash that you put there yesterday (and probably the day before and the day before that) and copy the aim.exe file to /etc/aol-sucks/aim.exe
  • Can't ICQ now interoperate with AIM? Does it do this via OSCAR or TOC? If OSCAR, then it'd be interesting to know how ICQ authenticates itself - is it through an MD5 of icq.exe, or something else?
  • You are, of course, correct. However, AOL is treading a thin line here. They have been ORDERED by the FCC to allow alternate access to their Internet messaging, and have not done so. It was one of the conditions of the Time/Warner/AOL/DC Comics/CNN/TNT/Life merger. Since they have failed to do so, they may face legal action from the FCC. Now, they *could* offer a for-pay route, but they've also failed to do _that_....
  • Because of the 30 million users that use AIM?
  • Clearly all that is necessary (for now) is to make a working copy is to require the user to obtain a lawful copy of AIM, and compute the MD5's off of that copy.

    An interesting question arises, however. What if instead of doing that, one produced a file comprising all possible checksums (huge, of course, but go with this for a moment)? Would distributing the MD5 database constitute a copyright infringement as an unlawful derivative work? How could it do so, if the MD5 is, by definition unreversable? Copyright only protects works fixed in tangible media and capable of reproduction in tangible form. There is no expressible content in the MD5 list. Perhaps. Perhaps. It would be a case of first impression, but a very interesting case.

    Of course, the size issue is avoided simply by providing an AIM MD5 checksum server, giving the checksum as a function of the query. Who would want the exposure? Dunno, probably nobody in their sound mind. But what an interesting legal question.
  • Of course, the 1-byte hashes, known to be hashes of one-byte only, permit an exhaustive search of an 8-bit space. In practice, does the AIM software query for 1-byte or 2-byte MD5's, or do they look for hashes that would be wider in nature?
  • You're wrong. Here's what the actual case says:

    REINHARDT, Circuit Judge: 1/ This case presents several difficult questions of first impression involving our copyright and trademark laws. [fo] We are asked to determine, first, whether the Copyright Act permits persons who are neither copyright holders nor licensees to disassemble a copyrighted computer program in order to gain an understanding of the unprotected functional elements of the program. In light of the public policies underlying the Act, we conclude that, when the person seeking the understanding has a legitimate reason for doing so and when no other means of access to the unprotected elements exists, such disassembly is as a matter of law a fair use of the copyrighted work. . . . Accordingly, we reverse the district court's grant of a preliminary injunction in favor of plaintiff- appellee Sega Enterprises, Ltd. on its claims of copyright and trademark infringement.

    ...

    11/ On November 29, 1991, Sega amended its complaint to include a claim for copyright infringement.

    So, yeah, it was a copyright case (could Accolade include the copyrighted TMSS initialization code?)

  • I've discovered that not towing the party line will get you modded down just as fast as actually trolling. The problem is that some of the moderators here seem to think the definition of "trolling" is anything which they strongly disagree with.

    Of course I expect this message to get modded down. Go figure.
  • But that makes any comment which goes against the party line a "troll" by your lose interpretation, doesn't it? After all, any comment which goes against the party line gets a rather predictable response here.

    The problem is that the original poster wasn't "trolling", (which comes from it's meaning of fishing by trailing a baited line behind a slow moving boat). That is, he wasn't fishing for flames. While it is true that in some cases giving one's comments may not be a good thing (such as a christian trying to convert people on alt.pagan), that only means that considering something a troll requires some context.

    In a news discussion forum which is for "nerds", it is important to realize that there is a wide variety of opinions which do not tow the party line. By such a lose interpretation of "trolling", we run the danger of kicking out anyone whose opinions run contrary to popular opnion. And we run the risk of mixing in things like "I think Microsoft Windows 2000 is a fairly good operating system" with "I want to screw Natale Portman." posts--which, for those of us who are open minded enough to want to hear the descenting opinion, makes the use of moderation completely pointless.
  • The malapropism police say that you need an odd kind of toe truck to tow the party line.


    Sorry, foot fetish.

    Or maybe it's the fact that there isn't a spelling checker and a grammer checker here--and sometimes, a cigar is jut a cigar, too. :-)
  • I'm not really sure, but it seems to me requiring the contents of an aim.exe for compatibility would, under Copyright law, legalize the free distribution of those contents for the purpose of compatibility. We had part of ICQ, why not all of AIM?

    Can someone actually look this up in the laws of various countries?
    --------
    Genius dies of the same blow that destroys liberty.
  • Everybody can write an AIM like service and host it.

    Yeah, and anybody can build their own telephone system, too. Corporations do it every day. Fuckload of good it does you if it can't talk to anyone else's, though, and that's the difference. Corporate telephone systems have a wire connecting to the outside phone lines. Joe's AIM Server won't have that kind of integration with AOL's AIM servers.

    Nobody's going to use Joe's AIM Server if it can't talk to AOL's AIM servers, and by extension, those who connect to them.

    --

  • Quake has several mechanisms to spot fake clients and cheaters.

    Because fake clients and cheaters serve only to damage the experience for other users. Why else would you use a fake client? If you don't want to pay for Quake, you'd pirate it, not write your own 3D engine. And cheaters is obvious.

    Fake AIM clients enhance the experience for other users, because every time a person they want to talk to joins the service, the service is more valuable to them.

    Id's restriction against fake clients and cheaters has nothing to do with bandwidth, and everything to do with the players and the game.

    --

  • This could also be used to prevent users from hacking the binary to make it not display advertising banners!

    Yes, except that there's no hacking of the EXE involved in disabling banners. You comment two lines out of a config file.

    --

  • and what file would this be?

    First I'd like to insert a snarky comment on how Google is such a difficult tool to use, and Thank Goodness for people like me who possess the skills to use such advanced utilities, but anyone who reads Ask Slashdot already knows this, so I'll pass.

    Anyway, the file is "aim.odl". Just insert a semicolon in front of the "load_ocm advert" lines, and just for extra safetly, rename the advert.ocm file. There are even little programs you can download that'll do it for you, apparently.

    --

  • If they want to talk to you, they will switch.
  • Why do people insist on using OSCAR? Is being able to view away messages that important to you? If you answer yes, then stop bitching every time AOL makes a change that breaks your client.

    One more time, and I'll spell it out slowly for everyone out there who like 2 syllable words. There are two protocols that AOL Instant Messenger uses. The first is OSCAR. It is more powerful, yes, and it's also AOL's "private" protocol. It's not supported except for AOL-developed clients, and any 3rd party implementation that uses OSCAR is a hack. The other protocol is TOC, which AOL has made available to the community for 3rd party clients. If you use OSCAR despite this, you get what you deserve.

    -Todd

    ---
  • 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?

    Actually, you're wrong. You can't take a section of the order out of context and expect it to stand. That whole section of the order that deals with remedies for AIM only apply to the next generation of AIM. It specifically says at the start that AOL-TW may not offer an AIM-like application with new features not present in 4.3 or ICQ as it currently stands until one of those remedies are met.

    And it doesn't even say that they have to open up. It says they either need to 1) implement a standard protocol (which to my knowledge there isn't yet); 2) enter into a contract for interoperability with another IM provider, and then set up 2 more such contracts within 180 days after that, however it doesn't specify that these have to be no-cost or low-cost contracts; or 3) show that they lost IM market share and haven't led the market for 4 consecutive months.

    So you see, unless and until the IETF or someone else comes out with a standard IM protocol (not a proposal), AOL's only option is to set up contracts with other IM providers. But it doesn't say they have to give it away. And in addition, while they do have to report every 6 months (it hasn't been 6 months since the merger was completed), the only timeframe for this is "before you implement new AIM features". So AOL could sidestep the whole thing by freezing the features on AIM and ICQ.

    -Todd

    ---
  • If you believe that, I have a bridge to sell you.
    ---

  • IM is not a new market.

    Am I the only one who's been doing IM since Powwow [netscape.com] came out?

  • I was going to point out that my girlfriend and I talked by "talk" in the late 80's actually, but you've definately got me.

    I was born in the 70's.

    Point still stands: what's wrong with these people who think ICQ was a _new_ concept?
  • Why don't you just require that the user downloads aim.exe and puts it where the program can find it?
  • > out that you'd need a couple of GB of fake-aim.exe

    Er. Read the article. The server requests a MD5 sum of a randomly chosen 16-byte area. You'd need a fake for each possible one. I don't know how big the aim exe is, but in a 1 Mg exe there are over a million possibilities.
  • > could you come up with a meg or so of bits that will always yield the exact same md5sum as if you had operated on aim.exe

    In theory, yes, but if you'd read the article, that's not what they're doing.

    They are reading a randomly chosen 16-byte segment and MD5ing that. You'd have to fake or store a MD5 for *each* possible 16 byte segment, ie about 1 million of them per Mb of exe. (or 1/16th of that if they always align the starting point by 16 bytes) Either way it is vastly less feasable.
  • .. is to *BOYCOTT* AOL/AIM.

    And don't give me that garbage about "but all my friends use it" Switch to a FREE IM and let your friends know WHY you are switching.

    If everyone STOPPED supporting AOL we WOULDN"T have this problem.

    It's their network, so AOL can go f#$* themselves.
  • Actually, that's been greatly misread. The correct reading of it is "AOL must open up their IM system IFF (if and only if) they add High-Bandwith features to AIM, specifically Video Conferencing. As long as they don't add that, they are not required to share AIM source code or specs with anyone.
  • Hi. I'm the lead gaim developer.

    An MD5 server is not feasible. There are two ways to implement said server. One is to distribute the MD5 encoded parts of the binary, and the other is to just distribute parts of the binary and let each client encode it. Each one is not possible.

    The first one is not possible because the demand on the server is simply too great. Doing the number of requests required, in the amount of time each request needs to take, isn't possible. Each request needs to be submitted, processed, and completed, before the client's connection to the AIM server times out (which is actually relatively quickly - I don't have an exact value for you but it's in the range of 20 or 30 seconds (rough guess)). For people who aren't on high-bandwidth connections (modem users) this isn't an option.

    The second one isn't possible for the same reason, but the amount of data transfered is greater (potentially up to 2^32 bytes (or whatever the size of aim.exe is)), in addition to the fact that it's probably not legal to distribute parts of the binary in this way.

    So while an MD5 server for this would be really neat, it's not feasible. Sorry.

  • It can't find out what version it is just by looking at the file, unfortunately. Also, it needs to use one of two specific versions in order for this to work at all - 3.5 or 4.1. 4.3 will not work because it has server-side buddy lists, and when those are in effect then presence (updates for who's online) doesn't work with the current libfaim. So you have to have either 3.5 or 4.1 - and right now it's hard-coded that you have to have 3.5.
  • 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.

    Yes it is.

    The thing everybody does not understand is that TOC does what 95% of everyone needs: chat. Oscar does the file xfering shit (although I think thats possible through TOC too?), buddy icons, direct talking (voice over AIM), sending of pictures, etc.

    Given that GAIM is AIM for linux, how many linux users exactly give a flying fuck about buddy icons? How many use AIM to xfer files, instead of say, scp or email?

    I agree that OSCAR support for linux clients would be cool, especially if linux is to ever become a desktop alternative (after all, Joe PC loves those superflous features I mentioned) but until that time, I, for one, dont really give a damn. (Note also that more people using linux on the desktop would actually give AOL a reason to let other clients in on the all the protocol fun. Until then, they rightly don't care.)

    Kaim [sourceforge.net] or Gaim is good enough for me. As long as TOC is never closed (fingers crossed) then I'll be happy, and so would everyone else, if they'd quit the zealotry and learn what they're ranting about.


    --
  • Because md5 is a *one-way* hash-function, a server with a database of *md5 sums* for the various chunks of aim.exe *could not in any way* be said to have a copy of aim.exe, or anything that could even be processed to produce aim.exe. The sum is *one-way*.

    The drawback here is that the space of offset x length pairs of md5 sums is much larger than the size of the original program -- roughly the original program size squared. But if the aim.exe isn't *too* large, a single server with a coupla gigs of hard drive space might be able to do it.

    Otherwise, the sum server could just use a cache of the recent values, and drop off the LRU. This assumes that AOL gnereally doesn't change its length-offset pairs that frequently.

    (Oh - the chicken-and-egg problem: someone with a *legitamate* copy of aim.exe could seed the server with valid pairs. Remember, because md5 is *one-way*, doing so would not be comparable to exchanging copies of aim.exe.)

  • Workaraound exists (Score:3)

    by gss ( 86275 ) on Wednesday March 28, 2001 @08:43PM (#331693)
    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.

  • Oh, I quite agree. Copying an MD5Sum of a part of a program is no more deserving of copyright than say copying the file length - that would be absurd on the face of it: I own the length 329466; the length of my new game program -- so if you use that number in any way, I'll sue.

    My statement about storing md5 sums being improbable was simply a recognition of the factorial problem... there are simply too many possible MD5sums that could be generated.

    The other point, about storing transforms of the original which could be turned into valid md5 sums, but which was not itself the original program was the one I thought would have copyright problems.

  • Re:why embed? (Score:3)

    by kevinank ( 87560 ) on Wednesday March 28, 2001 @08:48PM (#331695) Homepage

    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.

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

    oh God, i hope the FCC doesn't get involved in this one. AOL/Time Warner may be a monopoly in a lot of markets, by why do we want government agencies messing around with software, especially in relatively new markets like IM?

    perhaps with any luck this kind of behaviour will force many AIM users to switch over other IM networks like Jabber [jabber.org]. and for the Windows people who use the "official" client, perhaps the lure of a more stable client without ads might get them to switch. but however it's done, let's hope it's by fair competition, not FCC involvement. the IM market is too young to have government intervention.

    - j

  • There are numerous problems with this approach. Others have already posted several. It probably should be legal, but it's also probably going to be more hassle than it's worth to do... there's way too much slack for the landsharks in that scenario - maybe they couldn't beat you, but they could damn sure bankrupt you, assuming you aren't Billy G's kid or something...

    A better method, imhop (IANAL et cetera) - include a generic utility to implement a Free and Open security method, with an option to request a checksum on a file as an option alongside password and MAC authentication. That way any use made of it is going to be very clearly not your responsibility, and if someone with deep pockets does decide to set their landsharks to the task of driving you to suicide, their case will suck bad enough that folks like the ACLU will pay for your defense.

    There might even be a movie deal afterwards, who knows?


    "That old saw about the early bird just goes to show that the worm should have stayed in bed."
  • Try the new version of Fire.app (0.23b), it works great for me. I've been connected all day with no problems...Yay for Fire.app and MacOS X!

  • Sorry, I shouldn't have read the original message so quickly. Yeah, the server could calculate the things on the fly. I see no problem with that.

    ------

  • Re:OSCAR protocol work arounds. (Score:3)

    by Temporal ( 96070 ) on Wednesday March 28, 2001 @09:18PM (#331708) Journal
    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.

    ------
  • My friend just upgraded his Mac to OSX this past weekend, and suddenly discovered that his AIM client stopped working. We just assumed that AOL was doing its typical blocking of AIM clones (aren't they supposed to open it up because of their FCC agreement?). The only problem is that as of yet, there IS NO AOL IM CLIENT FOR OSX. My roomate has no problem using AOL's client, but they haven't made one yet for him to use! He's forced to use AOL's java version which is slow and very much on the crappy side. It's ok to protect your network from unwanted outside users, but you gotta support the users you do have!

  • Maybe.. (Score:2)

    by xant ( 99438 )
    I remember reading that SHA (Secure Hashing Algorithm) was being developed as a replacement for MD5 because there was a known attack which allowed you to produce an identical MD5SUM given a different set of bits. A web search could probably reveal what the attack is. Now it may well turn out that you'd need a couple of GB of fake-aim.exe to equal one aim.exe.
    --
  • Great, so now we'd have to pay AOL $3/month to use AIM (unless you're an AOL member already probably).

    I don't want to pay $3/mo to every thing on the Internet to use the Internet. Advertising keeps ABC,CBS,NBC,Fox free.

  • I'd like to see you try to get that many people (especially the Windows and Mac users) to use your protocol

    There are Jabber clients for Windows and classic Mac OS [jabbercentral.com]. The BSD clients should recompile on Mac OS X systems with XFree86 installed.

    abandoning AIM completely

    TOC still works.

  • 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?

    Two problems:
    • AIM is tied to x86 Windows, as the download is a binary program that creates aim.exe and must be run on x86 Windows. WINE (the most popular Windows-on-Linux/BSD solution) runs only on x86, as it performs no CPU emulation. If your organization does not own any x86 computers, you can't get aim.exe.
    • The only version of AIM that AOL is distributing is the one that uses server-side buddy lists, a feature that the libfaim people have not yet cracked.

  • If nothing else, determining the rightful owner of the XOR of two separately copyrighted files will be amusing

    According to traditional interpretations of US copyright law, it's considered a derivative work of both original files, subject to the derivative works provisions of any licenses to which the preparer of the XOR file is a party.

  • until they release a PPC binary I literally cannot use an official client on the machine I use to chat.

    Have you tried Bochs [bochs.com] (Lesser GPL) or Connectix Virtual PC [connectix.com] (proprietary) for running PC programs on your Mac?

  • Why should AOL make their service open? (Score:3)

    by Darth Turbogeek ( 142348 ) on Wednesday March 28, 2001 @08:48PM (#331757) Homepage
    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: (Score:5)

    by f5426 ( 144654 ) on Thursday March 29, 2001 @04:49AM (#331762)
    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.... (Score:3)

    by Chester K ( 145560 ) on Wednesday March 28, 2001 @08:45PM (#331764) Homepage
    ...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 (Score:4)

    by micromoog ( 206608 ) on Wednesday March 28, 2001 @09:03PM (#331806)
    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.

  • 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? (Score:4)

    by AlbanySux ( 248858 ) on Wednesday March 28, 2001 @08:40PM (#331839)
    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. (Score:3)

    by luismunoz ( 254664 ) on Thursday March 29, 2001 @06:05AM (#331844) Homepage
    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... (Score:4)

    by deran9ed ( 300694 ) on Wednesday March 28, 2001 @09:29PM (#331864) Homepage
    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... (Score:5)

    by __aaahtg7394 ( 307602 ) on Wednesday March 28, 2001 @09:00PM (#331878)
    (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

Slashdot Top Deals

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Close