Correction re "Sins of the Flash"
A few days, I posted a criticism of Adobe for a design that, I thought, was seriously incorrect. I made a crucial error: the access control decision is (correctly) made locally; what is done remotely is the user interface to the settings panel. The bug that Adobe fixed was a way for a remote site to hide the view of the UI panel, thus tempting you to click on what you thought were innocuous things but were in fact changing your privacy settings. (The annoying thing is that as I posted it, I had a niggling feeling that I had gotten something wrong, but I didn’t follow up. Sigh.)
This is a much better (though hardly good) design. It still leaves open the vulnerability: at least in theory, the bug could be reinstituted by court order, to aid in tricking a user into changing his or her own settings. In other words, a crucial part of the security and privacy process is still outsourced. The argument has been that back when Adobe designed the interface, it wasn’t as obviously wrong. I don’t think I agree — there was enough criticism of any form of active content going back to the very early days of the web — but I won’t belabor the point.
There’s one aspect I’m still unclear about. There is obviously some way to build a Flash file that tells the local plug-in to do something in conjunction with Adobe that changes local privacy settings. Is it possible for a malicious party to generate a Flash file that will talk to their site in conjunction with local privacy settings, rather than to Adobe? I hope (and think) not; if it is possible, the danger is obvious. Unless the interaction with Adobe is digitally signed, though, a malicious site could send a booby-trapped Flash file in conjunction with mounting a routing or DNS cache contamination attack and impersonate Adobe. This isn’t a trivial attack, but routing attacks and DNS attacks have been known for a very long time; until we get BGPSEC (and probably OSPFSEC) and DNSSEC widely deployed, that risk will remain. I do note that when I invoke the current remote-UI settings manager, I’m doing so over a connection that is at least initially HTTP, not HTTPS; I don’t know if there’s a second, secure connection set up.
To its credit, Adobe has realized that there are a number of problems with the whole model of a Flash-based settings mechanism; if nothing else, it was hard for most people to find. Accordingly, they’ve recently released versions of Flash that use local preference-setting interfaces (Control Panel on Windows; System Preferences on the Mac; something else normal on Linux) to change the values. That’s an excellent step forward. Now, they need to disable the remote variant (when contacted by a new Flash plug-in), and simply return a pointer to the local one…
