Slashdot Mirror
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?"
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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).
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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 on AIM, and many of the "regulars" there are running FreeBSD or Linux - the AOL users almost never go into AIM chats.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.
I read the internet for the articles.
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.
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.
IAAL,BIANLY
What a good idea...
DNA just wants to be free...
Or like Jabber, 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.
DNA just wants to be free...
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?
---
---
---
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.
http://www.fcc.gov/Bureaus/Cable/Public_Notices/20 01/fcc01011.pdf
(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 ?
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
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).
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.
pooptruck
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 !!!
- sigs are for wimps.
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.
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.
---
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
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.
-- Veni, vidi, dormivi
I think this is how the Dreamcast CD boot system works-- 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?
Matthew @ Bytemark Hosting
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
:)
:) AOL couldn't do a damn thing to stop it, either. :)
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.
My journal has hot
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.
--
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
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?
--
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
What about 4. put aim.exe in freenet, and have build in a freenet client along with its identifier?
Basically, it's not an executable, it's a large key. So you need the key to run a program. Oh, well.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
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 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.
Actually, linux is a supported platform. You can get it from http://www.aol.com/aim/linux.html. 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.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
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?
If so, then all you need to do is have the user download the file during installation.
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 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
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 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.
/etc/aol-sucks/aim.exe
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
The next site to slashdot will be ready soon, but subscribers can beat the rush and start slashdotting it early!
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.
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?)
Become a FSF associate member before the low #s are used
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.
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.
--
--
"I personal[ly] think Unix is "superior" because on LSD it tastes like Blue." -- jbarnett
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
---
"The details of my life are quite inconsequential..."
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
---
"The details of my life are quite inconsequential..."
If you believe that, I have a bridge to sell you.
---
"The details of my life are quite inconsequential..."
IM is not a new market.
Am I the only one who's been doing IM since Powwow came out?
- Michael T. Babcock (Yes, I blog)
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?
- Michael T. Babcock (Yes, I blog)
> 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.
My Karma: ran over your Dogma
StrawberryFrog
> 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.
My Karma: ran over your Dogma
StrawberryFrog
.. 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.
-----
"A man is judged by his every word." -RW Emerson
"They misunderestimated me." -GW Bush
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.
-----
"A man is judged by his every word." -RW Emerson
"They misunderestimated me." -GW Bush
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.
-----
"A man is judged by his every word." -RW Emerson
"They misunderestimated me." -GW Bush
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 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.
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
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.)
[
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.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
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.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
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!
"I like systems, their application excepted", George Sand (French)
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.
------
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!
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.
--
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
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. The BSD clients should recompile on Mac OS X systems with XFree86 installed.
abandoning AIM completely
TOC still works.
Will I retire or break 10K?
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:Will I retire or break 10K?
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.
Will I retire or break 10K?
until they release a PPC binary I literally cannot use an official client on the machine I use to chat.
Have you tried Bochs (Lesser GPL) or Connectix Virtual PC (proprietary) for running PC programs on your Mac?
Will I retire or break 10K?
Actually, linux is a supported platform
No it isn't. To support "Linux," you have to make your source available to recompile on every architecture that has a Linux kernel. It supports "Linux86" which is a subset of supporting Linux. It doesn't support Linux on PowerPC, Linux on MIPS, Linux on SPARC, or Linux on Alpha.
Or are you suggesting using AIM for Linux on an emulation layer such as Bochs? Good luck routing network packets through that.
Will I retire or break 10K?
I thought AIM ran on Mac OS, on those non-x86 architecture boxen?
Will I retire or break 10K?
Actually, TOC supports file transfers, albeit, not fully. A TOC user can receive files from an oscar user. a TOC user can even send files TO an oscar user under certain conditions. If the oscar user selects 'Get file' then the TOC user will be able to accept that request. The problem lies with the fact that AOL never bothered implementing the ability for a TOC user to initiate an rvous request. Bleh.
---
Rob Flynn
---
Rob Flynn
Pidgin
<Insert requisite IANAL disclaimer here>
I remember back in the day when Accolade backward engineered the Sega Genesis, allowing them to product games compatible with the system without Sega's intervention.
This was all well and good, but one of the initialization procedures required to startup the machine displayed a Sega logo... There was no around this, of course, and Sega took Accolade to court for infringing on its usage of their logo. As I recall, Accolade won since there was no other way of working with the system - it was Sega's fault for designing the system such that it required the infringement to occur.
I can't help but draw analogy between what was happening then and what is happening now - A party designs a system that forces anyone who works with it to do Bad Legal Things(tm) in an effort to keep anyone from working with it, despite perfectly legitimate reverse engineering. Tsk tsk tsk...
For those interested, the verdict an be found on EFF's site here.
From an advertising standpoint it benefits AOL to have 2 seperate Protocols. The benefit comes when they sell Ads space on that little box on the Windows AIM client. They can force users on the OSCAR protocol to use the Windows AIM client, and thus be served Ads. Where as the TOC client is just who-ever and whatever. They can then say "there are 10 million active users on AIM (refering to the OSCAR protocol) that are receiving ads." Then they can sell ads based on those statistics. At least AOL is providing an alternative protocol to using their services. This is all speculation of course, just a thought.
..There's a-dooin's a-transpirin'
While I can see why AOL wants to make sure they have add money coming in, and agree with that point, I hardly think that is their motivating factor. When MSN wanted to interface with AOL, they said no despite the fact that they could have worked out some add deal, and goodness knows MSN wouldn't have been reluctant about adds. I also see some sound reasons why AOL WOULDN'T want to do this - namely, it is unlikely that their add revenues from IM are their core bread and butter, and it is important to have as many people as possible connected to the system so people who are paying can talk to whoever they want. AOL has lots of subscribers who want to talk to people who aren't subscribers - it makes sense for AOL to provide that feature so people don't get inquisitive about what their friends are using.
Folks, this is about control. And the mere fact that this is an issue shows where the real problem lies.
Lets look at why we want to access AOL. Because they have millions of users who used all their computer savvy up just getting on AOL. We want to talk to these people (yes we have non-geek friends, so cork the comments) but can't convince them to make what is for them a nontrivial effort to get jabber working. AOL works well enough for them so that they don't want to mess with their computer which is now working to install unnecessary software (occasionally an adventure on Windows). That leaves us with the choice of bowing down to AOL or resorting to things like the phone and email.
When that choice presents itself, it points to a problem. AOL has too much control. Now, strictly speaking, it isn't AOL's fault. It's the fault of end users who are willing to get locked in. Same problem open source people have with Windows users. Unfortunately, most people just don't care enough about technology to fight it. Fact of life, and market reality. Those of us that do are a threat.
Because AOL likes this control. It means a VERY large captive audience, which means easy $$$$$. People who think too much about the system find ways to beat it. Either with programs like GAIM, or by being very annoying and coming up with something like jabber. So AOL fights by locking up their users. It's a bit of a risk, being a potential inconvenience, but realistically it turns out to be a small one. AOL has enough people signed up to get away with it.
I don't buy this whole thing about AOL did it so why shouldn't everyone else have to solve the same problems? AOL did not solve the problem of another AOL. They solved the problem of moving in where a vacuum existed. Winning over millions of people is easy when you don't have any serious competition. Problem is, once people are locked into a system, they don't change. That's why you want to keep systems open - so no one company can dominate.
I don't define valid open market success as controlling all of a market. That shouldn't be a valid goal. Note that I don't say they can't SELL to all of a market. But if a company begins to dominate to the point where they can shut other people out, the must open up if they want to continue to grow. Competition comes before outlandish individual success. It has to, if capitalism is to serve the public good (why it was created.)
No one company NEEDS to control everything. They would like to, because it makes things easy, but that's not why we have an economy. Hard work makes worthwhile things. People individually can reach the point where they can afford to rest, but companies shouldn't ever reach that point. They should always be hungry and striving for the next new and better thing. So if a company wants to grow to dominate an industry, it must be ensured that others can enter that industry with some hope of success. This keeps pressure on the leader to innovate, and allows fresh blood to sweap away an older, outdated system now and then. What if the inventors of the car had patented the idea of a steering wheel, so anyone wanting to build a new car had to use some other steering mechanism?
If AOL wants to dominate the industry, fine. But they can't be allow to be put in a position where they are more difficult to unseat than their market inertia warrants. They should always be fighting to maintain their market by making better quality products then the competition, not just being the 900 pound gorilla and sitting on them. If AOL doesn't like it, tough. They've had phenominal success already. Corporate greed is less important than the future of technology.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Open messenging and chat makes Internet access more useful. That is GOOD for the telecom industry, and those people have tons of money. So we may have an ally there. (as an aside, it was mentioned the telecom industry makes more in a week than the movie industry makes in a year).
Just because it CAN be done, doesn't mean it should!
Just like if I take an MP3 of Britney Spears and change every other byte to a zero. (*) There is no way to get back the original, but a court would very likely consider it an infringment to redistribute. We all know those are two different situations, but would, for example, Judge Kaplan agree? Remember how he ruled that DeCSS is illegal under the DMCA in spite of fair use, the Constitution, and even the defenses spelled out in the DMCA itself.
(*) One could definitely argue that the resulting file would be better than the original, and even better if the remaining bytes were turned to zeros as well. ;)
Just because it CAN be done, doesn't mean it should!
Here's an idea. Find a Jabber client, call it an AOL "upgrade" and mail it to your friends. Heck, people willing run VIRUSES that way, and here you will be doing some good. Now you all can talk to everyone ;)
Just because it CAN be done, doesn't mean it should!
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.
"Old Rallydrivers never die - they just fail to book in on time"
[see subject]
Rate me on Picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
VNC is GPL'd, but why in gods name would you want to give people Userlevel, and on windows, root, access to your machine? And I think AIM has an ftp-like thing setup already.
Rate me on Picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
Aim.exe is only 24k, smaller then your average slashdot page, and would take less then a second download on any modem faster then 14.4k/sec
:)
(untill AOL increases the size of AIM.exe
Rate me on Picture-rate.com
"and dear god does this website suck now." -- CmdrTaco
Requesting the MD5 of random parts of aim.exe is somewhat clever (but probably unnecessary complex. They could have achieved the very same effect by simply asking 16 bytes of the exe file)
.exe files when the client is Internet Explorer ?
What I find much more subtle, is the fact that they just started requested it. The thing was burried in the exe, and they were waiting before using it. Reminds me of DirectTV <http://slashdot.org/articles/01/01/25/1343218. shtml>
Corporations are getting smart. If AOL had always requested the MD5, then competitive clients could not have been developed, and they would have run the risk of getting an open-source competitor.
I find quite scary to see that closed-source software contains such hidden protocol tricks. Who knows what more is contained in the various exe people runs daily ? What's going to happen if IIS start requesting random MD5 of
Cheers,
--fred
1 reply beneath your current threshold.
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)
1 reply beneath your current threshold.
...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.
NO CARRIER
The FCC is carefully monitoring what AOL Time Warner is doing, and one of those areas is IM. Yes, this is a step backward from opening up the protocol and standard and allowing everyone on the net to talk to each other like one big happy family (instead of kicking out gaim and msn users). I have some degree of hope that the FCC will jump on this as just being pretty mean to the development of a unified messaging system for the internet (which, some envision, will become about as popular as today's e-mail).
Until then, yes, TOC works. Granted, it may not have as many nice features as OSCAR, but it is adequate for 95% of IM uses. Want file transfer? Use an ICQ clone. Then again, I can see AOL Time Warner messing around a lot with their pretty ICQ service too, but there's only so much we can do.
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
> AOL is right on this one. Sorry.
This isn't really about the servers or the software or the cutesy HTML-drenched messages we can send back and forth. This is about AOL's approach to the internet, and the scary fact that it does (and will continue to) succeed.
How does it work? It's very simple. AOL's user base (paying user base, the one they actually give half a damn about) is made up of mostly clueless users who wouldn't know an IM from an e-mail. Joe Blow internet user doesn't know or care how his messages get through, or what freedom fighter groups his beloved provider is pushing out of the way to make it happen.
AOL's community is far from 3l337, so they have nothing to fear when it comes to bad publicity about this. Does little ol' granny know or care that AIM is now restricted to people using specific clients? Nope. Does she care? Nope. And the people at AOL know it. Nobody they care about is affected by this.
Don't get me wrong. I'm as infuriated by these actions as anyone, and I think the big-shot CEOs who make these decisions should be hung. This is totally contrary to the idea of the internet. However, people are forgetting a very important fact that is along these lines: this IS the internet. We don't HAVE to use AIM. If we don't like something, we can build a better whatever-it-is.
In this case, I think Jabber is the way to go. Go out and give it a shot, and screw AOL. If you really need to talk to people from there, use e-mail or IRC or something. Support open standards if you don't like the closed ones, because honestly AOL will never suddenly support open protocols that it isn't forced to. Instead of swimming upstream and fighting their protocol changes, just ignore AOL and support a more worthy cause.
when I signed up for AIM I did so through the netscape web site. I never signed or agreed to use only AIM to connect with the service. The questions never even asked what platform I use. Since Linux is not a supported platform for AIM I have to use another client to connect to the service. Why should I be forced thereby to accept dowgraded versions of the service via TOC instead of Oscar? And if this is paid for by the advertising revenue. Does AOL charge these advertisers by the number of total users logged in even if some of those users cannot see the adverts in their clients?
oh yeah... :)
and the official AIM linux client is broken now too I do believe.
great luck huh?
at least toc still works, and the same trick won't work there. (tik is the legacy client that they won't (i hope) break support for- and it's open-source).
-skip
Given that it is now publicly known that the the response needed to get on the network is an MD5 sum, the next move likely would be to calculate the MD5 sum plus a "secret" unknownst to the free AOL client developers but known to them. This secret could be a piece of any file related to the main AIM distribution, an advertisement that your client recently downloaded, some piece of the program found in memory while running in a certain state, etc. Just have that secret added before, after, or somewhere in the middle of the string the MD5 sum is being calculated from, and you'll have major headaches working around that.
Sure you could query a system which ran the actual client and note the results, but then they would "taint" the RAM used so no two instant messangers looked the same. The calculation time needed to brute force a shared secret is enormous; the legal risks tapering with their EULA to reverse engineer it high. And given that AOL likely only gives one or two chances for the challenge/response sequence to proceed, this roadblock may keep alternative clients from using OSCAR for a long time.
MD5 sums with secrets is nothing new; look at your local /etc/shadow file (if you can). MD5-based password hashes (typically starting with "$1") support the concept of a "machine secret," although this typically is not used. All in all I've got to hand it to AOL; this is a brilliant move on their part, and one that makes it much harder to use their full-service protocol against their wishes on their network.
One could write a client that referenced AOL's in order to get online, but I would hate to see the legal mess they would get into.
This would avoid any future conflict with AOL, as well as clearing the conscience of those who are using the AIM system in an unauthorized manner.
AOL is right on this one. Sorry.
But now that decision has come back to haunt us. The AOL IM network is AOL's property and they can do with it what they want, including a check to make sure you're connecting with their client (with what's honestly a very clever trick for doing so).
But now we're in the same boat M$ was in, trying to connect our own client (and users) to AOL's system without AOL's expressed consent. (They haven't said we can't connect, we just have to do it their way.)
So who wants to be first to call M$ and try to get their help on this one? Your enemy's enemy is your friend.
Back in the day, some third-party developers made a Sega Genesis game. They did it without official support from Sega. At sometime (early I presume) in the process, they found out that games would not load up if some of the first four bytes were not SEGA.
Sega, who naturally had planned to attack any unsupported developers by including this "feature" in their system, filed a lawsuit against the developers on a trademark infringement.
The defence was very clever (quite similar to the previous discussion on exchanging our favorite long integers). The key to initializing the system was to feed the Genesis ASCII characters 83 69 71 65. This sequence booted up the system and from there everything worked normally.
The defence won the case and were able to proceed at long last. I do wonder if this line of defence would work for including aim.exe (or some broken-up representation therof) in the current political climate, or if the systems been damaged beyond easy repair recently.
It's not like the Server is getting the MD5Sum of the client itself... It sends a request for an MD5Sum and AIM sends it. All libfaim needs to do is recognize the MD5 handshake and send back the MD5Sum for a valid AIM client. I can guarantee it's perfectly legal to include the MD5Sum of a commercial program in libfaim.
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..
I suspect that what AOL really ought to do is "certify" certain open-source clients. Then make sure that all of the "certified" open source clients have ad banners, just like the real AIM.
;)
;)
And they could even use that to give the shaft to Micro$oft.
Of course, that's blue-sky dreaming. And everybody else has suggested the appropriate workaround -- make your users keep AIM.EXE in a specific location and/or query the server.. God I love machines that are owned by the user and can be tampered with!
Gentoo Sucks
So is AOL wrong for disallowing other clients from taking revenue away from them (AOL) if so please give me one good factual based reason on:
How doesn't this take away from AOL's pockets, when your using their resources (bandwidth, tech support dollars when servers go bonkers from overloads, etc.)?
What was this "insight" and work around that led you to again... use their (AOL's) resources?
You seem to be missing my points in my posts, and fuck no I'm not for AOL in any shape form or fashion, the facts remain, AOL has to pay for your clients, when they shouldn't.
Stupid News
360 degrees of Karma
Your not the first developers to face this dilemna
,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.
Wireless News Factor
C|NET
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
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.
360 degrees of Karma
I believe their traditional response has been "yes, but we offer an 'open' protocol for those clients to use." Unfortunately, they have also been making changes in that protocol-- most recently, they seem to have changed the required port for connections.
This obviously breaks all existing clients, and while they can generally be quickly fixed and rebuilt, it pretty much wipes out the possibility of competitors writing reliable clients for AIM, unless their customers/users get used to downloading a new version every couple of months.
(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
I know I have used an icq logon server to connect with naim and aol im before when aol's oscar was down....
I also know that naim version naim-0.10.1 (which has been around for a while) still has no probs logging on to the service.
Caino
Don't touch my .sig there!
I don't understand. Why use the AOL servers at all. Why not boycott them and make our own protocol?
"Don't use aim. Who wants to talk to a bunch of aolers anyways?"
The problem is that AOL, with the acquisition of Mirabilis, now controls the majority of Internet messaging. Any singe entity that controls that much of _anything_ could easily leverage their control illegally. So this is less of an issue of a small application but an issue of enormous corporate power.
Situation is the following:
AOL client must send back a derivative of itself. So it's impossible to send back a proper response if you have not a legal copy of AOL client.
Now let us imagine the following:
Let us create an open-source message protocol having no central server (As Gnutella does). And let us create a lot of gate servers located somewhere outside the US jurisdiction that interfaces the AOL world and the world of our protocol. There the gate may contain the valid *.exe file and produce valid responses. Of course, the gate should behave exactly like the official client or traditional proxy server (I am more than sure than AOL can work via proxy since it will othervise lose the unreasonably big number of Intranet clients) and so be untraceable from the AOL side.
Since the servers know each other they can request the valid response from their neighbours and so it's impossible to prove that any given server contains a *.exe file, so the violation of *.exe copyright restriction is unprovable from the new protocol side.
In the best case the new protocol will soon replace the AOL one and sent it to oblivion, and in the worst case the clients will at least internetwork with AOL reasonably unpunishably.
(IANAL) AOL can object to gate servers that are unreachable but not to authors of gate and client since they don't include *.exe to their distributions.
And BTW: You can include in your protocol everything you like, including the much higher security and the other useful features.
The injustice is not that UN*X clients talk to their servers and use up their bandwidth, the injustice is that AOL succeeded at inserting itself into what should have been an open part of the Internet infrastructure in the first place.
I quite agree: people shouldn't use AIM, not out of respect for AOL's bandwidth, but because AIM is a bad idea to begin with. Develop something new and better that uses entirely open protocols and fits in with the existing infrastructure; you can build on IRC or http or Gnutella or any number of other protocols and existing systems. Stop copying commercial Windows hacks and start using your imagination.
I think on balance, AOL has not even begun to pay their debt to the Internet; in fact, they probably still are imposing more costs on non-AOL users than they are paying. So, don't talk about "stealing" when people are trying to interoperate with their proprietary infrastructure.
But in the end, we agree: don't use AOL's services.