This is exactly the reason why the webgl standard strictly forbids allocating buffers without clearing them first. Otherwise anything the user looked at since the last power cycle - including emails, passwords, private keys, ... -could be extracted by visiting a website.

How long until we see the first infoleak bug where some combination of OS+driver+browser+webgl-command-sequence misses a buffer to clear - or "optimizes" it away - or fails to bounds-check a texture coordinate - etc? :)

We've already had these kinds of issues with webgl. Here's one that I found through some googling: http://www.cvedetails.com/cve/CVE-2014-3173/

You don't need webgl for this kind of infoleak either, regular good old 2d canvas also supports allocating memory. It also supports reading the current state of all of the pixels in the buffer through Javascript, so if you have an exploit that gets you an uninitialized canvas you can easily send whatever memory contents you got back to your server for later analysis.

Not always. I was trying to write an android application to serve as a frontend to a site by launching a background webview, drawing the elements I'm interested to a canvas and sending the pixels back to the application. (Un)fortunately, after you draw an HTML DOM element to a canvas, you're forbidden from reading the canvas pixels back and there's no flags you can set on the webview to let you do it.

Indeed, if the data in a page's canvas has a different origin, you're not allowed to read pixels back (http://www.w3.org/TR/html/scripting-1.html#security-with-can...).

If the DOM element you draw has the same origin as your canvas it seems like (from my reading of the spec) you should be allowed to do what you describe.

It's called a bug. It gets fixed. There's nothing special about this type of bug any more than any bug in the browser.

Remote screenshoting of hours old content across distinct local user accounts is perhaps more serious than many other bugs, especially when there seems to be a blame game going between the app/os/gpu vendors.

And in the mean time you share your porn with NSA for few years.

Well, the problem is it isn't a single bug, WebGL is an entire minefield of bugs. OpenGL drivers were generally never written with security in mind, and now all of a sudden we've got untrusted code able to poke away at them.

WebGL being enabled by default is insanity in my opinion.

RE your edit, there is a reason incognito mode is also known as "porn mode". It's primary use case - that obviously can't be stated officially - is to let you browse porn without fear that your mom / girlfriend / boss will find out by checking your browser history or having the site's URL show up as a suggestion when typing something in the address bar. It has never been a serious security tool.

Obviously. It does have another use case too, for developers, it's an easy way to run parallel login sessions on webapps without stomping over cookies. :)

True; I often do exactly that :).

And it would be great to have more than one incognito mode for that purpose precisely (to be able to run more than two sessions).

Chrome has "profiles" you can use to log into multiple sessions simultaneously. Not sure if you can combine it with incognito mode.

I use QupZilla because this is its default configuration (every window is a separate multi-tab [incognito] session). Not so great last time I checked on the Mac but one of my favorites on the PC.

https://www.qupzilla.com/

AFAIR on Chrome the session does not propagate between the tabs that don't share history (i.e. separately created, not one spawned by the other).

Session is shared across all incognito tabs. Firefox behaves the same way. Even if you close any incognito tabs and then open a new one, it's still on the same session. You need to completely restart the browser (or explicitly clear history) to clear.

Are you sure of that? When I have an amazon tab with a basket full, create a new tab and go on amazon I see the same basket.

I don't have Chrome on the machine I'm using now so someone else needs to check it. But I vaguely remember running at work several sessions to the same service in separate incognito windows and maybe even in multiple tabs of the same window. Now that I think of it, I'm not sure about the latter scenario.

Both scenarios use the same session.

Shares them across all incognito tabs for me.

Yeah. I wish all apps had an incognito mode for this reason.

Imagine being able to open an incognito terminal to type commands that won't get saved to history or pollute what you already have.

In bash (and probably others) commands prefixed with space are removed from history. (it's a setting - google HISTIGNORE )

You can:

    unset $HISTFILE

I thought incognito mode was introduced as a “solution” to a security problem, namely browser history leak via :visited link style that is nearly impossible to fix without without violation of one of the oldest specifications of the Web. At least that's what it looked like then.

People considered it a profile switching for dummies, now no one remembers that browser can have multiple profiles.

> read old buffers back into javascript variables

As I understand it, this is not how frame buffers work. All they contain is the rastered data to drive the a given frame.