Click to play, the next big problem for many smaller, companies

Richard Bateman richard at batemansr.us
Mon Sep 9 23:35:58 UTC 2013


Larissa,

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.

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?

Thanks, and thanks for your patience!

Richard


On Mon, Sep 9, 2013 at 4:47 PM, Larissa Co <lco at mozilla.com> wrote:

> On 9/9/13 2:04 PM, firefox-dev-request at mozilla.**org<firefox-dev-request at mozilla.org>wrote:
>
>> My proposal, once again, for a compromise:
>>
>> * Block all hidden plugins by default, *but*, have a persistent and
>> visible
>> notification of some sort that indicates what happened and prompts for
>> user
>> action.
>>
> 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).
>
> 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.
>
>> * Allow the user to indicate "never show for this plugin"
>>
> 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.
>
>> * Blacklist specific plugins that are known to have a lot of security
>> issues, such as Java, so that they revert to the current less obnoxious
>> behavior.
>>
> 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.
>
>>
>> To my mind, this solves most of the concerns and compromises on others:
>>
>> * In cases where a plugin is required for page functionality, users will
>> never be left without that functionality and not knowing what is wrong
>> * Compromised ad networks that use java to spread can be blocked without
>> hurting the user experience
>> * All hidden plugins are at least blocked by default, making it much more
>> likely that plugins that aren't blacklisted but are being used maliciously
>> will be stopped.
>>
>> No, it isn't perfect, and it doesn't solve all of the problems, but it's
>> the closest I can figure out how to come to solving the problems you wish
>> to solve without causing a situation where all of us using plugins have to
>> start recommending that their users don't use firefox anymore.
>>
> 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.
>
> Larissa
>
> ______________________________**_________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/**listinfo/firefox-dev<https://mail.mozilla.org/listinfo/firefox-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20130909/26d3ce91/attachment.html>


More information about the firefox-dev mailing list