W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2004

[whatwg] Menubars and phishing

From: Dylan Schiemann <list4@dylanmail.com>
Date: Mon, 14 Jun 2004 10:07:56 -0700
Message-ID: <40CDDB6C.3020507@dylanmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Hickson wrote:
| 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.
|
| 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.

One idea that was mentioned by Brad Neuberg was the way Java Web Start
handles things... Basically the first time you access an app, it asks
you what permissions you approve for the app... sort of a hybrid between
an installation process and a splash screen for the app perhaps?

|>| 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...

As do I... :) but most of our users aren't linux/unix users.  The point
is that I could think of some "web apps" really being apps that serve
roles identical to current local apps, but that by using the browser
rather than a local app, they have the benefits of being a web app
(cross-platform, no installation, nice web communications framework, etc.)

|>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.

For sophisticated users, this is true.  Many users don't understand the
differences between an application, a web site, and the internet.

|>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?

I'm not sure what you're asking here.  Wouldn't it then be stuck in a
normal web browser mode?  Choices like this seem like they should be
left up to the UA.

|>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.
|
| 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.

Right... my point was this: should we suggest providing an API for
interacting with the existing system controls, or an API that overrides
the system settings and replaces them with the app developers menu, or
something else.  In the case of the Mac interface, a local app
integrates with the single menu bar at the top, replacing some items and
adding others.  Is this something a "trusted" web app should be allowed
to do.  Similarly for the context menu, should the web app menu override
the UA context menu, or simply be able to add/remove items from it?

- --
Dylan Schiemann
http://www.sitepen.com/
http://www.dylanschiemann.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAzdts8nLgh/JJsxERAqZmAJwNu3LpmZH+abjSI0WoPoV3zFqg5QCfXKGI
dYjq0gkmUy6P/WAYCeY4xLc=
=NS32
-----END PGP SIGNATURE-----
Received on Monday, 14 June 2004 10:07:56 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:34 UTC