I think that maybe a viable interim workaround to flash's vulnerability problems would be to implement something like flashblock by default. There would have to be some "always show flash on *.google.com" whitelisting option (maybe automatically whitelist bookmarked sites?), and it would have to be an infobar style notification, since not all instances of flash are large enough/visible. But this would basically solve the problem of malicious flash on untrusted websites while not significantly hindering legitimate uses of flash.
Is something like this in progress or would it be considered? On Mon, Aug 10, 2009 at 05:50, Amanda Walker<ama...@chromium.org> wrote: > On Mon, Aug 10, 2009 at 12:32 AM, PhistucK <phist...@chromium.org> wrote: >> >> Obviously, but since there is a website (what started this thread) and >> people do run into issues (Help forums) with such a thing, is a specific >> solution for Flash, at least, coming up soon? People getting infected while >> using Chrome is... really, really, not optimal. > > Oh, agreed. But a sandbox for plugins that removes Adobe's ability to let > Flash update itself with security fixes doesn't really solve this problem > either (which is what some of the discussion earlier in the thread was > about). Right now, as I understand it, this vulnerability affects all > browsers, not just Chrome--saying that a plugin vendor is in a better > position to fix problems within a plugin isn't meant as a cop-out, it's just > a description of where the problem lies. Any sandbox is just one line of > defense. > The underlying problem is that the current spec for browser plugins (NPAPI) > effectively gives a plugin all of the capabilities of an application. > Flash, since it's a programming environment in its own right, uses those > capabilities to deliver value to users. For example, Gmail uses a small > Flash application that improves the user experience for attaching files to > email messages--but also depends on Flash's ability to access the file > system. A video chat widget written in Flash needs access to the I/O > subsystem in order to access the webcam. Acrobat (at least in recent > versions) allows embedded Javascript, which expands the capabilities of > Acrobat but also provides new places for potentially malicious code to live. > The fact that these capabilities are used for genuinely useful stuff as well > as security exploits is what makes sandboxing plugins difficult. We could > turn off file system access, but then all sorts of "file upload" widgets > would break, as well as Flash's own update facility. We could turn off > access to other I/O devices, but then webcam and video chat would break. > The real solution is to improve the plugin runtime environment so that > plugins don't need to talk to the OS directly for these sorts of things. > There is active work going on in places like the HTML5 working group, > Mozilla's plugin wiki and mailing lists, etc. to make this happen, and we're > contributing to that work. All of us, browser and plugin writers alike, are > painfully aware of the problems here. And while we don't have a spot fix > for this particular malicious website, it does serve as a good example of > why that work is necessary. > --Amanda > > > > -- Caleb Eggensperger http://calebegg.com/ --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
