InformAction Forums

Hey,

Lately I see myself using more and more WebGL, and allowing it in NoScript is a real pain. It would be very nice if it was a simple as allowing a Flash app: One click on a placeholder, eventually allowing JS on 1st party too.

But WebGL is hidden all too often and you have to:
- Allow 1st party JS
- Reload if NoScript is not set to auto-reload, and go to NS menu
- Move to blocked objects and find out WebGL for the website you're on
- Sometimes you also have to allow sound files, which is even more annoying if there are several mimetypes in use. (NS Menu > Blocked object for each and every type on top of allowing WebGL itself)
- Reload once more

With Flash, if the site is done properly you only have to click the placeholder once to get it running. At worst, allow JS, reload and click placeholder.

It would be nice that NoScript:
- Displays the WebGL placeholder more often. For some reason it is currently very rare even if 1st party JS is allowed. When really impossible to display a placeholder, allowing WebGL should be accessible as a 1st level item in NS drop down menu
- Assumes that clicking a WebGL placeholder or allowing it from the menu implies allowing JS for the host
- Assumes that sound files like OGG, MP3 and stuff are allowed as well
- Ideally it shouldn't require a page reload to get it running once allowed (like Flash), but since WebGL is not a plugin I don't know how feasible this is.


Finally, but that is a different feature, we should be able to see a WebGL app in the UI white list or elsewhere to make it easier to revoke permissions. Ideally, all (temp-)allowed blocked objects would appear individually in a list, and NS would infer which object belong to a WebGL app and display them under a tree architecture with the usual "+" button.


What do you guys think ? The first part is direly necessary IMO. The second is something I've wished for long before WebGL (without the tree architecture thing), but could live without I guess. It's gotten worse because of the difficulty to allow WebGL though - but if that is fixed then ceases being "worse" and gets back to just being inconvenient

URLs ?

This is a good all around example but beware, it's a game Mozilla made as a demo and performance test, so it will lock up Firefox if your computer is slow.
https://developer.cdn.mozilla.net/media ... /game.html



This example shows the trouble of allowing WebGL and OGG files. No MP3 or MP4 here, but you have to allow OGG not only for the first party site, but also for blob: and data:audio (this is unusual). It gets even worse because you can't allow all OGG data:audio, it has to be one file at a time... which is yet even more problematic because the NS menu is closed after allowing one blocked object item.
Or you can allow * on the domain, but that's not ideal.

This example also shows how reloading gets especially annoying with all the asset preparation that 3D often involves.


I absolutely love NoScript, just pointing out that there's quite some work to be done in this area
With a Flash equivalent all game resources would be allowed mostly with a single click. The barrier to entry for a WebGL app or game is pretty high for NoScript users :/


[EDIT: It seems that blob: and the bunch of data:audio blocked items disappear after you've allowed OGG for the domain and reloaded, although it doesn't show right away in NS menu, they still appear without a reload]

WebGLee wrote: This example shows the trouble of allowing WebGL and OGG files. No MP3 or MP4 here, but you have to allow OGG not only for the first party site, but also for blob: and data:audio (this is unusual). It gets even worse because you can't allow all OGG data:audio, it has to be one file at a time... which is yet even more problematic because the NS menu is closed after allowing one blocked object item.
Or you can allow * on the domain, but that's not ideal.

That wasn't my experience; I just allowed video/ogg@https://developer.cdn.mozilla.net (3rd menu option), and that was that. No sign of data:audio (and isn't blob: on the default whitelist?)

Read my edit about that

In the end you still need to:
- JS
- (auto-)reload
- WebGL
- (auto-)reload
- Various assets mimetypes, one type at a time (fortunately, not one asset at a time)
- (auto-)reload

Sometimes mimetypes aren't requested by the game/app early, so you'll basically have to allow it and reload the whole game to get that asset running. Sometimes, probably depending on how the game/app deals with loading, you won't need to reload.

