A quick note to the Bank of Montreal about their new security "Enhancements"

The following was sent to BMO's feedback address about their Online Security FAQ about new security "enhancements".

Please note that as an Internet consultant who is partly hired for my security expertise, I would be forced to avoid BMO banking based on the information in your FAQ. It demonstrates a lack of security in mandating insecure use of vendor-specific Macromedia Flash and Microsoft ActiveX, as well as ECMAScript (Previously known as JavaScript).

I already recommend customers disable these insecure client-side technologies, and would need to recommend customers against being a BMO customer as you seem to be promoting and dependent on these insecure technologies.

Please review your policies and your choices of technologies. Please stick with standards recognized by relevant standards bodies, and avoid the mis-use of the word "standard" to mean "non-standard brand choice" (IE: Microsoft ActiveX, Macromedia Flash).

Thank you.

Note: If you are dependent on Microsoft's ActiveX it wouldn't be possible for me to be a customer even if I was willing to run the insecure software. Microsoft's highly proprietary ActiveX software is only available on very specialized brands of computers, none of which I personally use.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Active X

My partner uses BMO and was avoiding the online updates.

we are very carefull with cookies ect..... but ACTIVE X who is there that is getting paid off my M$ or is an absolute moron thats chose to use it.

Sorry but ACTIVE X is good for nothing as far as im concerned and can't be trusted but neather MICROSOFT these days...

Insecure or Just Vendor Specific?

Hi Russell,

As an Internet consultant hired for my Flash application development expertise, I'd like you to clarify whether you intended to say that this particular use of Flash is insecure or that Flash is insecure full stop. If the latter, perhaps you would like to provide a bit more of an explanation for me and your readers - as far as I can see Flash has had a pretty excellent security record compared to a lot of client side technologies, particularly browsers.

I'm also curious about your definition of standards. ECMA stands for European Computer Manufacturer's Association and ECMAScript is one of their standards (262) supported on pretty much every browser out there. Wouldn't you describe this as a "relevant standards body"? I also think it would be fair to describe as "standard" (in the dictionary sense) a technology such as Flash which is installed on over 98% of internet connected computers, including the Mac and Linux platforms?

As I read the BMO FAQ the use of Flash was as a backup for non-cookie enabled browser environments and not core to the success of the application - it seems like a sensible idea.

I am not trying to pick a fight. I am a long time Mac/Linux user, I've written a fair amount of open source software and I'm writing this response in Firefox. That said I get pretty tired of Slashdotters and the like knocking Flash without backing up their statements. If it's just an underlying dislike for commercial software, just come out and say it. Then we can discuss that - though I might point out for starters that in "The Cathedral and the Bazzar" even Eric Raymond allows that there is a place for commercial software.

There is also a limit to how pure you can be about standards and remain relevant to the real world situation. Reading between the lines I'd guess you'd like to see everyone running Mozilla browsers on one of the less commercial linuxes with all websites written in CSS 2.0 with no javascript and PHP/MySQL on the server. This might be fun (although probably not for the user of a web banking application), but it is really unlikely to happen soon, and in the meantime there are some (I would hazard) much more important things to be worried about and for supporters of critical organisations like the EFF to concentrate on.

Anyway, thought I had to speak up for the Flash development community when I read this.

Thanks,
Robin

Clarifications...

I meant to say: "Flash is insecure full stop.", specifically as the client-side language in an Internet environment.

There are two levels that I am saying this at.

The first level of insecurity is technical. Like other more full-featured languages such as Java, Python, or Perl, Flash may have a place on the desktop executing trustworthy multimedia applications, but I disagree that it is secure to use when allowing random anonymous authors to execute code.

Any client-side language which allows an anonymous remote software author to read/write any file which the current logged in user has access to is insecure. Flash is not alone in being a full featured language, with other more full featured languages such as ActiveX and Java having the identical problem. If you can read/write arbitrary files as the current logged in user, you can leverage this to launch arbitrary programs (including downloading and launching any program you wish). Most operating systems have scripts that will run when a user logs in, with this timing being such that the owner of the computer wouldn't even know that the malware was initiated at some earlier point.

