Closed Bug 387285 Opened 17 years ago Closed 14 years ago

Hook up support for plug-in blocklisting (blacklisting)

Categories

(Camino Graveyard :: Plug-ins, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: alqahira, Assigned: stuart.morgan+bugzilla)

References

Details

Bug 330511 is finally adding support to blacklist/disable plugins (something we could have used on that broken version of RealPlayer, for instance) on a backend level.  We'll need to do stuff in app-level code to use it, AFAICT, so that's this bug.

(Bug 382367 might also be interesting.)
Summary: Hook up support for plug-in blacklisting → Hook up support for plug-in blocklisting (blacklisting)
I have the skeleton of the service implemented, but I still need to do the actual blocking.

Do we want to add some of the older bad plugins to an initial blocklist, in case people haven't updated? I'm thinking of the bad range of F4M, for example.
Assignee: nobody → stuart.morgan+bugzilla
(In reply to comment #1)
 
> Do we want to add some of the older bad plugins to an initial blocklist, in
> case people haven't updated? I'm thinking of the bad range of F4M, for example.
Yes. The bad F4M certainly, and maybe older Flash (9 and maybe 10.0) for those few users who don't bother upgrading their the OS.
To capture from IRC, we may well not do any UI for blocked plugins in 2.1, which would influence how aggressive we want to be with blocking; if we block old Flash, people are going to wonder why Flash suddenly stopped working. Flip4Mac seems more reasonable to me given that it's not so widespread, and that the consequences of not blocking it are more severe UX-wise.
Actually, it looks like we get in-place UI for free with the blocklist ("This plugin has been blocked for your protection"). So we can block lots of things ;)
Ew, that comes from a DTD, so it's not localizable :(  

Regardless, we'll probably want to fork that file and it fix up for Camino style, and add a URL to the plug-ins section of our Setup page so that people can at least get links to a current version.

So, I'd definitely block Flash 9 and the old RealPlayer version (if we can figure out the version number associated with the plug-in was).  And I agree about the F4M versions; we should block everything older than 2.3.6.5, as long as 2.3.6.5 appears to work fine on 10.4 (one of the two reasons we switched back to 2.2.3.7 was that it worked better on 10.4 than the newer ones, which introduced the hanging bug); if not, I'd block everything between 2.3.6.5 and 2.2.3.7, and then everything older than 2.2.3.7, so that we leave 2.2.3.7 available for 10.4.

We still see startup crashes (they spiked again recently, though not nearly as high as when I filed the bug) due to the Facebook plug-in (bug 548197), so it might be worth blocking it (or it might not).
Bug 558432 has the service implementation but with no actual blocking; we'll add blocking after it lands.
(In reply to comment #5)
> Ew, that comes from a DTD, so it's not localizable :(  
> 
> Regardless, we'll probably want to fork that file and it fix up for Camino
> style, and add a URL to the plug-ins section of our Setup page so that people
> can at least get links to a current version.

Yeah, we're going to have to fork that file, because the disabled UI is "The plugin for this content has been disabled. Click here to manage your plugins."

Bug 626142
Filed bug 626477 for continuing discussion of what exactly to block; closing as fixed since bug 558432 provided the facility for blocking in general.
OS: Mac OS X → Windows 7
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
OS: Windows 7 → Mac OS X
Hardware: PowerPC → All
You need to log in before you can comment on or make changes to this bug.