<div dir="ltr">Larissa,<div><br></div><div>This sounds great. I am still concerned about the effect it will have on our users, but I do understand what you're trying to do which is why I've been trying so hard to find a good compromise. The only other question I have, until I see the new proposed interface (and I'll try to pay enough attention to give you some feedback on that), is whether or not this will make it into Firefox 26. The main reason I have been feeling impatient is that I know how release cycles work, and the impression I have is that currently the behavior in the firefox 26 nightlies is scheduled to be released; once it has been released in one version of firefox we have to deal with the consequences for years to come because some users refuse to upgrade.</div>
<div><br></div><div>Will this change make it into 26? If not, can we leave CtP off by default for another version until it does make it in?</div><div><br></div><div>Thanks, and thanks for your patience!</div><div><br></div>
<div>Richard</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 9, 2013 at 4:47 PM, Larissa Co <span dir="ltr"><<a href="mailto:lco@mozilla.com" target="_blank">lco@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9/9/13 2:04 PM, <a href="mailto:firefox-dev-request@mozilla.org" target="_blank">firefox-dev-request@mozilla.<u></u>org</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My proposal, once again, for a compromise:<br>
<br>
* Block all hidden plugins by default, *but*, have a persistent and visible<br>
notification of some sort that indicates what happened and prompts for user<br>
action.<br>
</blockquote>
I am willing to try a persistent and visible notification for hidden plugins rather than a disappearing one. I think the plan will be to prototype both and figure out if one is more makes more sense than the other (vague on the details because I have to find a way to put said plan in motion).<br>
<br>
Bsmedberg, perhaps since we haven't built a disappearing doorhanger yet, we should try to implement something persistent only for hidden plugins? (It will at least be more discoverable than the icon is right now.) But before we do this, we need to give the user a "continue blocking" option so that the doorhanger doesn't appear automatically if the user has made a decision one way or another. In the current doorhanger, the user's button choices are both "allow" choices; it's only if they click out of the doorhanger to we continue to block the plugin.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Allow the user to indicate "never show for this plugin"<br>
</blockquote>
I still think that an " allow long term" option will be good enough (right now inactivity is defined as 3 months of not visiting the site), especially for users who use the site frequently. We can extend the limits of what "long term" means once we get more data about how users react in the real world. Again, the intent here is to keep users protected from malicious plugins that could be introduced without them remembering that they allowed plugins on the site... especially if the site has been rewritten without plugins.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Blacklist specific plugins that are known to have a lot of security<br>
issues, such as Java, so that they revert to the current less obnoxious<br>
behavior.<br>
</blockquote>
not sure what you mean "so that they revert to the current less obnoxious behavior", but we are planning on distinguishing between regular plugins like yours, and plugins we believe are particularly vulnerable. For those plugins, we'll make it harder for the user to allow the plugin long term.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To my mind, this solves most of the concerns and compromises on others:<br>
<br>
* In cases where a plugin is required for page functionality, users will<br>
never be left without that functionality and not knowing what is wrong<br>
* Compromised ad networks that use java to spread can be blocked without<br>
hurting the user experience<br>
* All hidden plugins are at least blocked by default, making it much more<br>
likely that plugins that aren't blacklisted but are being used maliciously<br>
will be stopped.<br>
<br>
No, it isn't perfect, and it doesn't solve all of the problems, but it's<br>
the closest I can figure out how to come to solving the problems you wish<br>
to solve without causing a situation where all of us using plugins have to<br>
start recommending that their users don't use firefox anymore.<br>
</blockquote>
Thanks for the great dialog and for the suggestions. I want you to know that we do care about users and developers, and we're trying to do what's best for a huge, varied user base, even if sometimes it makes people unhappy :( Sorry if it's going more slowly than expected to implement improvements to the initial design.<br>
<br>
Larissa<br>
<br>
______________________________<u></u>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/<u></u>listinfo/firefox-dev</a><br>
</blockquote></div><br></div>