[whatwg] Menubars and phishing

Sun Jun 13 15:26:47 PDT 2004

On Thu, 10 Jun 2004, Dylan Schiemann wrote:
>
> Ian Hickson wrote:
> | I'm really stuck on this problem of how to handle running remote
> | applications so they definitely look like they are remote, and an
> | application on paypcl.com is definitely distinguishable from one on
> | paypal.com, even if they use near-identical code.
>
> The best thing that comes to mind is this... starting a web app could
> have a mechanism much like starting a real application.  The first time
> you start the web app, you would give consent to give the app a certain
> level of permission, and a way to remember that permission level (much
> like approving the installation of a program).  And this would need to
> be easy enough to use that people wouldn't just click yes to everything.

How would that work?

You go to gmail.com. The application has already started. You don't want
to pop up further dialogs.

Then again, I suppose gmail doesn't want to run out of the browser, so it
wouldn't need to.

The alternative would be to take the <html application> idea one step
further -- when you go to a URI whose markup starts with an <html> element
with an "application" attribute, you display, inline in the browser, a
short message saying that the site from such-and-such a domain wants to
run as a separate window, and should you allow it to or not.

> | It should also always be possible for the user to control his windows
> | completely -- resize "unresizable" ones, not have any popup windows that
> | break out of the browser, always have access to the UA menu bar or
> | toolbar, etc.
>
> Yes and no.  Many traditional apps don't afford these rights to the
> user.

Actually, as a user, I use a system wherein I have full control over these
things. But...

> I see more of a need to easily kill or end an application session, that
> would clean-up everything from an offensive app, than requiring every
> window of an app to be able to show menus and be resizable.

The difference between Web apps and local apps is that you somewhat trust
local apps, but don't even remotely trust Web apps.

> The question comes down to this: should web apps have control over
> system menu controls?  Traditional software apps are afforded this
> control, so why not "approved" web apps, provided there's an
> unoverridable, obvious way to "escape" from the web app?

I suppose I could see cases where letting the application appear to run as
a standalone application could make sense. The question is, how should it
appear when that application _isn't_ run as a standalone application?

> Or at a minimum, why not one menu bar dropdown that has a title that is
> the name of the web app, and its own level of options that are
> added/removed through a standard API?  The same principle seems to be
> analogous for context menus.  The Adobe SVG viewer has a context menu
> API:
> http://www.protocol7.com/svg-wiki/default.asp?CustomizingContextMenu and
> I proposed something similar for mozilla a long time ago in place of the
> oncontextmenu event: http://bugzilla.mozilla.org/show_bug.cgi?id=87536

Oh context menus and drop down menus will definitely be supported, just
look at the number of sites that use them. The question is exactly how
should they look, basically.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'