I don't understand how you can think this is okay lol. But even if you don't agree, could you please make Giorgio aware of this ? It's okay if he doesn't intervene in this thread as long as he can consider the issue and decide if it's worth development time (it totally damn is, but that's just IMO :p).

If you guys need more examples to feed your decision I'm ready to dig some more

WebGLee wrote: But WebGL is hidden all too often and you have to:
- Allow 1st party JS
- Reload if NoScript is not set to auto-reload, and go to NS menu
- Move to blocked objects and find out WebGL for the website you're on
- Sometimes you also have to allow sound files, which is even more annoying if there are several mimetypes in use. (NS Menu > Blocked object for each and every type on top of allowing WebGL itself)
- Reload once more

Maybe you should enable WebGL for all script-allowed sites, in Options-Embeddings?

And if the other embeddings are a problem, you could also disable 'Apply these restrictions to whitelisted sites too'.

The fact of the matter is, when a page uses many distinct components, NoScript is going to manage them as distinct components. Flash is one-click because it's a black box that can do anything once allowed. IMO, WebGL is being more considerate to the user in this regard (although it may be inconvenient when you really wanted to blanket-allow).

It would be nice that NoScript:
- Displays the WebGL placeholder more often. For some reason it is currently very rare even if 1st party JS is allowed.

I can't comment on the technical aspects of that; I'm not sure why it is, or whether it can be changed.

When really impossible to display a placeholder, allowing WebGL should be accessible as a 1st level item in NS drop down menu

Why should it be more important/prominent than other types of blocked object?

The menu can often get quite crowded as it is...many people would love to find a way to shrink it.

- Assumes that clicking a WebGL placeholder or allowing it from the menu implies allowing JS for the host

Not a bad idea. I'm not sure how you'd incorporate it into the dialog, but it does make sense.

- Assumes that sound files like OGG, MP3 and stuff are allowed as well

There is already an option in the Blocked Objects submenu to allow * for a domain. If the user has instead clicked on an individual placeholder, I don't think this behavior should be assumed.

- Ideally it shouldn't require a page reload to get it running once allowed (like Flash), but since WebGL is not a plugin I don't know how feasible this is.

Sadly not AFAIK. Although the recent changes to inline script behavior might have changed this situation?

Finally, but that is a different feature, we should be able to see a WebGL app in the UI white list or elsewhere to make it easier to revoke permissions. Ideally, all (temp-)allowed blocked objects would appear individually in a list, and NS would infer which object belong to a WebGL app and display them under a tree architecture with the usual "+" button.

Ah, trying to solve the problem of "What is a web application?" If you come up with good algorithms for inferring this, I'm sure Giorgio and a stack of other people will want to talk to you .

Sorry if this sounds obstructionist. I actually think the WebGL demo you linked to is pretty cool (although the mouse controls were so over-responsive that the bots were absolutely crushing me). But in general, I'm not convinced that it should be treated differently to other types of objects (other than its dependence on JavaScript).

Thank you for the detailed reply

Maybe you should enable WebGL for all script-allowed sites, in Options-Embeddings?

And if the other embeddings are a problem, you could also disable 'Apply these restrictions to whitelisted sites too'.

I'm considering the first option as a temporary work around, although I'm not a fan. Allowing WebGL is I think potentially more dangerous than allowing only JS. (And any real use of WebGL requires JS anyway)

Disabling restrictions to whitelisted sites is also out of the question for me.

The fact of the matter is, when a page uses many distinct components, NoScript is going to manage them as distinct components. Flash is one-click because it's a black box that can do anything once allowed. IMO, WebGL is being more considerate to the user in this regard (although it may be inconvenient when you really wanted to blanket-allow).