The second level is the standard FLOSS argument that if you can't have a third party audit of the source code of software then there is no way to know if it is secure. I realize that "software manufacturing" developers don't agree with this, but it is my personal belief that software which governs our lives should have the same level of accountability and transparency as the public policy which governs our lives (See Code is Law SpeedGeek). You may opt to blindly trust a "software manufacturing" vendor whose software lacks that accountability and transparency, but your personal choices should not be imposed on others.

Trust depends on mutuality, and cannot be imposed or enforced. Having Flash imposed on me makes me distrust it even more than I might otherwise. I am curious if you saw the LAFKON video about "Trusted Computing", which is about understanding the word "trust" as much as it is about any specific (ab)use of "technology"?

You are free to trust this technology, just as I am free to mistrust this technology. It should be an individual choice, not something that is attempted to be imposed on any of us. Whether Eric Raymond (who I don't agree with on many political ideas) or some other personality believes that "proprietary" software should be a choice for someone else or not does not relate to the question about whether this choice should be imposed on me.

When I use the word "standard" in a public forum I do not use the word alone, given its usage has been warped to no longer have useful meaning. I use the phrase "standards recognized by relevant standards bodies" to differentiate from the usage that is a substitute for "popular vendor choice". While I will not disagree that Flash is a "popular vendor choice", it is clearly not a "standard recognized by a relevant standards body" with multiple interoperable implementations.

I wish Flash was this type of standard as it makes a great language to author presentations, but this is not the case so I don't use it. If you wanted to really defend Flash you would be lobbying Macromedia (Err.. Adobe) to work towards making Flash files a "standard recognized by a relevant standards body" with interoperable implementations so that there would be an implementations that everyone could be willing to choose.

You are free to pick whatever brands you want, but you should be willing to help protect my right to have the same freedom. It is not appropriate for large corporations to impose third party brands on their customers. Many countries have laws against "tied selling" which exist to stop that type of economically (and otherwise) harmful behaviour.

By the way, I'm not taking the "straw man" bait at the end ;-) It doesn't matter what technologies are used on the server-side, as long as these do not impact the choices people have on the client side.

Put another way, your right to swing your cane (run whatever software you want on your server) ends at my nose (my right to choose the software I want on my client).

I don't see how storing an additional file with a random number on a users hard disk improves security - it is just yet another implementation of a cookie, which are themselves of limited practical use in this case. I do find it amusing that client-side scripting languages are being used to re-implement cookies, and yet while almost all browsers support client-side certificates this powerful, standard and secure feature isn't being used.


Free/Libre and Open Source Software (FLOSS) consultant.

Flash Misconceptions

Mr McOrmond,

As a professional Flash application developer and one has who has developed 128-bit encryption systems for Flash/PHP to boot, I must say that you have either been grossly misinformed or have not done your research. I hope to clear up some of these misconceptions for you and hopefully anyone else who is reading this thread.

In answer to your first concerns regarding "allowing random anonymous authors to execute code", with Flash that is actually less likely than with HTML hacks through your basic web browser. There are so many safeguards built into Flash that reading information from a local disk (i.e. the user's disk) is next to impossible. There are even limitations on the way that Flash can interact with the browser, let alone the user's own system. Javascript offers a *much* larger possibility for abuse, and that comes built into your browser. Java applets (Java code run in a web browser) is similarly limited. If, for the sake of argument, Flash was allowed to excute code on the desktop, it would be just as dangerous as any application you are running now. That is, if you have any piece of software running on your system that you downloaded from the Internet (as you would have to do with a Flash application...they cannot differ if they are to offer the same functionality) then you are exposed to those risks now.

As to your second point regarding accountability, I couldn't agree more. Open Source software speaks to this in some ways although running an EXE does not necessarily guarantee that it was created from the accompanying source code. However, I think you and I will both agree that for the most part Open Source developers are fairly upfront about their products. Because I share in this belief, I also contribute my products to Open Source projects. You may be interested to note that unlike other languages, ActionScript (the programming language for Flash) is incredibly de-compilable. That is, a good Flash developer can load up Flash content and almost instantly have analyzed all of the subroutines and data contained in that file. On the one hand this necessitates better security within the Flash content (called a movie) but it also opens up the code for analysis by anyone who wants to see it.

You make a point of pointing out that you mistrust the technology. I for one can't blame you. Flash is a binary format much like bytecode Java and isn't open to casual analysis. Truth be told, I've run into numerous Flash projects that have been horribly coded, both from the point of view of security and also from the point of view of extensibility. Relative to more mature languages, Flash is still in need of some decent formalization, but that comes from maturity of developers and not from standardization (see below). You may be surprised to know that the first incarnation of Flash (called Future Splash) actually predates Java and PHP (both of which I am also familiar with). Python and PERL are excellent standardized languages but have had to be adapted heavily for use in modern online environments. In my view, many modern languages (ActionScript included) have learned much of the mistakes and holes of previous languages. Are they perfect? No. Are they better? Very much so! I've been developing since the days of DOS so I believe that I have a valid opinion on this.

This entire thing about ActiveX is really a bit of a moot point. Here are the facts: ActiveX is a technology developed by Microsoft for plugins into their operating system (Windows) and browser (Internet Explorer). You have numerous ActiveX modules running on your system at any time, regardless of if you have Internet Explorer open or not. A version of Flash was created as an ActiveX plugin because that is the only way to load it up within Internet Explorer. For other browsers such as Netscape or Firefox, Flash comes in a different flavour which allows it to be loaded in those environments. Flash is available for portable devices such as cell phones and runs on many different operating systems. The use of ActiveX was in no way Macromedia's (now Adobe's) decision, but they would have limited themselves greatly if they didn't support IE. One may argue that Internet Explorer itself is somewhat insecure as a browser (and I would tend to agree), but the Flash plugin behaves the same way regardless of which browser or operating system it's in. Flash is limited to interaction within the browser -- no file access, no cookies, not even to be allowed to know that anything else is around it in the browser such as other frames. Javascript is capable of interacting with all these things and since *every* banking site uses Javascript to some degree...well...you do the math.

You do make mention of choice a few times and I'm afraid I can't comment except to say that yes, you should have that right. You should not be forced into anything you are not comfortable with even (as much as it pains me to say) using Flash.

Regarding standardization (from above), I'm not sure how you would go about standardizing a binary format (Flash files as you mention) -- they're made that way for speed of download and playback -- but the language used to develop the code is *strictly* formalized: ECMA Script. This, naturally, leads me to another misconception that seems to be hanging around this thread...or rather a lack of understanding regarding it. ECMA Script (ECMA-262) simply refers to the way in which code is written by the developer. There is a certain syntax, or way of writing code which is similar across all languages who adopt this standard. ECMA Script is the first and foremost standardization of development languages (so saying it's not standardized is exactly the opposite of the truth) and spans diverse languages such as ActionScript, Java, Javascript, among many others. Flash must, by necessity, adopt numerous other standards in order to happily co-exist in the online world. All of these standards are open on the web as is full documentation for ActionScript. Many Flash projects also come in their raw form (see 'www.osflash.org' as a starting point). This in no way guarantees that code is written well (to either perform, be secure, or otherwise), simply that a developer such as myself can look at something as different as, say, Java and understand how it works.

In regards to Flash security in the browser in general, Flash uses the browser's communication channel to communicate with the server. That is, the browser handles the communication on behalf of Flash. Out of the browser, Flash will actually (and by default) be disallowed from communicating with the Internet. Macromedia (Adobe) put this in there just for that purpose. Your basic Javascript code is never checked in this way, and no other technology is either for that matter (with the exception of possibly Java). If you want to try it, go to your browser's cache and pull out any SWF that communicates with the Internet. Maybe just a simple Flash game that stores high scores online. You'll need the standalone Flash player from Adobe before you can even run it, and when you do the application will be stopped dead until you specifically allow it to communicate with the site it's trying to access (and that site only!). A Flash movie doesn't contain any data that can be directly understood by your processor, it must be translated by the Flash player (ActionScript is an interpreted language) and so there are no commands that I as a developer can issue that would allow me to go outside of this "security sandbox". While online, that little "lock" icon in your browser's window corner indicates that your communication is secure and by default so is the communication on behalf of the Flash movie. Add to that the fact that cookies are easily readable (whereas Flash "cookies" are not as easily accessible or readible), the fact that Flash is an application platform so it can doubly encrypt your data before sending it out (something I have a great deal of interest in), and the fact that hackers would have to do just that *little* bit more work to even analyze how the bank's login system works (on HTML it's right there in front of you), it seems quite sensible that they chose Flash as a security add-on. To end this entire security paragraph, may I suggest having a look at the built-in limitations of the Flash player at this location: http://www.macromedia.com/devnet/flash/whitepapers/security.pdf
-ALSO-
http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_16629
-AS WELL AS-
http://www.macromedia.com/devnet/flash/articles/fplayer_security.html
-AND-
http://www.macromedia.com/devnet/flash/security.html

(hope you didn't think that Macromedia took this lightly!)

So, if we consider it's use (and exact replicable operation) on diverse systems such as Macs, Unix, Windows, Handhelds, and others, we consider the fact that the SWF file (compiled Flash file) is exactly the same regardless of the platform (you can play the same file anywhere you have the Flash player), consider that the programming language is one of the *few* that strictly adheres to a global standard, given the fact that SWF files may be analyzed more deeply *on the fly* than any other client-side technology, and given the fact that security (to disallow numerous developer actions) built in to the Flash player exceeds any other technology, I would have to say that your fears are not only groundless but that they suggest a definite lack of research into the field.

I hope that as a proponent of Open Source software you have a chance to visit that OSFlash site I mentioned and try some of the projects, as well as looking at the code. I believe you will find them on par with any other Open Source project regardless of the language. I also hope you take the time to at least peruse some of the secuty articles Macromedia wrote regarding the Flash player to see exactly what limitations Flash developers are working with. Compare these security limitations to anything else you find on or off the web and I think you may find that you have are grievously mistaken.

Sincerely,
Patrick B

Flash used to circumvent security/privacy settings.

I'll be honest: Unless someone I can feel is trustworthy is able to look at the source code to a flash player, there is no way for someone to do the type of research you suggest. I obviously don't have the details you suggest that I should have for a technology I have no reason to personally investigate until there are widely deployed FLOSS implementations.

I don't see why something being binary or not affects whether it can be fully documented and standardized (by a recognized standards body). Everything that goes over public wires or airwaves can and should be publicly documented and standardized. Adobe can have their own proprietary implementations of Flash that implement a public standard, just as there are multiple implementations of browsers that conform to the same publicly documented standards. Computer owners and developers would then have their personal choices (and property rights) respected by being able to pick an implementation that they trust in order to access the content.

Adobe/Macromedia is minimizing the utility of Flash language by keeping documentation away from developers of compatible flash players. Trying to get Adobe to open up this documentation and the documentation/development process should be the primary focus of those who think Flash is so great.

I have never developed FLASH code, and have no need to look at it until there are widely deployed FLOSS implementations. People who I trust have told me that you can read/write files on the filesystem that the current logged in user can. Are you suggesting to me that FLASH does not allow a developer the ability to read/write files that are owned by the currently logged in user? Is there an "authority" on this that you can reference?

Having unauthenticated code randomly sent to a client able to read/write arbitrary files on the filesystem is a security risk, no matter what the language. You don't need to have the ability to execute arbitrary code from the client-side language directly in order to leverage the ability to read/write files to accomplish the same goals.

I had the same types of debates in the past with Java supporters. At one time Corel authored a version of their office suite for Java, and I asked: If Java running from the browser wasn't able to read/write arbitrary files in the users account (as falsely claimed by proponents), how is it that this word processor written in Java that comes from a website is able to read existing documents, edit them, and write them out? People who had no technical knowledge at all realized that all the "Java is secure" marketing brochures were nonsense once they had an easy demonstration of this fact.

Lets move away from that discussion for the moment, to something else: the use of "Flash" cookies as a backup to possibly disabled/deleted browser cookies.

I'm told that BMO might be using something from a company called Pass Mark Security.

The "technical" problem they are trying to solve: They want a cookie that is stored on a users computer so that they can determine if this is the same computer that has accessed their site in the past. They want to be able to have log analysis to see if a pattern changes at some point, switching from a customer only using a few specific computers to all of a sudden using a larger number of computers.

Computer owner/operators have decided for a variety of reasons (some of which I don't personally agree with) that cookies are too much of a privacy risk, and have disabled them. They also run third party tools to delete cookies from their hard disk.

Whether we agree or disagree with this security/privacy policy configured by the owner of the computer, I strongly believe that policies set by the owners should be respected.

Pass Mark Security describes what they are doing as follows:

Before starting the authentication process, every computer, PDA, phone, or other device that accesses a PassMark-protected Web site is quickly and silently assigned a globally-unique Device ID. It is then encrypted and stored on the user's device using multiple simultaneous methods, including secure cookies, Flash Shared Objects, and other means. That way, if the cookie is erased, the Device ID can be easily restored from other locations.

I take that to mean this: We have figured out a way to circumvent the users security/privacy settings, storing cookies in places that the owner of the computer might not find right away and remove.

Given that this privacy vulnerability is discussed on the WIKIPedia page for Flash, I suspect that if they don't already that tools that delete cookies will soon delete Flash shared objects as well.

I also suspect that PassMark realizes that they will always have a battle with the owner/operator of the computer who want to delete cookies, and that their "other means" will constantly be expanding to figure out ways to circumvent the security/privacy settings of their computer.

This isn't a technical problem with a technical solution. We should be respecting the security/privacy policies set by the owner/operator of computers, and not be circumventing these policies through PassMark or even worse, DRM.


Free/Libre and Open Source Software (FLOSS) consultant.

Flash Limitations

First of all, I am saying that without a doubt, you *ABSOLUTELY CANNOT* arbitrarily read and write files on a user's computer using Flash. If you're so adamant about this being the case and it being the backbone of your argument, I challenge you to find a Flash movie, piece of ActionScript, or anything that is actually capable of doing this. The people who you trust on this matter are *COMPLETELY WRONG*. I've gone to the bother of at least providing links to back up my challenge, why don't you do the same? Please provide *one* example of this being done via Flash. Not through some third-party add-on that allows Flash to write to your disk (which is, after all its purpose), just Flash. Your link to the Wikipedia article points out a security flaw in Flash player which has since been patched up. It describes the possibility of the Flash player being circumvented, but has not actually been done. How does a single (and only demonstrated) flaw in the software (quickly found and fixed) measure up to most software? Regarding cookies, I address that issue below. Besides that, both of these issues are quite public, well known, well documented, and widely discussed. The first isn't a security issue (cookies), rather something that users should be aware of (see paragraph below on this topic). The second is a flaw. Are you suggesting that this is evidence of Macromedia's un-trustworthiness?

As for Macromedia having an implementation of a public format, they do, it's called ECMA Script (please visit www.ecma-international.org before replying to this point), and the compiled format is a Flash movie. This format is fully documented and that is why a number of open source tools to *create* Flash movies have been developed (again, you are making an absolutely *false* statement; please back up your claims!) -- see: http://www.macromedia.com/licensing/developer/ -- They also have API hooks and a fully public SDK (see link) for developers and unless you suggest that the company fully and publicly release the source code for all of their products, what exactly is it that you want? Do you have the source code to Windows? How about Internet Explorer? How about most of the software that's on your machine? If you do, how did you ensure that the source code you have and the compiled code are the same thing? If you compiled it yourself, how do you know your compiler didn't insert some code that wasn't specified? In fact, what verifications are you doing now for your existing software that you would apply to Flash? If your "trusted" colleagues are the authority on this topic, perhaps they can explain to you how they ensure that all of their software does exactly what they think it does and nothing else. For a company such as Macromedia/Adobe, how is their product protected against massive copyright infringement if they suddenly and fully open up their products to the public (if this is what you want)? Does this not also open up software for devious coders and possibly pose a much greater security risk than having it distributed from one, well-known company? (I'm referring to the Flash player here, not the SWF file format)

On the topic of Flash "cookies", this does not circumvent your computer's policy settings. When the "cookie" is set, Flash will display a dialog box asking your permission to store data on your hard drive in a special file. This file is called a Local Shared Object (http://www.macromedia.com/software/flashplayer/articles/thirdpartylso/) and is accessed in Flash as a variable -- there is no disk access by a developer whatsoever. Most modern browsers now ask your permission to store cookies as default but Flash was doing that well before this ever became common place. Besides, are you absolutely sure that the browser is not storing cookies somewhere else than in the "cookies" folder? Maybe the system registry? Are you *absolutely* sure? What have you done to verify this?

The problem with "unauthenticated" code is a bit funny to me, for the above reasons and more. Every time you open up a web page, you are running "unauthenticated" code. Basic HTML can be circumvented in many ways to crash your machine or allow unauthorized access to your system. Every piece of content that must be translated before being displayed is a form of code, including Microsoft Word files, XML data, and so on. It's not easy get around the software's security, but then no piece of software is entirely perfect either. Flash is as much of security risk as a standardweb page. If you don't think so, please provide proof. As you mentioned, it should be demonstrable, so please put your money where your keyboard is. Stating that someone told you so is a very poor argument. I don't know these people and applying your skepticism shouldn't trust them, especially when they opine via someone else.

You may have had discussion with proponents of Java who said that reading/writing data from the user's disk was not possible but an entire section in the Java Developer's manual discussing *how to do this* clearly would have proved them wrong. If they actually made these statements, they were as misinformed then as you are now. There is ample documentation for you to go through. There are many links describing Flash "hacks" and tricks ... I encourage you to pull some up and see how even basic browser functionality can't be implemented without massive workarounds. Then I challenge you to find a link to any site proving any of your points.

The point I'm making is that, while you may have a point in saying that Flash is not trustworthy because the Flash player is not open, I challenge you to tell me what exactly is, and how you know this to be true? You are picking on Flash with no actual evidence except what is at this point third-party hearsay. What this amounts to is a one-sided *opinion*...a form of saying "trust me, I know what I'm talking about". Isn't that ultimately what you are saying is so wrong with Flash in the first place?

Will concede one point..

I do not have first hand knowledge about whether Flash allows people to write arbitrary files to disk, nor do I have an example to point to. I don't author Flash, don't use Flash, nor do I have an interest to learn these details (or consider the details relevant) until there are widely deployed FLOSS Flash clients.

This is not the core of my complaint, but a side issue I now wish I hadn't brought up as it has served as a distraction from my main point. The core issue is the fact that the only implementations of the players for the technology in question are "software manufacturing". People are free to disagree with me that any software that is not publicly disclosed is untrustworthy (It is an act of "faith" that allows people to trust this software, and not something that can be independently validated), just as there are those who have other political beliefs that differ from my own.

You are free to blindly trust this software, just as I am free to blindly mistrust this software. You seem to be taking offense that I don't have "proof" it is insecure, even though you equally (and for the same reason) have no "proof" that it is.

All the software I run on my home and work computers is FLOSS. FLOSS is like accountability and transparency in democratic governments: each individual citizen does not need to personally read every line of code (every government bill, every court decision) to know it is trustworthy. The point is that a large group of diverse people that are not part of the same company or political philosophy are able to read the code and publicly disclose things that they find that they do not agree with.

Any "faults" you can find with the FLOSS development process are also faults people could suggest of democracies. FLOSS is not perfect, it is just far better than any of the alternatives.

The licensing for the documention specifically states "This license does not permit the usage of the specification to create software which supports SWF file playback", which simply confirms "from the source" what I said about that documentation. Until the document allows all authors to author tools to generate, edit, read, and display Flash animations then the documentation is not useful. Client developers are relying on the right to reverse engineer in countries where this is still protected. It will not surprise me if Adobe later sues these developers that are trying to make Flash useful.

Pointing at ECMA is largely irrelevant to the discussion, given that this publicly available knowledge is not sufficient to write a full featured FLOSS client that can read and display all of the Flash content that the proprietary Adobe implementation can.

A cookie is a cookie is a cookie. If a user who doesn't want cookies stored on their computer, then of what use is this Flash feature to Pass Mark Security? Maybe you should be asking them this question if the proprietary Adobe Flash client easily allows those who don't want cookies to disable the storage of cookies.


Free/Libre and Open Source Software (FLOSS) consultant.

The FLOSS Philosophy

Perhaps I'm being too antagonistic when in the grand scheme of things I agree with you about accountability, openness, and peer review. It's the main reason I got into Open Source and despite the fact that I may use different licenses I believe the spirit is the same.

Please correct me if I'm wrong but FLOSS is a an initiative regarding peer review and evaluation of software, is that correct? Basically, trusted developers going over code to ensure that it does what it says it does.

I still maintain that by simply reading over source code you have no guarantee of what the compiled piece of software actually does. I can easily release a program with source code omitting sections of "hidden" functionality and unless you had someone going over the program machine language instruction by machine language instruction, you'd be very unlikely to know anything was amiss. With many software packages now in hundreds of megabyte packages, this would be a very lengthy endeavour. Also, much code is pulled in over the internet dynamically (no user interaction needed) so you'd have to capture it while it's live and active in memory. On this point, polymorphic viruses have been around for many years and this has become a de-facto standard for protecting software. As such, code in memory may change from moment to moment in the same program and you may never actually see what's happening.

This now comes back to my original point: what guarantees do you have that any software on your computer does what it says it does, even if the source code is fully open and may have been examined by FLOSS members? You put as much faith in the software you run as I do in Flash. Faith is blind and therefore we are both blind by this standard, that is true. I have documentation by Macromedia and numerous other sources to at least add some weight to my beliefs. It may in the end turn out to be disastrously wrong, that's a possibility, but at least there's a reason for my belief...documentation, lack of any specific evidence to counter this documentation, and (I'm certain) numerous individuals trying to discover how to bypass Flash security.

All that aside, your point about the Flash player being forced to be proprietary is a valid one. Macromedia reserves that right and they therefore keep the loop closed. In terms of accountability, this seems on the surface to be a lack thereof. I would, however, suggest that this leads to *increased* accountability. If flaws, malware, or other baddies are found lurking in the Flash player code, there is one direction in which you can squarely point your finger. Numerous derivatives blur this dstinction greatly, especially when you increase the number of people involved. You believe (please correct me if I'm misreading your statements) that this prevents the software from being accountable and therefore makes it untrustworthy; I maintain that this makes it exactly the opposite. The player code itself is small enough to be analyzed and I happen to think this would be a worthwhile project if only to examine the "guts" of the system. Putting a statement in the SDK agreement simply won't stop people from decompiling the player code and sharing their findings. Crackers have been doing this for years and I'm sure they're not about to stop now. If it is that one statemen in the SDK agreement that's putting you off then I'm sure you're probably put off by most commercial software because the same clauses are present there. This is, I believe, the crux of your argument, is it not?

A cookie is indeed a cookie. Presumably you don't allow them in your browser and certainly not via Flash. Without a cookie of some sort, however, the server can't track your current online status, can't encrypt your data, and basically can't handle anything other than one-way communications (server to you). Cookies are a necessary evil, not a grand plan at invading privacy (though they can admitedly be misused!).

However, at the end of the day having accountable software sounds like a fantastic idea. You mention that all the software on your computer is FLOSS compliant. I'm assuming this includes the operating system as well? Is there a list of software that you could provide me with (not necessarily your own), or links to such software that I could see for myself? I approach this very skeptically, I should tell you, simply because I develop code myself and ultimately believe that the concept of trust is not attainable when you're dealing with software. But still, I should give this a fair chance and come at it with the idea that perhaps you have something here.

What is FLOSS/etc

Free/Libre and Open Source Software (FLOSS) is about more than just "peer review and evaluation of software", but does include that.

It also changes some of the motivations for developing software, and with that the types of problems that get solved. As an example, if software is a service and you are paid to solve problems, it is much more likely that security problems will be dealt with for your clients than with "software manufacturing". With "software manufacturing" they are selling "per copy" and customers decide to buy copies based on "features" and not "solutions". This is not to say that all "software manufacturing" software is always insecure, but that the financial motivation to fix security or other bugs is less than when software is treated as a service rather than a product.

Most customers aren't going to point fingers at a sole supplier of a software "product" when it is defective. If people held "software manufacturers" to the same level of accountability as the manufacturers of other "products", then they would notice the waiver of warranty and be lobbying governments to make these "software manufacturing" waivers illegal.

Manufacturers of tangible products don't have the legal ability to waive warranties, with "software manufacturers" being the least accountable of any type of "manufacturer".

The fact is that while the risk is to many people, the people who understand the risks are few.

Then again, those in a dictatorship can point to their dictator all they want for failures, but simple do not (and can not) have the same influence as the same person in a open and accountable democracy.

Customers of Adobe that don't like what their software does (or doesn't do) have two choices: take it or leave it. Then again, anyone who says "leave it" has to content with all the fans of that software accusing them of being irrational/etc -- the vendor/superstar promoting peer pressure from fans in this culture is huge. All additional reasons for the lack of accountability.

Everything I know and believe about software comes from political science. I know this is controversial, but I believe software is a branch of political science and not engineering: and thus the phrase Code Is Law.

These are all longer questions where I think a wide variety of books and articles will present more details.

The infected compiler problem you speak of is also a problem that is being solved. I recently read an article that talks about comparing the functional outputs of a variety of compilers to detect when one might have been compromised (and no, I can't seem to find the article again).

I know that it is a common red herring brought up many times over the decades. Comparing the potential that my compiler is infected to the lack of transparency and accountability of "software manufacturing" is like comparing stubbing your toe to multiple machine gun wounds. I am not intending to be insulting, so please don't take it this way, but these are entirely different levels of trustworthiness.

It is obvious that you are comfortable with Macromedia/Adobe, trust their employees, all the motivations they have for developing the "product", all the deals they may have made with other companies, their legal team, the courts/government in the country they are in, etc, etc. I do not trust these folks who have both economic and political motivations to attack that exceeds the average "hit and run" script kiddie that might try to make my compiler not compile the source code that I gave it.

It is not an unreasonable thing for many of us to remember that it was Adobe that had Dmitry Sklyarov arrested for violations of the USA's DMCA simply for making interoperable software (eBook to PDF converter).

I spend much of my life doing my small part to repair the damage caused by anti-circumvention and related backward laws which stifle/chill creativity and innovation (look at other parts of this site). I think it is appropriate to personally boycott harmful companies that are political opponents, whether that be CAAST/BSA members (software manufacturing companies), CRIA/RIAA members (major recording labels), or other such organizations.

There is no reasonable reason to believe that Adobe wouldn't be willing to attack software developers yet again if someone wrote software that was compatible (read and write) with possible future encrypted versions of Flash files. This alone should be enough reason for people who believe that software developers should be free to develop interoperable software to never use Flash, but realize that many fellow software developers are not interested in the politics behind protecting our profession.

Before anyone jumps in: this is not the reason why I wrote the letter to BMO. It is not about Adobe or any specific software manufacturing vendor, but the general principle of not tieing the ability to use/purchase one product/service to specific brands of other products/services (ideas discussed in Section 77 of the Canadian Competition act).

The microcode in my microprocessor and the software in my BIOS are not yet FLOSS, but everything on top of that is. I consider these acceptable risks given that this code is a very unlikely target for attack.

On many of my machines I use Fedora Core, and have been looking more closely at Ubuntu. We also have routers in our small ISP that use NetBSD kernels.

It is easy to have all of your software on your personal computer be FLOSS, although this is not what I recommend to people migrating. I recommend they install FLOSS applications in parallel with existing applications on their computer, and tool-by-tool move over. The operating system is the last piece of the puzzle, not the first (and yes, there are many Linux fans who disagree with me on that ;-).

I hand out copies of a few CDs I carry with me: The Open CD which is FLOSS software for Microsoft Windows, Ubuntu (Intel and PowerPC), and music and movie CDs where the content is under a Creative Commons license given "peer production" and "peer distribution" are about far more than just software.


Free/Libre and Open Source Software (FLOSS) consultant.

"Why I hate FLASH" by Hubert Figuiere

This message was posted because of a thread in the GOSLING Ottawa mailing list. Hubert Figuiere posted a link to his own BLOG article: Why I hate Flash? which goes into far more details than I did.


Free/Libre and Open Source Software (FLOSS) consultant.