[whatwg] Menubars and phishing

[Brad Neuberg]

Java Web Start has come up with some nice ways of solving some of these 
problems that you can take some ideas from.  Java Web Start is bundled with 
Java.  When it detects that a certain kind of file is being downloaded, it 
prompts the user asking if they would like to download the application.  It 
also asks the user if they would like to give permission for just this 
session or for ever.  It also caches the application and only downloads it 
again if it has changed.

Java Web Start detects if the application has been run more than once and 
prompts the user if they would like to add an entry for the app to their 
desktop and to their start menu (this is cross platform).

Brad

At 01:27 PM 6/10/2004, Dylan Schiemann wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>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.
>
>| 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.  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.
>
>| Yet we want these applications to look nice, and have their own toolbars
>| and so forth, without looking silly.
>
>Agreed.
>
>| For popup windows I think the best plan is probably to have "fake" popup
>| windows that are basically just position <div>s (which can be resized,
>| etc, but are restricted to the content area of the parent Web page). So
>| that's not a big problem. The big problem is how to handle menus on the
>| primary top-level Web application window.
>
>part of the netWindows API does a great job with this.  I've used divs
>which then have svg documents in them as well for popups.  I like to
>call these windows "flyovers" rather than modal or modeless windows.
>
>There are reasonable use cases for wanting the flyover to be outside the
>area of the traditional parent window... for example, think of an
>interface like the Gimp... basically sometimes you want to move the
>flyover out of the way when working with an app... but you can't move it
>out of the way if it has to be contained by the parent window.  This
>gets much more complex in a multiple document system, where the parent
>document might not have a reason to be very large.
>
>| In fact, on Mac, there is no per-window menu bar, and there is no way that
>| Web apps will ever have access to the top-level menu bar, so come to think
>| of it menu bars in general are out.
>|
>| How should Web applications provide their feature access points?
>|
>| Any suggestions on how to handle this would be welcome.
>
>http://www.konfabulator.com/ does some interesting stuff on the Mac with
>widgets that might be in some way inspiring.
>
>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?  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
>
>- --
>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
>
>iD8DBQFAyMQn8nLgh/JJsxERAtmXAJ9Arn+yLdqTMegsd7i2GtlB/WshJQCgjs3k
>CnuLXvrdLSqAsFi7bcdiRyE=
>=j3rN
>-----END PGP SIGNATURE-----