801806 - SecReview: Windows Plugin Hang UI

Status: NEW

(mozilla.org :: Security Assurance: Review Request, task)

Description

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

SecReview tracking bug
Actions regarding the review of the dependent bug should be tracked here.

Comment 1

[(No longer employed by Mozilla) Aaron Klotz]

Who is/are the point of contact(s) for this review?

Aaron Klotz
Benjamin Smedberg

Please provide a short description of the feature / application (e.g. problem solved, use cases, etc.):

When a NPAPI plugin hangs in Firefox, the main thread is blocked and the user interface becomes unresponsive. The purpose of this feature is to spawn a child process that is able to display a UI to the user. This UI should inform the user that a plugin is hung and provide an opportunity to terminate the plugin if he/she desires.

Please provide links to additional information (e.g. feature page, wiki) if available and not yet included in feature description:

https://wiki.mozilla.org/Features/Firefox/Windows_Plugin_Hang_UI

Does this request block another bug? If so, please indicate the bug number

N/A

This review will be scheduled amongst other requested reviews. What is the urgency or needed completion date of this review?

Ideally we'd like to land this patch for Nightly within the next week.

To help prioritize this work request, does this project support a goal specifically listed on this quarter's goal list? If so, which goal?

This supports the 2012 High-level Goal of improving user satisfaction and engagement. There is not a specific entry in this quarter's goal list for this project.

Does this feature or code change affect Firefox, Thunderbird or any product or service the Mozilla ships to end users?

Yes, it directly affects the NPAPI plugin interface in Firefox.

Are there any portions of the project that interact with 3rd party services?

Indirectly. This project is invoked when a 3rd party plugin hangs.

Will your application/service collect user data? If so, please describe

No user data collected.

Desired Date of review (if known from https://mail.mozilla.com/home/[e-mail]/Security%20Review.html) and whom to invite.

December 26, 2012

Please invite Aaron Klotz, Benjamin Smedberg, Vladan Djeric

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I am going to leave the decision as to whether this is a group or individual review up to dveditz. That said I think we need a bit of a level set on schedules. Getting this done in the next week is highly unlikely due the holidays in the USA that affect the availability of resources. 

There is no review slot on 26-Dec, that one was removed already due to the Christmas holiday. In fact I am going to remove all review slots that week as we know we have large amounts of PTO at that time.

It should also be noted that we announced some time ago (and in many venues) that all review requests filed after 15-Nov should expect to be scheduled for Q1-2013 due to team PTO and priority of other projects (B2G, mobile, etc). So unless there is a chance confluence of events that allows for an earlier review please expect to delay the landing of this until at least January.

Comment 3

[Benjamin Smedberg]

Just because the security team is backed up does not mean that all work should come to a stop. This code is highly important and can almost certainly be handled by asynchronous security review. In the meantime we do plan on landing this in the FF20 cycle.

And FWIW aklotz is a new employee and the code was just finished, so muttering about how this should have been scheduled sooner is definitely moot and rather inappropriate.

Comment 4

[David Mandelin [:dmandelin]]

How long does it take to perform a security review for a feature like this? It seems like a pretty simple feature and something that could be knocked off quickly.

Comment 5

[Daniel Veditz [:dveditz]]

This can land prior to a security review. There doesn't seem to be a lot to worry about here.