I understand the difference and the technical reason why NoScript currently is so inconvenient to deal with when it comes to WebGL app and games. I'm saying something should be done to fix it: From a user perspective, allowing WebGL necessarily means that they accept JavaScript. If it's a game, it also means that they are accepting all sound, whether Web Audio of HTML5 Audio, no matter its mimetype. Over the years I haven't encountered a single situation where I didn't want JS and sound yet wanted WebGL.

I've seen video file types like MP4 used quite often but I guess these are to be pondered on separately.
For other resources that some apps and games may load like say, ZIP or 3D models such as 3DS, OBJ, FBX..., this is another question. If it's not something that is executable by the browser, what is the risk of allowing them at the same time WebGL and JS are allowed ?

It would be nice that NoScript:
- Displays the WebGL placeholder more often. For some reason it is currently very rare even if 1st party JS is allowed.

I can't comment on the technical aspects of that; I'm not sure why it is, or whether it can be changed.

That possibly has to do with the <noscript> element. The developer put it here to help the user figuring out what's wrong, but it works the opposite way with NS users in WebGL's case. :/

When really impossible to display a placeholder, allowing WebGL should be accessible as a 1st level item in NS drop down menu

Why should it be more important/prominent than other types of blocked object?

The menu can often get quite crowded as it is...many people would love to find a way to shrink it.

Right. Another idea would be to make the "Blocked Objects" menu NOT close when an item is allowed. After all the main menu doesn't close either, even with auto-reload turned on I think.

There is already an option in the Blocked Objects submenu to allow * for a domain. If the user has instead clicked on an individual placeholder, I don't think this behavior should be assumed.

Allowing * is a bit violent though. I'm not sure I would want that when I only want to play that WebGL game or use that app.

