Guenther Niess wrote:
I was just chatting about this with Maciek Niedzielski and he suggested
a different kind of workflow for XEP-0070-like functionality
But some problems are still there.
1. If you want to use the authorization service, you have to use a
client that support that protocoll.
I think that there are more clients out there that support sending a
plain message than clients that support XEP-0070 ;)
But I guess what you wanted to say is that a client needs to support
xmpp URI to make this work. So I can say two things:
1. I am almost sure that supporting XMPP URI is more important than
XEP-0070 for every client developer.
2. You don't really need XMPP URI here.. It just makes things easier.
But a website can also say "If this link doesn't work for you, please
copy the ID below and send it to [EMAIL PROTECTED]
2. I think the web based XMPP clients like meebo [1] have big problems
to implement such a protocol. (This should look more a configuration
problem of the browser)
I think firefox3 will allow you to use web-based applications to handle
URIs, so... at least browser world already noticed the problem.
4. It's not secure that the user "can't modify" information which the
user get from a website and send to a xmpp server, it's an illusion.
No matter how creative you are, you cannot invent a protocol that will
prevent this. But yes, here it would be really easy to do..
At all I think the spam problem by another user is not as big as the
problems you get when you can't use the authorization service. And
at my opinion when you implement the existing XEP 70 you can help the
user to get not such a big problem, by:
a) for XMPP browser plugins: automated server responses don't disturb
the user
That's a bit unfair to compare XEP-0070 with dedicated browser support
with my approach in a standard browser.
(And as as side note, it is easier to write firefox extension that will
support xmpp: URI and do something smart about it, even open your
web-based XMPP client, than to hack a special treatment for HTTP
authorization with "xmpp" realm).
b) other clients: caching decisions and delimit user requests at a
session can help.
Caching decisions? If you read XEP-0070, it is essential that you must
always check if the transaction id is the same as the one entered in
your web browser. You cannot assume that if you confirmed one request to
example.org 5 seconds ago, the next one can also be confirmed - because
this may be a person standing behind you trying to access the same
website at the same time.
c) for servers: saving denys in combination with the request ip can
help to locate spammer and exclude them
Every time you start banning by IPs, domains, etc, innocent people get hurt.
--
Maciek Niedzielski
xmpp:[EMAIL PROTECTED]
