gaim/www

Initial import into CVS
chipx86
2002-09-26, Christian Hammond
b4885d81db57
Parents 52dba86e97ec
Children 28db4c381fa4
Initial import into CVS
4 files changed, 226 insertions(+), 0 deletions(-)
  • +0 -0
    htdocs/EC_2000_sm.jpg
  • +0 -0
    htdocs/Tuxie_2001.jpg
  • +115 -0
    htdocs/aim_data.php3
  • +111 -0
    htdocs/aol.shtml
    • Binary file htdocs/EC_2000_sm.jpg has changed
    Binary file htdocs/Tuxie_2001.jpg has changed
    --- /dev/null Thu Jan 01 00:00:00 1970 +0000
    +++ b/htdocs/aim_data.php3 Thu Sep 26 06:21:46 2002 -0400
    @@ -0,0 +1,115 @@
    +<?
    +
    +// Written by temas. (Not that I think anyone would particularly have
    +// any use for this script)
    +
    +# If AOL ever breaks this script, uncomment the lines below and fill in
    +# the appropriate values for the hash. That way, at least people can
    +# use Gaim until we figure out how the script is broken and fix it.
    +
    +#printf("%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c", 0x44, 0xa9, 0x5d, 0x26,
    +# 0xd2, 0x49, 0x04, 0x23,
    +# 0x93, 0xb8, 0x82, 0x1f,
    +# 0x51, 0xc5, 0x4b, 0x01);
    +#exit;
    +
    +$aim_binary_dir = "/home/groups/g/ga/gaim/aim35";
    +
    +# If the length is 0 then Gaim should handle it itself. These values
    +# should never be less than zero since they can only be 16 bits, and
    +# Gaim stores them as long ints.
    +if ($offset < 0 || $len <= 0) {
    + exit;
    +}
    +# If AOL doesn't tell us what module (.ocm file) to get the data from,
    +# we use aim.exe
    +if (strlen($modname) == 0) {
    + $modname = "aim.exe";
    +} else {
    + # Gaim doesn't send the .ocm part. I don't know why. I forgot.
    + $origmod = $modname; # We need to save this for one of our special cases.
    + $modname = $modname . ".ocm";
    +}
    +
    +$filename = $aim_binary_dir . "/" . basename($modname);
    +
    +# If the given offset or length is larger than the size of the file, it's
    +# it's an invalid request, and so we hash the request. There's gotta be a
    +# prettier way of doing this, someone, please tell me what it is. This was
    +# copied from faimtest and translated from C to PHP.
    +$st = stat($filename);
    +
    +if (($st) && ($offset > $st[7] || $len > $st[7])) {
    + $buf[0] = $offset & 0xff;
    + $buf[1] = ($offset >> 8) & 0xff;
    + $buf[2] = ($offset >> 16) & 0xff;
    + $buf[3] = ($offset >> 24) & 0xff;
    + $buf[4] = $len & 0xff;
    + $buf[5] = ($len >> 8) & 0xff;
    + $buf[6] = ($len >> 16) & 0xff;
    + $buf[7] = ($len >> 24) & 0xff;
    + $data = sprintf("%c%c%c%c%c%c%c%c", $buf[0], $buf[1], $buf[2], $buf[3],
    + $buf[4], $buf[5], $buf[6], $buf[7]);
    +
    + print pack("H*", md5($data));
    + exit;
    +}
    +
    +# Oh, another fun special case ... Hacked by Rob. If it breaks, yell at me.
    +# Essentialy, if they give us a bogus filename, we hash the module name +
    +# the offset and length and return that. Pretty fun stuff.
    +
    +if (!$st)
    +{
    + $buf[0] = $offset & 0xff;
    + $buf[1] = ($offset >> 8) & 0xff;
    + $buf[2] = ($offset >> 16) & 0xff;
    + $buf[3] = ($offset >> 24) & 0xff;
    + $buf[4] = $len & 0xff;
    + $buf[5] = ($len >> 8) & 0xff;
    + $buf[6] = ($len >> 16) & 0xff;
    + $buf[7] = ($len >> 24) & 0xff;
    +
    + $data = sprintf("%s%c%c%c%c%c%c%c%c", $origmod, $buf[0], $buf[1], $buf[2], $buf[3], $buf[4], $buf[5], $buf[6], $buf[7]);
    +
    + print pack("H*", md5($data));
    + exit;
    +}
    +
    +# If we can start reading before the end of the file, make sure we don't try
    +# to read past the end of the file.
    +if ($offset + $len > $st[7]) {
    + $len = $st[7] - $offset;
    +}
    +
    +# The length is never more than 4096. Yes, taking the modulo is correct. (At
    +# least according to libfaim.)
    +$len %= 4096;
    +
    +# Yet another special case. If the length they're requesting is 0, then we
    +# hash NULL. Isn't that swell.
    +if ($len == 0) {
    + print pack("H*", md5($NULL));
    + exit;
    +}
    +
    +$fd = fopen($filename, "r");
    +if ($fd <= 0) {
    + exit;
    +}
    +if (fseek($fd, $offset, SEEK_SET) == -1) {
    + fclose($fd);
    + exit;
    +}
    +$buf = fread($fd, $len);
    +if (strlen($buf) == 0) {
    + fclose($fd);
    + exit;
    +}
    +fclose($fd);
    +
    +print pack("H*", md5($buf));
    +
    +exit;
    +
    +?>
    --- /dev/null Thu Jan 01 00:00:00 1970 +0000
    +++ b/htdocs/aol.shtml Thu Sep 26 06:21:46 2002 -0400
    @@ -0,0 +1,111 @@
    +<!--#include virtual="/header.shtml"-->
    +
    +<h1>My Two Cents on AOL's Blockings</h1>
    +<blockquote>
    +
    +<P>Every time an article gets posted on Slashdot about the AIM service that AOL
    +provides, I see the same comments being made over and over again. A sizable
    +percentage of those comments tend to be misinformed, or sometimes just wrong. So
    +here's my own thoughts and commentary on everything AOL has done with the AIM
    +service since the announcement of TOC.</P>
    +
    +<h3>AOL Announces TOC</h3>
    +
    +<p>In 1998 AOL announced that it was going to be providing an open protocol that
    +clients could use to access the AIM service; this protocol became known as TOC.
    +They not only released a specification of the protocol, they also released a
    +client that used the protocol - and released it under the GPL. TiK (as it was
    +called) was written in tcl/Tk, and though it wasn't a 1.0 release, it supported
    +nearly every feature the TOC protocol offered.</p>
    +
    +<p>AOL gave the Open Source community TOC, and most people seemed to think at
    +the time that this was a Really Good Thing, and that AOL was really trying to be
    +friends with us. AOL giving us TOC negates any argument about us not having any
    +right to use their servers. TOC operates as a proxy to the real service - it's
    +actually <i>less</i> efficient to use TOC than it is to use Oscar. Before you can
    +claim that all of these unofficial clients are a drain on AOL's resources, TOC
    +must be dropped. Unless if they drop TOC, we have a right to use those
    +resources.</p>
    +
    +<p>Since the release of TOC, it has <i>not</i> kept up with Oscar, and in fact
    +has <i>lost</i> features since its release. When TOC was announced, it could not
    +retrieve users' away messages or request RVOUS actions (RVOUS actions include
    +file transfers, buddy icons, direct IM, and voice chat). Since its release, it
    +has lost the ability to search for users, and features that Oscar has gained
    +have never been added to TOC. So while TOC can still perform all of the basic
    +functionality that users need, it is <i>not</i> a valid alternative to
    +Oscar.</p>
    +
    +<h3>AOL Blocks MSN and Odigo</h3>
    +
    +<p>Although these two events were separate they are related. Both were competing
    +IM systems. Please note the distinct difference between an IM system and and IM
    +client: clients connect to a system. AOL has never deliberately blocked any
    +client, even an unofficial one, from connecting to their service (though they
    +have made modifications that occasionally broke unofficial clients). They have
    +only blocked competing systems, such as MSN and Odigo, from being able to
    +communicate with AIM users.</p>
    +
    +<p>Because MSN and Odigo both have closed servers and closed
    +clients, I don't think these blocks were ever really looked at one way or the
    +other by most people; or at least, they should not have been. If MSN had "won"
    +the battle, so to speak, it would have been replacing one evil, AOL, for
    +another, Microsoft (the only reason I say "evil" is that their servers are not
    +open source).</p>
    +
    +<h3>AOL and Time/Warner Merge</h3>
    +
    +Everyone seems to think that because AOL and Time/Warner merged that AOL has to
    +open up their AIM service; the FCC said so, after all. This has been greatly
    +misread by nearly everyone except AOL. According to the FCC <a
    +href="aoltw.pdf">conditions</a>, AOL only needs to open AIM to at least one
    +would-be competitor <b>if</b> they add "advanced, IM-based high speed services",
    +specifically, video conferencing. Until they add video conferencing, they are
    +allowed to keep it as closed as they want.</p>
    +
    +<h3>AOL Blocks Jabber (and Gaim)</h3>
    +
    +<p>Once again, AOL did not deliberately block Gaim (a client); it was a
    +by-product of blocking Jabber (a system). What's really infuriating about this,
    +though, is that Jabber is working towards openness and interoperability, and AOL
    +doesn't want any part of it. Blocks by AOL have never been about resources or
    +making sure only valid clients connect; they have <b>always</b> been about
    +cutting out competitors' strongest link: the ability to talk to AIM/AOL
    +users. Without that ability, it is highly unlikely that a competing IM system
    +could survive (unless if you're Microsoft, in which case you just put MSN
    +Messenger on everyone's desktop).</p>
    +
    +<p>In any event, Jabber was blocked. It's currently able to connect, and the
    +last release of Gaim (0.11.0pre10) is able to use Oscar without any problems. If
    +a different checksum is asked for, we will be setting up a checksum server that
    +will provide the correct 16 bytes, so people will still be able to use Gaim.
    +This seems like the only reasonable solution for Gaim. Jabber's current solution
    +is to require a copy of the AIM binary at each server installation, which is
    +more reasonable since they are a server and not a client. However, since it has
    +been more than two weeks since the checksum value changed, I doubt that a
    +checksum server will be required. AOL had attempted to block Jabber based on
    +other parts of Oscar besides the checksum, so I think the worst of it is over.</p>
    +
    +<h3>Conclusion</h3>
    +
    +<p>So that's it. I wrote this just to get a couple points in, in case any
    +discussion about AIM ever happens again. Just to sum up, they were:</p>
    +
    +<ul>
    +<li>It's not the resources that are the issue; and if it were, TOC would be
    +blocked too;
    +<li>TOC is <i>not</I> a valid alternative to Oscar for a serious AIM client;
    +<li>AOL blocks competing systems, and never deliberately blocks clients (though
    +it may accidentally block them);
    +<li>the FCC did not require AOL to open AIM, and even if AOL adds video
    +conferencing, they don't have to open it as wide as people seem to think they
    +do;
    +<li>and finally, the Jabber/Gaim blocks are currently resolved, and we have
    +stand-by solutions in case the need arises.
    +</ul>
    +
    +<p><i>--EWarmenhoven, April 19, 2001</i></p>
    +
    +</blockquote>
    +
    +<!--#include virtual="/footer.shtml"-->