Nvidia Blames Apple For Bug That Exposes Browsing In Chrome's Incognito (venturebeat.com)

An anonymous reader points out this story at VentureBeat about a bug in Chrome's incognito mode that might be a cause for concern for some Apple users. From the story: "If you use Google Chrome's incognito mode to hide what you browse (ahem, porn), this might pique your interest. University of Toronto engineering student Evan Andersen discovered a bug that affects Nvidia graphics cards, exposing content that you thought would be for your eyes only. And because this only happens on Macs, Nvidia is pointing the finger at Apple."

Comments

Except it's not.

[Anonymous Coward]

This isn't just on Apple's OS. While I have nothing like Mr. Andersen's writeup to prove it, I've seen this kind of bug happen on Windows.

Re:Chrome?

[Anonymous Coward]

No, his reason is that sweet sweet +5 insightful. We don't need your facts around here.

Re:You're doing it wrong

[WarJolt]

>> I didn’t expect the pornography I had been looking at hours previously to be splashed on the screen

I think you're either doing it wrong or you're not looking at the right stuff. (Hours? Really?)

Not everyone's a minute man, Johnny Boy.

Blame Chrome

[pushing-robot]

Chrome advertises its Incognito mode as leaving no traces behind. Therefore, it should be responsible for wiping its framebuffer, just as it clears caches, cookies and history. It's like writing a file shredder that doesn't actually overwrite files, then blaming the OS and hard drive manufacturer for the oversight.

It might be nice if framebuffers and such were zeroed on release, but like overwriting files, it's a time/energy/security tradeoff. Besides, the screen isn't really protected anyway; IIRC applications on most OSes can capture the screen without even admin privileges. After apps are sandboxed into seeing only their own windows we can talk about securing the framebuffer.

Re:Simple explanation

[dgatwood]

Not really. An application will typically allocate and release memory all the time, being forced to clear it every time is massive overkill and a performance problem. The driver exposes the GPU memory, the OS allocates it to applications just like with RAM. It's the only one that knows when memory switches application context and must be cleared. So there's really only one sane solution.

The usual solution is basically:

• Whenever you add a new page into an application's address space, you map a zero-filled page as copy-on-write. If the page never gets touched, it is zero-filled, and you take the performance hit only when it ceases to be all zeroes.
• Small allocations are allocated using a pool allocator backed by those pages.

This works well as long as the CPU is in charge, ensuring that any dirty data must have originated in some other part of the app (by reusing a pool region). Where it starts to get hairy is when you have a GPU that has access to all of RAM and uses a separate page table with separate COW flags, etc.

I'm not certain what went wrong in this particular case. However, I do remember a really annoying change in about 10.6 or 10.7 where Apple stopped using a vertical blanking interrupt to control various aspects of the GPU's operation and maybe some other parts of the OS. This improved battery life, IIRC, but the result is that you'll often see the GPU draw a frame of video before the previous contents of VRAM have gotten wiped. I would not be at all surprised if that was what happened here.

As for whose responsibility it is to clear the memory, my gut says that if Chrome wants to guarantee that its video buffers are cleared, Chrome is responsible for doing it. Otherwise, it should assume that VRAM is a shared resource, and anything it puts in VRAM can potentially be accessed by any other app at any time for any reason. With that said, I'm open to other opinions on the matter.

This, this, this!

[tlambert]

Chrome advertises its Incognito mode as leaving no traces behind. Therefore, it should be responsible for wiping its framebuffer, just as it clears caches, cookies and history. It's like writing a file shredder that doesn't actually overwrite files, then blaming the OS and hard drive manufacturer for the oversight.

This, this, this!

If it's incognito, it should not trust anyone else to ensure the privacy of the user's data, not even the OS. We already know that it's possible to use CPU cache bugs as a covert channel to snoop on other processes running on your computer; if the application claims to maintain security, it needs to zero the memory itself.

As an aside, a GPU is a better machine for zeroing pages than the main CPU, and won't pipeline stall or time stall the main CPU by doing it, and GPUs are traditionally really good at manipulating large amounts of memory. So one has to wonder: why doesn't nVidia expose a primitive that Chrome can then use to zero the pages of a frame buffer, before or after it is used?

Re: It's your own fault Apple

[Anonymous Coward]

IOS saves screenshots of the applications for the task selector thingy and also for "fast" application switching where the screenshot is used for the zooming effect and as placeholder while the real application is still being (re)loaded. There is a separate screenshot for each orientation. It is possible that you launch or switch to the the browser or some other application and IOS will display a possibly very old screenshot of your private porn browsing session or some other private stuff that you had closed and purged from the logs ages ago. During the application switch effect the old screenshot is visible only momentarily but the same images can also be viewed from the task selector.

1. Device at orientation A: open browser, enter private mode and browse for some pron.
2. Switch to the home screen (screenshot it saved) and change to orientation B
3. Go back to browser and close all pron tabs
4. Switch to the home screen (screenshot is saved but this one is for orientation B)
5. Change back to orientation A and enter the task selector or go back to the application. The old private browsing screenshot should be visible.