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?"
...intercept the checksum request and return the expected value that would correspond with the appropriate version?
Can't we all just get along?
I suggest that everyone moves to an open standard, like Jabber. Or even better, talk, ytalk, or zephyrs. Seriously.
Who the fuck needs more than one goddamn datagram communication format? Especially when the TWO most popular ones are both owned by fucking *AOL*.
It can be performed at somewhere between 20 and 40 megabytes per second on 16 byte strings (8 byte strings is 8 meg a second on my piii 500 64 byte strings is 40 meg a second. 16 should be somewhere in the middle). This is *way* fast enough to stream out to clients. You can also cache the replies, since I really doubt AOL is going to start requesting random portions. This would require their servers perform an MD5 on every client connection, since they couldn't cache the results (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?). It's easily as expensive for them to do this as it is for you to set up a web server to do the same thing. So it doesn't make sense to do it. Likely they'll just use portions of the executable that don't change from version to version, and pick maybe 100, or 1000 md5 checksums they'll ask for (something easily cached in 16k of memory), at worst, in a given day. I sincerely doubt they will do random checks. I can't even compute the number of possibilities, it's too large, but it's simply not feasible for them to request random strings every connection, because of the compute power *they* would require as well. This is likely why they change it every day, once a day. Thus, you could have a little server with a nice net connection that connected a few times a day just to see what the "password of the day was", calculated it and streamed it out to clients. I whipped up a python script to do this in about 35 seconds. Surely you could do the same.
Welcome to Slashdot. Anything informative, insightful, interesting or funny is modded down, while anything redundant, trolling or just plain stupid is modded up. The good news is that most worth talking to read at -1.
I agree. You should demand a 100% refund of your money.
What are forgetting however is that it does not take the md5 sum of the entire client.( it actually doesnt use the .exe file at all, it takes the md5 sum of a SPACE IN MEMORY that the client takes up (by dereferencing a pointer) ) So when AIM sends the initial request, it actually asks for a certain place within the .exe to another spot in the .exe, which is not the same every time, even if its the same version. So the server would really HAVE to have the .exe of every AIM just to deal with this.
-thatmoron
That's assuming that someone hasn't written a fake AIM client to spamvertise in IM etc....
"You know you want me baby!" - Crow T Robot
Oh, OK, I thought I'd seen something more complicated than that. Never mind.
And as you yourself point out, the TOC protocol is a completely-legit way to access the service without ads.
AOL allows TOC clients without ads. They're just pissed off about OSCAR clients.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Sadly, there are not only fake AIM clients that spam, there are also VB scripts that interface with the official Windows AIM client and spam.
--
$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;
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.
You could even package a script with libfaim that goes out and downloads AIM.EXE from wherever AOL makes it available to the general public. Then you reduce the burden on the user, and you reduce the likelihood of people providing differing versions of AIM.EXE.
4.) add support for a server that you request bytes of aim.exe from
Don't send the bytes. That's probably illegal. Send the hash. The server could hash the entire AIM binary several times per second. Plus, you can cache whatever AOL is asking for this week, which eliminates nearly all of the hashing load.
The real problems with that are the network bandwidth you'd have to provide and the potential privacy issues involved in having every libfaim-linked binary "phone home" to your server.
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.
There is no guarantee that TOC will remain the same either - other companies who have interfaced over TOC before have been blocked (Tribal Voice). It also has *lost* features over the last year or so, and has bad uptime compared to the OSCAR farm.
Well, they actually did release a (beta-quality) AIM client, based on Gtk+, some time back. (I'm not an AIM user, so I just know what I've heard.) From what I heard, many people weren't pleased with its quality, and its lack of features, so it's not been particularly well received.
But I agree - it's not like they're charging money for it. So someone else writes a client that uses your service - big deal, they're not trying to turn a profit by doing it. They just want to write a good client.
But that's Corporate America for you - it's all about control with them, even if it seems pointless. (Like the RIAA and the MPAA.)
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Well, considering the AIM package is freely downloadable, I don't know how big an issue that'd be anyway. So you have the binary image? You can get that any old time you want.
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
Yes, except for the fact that (practically) the server could ask for a hash of pretty much any length section of the file. That creates an exponentially-large set of hashes to generate. I can see doing some kind of caching, but prehashing everything would be very expensive space-wise. (As in, probably bigger than any available disk.)
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
No, there was a more recently released binary client based on Gtk+. The Tik Tcl/Tk client came earlier. Also, from several reports I've heard, AOL's working on pretty much repealing support for the TOC protocol - so if you can't speak OSCAR, at some point you may not be able to talk on AIM without an "official" client at all.
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
You misunderstand their intentions. It's not about the usefulness of their service - they're not interested in being humanitarians. It's about control - they control their servers, and you don't. They want to keep it that way, by denying "unapproved" clients. Just like the MPAA, RIAA, and Microsoft.
_____
Sam: "That was needlessly cryptic."
Max: "I'd be peeing my pants if I wore any!"
I'm not totally sure I understand what you're saying for #3, but I think it's what I was thinking, which is that you basically do it like DivX for Mac(not sure if the PC version works this way):
the first time you open it, it asks you to find your copy of WiMP 6.3. When you do, it can use WiMP for the MPEG-4 decoding. It would be illegal for them to ship with WiMP included in their client, but there's nothing illegal about asking a user to find their own copy.
Same situation Mac users are facing with theme updates to OS X: you distribute a theme that takes the original Aqua theme and modifies some of the resources, and Apple legal will be all over your ass. But if you made a script which modified the user's own file, there would be no problem, as you would not be infringing on Apple's copyright(no Apple code in your script)
I'm not sure I understand what you say the problem with doing this is. It seems other developers have used essentially the same idea in different situations.
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.
My point is that free clients increase the value of their service at a small cost to themselves. Too many companies, it seems, are more interested in control rather than service. Tight control doesn't always lead to higher profits or longer life.
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.
Fire.app for MacOS X supports jabber, icq, msn, yahoo & even irc. It supports AIM but now that is getting blocked by AOL.
Good job making AOL keep it's protocol open!
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
I think he meant that you would have dedicated GAIM MD5 servers which the GAIM client could connect to when asked for the checksum. Using round-robin DNS to load balance them and centrally manage the cluster as servers came and went. As someone was willing to have a Windows PC on a fast connection doing nothing other than checksum serving (assuming you guys can create the server) then it could be possible.
Fully open ... like... oh, say, Jabber?
DNA just wants to be free...
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...
I'm using a version of caim I've hacked up myself, and its based on libfaim, and it works fine. albiet its probably based on an older version of libfaim.
This is what I'm guessing is going on, when you give a "newer version #", it requests the md5sum data, but when you give an older version # (like my libfaim), it doesn't. The question is, will the new functionality still work if you identify yourself with an older version #. My guess is no (based on the windows client which tells me what functionality each user has, and probably doesn't even try to do something if it thinks it cant). Otherwise, a simple solution would be reverting the version # to an older version. too bad it probably wouldn't work.
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.
---
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.
You wouldn't need that much space. Just calculate another md5 checksum starting at each byte position. So if the program is 1 MB, you'd need 32 MB of checksum data. That's a little more reasonable... it doesn't seem any more legal, though.
I always mod up spelling trolls.
That is EXACTLY what the person you replied to said.
moron.
Search first, ask questions later.
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.)--
i proposed this idea to the lead gaim developer some hours ago..
We'll see what happens!
-- Thrakkerzog
If you pre-hash the entire aim.exe, it would reduce the load quite a bit. It would take a lot of disk space, but would help reduce server load.
-- Thrakkerzog
oops, I did not know that the length was an option for the hash. :-(
Even so, you could get away with not hashing a lot of the possibilities, as they could not afford to receive values over a certain size.
Anyway, quite a predicament..
-- Thrakkerzog
Hmm..
:-)
modem users could still use toc..
What if the md5 server cached hashing values? At the moment, doesn't the IM server request a different hash each day? Until they made it request a different hash each time, load would not be that bad...
Still, I guess it is a pipe dream.
-- Thrakkerzog
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
Good point. That'll never fly. Gotta run - time for my weekly apt-get update;apt-get upgrade.
Does it use TOC or OSCAR?
Isn't this what Microsoft is in trouble for doing? Non-price predation I beleive it's called (not that I'm a lawyer, but I do read Slashdot :-) ).
Read more in Dr. Dobb's Journal. It's great.
Looks like AOL, once again, takes the road to a brick wall. They're not going to get anymore people using their IM client by locking people out. On another thought. How about finding a prime that when converted creates an exact duplicate of the AIM executable. Just like that DECSS prime that was mentioned earlier. Surely this would be legal?
When shit hits the fan get some of these https://youtu.be/pY-GncsZ-UE
I could care less if AOL made OSCAR a spec that would help clones to mimic its functionality, or not.
I think I will never use AIM, for the simple reason that it is yet another way for people to get ahold of me. I have a cell phone, need to get my attention - call me. If not - send e-mail. Too slow? Well those are the two ways you can reliably get my attention. AIM for me will be like ICQ. Something somebody ordered me to install but something I never use.
Alex
Wealth is the product of man's capacity to think. -Ayn Rand
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!
I have read some people say that this will stop Oscar usage in linux without hacks, this is not totally true. Aol DOES make an official Linux client (GTK) which does use Oscar. Unfortunately this is only available for x86 and its list of features is a fraction of what is implimented in GAIM with the Toc protocol.
The funny thing is that I have heard people say that they think this move may be due to advertisements; However, the official linux client using Oscar does NOT have advertisements. The truth of the matter is that AIM realizes the potential for Jabber, this is just an outcry from AOL to Jabber saying, "We will not let you win, don't even try".
Should Linux users be worried about this? YES! The simple fact that they are not worried about advertisements makes this a war *directly* against and only against unofficial (and open) clients. AOL has offically declared war on Jabber, and we are experiencing the side effects of this. How long before AOL realizes that they could turn off TOC services?
I have a girlfriend who is currently overseas, without AIM our relationship would be either much more difficult or non-existant; As I often talk to her with my ppcLinux machine, the official client has no chance of running here.. i need my open source AIM.
Checkout Jabber at Jabber.org and Jabber.com
This protocol is what AIM is trying to fight.. There aren't many users, but the protocol is great. All messages and transports use XML, it decentralized to an extent. The decentralization is caused by the use of email-like addresses, for instance: I am ewindisc@jabber.org. It even uses MX records!
Jabber is great, but the transports break often and it doesn't have enough of a userbase to be useful alone.
Although it is very likely that the Java client uses the TOC protocol, if it DOES use the Oscar protocol then it most likely has some other data that it uses for a checksum.
This other data could be the actual class file, which is possible via java's ClassLoader... or it could be a fixed array. If it is a fixed array, you can bet it is a small one; This could be easily integrated into an unofficial client. Of course, the problem with integrating such an array into an unofficial client is that it IS a java applet... AOL could replace the applet without worries of backwards compatability issues that uses another array.
I'm the author of BeAIM, a (rather out-of-date) AIM clone for BeOS. BeAIM doesn't seem to be having any problems logging in or staying connected, and AFAIK, it never has. Every time AOL has pulled a fast one and libfaim-based stuff stopped working, BeAIM seemed to work fine.
:-)
I don't mean to disrespect the libfaim coders at *all*... BeAIM wouldn't exist without their work (it's not based on libfaim, but many ideas and techniques were borrowed, and I spent many hours with mid's OSCAR docs!) But why is my code still working fine when nobody else's is? BeAIM doesn't do anything tricky. It uses OSCAR, it doesn't try to pretend it's a Windows client (it actually reports itself to the BOS server as "BeAIM") and I'm certainly not doing anything with MD5 or AIM.exe.
I haven't researched this much... hopefully sometime today I'm going to try and figure out if BeAIM is actually receiving the mysterious 0001/0001f packets. But as of right now, I'm terribly confused about all this.
I can only come up w/ a few scenarios as to why this is happening...
1. This is all a mistake. The 16 bytes in question aren't an MD5 sum of AIM.exe and the libfaim folks are wrong.
Somehow I doubt this; again, I haven't researched much, but they seem to be fairly sure this is the case and I'm inclined to take their word for it.
2. BeAIM is just amazingly well coded.
Ummm.... no. Trust me.
3. Somebody inside AOL really likes BeAIM, and so BeAIM is not being blocked.
This is possible, I guess, especially since there's a tiny number of BeAIM users (all things considered). But, I kind of doubt it. I'm guessing it would take a fair bit of work on AOL's part for this to happen, with no benefit at all to them.
4. AOL is specifically targeting libfaim.
This almost makes the most sense; after all, the last time I checked, the two major users of libfaim-based code were GAIM and Jabber transports, which are probably also some of the biggest non-official bits of software that access AIM. If they wanted to take a good swipe at all the non-official AIM users this would be a nice way to do it. If this is the case, I'd like to know what methods they're using to identify libfaim-based clients... and if they can do that, then why bother with the MD5 bit in the first place?
Conspiracy theories aside, here's another possibility... perhaps the packets requesting the MD5 chunks are only sent if certain *other* conditions are met. I doubt that the MD5 thing has been supported since AIM 1.0, and they wouldn't want to be booting older official clients off, and somehow BeAIM qualifies as an "older" client. Then again, last I checked, really old clients simply aren't allowed to login.
Anyway, I'm fairly confused by all this but now it's got me interested...
Slarty
Hi... I'm Larry... the shivering chipmunk... brrrrr!... I'm cold... I need a sweater...
Randomly selecting portions of the binary for checksum are not going to be too difficult for aol to do, so any solution should probably point to an instance of the aim binary at some predetermined location in the aim clone tree. (What we really need is some nullsoft peeps to smack these aim developers around a bit.)
/usr/local/share/gaim/aim.exe? Then any transform that can be gleaned from aim should be easily applicable to gaim.
It may make sense to have clients install the aim binary seperately into a pretermined location of the source tree.
This is crappy of aol, but the PIA factor from the aim folks isn't nearly high enough to stop the competing products.
--Adrian
The malapropism police say that you need an odd kind of toe truck to tow the party line.
pooptruck
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 don't get it. I just downlaoded the "official, fully functional AIM client" from AOL. Well, not only is it not fully functional, but there is no ad banner on it. So why do they want me to use THERE client?
Ambition is a poor excuse for not having enough sense to be lazy.
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.
Why not move your mom to an open source client of your choosing.
AIM uses the AOL servers, why not let them decide who gets to connect ?
- sigs are for wimps.
Stop modding down my comments on this.
I'm all for "chat" clients that interoperate with each other, but I also think AOL should do whatever they want with their network/resources.
Why the hell are my comments being censored in this way ?!?!?
- sigs are for wimps.
I fail to see how this chat client is a monopoly.
This is so far away from a telephone, the web, or an Operating System. Everybody can write an AIM like service and host it.
So what, should Quake 3 have to allow for home grown Quake servers to connect so people can cheat ? Does Quake have a monopoly on online multiplayer FPS games ?
- sigs are for wimps.
All good points, but the fact remains, AIM uses AOL resources and their technology.
I don't see why they don't have a right to just do as they please with their service.
Again, can Id prohibit "fake" Quake clients, or should everybody be allowed to do their own Quake clients ?
- sigs are for wimps.
Quake has several mechanisms to spot fake clients and cheaters.
The anology might not be the best, since in the case of AIM, you are using their servers, which is even more objectionable without their permission.
They made their protocol, they provide the servers, they want their clients and the ones they approve to work and others not.. What's the problem with that ?
- sigs are for wimps.
I rather post a "stupid comment" with a point, than the waste of bandwith you call a reply. *sigh*
- sigs are for wimps.
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.
Why is it everyone is obsessed with reverse-engineering OSCAR? Perhaps I'm missing something, but what advantages does it have over TOC? I can talk, I can transfer files, I can do group chats, all the features one would use in AIM.
I can do everything I want to do with gaim's TOC implementation - projects based on libfaim, like naim and the god-awful jabber server transport break constantly, especially the latter. I wish folks would stick to what works.
As for the md5 checking, install AIM on a windows box, tar it up, and move it over. Place it somewhere on your unix box so that when a request comes over OSCAR it can use it. Admittedly, I haven't looked extensively at the problem, but I don't see why anyone would need to do it anyhow.
-lx
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.
---
Why don't you just use TOC for the Jabber plugin? (Just an innocent question from someone who doesn't know what features TOC is missing :-).
I'd rather that the AIM transport worked all of the time than having to keep up with the AOL vs. the world wars.
Hexy - a strategy game for iPhone/iPod Touch
Actually, GAIM sucks. Why? Because it's nothing but a huge memory leak. I would be using it myself, if it weren't for that fact. On one hand, you could argue that it could be run from a machine with gobs of RAM and X-forwarded to the machine you want to chat with. However, it leaks into the X server's memory, so that won't help. I've been looking for a decent AIM client for a while, and my current solution is to run AOL's Linux client on my FreeBSD server and X-forward it to my SPARCstation 5 (machine I chat from). It's a shame, but getting any AIM/ICQ clients to build on non-Linux is damn near impossible. (Tik works because it's Tcl/tk, but is also damn slow and sluggish)
Nah, it's not 1:1, even in theory. The digest that is produced is only 128-bit, while the number of possible inputs is infinite. For example, if you did a MD5sum of each of the books in the Library of Congress, it's entirely possible that one or more of them would be exactly equal to the MD5sum of this here little post. What is supposedly computationally infeasible would be for me to give you a 128-bit message digest and then tell you to come up with an input which will produce the exact same digest. Likewise if I told you to come up with two different inputs that would produce the same message digest.
An example of why MD5 is useful is that I can take the MD5sum of a file, post the message digest somewhere like a website where someone else can't alter it, then freely distribute the original file. If you decide to use the file, no matter from what shady site you downloaded it, you can produce your own MD5 digest of it and make sure that it's equal to the one listed on my web site. If it's the same, you can feel safe that nobody's injected any malicious code into it, because it would supposedly be computationally infeasible for a hacker to alter the file in such a way so as to produce the same message digest as the one listed on my site.
Cheers,
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,
Of course, the real solution is to come up with a open system that's so good that all the AOLers switch to that, and then invite AOL to shove its stupid little power games right up its (deleted)
I don't care if it's 90,000 hectares. That lake was not my doing.
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.
Excuse my ignorance, but what are the major advantages of OSCAR over the freely available protocol?
-- jar
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
Whoa. It's almost like that was their goal all along! Heavy.
__________________________________________________ ___
rooooar
What about 4. put aim.exe in freenet, and have build in a freenet client along with its identifier?
I think something you and maybe AOL has forgotten is that the value (utility) of a network increases geometrically with the number of nodes or users. Although the open source users may be adding to the load on AOL's servers and not supporting them directly through advertising, the added value of the AIM network to legitimite users is increasing their usage and exposure to AIM's advertisements. Assuming that open source users are only a small fraction of total users, and that they do not only communicate with other open source users, then AOL would benifit more from allowing them access to the OSCAR protocol. AOL supports internet email for these same reasons, despite the added cost of running email gateways. Why don't they realize that this applies to AIM as well?
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.
I think it's written in JavaScript and XUL. Maybe they send md5sums of a DLL or something?
according to this post there's a linux version. couldn't you just script it to download that version durring installation? extract it from the rpm then do checksums as needed?
so cache the most recent 1000 requests. aol's servers will have the same processing overhead to find the md5 checksums so there will probably be a small number of checksums durring a day.
This compatibilty array has got to be the best idea I've read all night.
Fire talks AIM, ICQ, Yahoo, Jabber and MSN.
http://slashdot.org/comments.pl?sid=01/03/22/23482 44&cid=181
a) Fully open IM system? Jabber.
b) Why hasn't Jabber taken over, then? Because most of the free world uses AIM. You want to try to convice 70 million AIM users to switch to a service where none of their friends are, and for which there isn't even a decently usable Win32 client?
Remember when you had to buy an AT&T phone in order to talk to AT&T customers? Same deal here.
Can anyone point me to a good article on telephone system interoperability? You know, how you used to have to buy an AT&T phone to talk to other AT&T customers...
If I could only find such an article, and post it as a reply to every single "well just use AOL's client, you ungrateful bastards" post...
Because it's just those "clueless AOL minions" that many of us need to keep in contact with! Surprisingly, many of us geeks have non-geek friends and family members who use AOL/AIM and will/can not be convinced to switch to the IM flavor of the month-- all their contacts speak AIM, too! I have no choice when it comes to IM-- use AOL, or don't talk to anyone.
It's just like the days when you had to buy/rent a Bell telephone in order to talk to Bell customers! It's called a monopoly, and the FTC/FCC ruled is as such. Another example is with cable networks (AOL/TW vs. Disney, IIRC).
I'll tell you what-- when you convince everyone I know, and everyone they know, and everyone they know (remember Gnutella's scalability problem?) to switch to Jabber/MSN/Yahoo/whatever, I'll switch too and quit my whining. Okay?
Sheesh.
There is already an "Open" standard in development by the IMPP working group at IETF.
;-)).
And whats more if you look at the authors on the drafts then you will clearly seem Microsoft listed.
I know a lot of people here like to bash Microsoft of keeping stuff to themselves but with IM they are playing the game (or should that be GAIM
Back in the late 80's, Compuserve and AOL both discovered this vast area called the Internet, and their users clamored to be able to email their friends at school and work from those services. What did they do? They used the standard mail protocol, SMTP, and began using the resources of schools, offices, government, the military, etc.
Did UCLA ban AOL traffic since it cost UCLA money -- and thus me since I live in California and UCLA is a public institution funded by my tax dollars? No. Everyone said, "Welcome to the party; use our servers; talk with us."
Instant messaging, while more server-processing intensive, in my view is just like email. It's a form of communicating with the world. Messages, files, speech, et al. These are all the same; they should be public infrastructure.
They claim that using their servers 1) costs them money in support and resources and 2) costs them in lost eyeballs for advertising. Instead, they should work with the IETF, Jabber, everyone to turn IM into an Internet standard so the servers could be distributed just as email servers are.
This may seem idealistic, based on the good of the public, even *gasp* un-American ... But fsck it's just the right thing to do!
Peace, PatientZero
Freedom to fear. Freedom from thought. Freedom to kill.
I guess the War on Terror really is about freedom!
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.
How about including an array of values that when x-ored produce the same MD5 sums as aim.exe.
I would have thought you can do this for compatibility reasons.
To produce this array, xor the aim.exe original, turning it from a program into a compatibility data array
-- Don't believe everything you read, hear or think
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.
I think that option 4 can be construed as a copyright violation.
If a server can MD5-sum any portion of the aim.exe file upon request, I could easily request MD5-sums of every single byte and reconstruct the original aim.exe image.
The fact that it is freely downloadable doesn't necessarily mean is freely distributable.
If it is freely distributable then you don't have to bother having the MD5 server in the first place.
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---
I seem to be able to log into AIM using oscar and Gaim... is it possible there is a AIM server or 2 that's not been updated?
Calmacil
I can't seem to face up to the facts, I'm tense and nervous and I can't relax... --Talking Heads
Windows executables have a version block as well. Right click, choose properties and if it's well written, there it is.
Do you have the peice of paper that says that opening AIM was a condition of the merger?
No, really, do you? I'm genuinely interested to see it.
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?
Dang it, TNT was just about the coolest thing around. It was an AIM client, supported by AOL, if I recall correctly, that was written in elisp. It meant that I could IM my friends from any box that had, or could telnet to, a *NIX prompt. I used to use it to keep in touch with my online friends during school breaks at home when all I had was a 10-year-old 8088 with a 9600 baud modem to keep me company.
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?
Troll somewhere else Ernest.
Execute? [Y/N] _
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
You can use the 'what' command on digital unix to find out cvs versions of files if the author put a #pragma line in... is something like this supported under gcc/linux?
And a one line sed file strips it out anyway.
That's the problem with open source.
Xix.
"Everything is adjustable, provided you have the right tools"
I know that there isn't a ton of money in advertising, but I think that is why they do not want unauthorized clients connecting to their service. From what I remember there were banner ads on the Win client, but I could be mistaken. I still really don't understand why they are try that hard though, ther more people that can communicate on their servers the more people's friends (who don't use linux) will use AOL/AIM. I really do think that people should really start using jabber. Who know mabye AOL would have to include jabber support if it were popular enough.
1) you can already bypass the ads with aim.
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.
there's no theft of ad revenue, and aol is breaking thier promise.
"IM is not a new market.
... (circa 197x :-)
Am I the only one who's been doing IM since Powwow came out?"
Ha! Newbie!
how about #CP MSG userid
A.
...bringing you cynical quips since 1998
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.
What version of Gaim did you try? I've used the 0.11.0 prereleases and, more recently, the CVS copy. I haven't had any problems with Gaim leaking memory. If I remember correctly, the memory leaks in Gaim were fixed before 0.11.0 prereleases started coming out.
----
"Here to discuss how the AOL merger will affect consumers is the CEO of AOL."
grep -ri 'should work'
It's not a bad idea, but there are a couple of implementation problems. First, it's GPL, so I can just get my copy and delete all the ad banner code, right? Second, if they are going to use the md5sum authentication method, they'll have to certify every release, including nightly cvs builds. That's totally doable, but it'd require someone doing a real part-time job of it, especially if they were going to allow clients other than Gaim.
----
"Here to discuss how the AOL merger will affect consumers is the CEO of AOL."
grep -ri 'should work'
Hell yes.. the only way people are going to gain ground on an open standards IM is to make it better, more convenient, etc.. than any other IM. This can be done. Relying on proprietary transports is not a long term answer.
JOhn
Campaign for Liberty
If they want to talk to you, they will switch.
I'm using the official Linux AIM client right now and it is working just fine. They a Linux client and a Java client, so most users should be able to run an official AOL client.
Why? I use AIM because the people I am interested in talking to use AOL Instant Messenger in Windows. I'm not using it because of a love of AOL's software. If others would use something like Jabber I'd be thrilled, but that isn't going to happen anytime soon.
treke
Fame is a vapor; popularity an accident; the only earthly certainty is oblivion.
Interestingly, this linux client doesn't appear (from the screenshots) to carry ads.
Tik uses the TOC protocol, which is unaffected. The protocol which is being blocked is Oscar, which has more features such as file transfer. You can still use GAIM with the TOC protocol and connect.
--
Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.
Win dain a lotica, en vai tu ri silota
The client was called TiK and was based on TclTk, not Gtk+. It was rather well recieved because it was open source (as TclTk necessarily is), had no ads, and could be extended with numerous plugins. However, AOL one day just deleted the web site for TiK. Some TiK users still held on but by then GAIM was offering support for the OSCAR protocol, which is what the official client uses, rather than the TOC protocol which TiK uses.
The TOC protocol still works without authentication now, by the way. However, you can't do things like file transfers with TOC.
--
Obfuscated e-mail addresses won't stop sadistic 12-year-old ACs.
Win dain a lotica, en vai tu ri silota
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.
All this talk about AOL having a monopoly on a FREE service. You people make me laugh.
The only problem with this is, you have to have a very specific version of the winaim binary. You can't have 4.3.2229 (which is currently the only one I can find on AOL's webpage). You must have 3.5.1670. If you do not have that version it will not work.
-----
"A man is judged by his every word." -RW Emerson
"They misunderestimated me." -GW Bush
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
As such, I would strongly suggest that if Jabber and company offer to display AOL ads. I mean, I honestly think it's only fair since you're using their bandwidth, their server power, and their support staff. It really is pretty much a free ride right now...
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))"
If the big concern is wanting to talk with all your friends using AIM, why not create an new AIM away message in AIM that says something like
"I am switching from AIM to Jabber. See http://jabber.org/. My jabber id is ####."
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.)
[
As to not being able to figure out what version of aim.exe the user has, there's a simple solution: calculate the md5 digest of aim.exe (or any piece of the file that generates a unique digest for each version) and distribute a lookup table that translates from md5 digest to AIM version. If you've already got the md5 infrastructure this should be a piece 'o cake.
;-)
Let the users figure out how to get aim.exe -- they're awfully good at things like that when they need to be. . .
-DA
> 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.
Why don't you arrange for Oscar to download the client for the user on
installation? It's only a few kB, after all.
Or any of their other clients for that matter.
The applet at http://www.aol.com/aim/aimexpress.html doesn't have a copy of aim.exe so how does it work. Actually somebody code easily decompile the classes and see what's going on.
Although I agree AOL probably needs to make up for some of the operating costs there must be a better way than through advertising. Since AOL might quite possibly become the defacto standard (since they own 2 major IM services now) it would suck if this happened and they forced the ads upon us. IM is becoming a major communication tool. Can you imagine whenever I picked up the phone I had to listen to an ad first. Bad analogy but the best one I could think of. Probably the best way would be to charge to have an account.
That's my point. Advertising is a poor way for AOL to support the cost of operating their servers. It shouldn't matter which client you use, be it open source or not.
When did I ever say phone service was free? You can charge for service, or give basic service for free and charge for extended services. I said it was a weak analogy, give me a freakin' break!
I was only trying to say that there are other ways to make money than from advertising. Paying for a service, or giving away basic service and paying extra for extended service is another way. Yes my analogy doesn't fit, no I wouldn't expect everything for free.
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
Most of the posts on this topic suggest setting up a server somewhere solely to md5sum a relatively small chunk of data. Essentially the same effect could be produced by adding an option to GAIM to specify a file on which to calculate checksum requests. The AOL version of AIM is a free download, so why not just get a copy, extract aim.exe, throw it in your GAIM folder, tell GAIM to checksum it, and be done with this? Why would anyone set up a server to do what each client can do on its own? Aim.exe is FREE. Hell, I'll give you a copy.
MrSndrs
This is fully within AOL to do.
Although, that being said, they are planning a release of a linux based AOL appliance. Which presumably will have an AIM clone running on linux.
Really, AIM is the protocol of AOL, it requires AOL servers to run, and their is no implicit permission to use their protocol on their servers if they are not your ISP. People might instead rally around an open messenging service like those offered by Yahoo!.
Nope, the latest version works just fine. I've been connected all day with the new version of Fire (0.23b) and haven't been booted yet...Yay for Fire.app and MacOS X...
"I like systems, their application excepted", George Sand (French)
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)
You can check a user's away message with AIM without messaging him/her. Just right click on the username and view the member info.
The problem is that AOL can't add anything to their client as a security feature. If a majority of the existing clients don't already have it, then it won't work. Just mimick the last version of the official client that didn't have the security feature.
My mistake. I didn't realize that this wasn't included in the TOC protocol.
- It's a much smaller download than Win32, and uses Oscar (thus probably implements the MD5 stuff).
- AOL makes it available via FTP, so you can just retrieve the part that is necessary for your MD5sum. (using FTP RETR) Very quick for small parts.
- You can save whatever you downloaded so that you don't have to redo the download later.
- the
.prc file (or some part of it) is probably what the checksum comes out of. Since it's uncompressed, there is less work to do.
I'm no lawyer, but if libfaim simply implements the downloading of the file, is that not analagous to linking to it? Isn't linking to a file or page legal?Is there a better platform than Palm to do this on?
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.
then how come the offical linux client does NOT have ads?
Perhaps someone could set up a http server that will return the md5sum for any given offset into the binary, eg:
t some offset >
http://www.aolmd5sum.net/getmd5sum.pl?offset=&l
That the binary is only on that server and is never distributed.
Thats just one idea...
I wonder why AOL is so concerned about the client - I thought they would be encouraging use of their system instead of M$'s IM or any other IM.
I fully understand that this is AOL's client and that they have the right to change it so no one else can use it. What I don't really understand is that AIM is free to any Windows user. They don't want to make a linux version which they also have the right to do, but it doesn't make sence to block out other ppl trying to get in. The service is free anyways. If anything they should fell honored that they have other ppl trying to use this free service. This kind of reminds me when I was like 3 or 4 years old and I wouldn't let anyone else play with my toys.
Laine Walker-Avina
"In
that wouldn't work with open source clients because you can just grab the source and remove the banner ads.\ =\=\=\
=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=\=
I may be a simpleton - if this is the case please ignore the following suggestion - do an XOR of each bit in the exe file - save the binary data as a bitmap or something (maybe even the splash screen just to have a good excuse to distribute it) - then when you want to do your checksum just xor the part you need to do the checksum on first?
--
This space left intentionally blank.
Ok, so GAIM is another aol contender... any news on Tik? ...I'm an ICQ person myself, just beginning to dabble in the world of AIM. I've used AOL's official java client tiktoc for soooo long that Tik is a wonderful alternative. How are these two players effected?
Use my userscript to add story images to Slashdot. There's no going back.
Why wouldn't they want to shut out potential users? How do you think they make their money? By making sure that the ad banners reach the eyeballs of the users. The non-AOL clones just use up AOL's resources while giving them absolutely zero benefit.
Once again, the /. community squawks because they can't get something for free.
--
I see you are insightful by the moderation, so whatever I say will probably be for naught, but I'm going to say it anyway. Not everyone with a brain in this world is a computer geek, or "lUSER". There are doctor's, lawyer's, nurse's, physicist's, and many other non-computer related specialists who look for easy to use programs and interfaces to communicate. AOL's interface is easy, intuitive, although a pain in the ass with the advertising. This is why, even though I run Linux for everything for games and AOL, that I still keep a dual boot system. Don't get me wrong, I love computers, programming, and hardware as well as the next person...but there is more to life than that.
Time is what keeps everything from happening all at once.
That would mean we need about 9 GB for every combination. 24 KB = 24576 bytes. Number of byte ranges possible = 24576 * (24576+1) / 2 = 302002176. Each md5 hash is 32 bytes long. So total storage space required = 302002176 * 32 bytes = 9 GB. This can be easily implemented. But if AOL changes even one byte of aim.exe, the whole 9 GB will have to be rebuilt.
Oops ... md5 hashes are 16 bytes long. So that would be only 4.5 GB of space.
Goes to show that there are technically skilled people on both sides of the fence. Probably they read slashdot too :)
In essence, it seems to me the problem is this:
Here's my solution:
Give AOL an alternative way to make money off AIM, removing their objection to open-source clients. Yes, I'm talking about...paying money to use AIM. I, and I think many other people, would not find it unreasonable to pay a modest fee to AOL in exchange for using their services in the way I want to use them. From everything I understand, ad revenue isn't that hot anyway as an income provider. I think AOL would be receptive to this idea.
I really think this is the only way to keep everyone happy. I, like you, want to use AIM any way I want. But I also understand that AOL wants money. Let's just give it to them in a way that lets us use open-source clients.
Please no. I use BeAim and its the greatest AIM clone ever. If they shut out clones I will be very pissed. mostly because theres no java in BeOS and this is my only way of getting on AIM. Grrrr. Please dont do it aol! If they do, they should just release clients for alllll OS's. Highly doubtful though... Beos forever!
------------------------------ SirPhreak - "It's Thinking..."
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 have a friend who has been using an OLD version of aim, never seemed to want to upgrade. Well, the other day, it wouldn't let him log in, so he had to upgrade..
I'm using WinAIM 2.1.1187 on one account and 3.0.1464 on my primary account, and I have no trouble holding a connection. So sue me.
Will I retire or break 10K?
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
By making their AIM client publicly available to non-AOL customers, they gained access to a larger userbase of people who would, in turn, spread it 'virally' as they convinced their friends, family, and associates to use it. AOL could then do a number of things:
-
Get increased revenue from selling banner ads, although the market has soured to this idea.
-
Develop value-added services and versions of the software they could then sell to other businesses, such as the AIM-based client 'SameTime' distributed by IBM/Lotus, or making AIM available through wireless devices such as cellular phones, handhelds, and the like.
By making the protocol specification for TOC available, AOL encouraged third-party development on systems too marginal ('uneconomic') for them to develop an instant-messaging client for, such as BeOS and AmigaOS.They did not intend for people (or companies) to develop clients for the Windows or Mac platforms, which probably explains why they removed the spec from their web site soon after Tribal Voice implemented the TOC protocol in their PowWow instant messaging client.
Regards,
Aryeh Goretsky
-- -
Dexter is a good dog.
Because some of us have friends who use Windows or Mac OS and are somewhat loyal to AIM because it is what their friends use. I'd like to see you try to get that many people (especially the Windows and Mac users) to use your protocol, abandoning AIM completely.
<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'
Assuming the AIM server can request a 128 bit MD5 digest from any byte offset within a 1MB executable (in reality, not all of the executable will be usable; since AIM is reading the in-memory image, any regions with dynamic fixups applied will be unsuitable), storing all the possible MD5 digests would require 16MB. That's a fair chunk of data.
To bypass the ads in Windows AIM, you comment out TWO LINES in a config file. That's hardly what I'd call "hacking the client." And as you yourself point out, the TOC protocol is a completely-legit way to access the service without ads.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
Since a person is already downloading GAIM or someother piece of software to use IM'ing, have the user get one more piece of software; just tell the user "hey, you need to install AOL IM on a windows machine and then copy aim.exe into this config directory".
Then there is a local copy and no central person for AOL to attack. Is this feasible then?
"Drug related crime" is a misnomer, "prohibition related crime" is the more accurate and correct phrase.
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!
I'll restate myself. Why should any maker of proprietry software do something that they dont wish to do with THEIR software, or their service? Is that not what is being required? Yes, this does indeed go against the mantra of freedom that I read so often here, but I will ask again - if they own it, why cant they be the ones to control what is done with it? Yes AOL is on of the great Satans out there and they do indeed suck, so why are people getting up in arms about what they do? Is that not one of the points of Open Source, to not be beholden to anyone in what is written and distributed?
"Old Rallydrivers never die - they just fail to book in on time"
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.
Can somebody please clue me in to why I am doing all right? I am using Tik and GAIM at the same time (tik monitors who is online and turns on LEDs on an led display I set up, and I use GAIM to actually talk to people). However they are both able to log in fine and I'm not having any troubles. Why is this? And is it likely that I will have trouble logging in at some point?
The Linux client from AOL uses TOC.
AIM. Big hairy deal.
Microsoft. A really BIG deal!
Now what happens when the Microsoft boys (who I'm sure are working on this as we speak) pull another stunt like they did with Kerberos. Except that this time they require checksums from word.exe to connect to a Win2000 server. Or anything else along that line.
You now require a copy of Win2000 on your client just to grab checksums from to satisfy some protocol's authentication procedure?
*shudder*
If you're a zombie and you know it, bite your friend!
That's too bad, and it's one thing I liked about Amiga software after AmigaOS 2.0 came out.
Each properly-written program for the Amiga included in its binary executable a plaintext ASCII string that told its version and optionally other information. How hard it it to put, at the start of your program's main module something like this:
That's all it was! The Amiga c:version command would read the filename given to it as an argument, find this string and print it out. Other programs could just as easily read the string to find out the version of what other programs it was dealing with.I haven't written a lot lately, but I can tell you that programming the Amiga was a learning experience not to forget.
to set up an AIM server that acts as a "proxy"?
I mean that it acts as a AIM client for the real AIM server and as a server for the AIM client. But that when the real AIM server asks for the aim.exe md sum it returns the correct one.
What I don't know is if the real AIM server would accept a lot of clients with the same IP address.
Rectifications are welcomed.
is the answer to all problems, great and small. While a dedicated server to calculate the MD5 checksums might be infeasible beacuse of load, a p2p solution could fit nicely. The AOL server asks you for the checksum, your client goes to, say, gnutella. Rather than serve up the entire aim.exe file, there would be a protocol that requests MD5 checksums for it.
My gaim client still works. Am I missing something here?
Remember that you are unique, just like everybody else.
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.
I just got OS X set up.. It's incredible. I downloaded Fire.app (AIM for OS X) and it works great.. then the other day, I got logged off. Repeatedly. :-(
The worst part is AIM from AOL won't be available for OS X for a few weeks yet. They block their own service on a platform they're not ready to support just yet!
I hear Apple and AOL have been working close together. Great. Whatever. But for now, I'll glady use pirate software. Fire is so much better than any AOL copy though.. Maybe they can learn?
Nahhh.
The next comment I write will be ready soon, but subscribers can beat the rush and see it early!
Embed the whole goddamn array of md5 checksums (compressed of course). That way you're not embedding the aim.exe image. And the aim.exe image can't be retreived from the md5 array, so no aim.exe copying problem. fuck em
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?
The Java version uses TOC I believe.
I just downloaded the AOL Linux AIM client to do a little research. Guess what. It uses login.oscar.aol.com on port 5190.
Guess what else, NO ADDS! Nope, I'm afraid AOL is just a jealous powermonger. Their client is junk compared to gaim and the others that are out there.
I think AOL needs a few lessons in playing nice with others. They're trying to be an all powerful juggernaut of internet connectivity, but they're pissing off all the people who are more than casual users of computers.
If AOL is going to make a Linux client with no adds that sucks, we should be able to make a better one.
I just downloaded the Linux AIM client from AOL's site. Guess what, NO ADDS! And yes, it uses oscar.
This means that we're going to have to find some other explanation for the recent security increase. They're not doing it because they want to make more money.
AOL is just being annoying to the open source community. I say we work as hard as possible to get around this. Let's show AOL that the open source community won't roll over for a power trip.
Everyone is talking about aim.exe (I'm assuming they mean windows). However, the linux AIM client seems to work fine. So whatever MD5 sums they request have to be consistent for both files, correct? I did not read the article yet, so perhaps this has been addressed.
there are no stupid questions, but there are a lot of inquisitive idiots
Well, lets take a good look at what is happening with the official clients. Nearly all of the folks that I have contact with online use AIM. So, I am forced to use at least something that can talk to their client. Whilst at my place of employment, I use the 'official' version of AIM. Funny thing though. I get booted off at random times (seemingly, that is). Here I am getting some info on a particular C++ class, and boom! I have to log back on... and then it takes a good half hour for the bloody thing to even connect. It disconnects as it is logging in, over and over, I am cast into the void. I have tried several different clients on this damnable service. I am ready to move on... but I can't get anyone to make the move with me.
hmm... :)
Using v. 1.1.112 of the official client for Linux (not the java client), it hangs on "Verifying username and password" for me. Which it didn't do a week ago. And gaim/toc can login with this username. Maybe I'm just having odd problems though
But the official Win32 client will run under wine, so if all else fails, that should keep working fine. (for those who need to read away messages, or for whatever other reason need OSCAR)
-skip
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
Clarification time:
you can't precalculate because there are too damn many permutations. AIM could ask for a single byte, or it could ask for all the bytes or it could ask for half the bytes. Although the message digest is fixed length, the message itself can be of ANY length. The number of possible combinations in a byte array (aim.exe here) of length n is (n^2)/2. Which consumes 8*n^2 bytes if you write all the hashes to disk. For the 24kb aim executable, this will require approximately 4.6Gb of storage. An average computer can calculate about 15 thousand MD5 hashes a second (my personal experience, actual studies may vary), which makes for at least a few days (3.54938 days, thank you Commander Data) work in calculating them. Actually this isnt so bad, except that AOL can update their client at will, which will render your previous work pretty much useless.
How about...
The problem with including the AIM.exe executable in the GAIM as a byte array is the obvious issue that aim.exe is a software product, as opposed to garbage data. If one were to ROT13 the file so that it was no longer an executable, would its inclusion be allowable under "reverse engineering for compatibility?" Of course, under linux, it isnt an executable anyway. Why would it be legal to include the data of aim.exe as "compatibility data" but not as a "peice of AIM?" What if you rename it? What if you split it in half? What if you tell AOL to fuck itself? So many unexplored possibilities. Or you could just use TOC, haha, silly idea.
because aol pissed us off, and they piss us off quite often.
this sig is funny. laugh.
-kaitos
The analogy just doesn't fit, I'm paying a fixed sum every month just to have a phone line that I can use. And I pay for every call depending on it's length.
I'm sure AOL won't mind switching from the ad based revenue model to a telcom revenue model for the IM access. But as usual you probably want it all free, free from ads and free from paying.
AOL doesn't like the clones because they use up AOL's resources, not because they don't show banner ads.
Hmm. I think SIM is trademarked by Maxis, or whoever releases SimCity now :)
If there's a Java AIM that still works, it's quite likely that it doesn't have any means to respond to the md5sum check, so how does it work ? Did anyone bother decompiling the Java client and figuring out how it does its magic ?
-Billco, Fnarg.com
even though i took computer programming sometimes you just want to do programs the easy way
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.
How about we just do an old fashioned slashdotting of aol.com? Sure, they probably have a farm of servers, and can handle this load. Sure they'll probably get paid for every hit by their ads. but it'll be great for getting our frustrations out! Come on everyone, click here!!!!
I care about having a fully functional AIM client. Until AOL makes thier linux client as good as GAIM I have no problem switching over even if it did have an annoying ad. I use GAIM because its more feature complete than "Offical AIM for Linux". I like having an aliased buddy list, highlighting misspelled words, fixing common mispsellings. Hell, no only does offical aim do none of that, but it doesn't even do real OSCAR featues such as direct IM and getting away messages. GAIM did all these to a degree. And to those who say 'screw the extra stuff' I have friends who are NOT technical. They send me things, or try to at least, through AIM, whether its some document to look at or a picture of thier new motorcycle. I don't like having to say 'sorry AOL likes to screw me there is no way I can see your pic through IM because AOL won't put a developer on AIM for Linux and they are screwing the open-source, radiply evolving projects, thus forcing me to use this incomplete software. I'd like to see AOL 1)Give me a functional client or 2)Cut GAIM some slack (i.e. give them permission to distribute a aim.exe binary to give Linux users a stopgap solution while they work on AIM for linux(it exists, but I consider it broken). Its not like AIM fo rlinux has ads right now anyway.)
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.
We just need to find an appropriate prime that contains the source to aim.exe. Not that I'm volunteering....
Kurdt
Kurdt
I'm not anti-social. Just pro-technology.
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.
Here is a solution.
That's all. The users are required to download a copy of AIM separately, but this is no problem. It's still free.
IANAL but I think that if embedding a copy of aim.exe is the only way to get interoperatively, then this solution perhaps it's legal. (Any lawyer in the audience?)
A better solution is to switch to an OpenSource IM standard
MOD THE CHILD UP!
Why it is illegal to ship aim.exe ?
IANAL, but I think if it is legal to create and use an AIM clone, then if the only way to do this is by shipping a copy of aim.exe file for chechsums purposes, then this should also be legal. We can argue "fair use" and "interoperatibility" arguments.
Else almost any network enable app can use this scheme to monopolize the market. (Napster, ICQ, MS-IIS, MS-IExplorer, MS-Exchange)
Any argument against this logic ?
MOD THE CHILD UP!
Also, you could allow people to mirror the results, and have a hierarchy of sites to provide the md5sum. The application itself should be able to cache the md5sum result too, which would be a huge win unless AOL are changing it randomly.
Probably you've already gone through these sorts of options.
Hell, you could even have a DNS server return the md5sum in response to a particular address lookup, and that would be cached nicely by the whole damn internet :-)
I think it'd be a good idea to go ahead and implement the "user-supplied aol.exe" solution anyways. Users can find version 3.5 -- we'll mirror it or trade it on music city if we have to.
-- juju
I just now d/led the official client (1.1.112) onto my Slackware machine and it seems to work fine. I haven't been booted off yet, although i've only been connected for about 10 minutes.
Does anyone know which protocol the official aim linux client uses? TOC or Oscar? Noone is online so I cannot test it!
-- juju
Yahoo! reports that AOL has just released AIM 4.5 Beta for Mac OS X. Someone needs to analyze this and see if it has windoze aim.exe built-in to handle the handshake business.
Why can't use just use wine with a win32 ver of aim?
[Just Shut Up and Do What I say]
Here is an article that carries the daily diary of some hackers. It's a very very interesting read.
There's always sufficient, but not always at the right place nor for the right folks.
Ennui
Ennui
"I walk in the air, between the rain, through myself an
Thats right, open everything up, just make sure that the banners are present. That should be all that AOL cares about right? We are using there servers, and they want to get paid, rightly so.
Infact I think something along these lines would increase how many people use aim, while increasing AOLs money.
Now I am not a fan of AIM at all. I love icq, but 1/2 of the reason I hate is is how it works(limited options). The other half is unique names.
The spirit of resistance to government is so valuable on certain occasions that I wish it to be always kept alive
Umm... maybe I'm retarded or something, but you can't check away messages without messaging someone in GAIM, can you? I mean, that has always been one of my major gripes with it. It definitely doesn't work if you do the equivalent of the Windows AIM's "Get Member Info" option. Ugh. Now I have to go through every menu option =(
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.
how can you say that? Can you show some test cases?
Fight censors!
"Not my manner of thinking but the manner of thinking of others has been the source of my unhappiness." - M
Apologies. I was a bit tired of all the whining going on, so I posted a bit hastily. What I do mean to say, that if you are going to say anything contrary to the conventional wisdom, you'd better be very careful about it. Augusto's posts did not seem very well thought out to me at that moment, but I conceed that my general irritation might have clouded my judgment.
Also, as a mitigating circumstance, I hope it is clear my anger was not directed at Augusto but at the poster whining about the moderation. Frankly, these things happen. I try to be as fair as possible, but moderation will occasionally go awry, that's the nature of the system.
Hope I made myself a little clearer now. (Note to self: take a deep breath before flying off the handle).
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?
I'm pretty sure that the linux version of AIM uses Oscar too. Couldn't you sniff and checksum that instead of aim.exe? Plus the linux version of aim is a heck of a lot easier to install in linux than the windows version of aim (using wine, perhaps?).
16 megs... You know bzip2 is pretty good compression! But that's besides the point.
What I'm envisioning is a place in AIM config that they can specify what MD5Sum they want to report to AOL, similar to Opera's feature of pretending to be Internet Explorer or Netscape just by changing the header info. This way the users could go to a web site when they can't login and copy/paste the MD5Sum for the week. Of course if AOL get's real defensive then the complete list might be needed.
How did I know I would be modded down as 'flamebait'
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.
but if gaim can find the win exe file could it find out what version it is? and if it can get the version why not get it when gaim loads and send that to the aim servers when it logs on.. so no matter what version of the aim.exe you have, gaim will report the proper version for the aim.exe it will be using to get the md5sums..
damnit! AOL sux! i've been using gaim for aslong as i've been using linux. i like to check peoples away messages with out messaging them. this is all aol's fault! why can't they play nice? GAIM rocks!
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..
Aol doesnt realease the source code, and the version they have only runs on certain Linux machines, but what about the other *nix's ......
just install aol, delete everything but the exe file. how hard can it be? as if you can't -FIND- AOL software?
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
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
Assumption: we need a 128 bit or 8 byte checksum.
The checksum file is a combination of absolut checksums 8 byte width for each 8byte block of aim.exe followed by 8 2byte checksums relative to the last absolut block. That would look like this:
Original (I don't have aim.exe handy, therefore this is fake data):
00 02 31 03 21 80 22 31 04 7A 03 64 1A 40 42 41 ...
checksum data:
00 00 00 00 00 00 00 00
...
00 00
00 02
00 33
00 36
00 57
00 D7
00 F9
01 2A
00 00 00 00 00 00 01 2A
00 04
00 7E
00 81
00 E5
00 FF
01 3F
01 81
01 C2
00 00 00 00 00 00 02 EC
A checksum for a given address in aim.exe can now easily be calculated:
checksum(addr)= data[3*(addr&~7)] + data[3*(addr&~7)+2+2*(addr&7)]
To determine the checksum for a block from addr1 to addr2, just do a checksum(addr2)-checksum(adr1-1), et voila, here we are.
please note: this shouldn't be a copyright infringement since the used data doesn't contain aim.exe, but information about aim.exe.
this is a 8byte value: data[3*(addr&~7)]
and this is a 2byte value: data[3*(addr&~7)+2+2*(addr&7)]
calculating the sum, this has to be taken into account.
you would think that since AOL went all out this time and wrote across all platforms, they would write a command line version of AIM and they wouldn't have to worry about it...its not like people are writing apps to hack the crap out of their system...and CAIM and GAIM and all those are better than AOL's X version..and some people can't run X all the time...
.kb
Two Wrongs Don't Make A Right-- But They Make Me Feel A Whole Lot Better
When jabber or any clone client receives the request for the md5sum for bytes A thru B of the aim.exe, we simply proxy this request to another server... which could be the local machine.
Therefore, we simply setup a simple daemon someplace (aimsumd) which given a version number, and two byte locations returns the md5sum.
client A, upon receiving this request from OSCAR, makes a similar request to an aimsumd server, and sends the result back to OSCAR.
Like I said, simple in principal, pain in the a$$ in practice.
Well first the output of MD5 is 16 bytes so there is a possibility, probability even that the article is simply wrong.
More importantly however this could simply be another trap set up by AOL. Sure they might begin by asking for 16 bytes - which is pretty much the shortest message that makes sense to compress. However whoever designed the protocol probably put in the option of hashing a randomly chosen segment of the file.
Another option they may have gone for is to allow the server to send a random challenge to be added in to the digest.
The only way to defeat this effectively is to have the aim.exe available.
Disclaimer, I am not a lawyer, this is not legal advice
The legality of controlling an interface through the aim.exe copyright is questionable however as others have noted in the thread. AOL certainly appear to be flagrantly violating the FCC order to support interoperability.
There is also a doctrine called 'copyright abuse'. The idea is that it should not be possible to use one form of intellectual property to achieve an end intended by another. The form of IP set up for protecting inventions is patent law. Attempting to use copyright law to protect an invention can result in the courts saying that it is OK to infringe the copyright to the extent necessary to duplicate the invention.
Put another way copyright protects the expression of an idea, not the idea itself. AOL is attempting to protect the idea, hence copyright abuse.
I guess AOL might have an argument under DMCA if they claimed that the AOl IM scheme was a copyright protection scheme, to do so however they would have to convince the court that AOL owned the copyright in the messages sent ove IM. I doubt that this would fly irregardless of whatever statements exist in the terms of service. Copyrights cannot be assigned through clickwrap.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
How about reverse engineering the servers? We would have to start our own user database, but that means no more getting "the screenname you have requested is currently in use" because somebody has registerd it along with 20 other screennames they dont use anymore. The problem with a new server is finding the host. I'm not verry familure with the aim protocall, but even a few houndred users all refreshing there buddylists would eat up a few megs an hour. Just an idea....
ln -s
I can spell, just can't type while eating.
ln -s
Robert Hutchinson
Robert Hutchinson
Smash it. Smash it good.
Well, AOL is right with closing their servers, i'm afraid... opensource clients usually don't have AOL's ad banners and so on, from which they expect to earn money for their product...
;-)
No, i think what is as stake is more that there is no true possibility to run AIM on other platforms such as Linux if they block us from using their servers. Ever tried AIM for Linux ? a HUGE bullshit that is not working well at all... even not working at all if u're not english-speaking: it simply blocks sentences with accents, leaving the lines empty, or with crappy squares.
And i don't think there's a *BSD client (available from AOL) at all, but i might be wrong...
Anyway... there are lots of problems with AOL: in France there's a cable provider, called NCNumericable, that distributes its services only using AOL... They've done the job soooo well, that their service is only available on W95/98/ME... even not on WNT/2k !!! But they're number one after all, they don't have to be technically good
Actually, even, they can take another stance
ipf block in on all from any to any port = AIM_PORT
ipf pass in on 152.0.0.0 to any port = AIM_PORT
Turn around and say they need to block certain ip address ranges for security concerns, then what will people say they're lying?
If it were your service and you were losing revenue you would be just as pissed as AOL. I have a better solution though, why not just unpatent everything and live in an unbalanced state of chaos? This way if someone steals from you, you have no right to complain, however if you do the same, same rules apply no one can say nothing. As it stands if I steal something from you its a crime, and vice versa, so should we be barbarians or just deal with whats in front of us?
360 degrees of Karma
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
From the FCC approval conditions, pages 3-4:
"AOL Time-Warner may not offer an AIHS application that includes the transmission and reception... of one or two-way streaming video communications... 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"
To my knowledge, AOL has not broken this condition, and thus is perfectly within their legal rights to block other IM clients.
I have no interest in AOL IM myself, but my nieces can't live without it. All their friends are on it.
It's a standalone application. I have installed it on Linux myself, for when my oldest niece comes to visit.
Allow me to show my infinite technical ignorance and dream for a second as someone with experience in Intellectual Property law:
When you really think about it, all aim.exe really is is just a long sequence of 0's and 1's, right? Unfortunately, copyright law makes it illegal for you to store THAT particular sequence.
But, what if you just did something simple so it isn't exactly the same number sequence anymore... like, XOR the entire aim.exe and store *that* instead?
Legal or not? Ooooh - then you could copyright the XOR'd version, too!
"They said I probly shouldn't fly with just one eye," "I am Bender. Please insert girder."
i admit my ignorance here, but i'm used to dealing with wussy servers (k6-2 300 is my server... we'll leave the workstations out of this ;^)
also, keep in mind how many users you're going to have hitting this server (gaim is actually relatively well-deployed).
in any case, we don't like the concept of doing it for a host of other reasons. thank you for replying with good content, i wish i could mod you up for people to better understand the situation.
-jbm, who is now giving up one the preview button
(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
It is stupid for them to do this, all they are doing is just shutting out potential users. I guess large companies like AOL just hate not having a monopoly on things.
yes, we could call it SIM (Slashdot Instant Messenger).
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!
is aol so hell bent on fucking over a new market segment.. dont' they realize that by shutting everyone in free software/open source out they close the door on their own futures ? i wonder what mirabilis thinks of this
I don't know, but I've always found AOL a bigger anti-trust than Microsoft. They own the (censored) Internet, they own Instant Messaging (and the phrase "Instant Messaging" until a recent court decision), and hell, I'd much rather use Yahoo, but all my friends are on AOL, and they won't allow it.
I don't understand. Why use the AOL servers at all. Why not boycott them and make our own protocol?
If there is one aspect of this situation that I find interesting is that it happened first between AOL and Microsoft, and I viewed it differently then. To those of us opposed to eith AOL or Microsoft, the thought of multi-billion Dollar corporations bickering over instant message usage was humorous. I certainly felt a childish sympathy for AOL, despite the fact neither side had good intentions.
Eric Raymond went so far as to write that we community members should 'applaud' Microsoft's efforts. Microsoft used the guise of 'open standards' that it usually will not hold it's own products by. Applaud them I did not, but the situation did call my attention to AOL's near-monopoly on Internet chat.
I suppose I was naive for thinking AOL was simply "sticking it to Evil Microsoft", but now it seems more like the Free community and Redmond are similar in AOL's eyes. Thoughts?
"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 front page post says that this feature was unused until now. Not so: AOL used this technique to stop MSN's instant messenger from connecting to AIM. MS and AOL went back and forth, imitating the handshake and changing it, for quite a while. I don't have the links to information on that right now, but I'll go look it up.
How should things work? You don't go to AOL for proprietary mail service--your ISP provides you with mail service. What we need is a distributed chat protocol based on servers run by your ISPs. For example, each ISP could run an IRC server to which their users can connect, and those servers could form a global network. Now, IRC has some problems, but all that effort that has been wasted on building AOL clients could have gone into fixing those problems.
AOL has no power, they simply have a lot of clueless users. Clueless users can be helped with education and better, free software. That, rather than AIM clones, should be where open source efforts go.
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.
I might not have such a big problem with this if there Linux client wasn't as featurless as it is, and if they had clients for other systems like be. It even looks like gaim....at least gaim about 10 releases ago....
I believe Yahoo Messenger is based on iChat Pager, formerly made by Koz. Apparently it's been making some big waves in the last six months. Can't say I like it as much as AIM, and I don't know how open the Yahoo (or I guess iChat) protocol is. Is there anyone who has looked beyond the surface of this app? Something tells me that the outcome of the ongoing "IM standard" consortium (which I am fairly sure is NOT attended by AOL) is going to be an open standard heavily based on the iChat method.
$mail="tufwfuveps@nbjk.dpn";$mail=~y/b-z/a-z/;pri
Mac OSX got screwed by AIM too, they killed FIRE, OSX's AIM/Yahoo/MSN/ICQ client. This forces me to run os9 aim in Classic
I'm a firm believer in the philosophy of a ruling class. Especially since I rule. -Randal, Clerks
if they also have 100 friends on aol then this means that they will also have to switch, this is insane, they won't swithc just because they want to talk to you
Quick, someone tell me how checksums are computed...until then, if they are composed of any length of a sequence of the n bytes in the file then from the first location there are n possible byte strings, from the second location n-1 possible byte strings... = (n) + (n-1) + (n-2) + ... + 2 + 1
= n(n+1)/2 possible check sums where n is the number of bytes in the file...
We here at AOL have a duty to protect our users from Elite Haxors using unamerican open source software. Such people could in theory entice our customers to use this open source software.
If you would like to communicate with AOL users simply use one of your 700 free hours CDs on an approved operating system. (Currently windows 9X, NT and Mac OS 7.5 - 9). Mac OS X is no longer supported by AOL because it is based upon free software.
Sign up and get 700 free hours.