Closed Bug 584544 Opened 11 years ago Closed 11 years ago

remote site whitelist / blacklist for webgl


(Toolkit :: Blocklist Policy Requests, defect)

Windows 7
Not set





(Reporter: blizzard, Unassigned)



We need to add support for a webgl blacklist and possibly a whitelist as well. Depends on the implementation inside of Firefox - i.e. if we have an explicit whitelist or blacklist for people to use to enable and disable webgl.
Oops, sorry I meant "permissions.sqlite", I got those mixed up.
Wait, the word "remote" here is throwing me off -- we need to add support for a webgl enabled/disabled per-site capability.  But not one that we want to manage or serve remotely; it should be similar to "is this site allowed to load images" or "is this site allowed to use geolocation".
If that's the case, this bug probably shouldn't be in the AMO Blocklisting component.
Even if remote kill is wanted the bug shouldn't be in the AMO product, you're asking for a client code change to support this.

The permission manager is perfectly suited for what Vlad described in comment 3.

But why would a user want to manage WebGL on a per-site basis? I don't think we have a similar capability for <video> or other similar features, and we certainly don't for plugins where people have been crying out for it for years (until they give up on us and install FlashBlock). Is WebGL riskier than video? resource suckier?

Geolocation has a control because it's a privacy issue.

Image loading has a control for historical reasons, primarily performance and bandwidth in the dial-up/metered era. Valid reasons, but wouldn't users concerned about that want to lump all resource intensive features together?

I'm not at ALL against per-site control for WebGL, but I'm curious as to why you want it. I want it because I want it for everything
  downloadable fonts
  audio (or combined with video into "media"?)
  plugins (or combined with video as "media"?)
  images  (already have)
  coookies (already have)
  data storage (sort of have)

but since we're not doing it for many of the historical features what's the deal here?

Will WebGL start out disabled by default, so a per-site whitelist is the only way to get it?
Blocks: 596720
No longer blocks: 575738
I kind of agree here -- we shouldn't have a site blocklist for this.  Malicious sites can be handled by safe browsing.  So -> WONTFIX; object if you have objections.
Closed: 11 years ago
Resolution: --- → WONTFIX
is there a different bug for an in-product (permission manager?) whitelist/blacklist for WebGL? Do we have it already?
Product: → Toolkit
Could this be reconsidered? I find a whitelist would be extremely beneficial in terms of both privacy and security. WebGL is incredibly useful as a web technology but can cause plethora of different issues, as previously mentioned, a whitelist would allow giving access to webgl functionality only to those websites that are utilizing it with a use for the person using the browser. This would also mean people browsing on battery power do not have to worry about their GPU spinning up because some tracking script or ad network decided to render something.
You need to log in before you can comment on or make changes to this bug.