Douglas Crockford, No Script, and IT Policy

by Nate 22. November 2007 07:27

Over the last year or so I've turned into more of a "client-side" developer than I would have thought possible a couple of years ago and, therefore, write quite a bit of JavaScript every day. That said, I haven't really contributed to the development of JavaScript, JSON, or AJAX (but have greatly benefited from each of them), and you should certainly listen to anything everything that Douglas Crockford says about JavaScript and technology in general over everything anything (about JavaScript or technology in general) that I say. But... I'll have to say that I disagree with a recent entry that Douglas published on the security of JavaScript and how it relates to people's everyday browsing habits.

In a recent post, titled No Script, Douglas wrote about a Firefox Extension (named, of course, "No Script") that turns off, by default, most of the executable content in Firefox and only "allows JavaScript, Java and other executable content to run from trusted domains of your choice, e.g. your home-banking web site, and guards the "trust boundaries" against cross-site scripting attacks (XSS)". In the entry, Douglas goes on to recommend that we should "be using Firefox with No Script". On the official Firefox Add-ons page, the description of this NoScript extension goes on to claim that "Firefox is really safer with NoScript ;-)".

While I would never argue with Douglas' or the extension development team's assertion that Firefox (or any browser) is more secure with executable content turned off, I did ask myself a couple of questions the first time I read Douglas' recommendation:

  • How much of a threat is JavaScript (or other executable content like Flash and Silverlight) to the majority of everyday users on the internet?
  • Is the threat great enough to ask these everyday users to make snap judgements as to what executable(s) are allowed to run when they visit a website?
  • Can an everyday user really be expected to make a sound judgement as to what executable(s) should be allowed to run when they visit a website?

And, by the way, it looks like Jon Udell asked himself a similar question when he read Douglas' entry.

I'm going to go on a bit of a tangent here, but if you stick with me I think you'll see where I'm going when I'm done: In my 9 to 5 job, I work closely with the federal government on a number of projects, and I'll have to say that Douglas' recommendation reminds me a bit of the IT policies that have recently been working there way down in the federal government from on high. In short, a lot (most) of these policies seem to be pushed down with little or no consideration of the amount of impact that they will have on the productivity of the overall workforce. While I understand that this is a difficult metric to quantify, it seems to me that it is an important factor that should always be considered.

While security - especially in an enterprise - should always be a chief consideration when formulating IT policy, it seems like organizations sometimes take it a bit too far. I'm probably misrepresenting utilitarianism when I say this, but doesn't it make sense to consider the greater good when developing IT policy? Shouldn't the impact of a policy always be quantified (on both sides) before implementation?

Here are a few greatly-simplified examples that demonstrate the effects of (what I see as) rash IT policy formulation, and realize that I worked in IT support before my current job, so I can see this issue from a couple of different viewpoints:

  1. Sure, it's a pain to rebuild a workstation after it has been infected by a virus (most of the time this costs somewhere between 1.5 to 5 hours of IT support time), but how much more of a pain is it for users (over ten thousand in some enterprises) when you have antivirus software running real-time scans on their workstation and consuming a third - or more - of the workstation's resources? If quantified, the impact of installing bulky antivirus software on workstations could cost an organization thousands, if not hundreds of thousands, of hours of productivity over the course of a year. Even if some data are lost because of an outbreak (and if proper pro-active backup policies are in place, data should never be lost), the cost of productivity lost would likely greatly outweigh the benefits of having antivirus software installed. I'm assuming, of course, that every user needs every bit of their computer's computing resources to perform their job. This may be a false assumption, but it helps to clarify my argument and lets you know where I'm coming from.
  2. It's, of course, no fun for an organization to have to run recovery on hundreds (possibly thousands?) of workstations a year because of user error, but how much productivity is lost - on both the user's end and the IT support staff's end - when local admin access is taken away and users have to either make due with an uncomfortable limited set of tools that are pushed down on them or wait for IT staff to approve and install software for them on their computer?

The connection between Douglas' recommendation and the argument about the cost of some IT policies that I just made may not be obvious. To me, however, there is a direct correlation between the two in the form of the thought process that brings each (Douglas and those who make IT policy decisions) to the conclusion that security trumps all. Where's the connection? Well, Douglas is assuming - much like the federal government in the examples given above - that security trumps productivity, and, because of this, it seems like he is willing to limit a user's productivity and/or freedom to protect a very small amount of users that might someday become a victim because of vulnerabilities caused by JavaScript/Flash/Silverlight. [Note: I say "seems like" because I am making an assumption, based on Douglas' blog entry, that this is how he feels. This is an assumption because he doesn't flat-out say that he feels this way, though I think that this can be inferred].

