So, the actual task of scrolling the list isn't actually the 
performance problem here then? It's more the length of the list that 
makes it take a long time to reach its end?

How does the iPhone handle a list with thousands of entries (i.e. if 
you access the "Tracks" category in the "Music" part)? Does it still 
scroll smoothly? Are the entries displayed instantly (or do they need 
their time to display like in the demo videos by Apple)?

The password is sent in clear text, but only once upon login. From 
then on, a unique session ID is used to identify your iPhone as an 
authorized client. And in fact, the AJAX Remote was designed with 
your local network in mind, which - by itself - should already be 
encrypted and thus secure the connection.

However, taking a closer look at the security issues that spring to 
mind are giving a somewhat different image than you might expect:

1) You can browse the filesystem using Remote Buddy and open them in 
applications installed on your Mac, but not download them via your 
browser. However, before you can do that, as an attacker, you do need 
to have either the correct password or a currently valid session ID 
(which is strong enough to withstand brute force attacks for a very 
long time).

2) If you want to find out about either of the password or session ID 
easily, the attacker would need to listen to your network connection. 
If he can do this, however, he'll already have been able to gain 
access to other passwords in the past, as many websites that offer 
login options do not offer encrypted connections for them 
(iospirit.com, btw, does encrypt your entire login and then your 
entire session via SSL, no matter which area of the website you access).

3) If someone already has the ability to sniff your network 
connection, SSL is of very limited use. "But SSL encrypts my 
connection, right?" I hear you ask. Yes, it does. But as so often, 
it's the details:

If you want to encrypt your network connection via SSL, you'll need a 
private key and a certificate belonging to it. Both can be generated 
easily with tools shipping with each OS X install. So far so good.

Usually, when a company uses a certificate on their webserver to 
secure its connection, they let it sign by a trust center (this has 
been done for i.e. https://secure.iospirit.com/ - and it costs you 
quite some dollars to do - more than at least two copies of Remote 
Buddy for sure - annually, per domain). Your browser already has a 
trusted copy of the trust center's certificate and this way can 
verify that the certificate it receives is not spoofed / faked. 
However, with self-signed certificates, and that's what we're 
speaking about here, your browser can't verify whether it's really 
your certificate that is being used to secure the connection. So, 
with self-signed certificates, a man-in-the-middle attack (MITMA) is 
perfectly possible. MITMAs work this way:

Your server, your certificate <-> Man in the middle client

and then

Man in the middle, uses his own certificate <-> your client

So basically, the MITM establishes a secure connection in your place, 
gets access to the data in clear text, then plays the role of the 
server and establishes a "secure" connection with your client (which 
believes the MITM *is* your server). As your certificate is not 
signed, you'll receive a warning, but unless you really go to some 
length to check the validity of the certificate *each and every time* 
upon that warning, you can't be sure that nobody is listening to your 
connection and abusing the service.

There's more info on Wikipedia on this:

http://en.wikipedia.org/wiki/Man_in_the_middle

The usage of dynamic IPs for internet connections does add to the 
problem as a certificate does contain the website's domain name (also 
called "common name") - and this one keeps changing on each reconnect 
of your Mac. So, unless you have a static IP, even if you would go 
through a trust center, you’d have to shell out (a lot of) money and 
time each time the IP of your Mac changes. Otherwise, when common 
name and "domain name" (here: your IP) do not match, the browser will 
warn you as well (try connecting to https://www.iospirit.com/ to 
receive such a warning - as the certificate is bound to a different 
subdomain, https://secure.iospirit.com/ ).

So, yes, free, self-signed SSL certificates certainly help against 
"dumb" attackers. But if someone really is able to listen to your 
network connection, he'll usually also have the tools and knowledge 
to know how he can listen to your connection nonetheless using a MITMA.

I'll look at adding SSL support nonetheless, although I feel that the 
gain in security will mostly be a felt one rather than a real one.

Best regards, 
Felix