IMO this needs to be thought about from both a user and security perspective and cover both grounds. What does it mean for the user to allow WebGL ? It means JS and sound obviously, so we should make sure these are allowed and run as smoothly as possible (i.e. with the least amount of user interaction and page reloads possible).
Then what ? WebGL may want 3D models, ZIP or whatever. As I said these are not executable by the browser, they are to be parsed by JS, and JS is allowed. Is it safe to auto-allow such mimetypes then ? (hint: I don't know :p)
Then what about video. It IS executable by the browser, and the user may not want to allow it when he turned WebGL on.

Finally, the things we can't auto-allow need to be more user friendly to allow. (as little user interaction and as few page reloads as possible)

But in general, I'm not convinced that it should be treated differently to other types of objects (other than its dependence on JavaScript).

Because WebGL is not an object. WebGL means you do have an app on your hands, with all its dependencies. JS is the indisputable one and sound is not very far behind

WebGLee wrote:Allowing WebGL is I think potentially more dangerous than allowing only JS. (And any real use of WebGL requires JS anyway)
...
From a user perspective, allowing WebGL necessarily means that they accept JavaScript. If it's a game, it also means that they are accepting all sound, whether Web Audio of HTML5 Audio, no matter its mimetype. Over the years I haven't encountered a single situation where I didn't want JS and sound yet wanted WebGL.
...
I've seen video file types like MP4 used quite often but I guess these are to be pondered on separately.
For other resources that some apps and games may load like say, ZIP or 3D models such as 3DS, OBJ, FBX..., this is another question. If it's not something that is executable by the browser, what is the risk of allowing them at the same time WebGL and JS are allowed ?
...
IMO this needs to be thought about from both a user and security perspective and cover both grounds. What does it mean for the user to allow WebGL ? It means JS and sound obviously, so we should make sure these are allowed and run as smoothly as possible (i.e. with the least amount of user interaction and page reloads possible).
Then what ? WebGL may want 3D models, ZIP or whatever. As I said these are not executable by the browser, they are to be parsed by JS, and JS is allowed. Is it safe to auto-allow such mimetypes then ? (hint: I don't know :p)
...
Because WebGL is not an object. WebGL means you do have an app on your hands, with all its dependencies. JS is the indisputable one and sound is not very far behind

This raises the interesting question of whether some content types should be considered subsets of / subordinate to others. It makes sense that WebGL implies JavaScript, and can do JavaScript+more. Do you think it would also apply to other types? I wouldn't think anything plugin-based (Flash, Java) could be automatic, since you might have good reasons for blacklisting a vulnerable plugin. But perhaps the others - audio, video, frames - should have a hierarchy. If Flash is allowed, then probably HTML5 video and audio should be.

It's worth discussing.

Right. Another idea would be to make the "Blocked Objects" menu NOT close when an item is allowed. After all the main menu doesn't close either, even with auto-reload turned on I think.

I'm not sure whether submenus can be sticky, but if so, it's probably somewhere on Giorgio's to-do list.

Thrawn wrote:This raises the interesting question of whether some content types should be considered subsets of / subordinate to others.

No. Let's not have NS start making non-intuitive security decisions for the user.
I think WebGLee's point is that since WebGL isn't an embedding in the standard sense, it makes sense for NS to (optionally) give WebGL's dependencies special treatment, allowing them at the same time as the WebGL.

Thrawn wrote:Do you think it would also apply to other types? I wouldn't think anything plugin-based (Flash, Java) could be automatic, since you might have good reasons for blacklisting a vulnerable plugin. But perhaps the others - audio, video, frames - should have a hierarchy. If Flash is allowed, then probably HTML5 video and audio should be.

Again, please no non-intuitive auto-allow hierarchies. Everything in the Embeddings tab is there because those things are potentially a security threat. armorgames.com for example currently requires you to allow only one Flash object to play the games. Just because I want to allow that Flash object, does that mean I should necessarily also allow the two audio clips on the page, exposing myself to more potential danger, even though I don't need or want them at all?

The only exception to my reasoning here, is the pairing of WebGL+HTML5 audio/video mentioned by WebGLee. And I think even that should be hidden behind about:config preference (maybe noscript.WebGLImpliesAudio and noscript.WebGLImpliesVideo?) and these "unusual" auto-allows should be logged to the Error Console.

Yeah, WebGL is special here. It's useless to allow WebGL alone because JavaScript is mandatory to pilot everything. Sound can be avoided for applications but is quite mandatory for games.

Implementing this IMO is super urgent, especially if the Blocked Objects menu keeps closing after one item is allowed. It's starting to drive me nuts . Other users will just be driven away from WebGL games or decrease their NS security to be able to play.

Now as Barbaz said, pairing other authorisations than WebGL+JS+Sound is tricky. Just like him, when I allow a Flash game or video I do not want all the videos of that page to be allowed. Ideally I would mirror this "allow only that game" behaviour to WebGL, but it isn't possible because JS and sound are for the whole page. (That's why I will miss Flash btw)

So far I only see one other pairing that would be justified, it's HTML5 games. I mean canvas. Well, non-WebGL canvas. They'll need JS and sound, but I think they don't even have a placeholder so you basically have to allow JS and see if indeed there was supposed to be a game there. Since both WebGL and normal HTML5 games use <canvas>, maybe NoScript can put a placeholder (or menu item) based on that, and tie allowance of this item to JS and sound ?

That brings me back to the issue where NoScript very rarely displays such placeholders. (Because I guess, they are shielded or their dimensions are shielded by JavaScript)


So to sum up the goals in the form of "user stories":
- As a security conscious user who wants to play a game, I expect NoScript to give the game access to all the resources it needs, so that I can experience it smoothly and in its entirety.
- As a security conscious user who wants to play a game, I wish NoScript to do everything technically possible to protect me from the other crap that may live on the game web page, so that only my request "Allow this game." is fulfilled, and nothing more. <--- Compromise is necessary here, but you get the idea
- As a security conscious user who wants to play a game, I do not want to click more than twice before being able to play smoothly. I would also appreciate no page reload or, failing that, only one. I would want things that way so that I do not have to choose between weaken my security settings and renouncing to play.