I truly believe that the effect of a lot of these policies - which are certainly valid, especially if the policy makers are looking at the formulation of their policy solely through a "security lens" - if weighed against the quantified loss of productivity in the workplace, would be thrown out in a heart beat. The question is, how much of a threat really exists from allowing JavaScript and other executables to "run free" in a browser? And, if quantified and compared with the loss of productivity that would come from everyday users having to deal with the complexity of allowing or not allowing JavaScript to run in their browser, would a "No Script" policy still be as attractive (or even a viable suggestion)?

In short, let's be realistic here. JavaScript and Flash are an integral part of today's web. Turning them off by default on every browser will never happen and would be a bad thing for developers and users alike. That said, Douglas is right, though, in saying that there has to be a plan: "In the long term, I want to replace JavaScript and the DOM with a smarter, safer design. In the medium term, I want to use something like Google Gears to give us vats with which we can have safe mashups". I certainly agree, but I disagree about the short-term. JavaScript is here to stay (at least until something like it, but better, comes along), and, although it may not be the safest option, user's aren't going to rush out and turn off JavaScript in their browser.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Javascript

Microsoft SQL Server 2008 November CTP

by Nate 19. November 2007 20:11

Those of you who use Microsoft SQL Server will be interested to hear that the SQL Server team has just released the November Community Technology Preview of SQL Server 2008 "Katmai". Of special note for us GIS types is that this is the first publicly available release that includes support for the new spatial data types.

The last couple of weeks have seen a slew of news about this upcoming release, including some pretty interesting demonstrations of the new spatial data types. A good blog to keep your eye on is Isaac's MSDN blog; he recently linked to a webcast that he gave on the 1st of November, titled "Introduction to Spatial in SQL Server". This is a good place to start if you're just being introduced to the new capabilities.

Here's a link to the download.

I'll be playing around with Virtual Earth and this release quite a bit over the next month and will post about my experiences here.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Microsoft Virtual Earth | SQL Server

New Features Added to the Virtual Earth API

by Nate 18. November 2007 21:52

This news comes from Hannes's Virtual Earth Blog.

Microsoft has just released several new features into the Virtual Earth API, allowing developers to further enhance their Virtual Earth map control v6 applications:

  1. It is now possible to import 3D collections into VEDataType.VECollection.
  2. It is now possible to import KML and GPX data into VEDataType.ImportXML. This is obviously great news. We can now consider using KML as a data standard for our organization.
  3. Localized driving directions can now be accessed through the API by adding the market you're interested in (en-us for the United States) to the end of the map control URL (e.g. http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6&mkt=en-us).
  4. SSL support has been added for the Virtual Earth map control (https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6). This may not sound like a huge enhancement, but support for SSL is a huge need for enterprise customers. It is a major pain when developers have an SSL-secured application but their users get security warnings when browsing to a page that has an embedded map. I have heard much grumbling among users of the Google Maps API that including SSL support doesn't seem to be a priority for Google. Maybe this is just another demonstration that Virtual Earth is becoming the standard for mapping in the enterprise?

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Javascript | Microsoft Virtual Earth

Virtual Earth Dashboard Display Bug

by Nate 16. November 2007 02:30

Here's a quick tip that I uncovered today while working with V6 of the Virtual Earth map control: If you notice that your application's Virtual Earth dashboard appears funky with the "Road", "Aerial", and "Hybrid" choices displaying below the actual dashboard (as seen in the first screenshot below), you've probably set a font-size on the body of your web page. This is what's causing the text to wrap below the actual control.

The fix is simple: Define the preferred font-size on something other than the <body> tag of your page. If you can't do this for some reason, you should also be able to dig a bit into Virtual Earth's CSS classes using a tool like Firebug, find the default font-size for the dashboard, and set your Virtual Earth map div with this default font-size. Just make sure that you use the !important designation to make sure that your styles get applied. I haven't tried this approach, but it *should work (famous last words, right?).

I strongly suggest, though, moving your font definitions from the <body> to something more "controlled", such as your paragraph <p> tag; this will save you from a lot of headaches in the future.

Before

virtualearth_dashboard_bug

After

virtualearth_dashboard_bug2

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

CSS | Microsoft Virtual Earth

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen
GeoURL