> from my perspective, i strongly disagree... > > if you're going to be writing apps that deal with sensitive information, > you > better damm well give some thought as to how secure the client is, or even > if the client is actually valid! To the best of my knowledge, if you're developing an app that uses a web browser as the client, then you better damn well give up on lying awake at night worrying about this as an issue. IE, which still holds something like 80+% market share of the browser base, is full of many, many holes. I'm sure this isn't news to you. Unless you're talking about exposing this sensitive data only to a user base within a strictly maintained network environment, then you *must* assume that some of the data can and perhaps will be compromised at the client end some of the time. There are an amazing number of variables to take into account, all of which, under most circumstances, are entirely out of your control. Which version of which browser is being used? Which operating system? What service pack and security updates have been applied? Which firewall software or hardware is in use, if any? Which antiviral software is being used, and how often is it being updated? Another way of looking at this is, "where does your responsibility as a web developer end?" Is it up to you to be concerned what happens to the data once it has been requested by the client, as opposed to it being the client's concern? What if a particular user is writing this data down in a notebook and loses it on the train on the way home from work? What if they're printing it out on a communal printer and other people are leafing through it while waiting for their own print jobs to finish? What if they're copying and pasting it into an email and blindly sending it to a huge distribution list? What if this data is stored in their browser cache and their laptop gets stolen? And on, and on, and on. Even given your suggestion re: browser vendors exposing some method of independently verifying 'unhacked' browsers, the implications would probably be many and varied. Do you suddenly stop communicating with every browser that has an unregistered 3rd-party add-on? What would be the effect on your business if customers objected to you telling them what browser add-ons they are allowed to use? How would that trickle over into open-source and smaller start-up initiatives that a company like Microsoft (infamously open-source opposed, according to the EFF) might not like to see thrive? Do you simply consolidate browser market dominance, and stifle innovation, by introducing a defacto licensing requirement? And on, and on, and on. If you're honestly concerned about the security of the data once it has been requested, then all I can suggest is, don't use a browser as the client. Develop a purpose-built client that enforces more security than you can hope for out of a browser. Even then, accept that the people who request the data may not have even the slightest respect for your security concerns once it's in their possession. As a last resort, and purely as a public awareness initiative, you might want to invite your users to check their browser for known spyware, etc, using a service such as DoxDesk (http://www.doxdesk.com/parasite/). I believe this site uses an activex control to specifically check details in IE. I have no idea how accurate it is. Alternatively, you could encourage them to use an application such as Ad-Aware (http://www.lavasoft.de/) etc to perform routine security checks. Beyond that, like I said, get some sleep. Regards, Murray -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
