RE: <bb> element

On Fri, 7 Aug 2009, Adrian Bateman wrote:
>
> * <bb type="">
>   User agent command including "make application".
> 
> Feedback
> --------
> 
> Having a consistent installation experience for independent applications
> is the key to their success. Supporting the instantiation of individual
> apps through a page control provides too much programmable flexibility
> that developers could use to hijack the end-user experience thus
> creating an inconsistent process.
> 
> Events
> 
> The current specification places the tag in the body of the document and
> implies it will continue to support all standard HTML 5 event handlers:
> 
> onabort, ondragover, onmousemove, onbeforeunload, ondragstart,
> onmouseout, onblur, ondrop, onmouseover, onchange, onerror, onmouseup,
> onclick, onfocus onmousewheel, oncontextmenu, onkeydown, onresize,
> ondblclick, onkeypress, onscroll, ondrag, onkeyup, onselect, ondragend,
> onload, onstorage, ondragenter, onmessage, onsubmit, ondragleave,
> onmousedown, onunload
> 
> The potential risk of supporting all of these events is that websites
> could hijack events and confuse users with inconsistent experiences. For
> example, developers could create their own dialog that is displayed when
> the onclick event takes place. This would be an additional dialog that
> would be displayed in addition to the currently proposed consent dialog.

I don't think that's really a practical concern, to be honest. It's no 
different than what happens now when you click a link to a file that 
downloads an executable.


> Scripting
> 
> We believe there is a risk in allowing an element of this nature to be
> manipulated by script because it could create a scenario where
> developers auto-select it as part of the onload page (to force their
> website to be accessed as an individual app) and the user would see a
> consent dialog without knowing why. This would remove the user from
> being in control of the experience.

Originally the proposal was an API function, and I thought that was too 
dangerous for the reasons you give, which is why it's an element. I agree 
that an element is suscuptible to click-jacking, though.


> Tag on Page Body
> 
> Having the tag in the body as the main discovery mechanism is a concern
> for us. We would like to see a model where the browser chrome is the
> primary mechanism by which users install web apps or individual
> applications. Our belief is that this will promote a more consistent
> experience and could potentially remove the need for having a consent
> dialog. This might be able to be accomplished by providing a link tag on
> the header of the page to specify that this website could be used
> independent of the browser:
> 
> <link rel="AppManifest" href="manifest.xml" type="application/xml">

<html manifest> in conjection with <meta name=application-name> (both 
already specified) may make sense as a solution to that.


> We see the <bb> tag as an additional tag that could be added to provide 
> additional advertisement to the site with a private event that is 
> handled by the browser.

That seems to be exactly what it is already.


> Furthermore, there might be additional information that web browsers may 
> require from the site, beyond its current URL and metadata information, 
> in order to enhance the launching and execution of the website as an 
> independent application. That is the reason we believe a manifest URL 
> needs to be provided.
> 
> For example, the <bb> tag specification assumes that the current page 
> the user is viewing will be the starting page for creating an 
> independent application. In some cases, the website may want to promote 
> a web app whose starting page is not the same as the one being viewed.

In practice applications these days tend to just have one page, but I 
could see that that would be a possibility.


On Fri, 7 Aug 2009, Jonas Sicking wrote:
> 
> While we haven't done a formal review of this feature at mozilla, my 
> initial reaction is that I don't think we'll want to implement this 
> element. The content area is simply too prone to manipulation for <bb> 
> to provide any level of comfort with performing the action that clicking 
> the <bb> is intended perform. I.e. I see no correlation between the user 
> clicking a <bb> and the user intending to take any action related to the 
> <bb>, or even any action at all.
> 
> For example it's trivial for the page to get the user to click on the 
> <bb> by using click-jacking techniques, or by simply making the <bb> 
> fill up the full viewport but be 99% transparent.
> 
> An alternative solution might be for a declarative way for the page to 
> indicate that it supports certain actions, like install an offline app, 
> so that the UA can add UI somewhere in the browser UI that the user can 
> interact with.
> 
> Though I guess we could use the <bb> as that declarative method. However 
> the name 'browser button' seems weird in that case since buttons can 
> generally be clicked.

With <meta name=application-name> and <html manifest>, it's possible that 
we already have the declarative solutions you mention.


