Benjamin Smedberg wrote: > Talking about click-to-play has been complicated, because we have > several parallel goals and efforts: > > * Make users more secure by blocking known-unsafe version of plugins > * Give users control by having them opt in to "new" plugins that are > found on their machine > * Make Firefox faster and less crashy by reducing the number of > plugin instances that users see
Generally, I agree with these points but it depends on what you consider a known-unsafe plugin. For example, I consider *all* versions of Java, even ones without known exploits, to be known-unsafe, based on the historical track record. But, also, Java and Flash make the news the most because of their huge marketshares, but that doesn't mean that they are less safe than other plugins. Consequently, I don't think "known-unsafe" is the right distinction to make. In particular, I am concerned about the distinction between time between when a plugin begins to be exploited vs. the time we find out that the plugin is being exploited vs. the time when we actually secure the user. If we look at bug 829111, we can see that we filed the bug to CtP Java on 2013-01-10 and the blocklist update was made the next day, which means that most users probably received the blocklist update within 48 hours of us becoming aware of it (if they were using Firefox during that time period). I think that is actually as good of a response time as we reasonably expect with our current procedures. But, the big unknown is always "was this vulnerability being exploited before we knew about it, and if so for how long?" And, we really don't have any way of answering that question. In these cases of very longstanding bugs, we should assume that the people exploiting them have known about them long before we do. Thus, it is important to protect users as much as possib le BEFORE we even definitely know there is a problem. > Another issue with the current UI is that because the click-to-play > UI is in-content, it is relatively easy to construct a website which > "clickjacks" the user into activating a plugin even if they didn't > mean to. The security team has proposed that when a plugin is known > to be insecure, we should not simply accept a single click on a plugin > instance, but instead the user should activate the plugin from the > doorhanger UI instead (which is not clickjackable). This is covered > in bug 832481. Larissa Co from UX is currently in the process of > understanding the interaction model here and coming up with the best > design. I agree with this. Because clickjacking the in-content UI seems simple for somebody who can create exploits for plugin vulnerabilities, we cannot rely on the in-content UI as a security mechanism to protect the user from a vulnerable plugin from being exploited. And, because of what I said above about it being unreasonable to wait until we know of a vulnerability, that means we should have a clickjacking-proof UI as the default UI for CtP for as many plugins as possible (i.e. everything except Flash). > The last issue that has come up is how we deal with small or hidden > plugin instances. This is mostly a problem with Flash, because > invisible Flash instances are commonly used by websites for various > reasons, including playing music (Pandora), playing noises (Chat), > fancy file-upload controls (facebook/wordpress), and advertising > trackers (many big news sites). Striking the right UI balance here > has been very difficult. Users always have the option of enabling > all Flash on a page by clicking the plugin icon in the location bar. > But most users don't notice this UI, and even if they do they don't > know what it's for. I think it is important that we don't water down the security properties of this feature for non-Flash plugins just so that we can do something reasonable for Flash. I'd rather we accept the unfair reality that Flash needs to be treated specially; i.e. only allow the in-content activation and/or in-content "always allow for this site" for Flash. > Finally, although this is not directly related to click-to-play, we > are planning on removing the Plugin Finder Service (PFS) from Firefox. > Previously when Firefox encountered web content which needed a > plugin, it would prompt the user to install the plugin. Instead, we > are now discouraging users from using browser plugins, and want to avoid > this prompt. I agree with this strategy. However, please give a heads-up to Mozilla China. When I was at the China office two years ago, getting more plugins to be in the plugin finder service was a high priority for them, because ActiveX and plugins are much more common in China, and are frequently mandatory for online banking, etc. Also, I hope that we can eventually make it easier for for users to find out how to make Flash click-to-play. I purposely force myself to use Firefox without Adblock Plus, noscript, or Flashblock so that I can experience what a "typical user" experiences. Performance (jank and hangs) that I can attribute to Flash are the most common reason for me to be forced to restart my browser (or, typically, kill the Flash process). Less knowledgeable users are just going to blame Firefox for being slow, hangy, and janky. FWIW, I cannot bring myself to have the Java plugin installed at all, because the risk:reward ratio for it is so terrible. But, I do know that there are very popular sites like Minecraft are based on Java, so I understand why many users want to have it. Cheers, Brian _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
