Re: ISSUE-131 (Code outside browser): Executing code outside of browser in 8.3.2.3 is vague / scary [All]

Just as a related FYI, we're adding plugin blocking to Firefox 3.  
Since Firefox 2 we've had the ability to block extensions which were  
identified as security vulnerabilities, and now we've added plugins to  
this list. Sadly, due to legal reasons surrounding software  
redistribution, we often won't be able to add a full automatic  
upgrade, though we'll be able to point users to a URL where they can  
get the upgrade.

See https://bugzilla.mozilla.org/show_bug.cgi?id=330511 for more  
details.

cheers,
mike

On 2-Jan-08, at 1:13 PM, Ian Fette wrote:

> Re: Flash, you may have a point there, but I am not sure I want to  
> give in just yet. For instance, with Flash - most users are going to  
> say "Well, if you can upgrade it and make it work, why the heck are  
> you asking me". A vocal minority may complain about the automatic  
> upgrade. Here at least though, someone could probably understand  
> what you're asking them to do.
>
> For Acrobat reader, 99%+ of users are going to be totally unable to  
> understand the distinction between the plugin's rendering part that  
> runs inside of the process, and the majority of the code  
> (acrord32.exe) that is running outside of the browser. They're going  
> to see a dialog that says "Blah blah blah do you want Acrobat reader  
> to work Yes/No" and they're going to think "Wow, that's a stupid  
> question." And that's a horrible thing, because it means you're  
> presenting the user with useless UI and creating a bad user  
> experience, which means that either the browser isn't going to  
> implement that (assuming they have UI standards about not bothering  
> the user with things they don't understand), or the user is going to  
> suffer.
>
> Another case in point about useless UI: the first time you submit a  
> non-encrpyed form. "Oh my god, you just tried to do a search on  
> Google. Are you sure you really want to submit this form? It's not  
> encrypted !!1!one!!1!" - I think that dialog was going away in FF3,  
> but I don't really remember. But it's basically all the same - it's  
> UI that 99% of the time is pointless and isn't understandable by the  
> user anyways, so why do it?
>
> On Jan 2, 2008 10:01 AM, Anil Saldhana <Anil.Saldhana@redhat.com>  
> wrote:
> Since I have never written a browser or a plugin, I cannot claim to be
> an expert in these two areas. :)  But I will still write what I think.
>
> It should not be difficult for a plugin writer to convey to the  
> browser
> that on a given platform (OS etc), the plugin will execute outside the
> browser context. Before the plugin kicks in, it can reflect this on to
> user (with a consent dialog) such that the user can always blame  
> himself
> in the end, for agreeing to execute the plugin. :)
>
> Now to the question of the browser popping up a consent dialog each  
> time
> a pdf is opened, the consent dialog can certainly have a "Remember my
> decision for this plugin xxx" such that you have a seamless pdf  
> viewing
> each time.
>
> All I wish for is when a plugin tries to do anything different from  
> what
> my expectations are (outside the browser context or upgrade
> automatically), I am told about it. In the case of the flash plugin
> upgrading itself, it is not very difficult for them to add a notice
> inside the flash movie chrome such as:
> "The execution of this flash movie requires that you upgrade your  
> flash
> plugin version to v10. We can do it automatically for you. Press Yes  
> if
> you agree. No to cancel".
>
> Ian Fette wrote:
> > I think there are a lot of things that suck, that could probably be
> > eventually fixed if browser vendors took a stand. Plugins are one  
> of them,
> > user agent strings are another (have you seen the iPhone user- 
> agent string?
> > "Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+  
> (KHTML,
> > like Gecko) Version/3.0 Mobile/1A542a Safari/419.3" This is  
> absolutely nuts,
> > and is huge overhead that is being transmitted everywhere. Apple  
> could take
> > a stand and say "This is stupid, we're just going to say "iPhone -
> > AppleWebKit", but then tons of sites would break due to crap code  
> doing
> > (often unnecessary) UA checking in a poor manner. Could apple  
> change these
> > things, like warning on plugins doing wacky IPC, crazy UA strings,  
> etc?
> > Sure. Would the responsible parties eventually fix it? Probably.  
> But who
> > suffers in the meantime? The user.
> >
> > I'm not sure I like requiring things that cause the user to  
> suffer, because
> > it means that either the user is going to suffer (bad), or the  
> browsers
> > aren't going to implement the change because it would cause the  
> user to
> > suffer (also bad).
> >
> > If we have problems with things like NPAPI, or plugin rights,  
> those should
> > be addressed somewhere, but I don't think that trying to slip them  
> in
> > WSC-XIT is the appropriate place to do so.
> >
> > On Jan 2, 2008 9:23 AM, Anil Saldhana <Anil.Saldhana@redhat.com>  
> wrote:
> >
> >> On many platforms, the acrobat reader opens the PDF within the  
> browser
> >> chrome (same tab on firefox).
> >>
> >> I think this is an important requirement from an user's  
> perspective that
> >> they be notified when a plugin tries to execute things outside the
> >> contract established between the user and the browser. I  
> understand that
> >> it is going to be extremely hard in getting it right. But until the
> >> browser vendors/implementers raise a red flag on this, I support  
> the
> >> retention of this bullet. :)
> >>
> >> I did recently mention the case of the Adobe flash plugin  
> automatically
> >> upgrading itself due to the new Flex software intentions. The  
> user has
> >> no control over the upgrade. Just because a flash movie requires an
> >> upgraded plugin, does not mean the user has no say in consenting  
> to the
> >> plugin upgrade. :)
> >>
> >> Ian Fette wrote:
> >>> As per our 12/12 meeting, I am proposing removing the third  
> bullet under
> >>> 8.3.2 - "Web user agents MUST inform the user and request  
> consent when
> >> web
> >>> content attempts to install or execute software outside of the  
> browser
> >>> environment". There are many things that make this hard /  
> impossible to
> >> get
> >>> right, and even harder to actually get the intended effect  
> without being
> >>> totally annoying.
> >>>
> >>> For instance, when you load a PDF, Acrobat Reader is launched  
> outside of
> >> the
> >>> browser context. Yet I don't really want a dialog box every time I
> >> browse to
> >>> a PDF, I just want to see the PDF. Same thing when I click on a  
> mailto:
> >> link
> >>> - it's going to get shell executed, and software (my MUA) is  
> going to
> >> run
> >>> outside the browser. Or if there's an embedded video that causes  
> the
> >> windows
> >>> mediaplayer plugin to do some funky COM stuff outside of the  
> browser -
> >>> again, I really don't want dialog boxes here. I understand the  
> intent
> >> and
> >>> think it's probably a good one, but it's really hard to actually  
> get it
> >>> right in words, and I think it's something that browsers are doing
> >> pretty
> >>> well anyways.
> >>>
> >>> I'm not going to rehash everything in this email, please see the  
> 12/12
> >> notes
> >>> for a full review of the conversation (
> >>> http://www.w3.org/2007/12/12-wsc-minutes.html ). In that  
> meeting, I said
> >> I
> >>> would email back on this issue and propose that the best way to  
> resolve
> >> it
> >>> is to simply remove the bullet point, unless anyone feels  
> strongly about
> >> it.
> >>> If you do feel strongly about it, then please come up with some
> >> alternate
> >>> text.
> >>>
> >>> Thanks,
> >>> Ian
> >>>
> >>> On Nov 6, 2007 8:36 AM, < michael.mccormick@wellsfargo.com> wrote:
> >>>
> >>>> The "install" part is very important, but the "execute" part is a
> >> rabbit
> >>>> hole we probably don't want to go down.
> >>>>
> >>>> For example, when I point IE at a resource of MIME type ms/xls,  
> Excel
> >>>> launches outside the browser as a helper app.  It would be  
> annoying if
> >> I
> >>>> got constant warning messages every time I pull up a XLS, PDF,  
> etc.
> >>>> Constant warnings = ignored warnings.
> >>>>
> >>>> I do want to be warned when a page tries to install a plugin like
> >>>> Acroread, but not every time that plugin runs.  Same for helpers,
> >>>> toolbars, extensions, ActiveX controls, etc.
> >>>>
> >>>> -----Original Message-----
> >>>> From: public-wsc-wg-request@w3.org [mailto:public-wsc-wg-request@w3.org
> >> ]
> >>>> On Behalf Of Web Security Context Working Group Issue Tracker
> >>>> Sent: Tuesday, November 06, 2007 9:50 AM
> >>>> To: public-wsc-wg@w3.org
> >>>> Subject: ISSUE-131 (Code outside browser): Executing code  
> outside of
> >>>> browser in 8.3.2.3 is vague / scary [All]
> >>>>
> >>>>
> >>>>
> >>>> ISSUE-131 (Code outside browser): Executing code outside of  
> browser in
> >>>> 8.3.2.3 is vague / scary [All]
> >>>>
> >>>> http://www.w3.org/2006/WSC/track/issues/
> >>>>
> >>>> Raised by: Ian Fette
> >>>> On product: All
> >>>>
> >>>> 8.3.2.3 says "Web user agents MUST inform the user and request  
> consent
> >>>> when web content attempts to install or execute software  
> outside of the
> >>>> browser environment."
> >>>>
> >>>> This is a bit vague and probably not what we intend. For  
> instance, when
> >>>> you navigate to a PDF on a browser using Acrobat Reader w/NPAPI  
> plugin,
> >>>> what happens is that there is a plugin running in the browser,  
> and then
> >>>> Acrobat Reader launches in the browser, and there's a ton of IPC
> >> between
> >>>> the plugin and Reader running in the background (which is doing  
> the
> >>>> heavy lifting). This is executing software outside of the browser
> >>>> environment, yet I don't think this is really what we were  
> intending to
> >>>> warn users about. At least, I will scream if I get a popup  
> every time I
> >>>> navigate to a PDF. Seriously.
> >>
> >
>
> --
> Anil Saldhana
> Project/Technical Lead,
> JBoss Security & Identity Management
> JBoss, A division of Red Hat Inc.
> http://labs.jboss.com/portal/jbosssecurity/
>