[API] Windows Messenger JavaScript API

[Pedro Melo]

Hi,

On Mar 3, 2008, at 11:48 AM, Fabio Forno wrote:
> On Mon, Mar 3, 2008 at 11:41 AM, Pedro Melo <melo at simplicidade.org>  
> wrote:
>>  Did you look at the security implications that they mention if any?
>>  Do they require their code to be inside an iframe?
>
> I'm looking at them. As for now I've just read that they use Live ID
> for authentication and authorization, which is very similar to OpenID
> I guess. Therefore embedding messaging sessions in third party web
> applications should be safe, at least for credentials.
> In standalone clients where the "xiclet" doesn't have to live in a
> hostile environment, since it will receive a dedicated drawing area,
> there won't be these problems. However there remains more subtle, IM
> related, security implications, both for web and standalone
> applications:
>
> - should the xiclet be able to access your roster?
> - may it send messages using your jid to any contact?
> - may it listen for incoming messages from any contact as well?

Right I would say: no, no, no.

But those are my initial position, and are not absolute.

Let me take the last two first.

I see all communication between IM Client <-> Xiclets (and I use the  
term IM Client loosely, it could be a Web Interface like JWChat) in  
terms of a context with communication channels.

For each app running there is a application instance object. This  
instance has an API to create a communication channel. The  
application can only see and or generate messages in that channel. A  
typical channel is a one-to-one chat session, maybe using <thread> to  
keep it separated from the rest, or a MUC room, created for this  
application instance.

The environment would give some sort of API to invite people into a  
channel. And this takes us the to the first bullet. I think we can,  
for now, deny roster access if we provide a invite_into_channel API.  
This way, the client can choose whatever method is better suited for  
selecting buddies and invite them into the channel, without giving  
access to the roster.

Not giving access to the roster now, allows us time to think about  
all the implications. A future version might relax those restrictions.

Its easier to give something in the future, than to take it back...


> It's easy to find use cases where I'd like to be able to do these
> things (for example I'd like to allow a xiclet to subscribe a pubsub
> node and handle incoming events), therefore I don't want to renounce
> to them. However we run the risk of confusing or bothering users if
> they need to authorize everything.



>>  I'm trying to gather all data about security approaches of these
>>  experiments by other communities. I think will need some external
>>  input to validate our security model.
>
> Besides msn, sameplace and meboo other relevant communities?

Yes, and the kool appz OpenSocial and what not. We might want to have  
a "profile" or "mode" in which our Xiclets become a OpenSocial  
container.

> btw: we need a wiki where to put these considerations once  
> discussed on the ML

What about a geek aproach? A shared subversion repo where you can  
write those docs?

It would be nice because we could also commit examples ...

But a wiki is also fine. I suggest wiki.jabber.org.

Best regards,
-- 
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo at simplicidade.org
Use XMPP!