On Mon, 10 Aug 2009, Adrian Bateman wrote:
> 
> I think there are two issues here. The first is for the page to signal 
> to the browser that it wants the user to have the option for the web 
> application appear in a more familiar setting where it looks more like a 
> native application. The second is for the user to actually take that 
> option.
> 
> I think that once we start to provide this opportunity, there will be 
> much more data that the site author wants to provide. For example, this 
> might include icons to use, title text for links/shortcuts, and a regex 
> that determines whether the URL of a link should be considered to be 
> part of the same app or from another site.

These three things are already handled (rel=icon, meta application-name, 
and manifests respectively).


> As you say, including this type of interaction in the client area is 
> going to be problematic and the suggestion in the spec that a dialog 
> must be presented because of this seems like too tight a constraint on 
> the browser UI.
> 
> We discussed whether this information should be in an external file 
> pointed to by a <link> element or whether it should be <meta> data or 
> something else in the <head> section.
> 
> One possible problem is that if the "make application" command only 
> shows up in the browser chrome then some web developers will feel the 
> need to create a page that essentially draws a big arrow in the client 
> area pointing at where they think the UI is likely to be positioned. I'm 
> not sure if the potential click-jacking risk is worth trying to avoid 
> this though.

On Mon, 10 Aug 2009, Jonas Sicking wrote:
> 
> I agree that there's a risk that sites will render big red pointing 
> arrows in an effort to get users to click the magic "install as 
> application button". And I'm quite certain that especially for browsers 
> without majority marketshare these arrows will effectively be pointing 
> every which way except where that magic button is actually located.
> 
> However unfortunately I think that the alternative that HTML5 currently 
> provides is worse as it will result in users suddenly being presented 
> with hard to understand dialogs where a fatal guess as to which button 
> will get rid of that annoying dialog will result in phishing and malware 
> websites being permanented on the users desktop.
> 
> In all seriousness though: By putting the button into the web page 
> people are inevitably going to want to style it. If we allow that then 
> it's going to be trivial to trick the user to clicking the button, 
> leaving the dialog as the only defense mechanism. And I think that it's 
> pretty accepted that all too many users don't read dialogs but instead 
> more or less randomly click the button that they think will lead them to 
> the desired content (or simply get rid of the dialog).
> 
> If we don't allow the button to be styled we're in a situation where the 
> site author isn't happy with a "ugly" button, while the user is still 
> exploitable to click-jacking attacks.

On Mon, 10 Aug 2009, Maciej Stachowiak wrote:
> 
> The <bb> element was originally added in part based on a request from 
> Apple, so I feel that I should comment. We had multiple comments from 
> developers of web applications that our old "Save as Web Application" 
> feature would be more useful if they could have more visible UI, ideally 
> inside the page, to let users trigger the save. There would, in any 
> case, still be user confirmation.
> 
> We were not envisioning an element for this originally - an API 
> (restricted to being triggered by user actions) seemed more appropriate. 
> Since then, we've temporarily set aside the "Save as Web Application" 
> Safari feature, and it's not included in Safari 4. We may bring it back 
> in a later Safari release, but we need time to work through the user 
> interaction issues to make it a really good experience. So we don't have 
> a short-term need for this functionality or immediate plans to implement 
> <bb>.
> 
> As for the recent comments proposals on this:
> 
> - The idea of a declarative way of marking something as installable.
> 
> Our old feature allowed a user to save absolutely anything as a 
> standalone Web Application if they chose to, even without content author 
> opt-in. So a declarative facility would not have much direct impact. 
> What might be plausible is to add additional, more visible UI as part of 
> the browser chrome, only when a declarative tag is present.
> 
> One possibility: the presence of <meta name="application-name"> could be 
> used as the declarative trigger.
> 
> - Security issues.
> 
> I think the security/spoofing issues are minimal, since active user 
> confirmation is required, and the cost of installing a standalone Web 
> app (at least in our implementation) without using it was low - all the 
> user has to do is delete it if they don't want it. That being said, it's 
> true that any privileged in-page UI is a risk.
> 
> [...]
> 
> My personal recommendation would be to remove <bb> for now, since 
> implementors are not yet sure if it is the right approach, and are still 
> exploring what to do in terms of the app installation experience. We can 
> add something once we have enough implementation experience to know what 
> makes sense in this area.

I've removed the <bb> section for now.

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

Received on Friday, 14 August 2009 10:34:00 UTC