On Tue, 30 Sep 2008, Robert O'Callahan wrote:
If the chat gadget is configured to only talk to the site owner, how can it
be abused? I suppose the site owner can discover the chat nick of a visitor
who otherwise wouldn't want to disclose it. That's a risk that the chat
system developers might very well be willing to accept.
Assume you are logged in with Facebook, Google, or any other "common"
party that provides general chat / calendar services or anything of that
kind; and let's say this party permits site operators embed a gadget that
shows every visitor a schedule of events advertised on a page overlaid on
top of visitor's schedule (with the option to add these to your calendar,
or edit your calendar data - it does not have to be read-only); or gives
you the opportunity to chat, review and annotate documents, or otherwise
collaborate with site owners using similar facilities provided by gadget
operator in their third-party domain, in your capacity as the user logged
in with said services.
[If the visitor is not logged in, such a gadget would not display, or
would offer a login link that pops up a new https:// window.]
This is not a very far-fetched scenario - I've seen designs of this type -
and they are very much possible and safe to arrange without disclosing any
user-specific information to the page that embeds said gadgets. The only
security problem arises with UI redress flaws; so it would be nice to
offer viable alternatives for such applications, too.
That's a terrible user experience, by most accounts, and goes against the
concept of a gadget; I believe it is often avoided at all costs except when
absolutely necessary (e.g., login, where the user needs the opportunity to
verify URL, SSL status, etc).
Maybe we can make it a better user experience, for example, by allowing
the new window/tab to appear as a new pane at the top or bottom of the
existing tab. That would nicely handle your chat example, IMHO.
Possibly.
/mz
