584544 - remote site whitelist / blacklist for webgl

Status: RESOLVED WONTFIX

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Christopher Blizzard (:blizzard)]

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.

Comment 1

[[Baboo]]

CAPS?

Comment 2

[[Baboo]]

Oops, sorry I meant "permissions.sqlite", I got those mixed up.

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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".

Comment 4

[Jesse Ruderman]

If that's the case, this bug probably shouldn't be in the AMO Blocklisting component.

Comment 5

[Daniel Veditz [:dveditz]]

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
  javascript
  downloadable fonts
  video
  audio (or combined with video into "media"?)
  plugins (or combined with video as "media"?)
  WebGL
  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?

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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.

Comment 7

[Daniel Veditz [:dveditz]]

is there a different bug for an in-product (permission manager?) whitelist/blacklist for WebGL? Do we have it already?

Comment 8

[avamander]

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.