Talk:UDP API DEV

Uh, very cute but... unless you've got exp to hand you the udp sources, he'll be the one who has to implement it, in which case this is just a set of feature requests, and we have a bug tracker for that. (But expect most of them to be put on his indefinite todo list or be refused outright.)

--Pelican 16:00, 27 Oct 2005 (CEST)

I have the source. I’ve taken over the development. --Epoximator 16:10, 27 Oct 2005 (CEST)

Mind writing a little something that I can post on the main page Epox? Webaom never quite got the publicity it deserved either really, wouldn't hurt to do a bit of a heads up on what can be done. --Rar 21:43, 27 Oct 2005 (CEST)

I have posted something in the forum now: http://www.anidb.net/forum/viewtopic.php?t=2328&start=45. You can use that if you want. --Epoximator 13:58, 28 Oct 2005 (CEST)

Encodings

Protocol 2 says that the current character encoding is “unknown.” Shouldn't this be defined, preferably to some Unicode, like UTF-8? Considering AniDB maintains data in several languages, isn't having an agreed-upon encoding important? Derobert 01:35, 14 November 2005 (CET)

I guess it's ok to set this to ASCII now. All non ASCII chars should be html escaped. --Epoximator 11:40, 27 January 2006 (CET)

ANIME

I'd like this command to cope with a couple of different encodings when passed a title, and be explicit over whether it finds only one result or does a best-match guess. --Rar 04:51, 30 Oct 2005 (CET)

On second thought, is a wide search really wanted or is 'WHERE lower(name)=' good enough?. About encodings, do you care to elaborate? --Epoximator 18:24, 25 November 2005 (CET)

Oh, specifically, I'd like anime lookups to be able to take sjis/utf8 rather than just html escaped ascii, as an option. While all real programming languages have trivial encoding switching: string.decode('sjis').encode('ascii','xmlcharrefreplace') some that might find a use for udp access to anidb (such as the dire mirc scripting language), do not, so dealing with it serverside would be nice. --Rar 01:28, 29 January 2006 (CET)

ENCODING

This could be included in the AUTH command or an environment command that includes options for encryption, encoding and compression. (In response to rar's request.) --Epoximator 11:48, 31 January 2006 (CET)

This should definetly become an additional, optional parameter of the AUTH command. There is really no reason why this should be an extra command. It just means two more UDP packets overhead on each client connection. --Exp 05:28, 8 February 2006 (CET)

I think epoxi was more thinking of this command as setting a session state flag, like a parameter in AUTH would, rather than being sent prior to *every* command, which would of course be silly. I see no reason not to have both. --Rar 16:21, 10 February 2006 (CET)

FILE

Pass a list of fields (limit e.g. 10 entries) and return content. This makes it possible to request new fields in the database without breaking API for older clients. On updates, only the list of possible fields need to be extendet. -- --Dinoex

I think it's a good idea. Modified a bit. --Epoximator 13:38, 26 November 2005 (CET)

Encryption

"encryption pass must be set in profile settings on the website"

for this to be really useful for all the paranoid ppl out there, you should really change the website to https. luckily for me, I'm not paranoid about this, but I thought it should be pointed out. --Suppy 06:41, 27 January 2006 (CET)

https is concidered a possible performance issue and is therefore currently not supported by anidb. if I have too much time I might write something up which allows only the signup, login and profile pages to be transmitted via https and everything else via http. does anyone know if there is a good howto somewhere on how to best set this up? (i could always hardcode these limitations, but there should be a better way)

And the main reason for this feature is the usage of clients over untrusted connections. Which is possible once you configured your client password via a trusted connection.

--Exp 06:58, 27 January 2006 (CET)

Crypto Protocol

The encryption specified in the protocol is poorly defined. AES is just a cipher, not a protocol; there are critical details missing, like the type of chaining being done; if its being used in stream or block mode; how replay prevention and other Mallory attacks are to be prevented; etc. Consider using an existing, well-understood crypto protocol. TLS comes to mind. Derobert 02:22, 28 January 2006 (CET)

Technically the suggested (this page is not the actual specification, it's for proposals) encryption sceheme is, in fact, perfectly well defined if you presume that messages can be padded beyond the end of the one line they are allowed to contain to a multiple of the block length (128 bits). However, it isn't very useful as a security measure because of the obvious vulnerability you point out: replay attacks. (This means that you can just parrot encrypted packets and they'll decrypt to the same plaintext. So while you can't get the user's password, you can authenticate yourself as a user whose traffic you've monitored.)

...but in reality, there's no need for AniDB to be a secure application. Best to just forget about encryption altogether; it's far more trouble than it's worth in this case.

--Pelican 20:45, 28 January 2006 (CET)

Well, the actual implementation by epoximator will define the exact encryption type and the API documentation will be updated to reflect this. I agree with pelican to a certain extend. The security needs of AniDB can be viewed as being rather limited. As such TLS seems like an overkill (especially since it brings quite some additional performance and bandwidth overhead). And even the very basic AES encryption will be disabled by default. And yes, replay attacks will be possible, but the damage an attacker can do with those should be limited. I'll add a small change to the protocol which will make replay attacks slightly more complicated, but still not impossible. The encryption should be kept as simple as possible in order to minimize the additional overhead.

And even a very basic AES encryption will be enough to prevent the password from being snooped while it is transmitted. I.e. in unsecured wireless network environments.

--Exp 04:55, 30 January 2006 (CET)

If TLS really is too much overhead, I'd suggest using ESP (from IPSec) with static keying (so you don't need the additional complexity of IKE). You can encapsulate that in a UDP packet, instead of IP proto 50.

I think, if you're going to give users a "secure" checkbox, it really ought to be secure. The best way to accomplish that is to use a well-understood, well-studied security protocol instead of inventing yet another. The "invent yet another" security protocols all too often turn out to be completely insecure.

BTW: If you're just trying to prevent password sniffing, there are already several well-studied HMAC-based protocols which do that, and do it with minimal overhead. Low enough that you could probably just use it by default.

—Derobert 14:56, 30 January 2006 (CET)

Errors / bugs

GROUP

I obtain: '41|851|665|109|1004|Zhentarim DivX|zx|#zhentarim|irc.chatsociety.net|http://www.zhentarim.net/' The irc channel and irc server are on two fields, and this is not documented. --Darsh 12:14, 28 April 2006 (CEST)

Updated doc --Epoximator 20:52, 28 April 2006 (CEST)