Does a policy prohibiting jQuery in Enterprise applications make sense?

I just don’t get it, I actually couldn’t believe it at first; what possible justification would there be for the all-out prohibition of jQuery within an Enterprise? Believe it or not, this is actually happening, on the doorsteps of 2011, and in larger numbers than I would’ve imagined.

Whatever the case may be, here’s an ironclad top 10 list of why avoiding jQuery is a costly mistake:

1. It’s far and away the most popular and fastest growing JavaScript library on the planet [2]
2. It’s arguably the safest, most scrutinized library of its kind with no open vulnerabilities
3. It’s more pervasive than IIS itself –  in use by > 28% of all websites on the internet [2] [3]
4. Even the US government uses it at Whitehouse.gov [2]
5. It’s distributed freely across the globe through both MS and Google CDN edge-servers [2]
6. Microsoft has committed to help with QA testing and code development. It also includes jQuery as part of Visual Studio and ASP.NET MVC  [2]; on top of that, Microsoft ‘now offers actual tech support for jQuery as part of their Product Support Services (PSS) as jQuery integration has become part of several of the ASP.NET toolkits’ [5]
7. Nokia is contributing with testing and has also hired one of the core developers, Brandon Aaron [2]
8. It supports browsers from virtually a decade ago – everything  from IE6 and FF2 onward [1]
9. jQuery solutions are far more supportable than their raw-JavaScript counterparts
10. Forcing enterprise developers to hand-roll JavaScript is not a solution, just a costlier, more error-prone and less-secure alternative

Hopefully getting the right information in the hands of decision makers is enough to put this to an end.

In what scenarios have you seen jQuery use prohibited?

[1]  – Compatibility
http://docs.jquery.com/Browser_compatibility

[2] – jQuery’s triumphant march to success
http://royal.pingdom.com/2010/03/26/jquery-triumphant-march-to-success/

[3] – June 2010 Web Server Survey
http://news.netcraft.com/archives/2010/06/16/june-2010-web-server-survey.html

[4] – Does a policy prohibiting jQuery in Enterprise applications make sense?
http://stackoverflow.com/questions/4082401/does-a-policy-prohibiting-jquery-in-enterprise-applications-make-sense

[5] – Microsoft and jQuery 
http://west-wind.com/weblog/posts/807874.aspx?id=807874

What the Enterprise Can Learn From StackOverflow.com – Top 3 Lessons

Update (Nov 3, 2010): I stand corrected, the president of Fog Creek Software informed me on Twitter that ‘the Stack Overflow Product is actually available for enterprises and a few of the top banks are using it internally”. Hopefully we can get more details around this soon…

Stackoverflow has turned the antiquated concept of basic Q & A into a very successful modern franchise. Enterprises grappling with fostering engagement within their knowledge communities should take note. While this platform is not available to to an internal audience, there are key elements that can still help in shaping your unique strategy.

Without further ado, here are the Top 3 StackOverflow Lessons for creating an effective knowledge-base:

1. Kill Person-to-Person Collaboration
   
   This is the kryptonite of effective knowledge sharing, especially in the Enterprise. Notice that Stackoverflow profiles don’t publish user emails – this is partially to protect the user from unsolicited contact and a flood of questions from newbies, but also to foster person-to-community collaboration. Enterprise Search solutions attempt to ‘open’ content that was previously sealed behind business silos after the fact – well, you can start by not allowing this content to be hidden in the first place. This is poorly done in most organizations, with most users shying away from public distribution lists to carry personal conversations under the fear of inconveniencing others!
   
   
2. Make Participation Highly Addictive
   
   Community up-take is the make-it-or-break-it factor for these applications, meaning they must be highly intuitive (low-barrier to entry) and highly addictive. Stackoverflow achieves this delicate balance through a simple yet competitive reputation system that draws out best-of-breed developers simply to compete and to learn from one another.  A slightly refined version of this would work within the Enterprise as well; far too often, the incentive to participate just isn’t there. Before you can reward top participants, you have to start measuring. 
   
   
3. Recognize Top Contributors Externally
   
   This one is somewhat controversial (like most new ideas are) but imagine a scenario where the ranking of the top contributors within your organization were opened up externally to prying eyes. Sure, this might be a frightening scenario if you’re worried about exposing (and losing) your top talent, but it’s also the strongest reward you can provide, too. Most traditional incentive/reward programs are completely hidden from the outside world, which misses the point, IMO. As nice of a gesture as a jacket or a $100 gift-certificate may be, the real value to heard-working professionals is recognition of their dedication and devotion within the broader community.  
   
   
   
   (Now, Stackoverflow promotes ‘flairs’ for different reasons, I think; for one, it’s a highly effective way to spread the word and drive in traffic through a hub-and-spoke model. But I think the implications for external recognition within the Enterprise community are far more profound.)

What’s your Enterprise doing to embrace the lessons from the Web’s top successes?

[1] – Finding Opportunity for Success in the Failure of Others
http://www.readwriteweb.com/start/2010/10/finding-opportunity-for-succes-in-failure-of-others.php

[2] – What is reputation?
http://stackoverflow.com/faq

Measuring the ROI of Enterprise Search – Making the Case with Numbers

Far too often, the Enterprise Search experience is woefully inadequate and falls noticeably short of the carefully tuned and nurtured experience that internet users have come to expect, courtesy of the heated contest between Google, Bing and Yahoo. One factor that’s not helping to close this innovation lag is the complexity involved in building the clean-cut, formal ROI case that often drives project charters within the Enterprise.

NOTE: recognizing that “Enterprise Search” can include a vast spectrum of content sources and content types, each with unique characteristics and limitations, we will focus the discussion here on web-centric content that’s typically served through standard HTML, in both internal and external scenarios.

So how exactly do you build the business case for overhauling your search implementation? A leading Canadian IT consulting firm, NLC, recently tackled the question head on in their ‘Building the Business Case for Enterprise Search’ whitepaper [1] last week. While maintaining that a formal analysis ‘misses’ the real value of Enterprise Search, the paper does go on to provide a formal approach based on the IDC report, The Hidden Costs of Information Work (May 2009).

The proposed formula boils down to measuring:

• Search Cost Today = # of knowledge workers X avg. salary (incl. benefits) X % of time spent searching
• Potential Annual Benefit = Search Cost Today X The Search Lift Ratio (%)

Once deployed, estimates around ‘The Search Lift Ratio’ can easily be quantified through a combination of A/B testing, measurable and correlated call-to-actions (phone numbers present a challenge here, in some cases), ‘accurate’ time-on-page measurements [5] and traditional survey/feedback polls [4].

While the guidance is sound, it is largely based on estimates and, like similar reports before it [6], focuses primarily on the productivity gain; it does, however, offer a compelling, low-cost approach to building the case without relying on metrics that may be available in other areas. 

The “saves you money” argument, by all accounts, is wildly overshadowed by the broader “makes you money” advantages [2], yes; but, recognizing that corporate culture thrives on the the power of hard numbers, can we do  better upfront in the ‘reasonably measurable’ areas by relying on other metrics?

Assuming that the business has realized the value of matured analytics, even around legacy search implementations, can we explore these to make a stronger case?

While some of these are domain-specific, here are other areas that may yield useful ROI nuggets:

• Reduced Database Volume => License/Hardware Savings: for high-volume applications that rely on a traditional RDBMS alone for ad-hoc queries or search-based functionality, a well-designed search implementation can significantly reduce the load on those database servers, resulting in both hardware and licensing savings. Through standard profiling tools, the volume of traffic that stands be offloaded to a search infrastructure can be quantified beforehand. Similar hardware/licensing savings (and training/staffing can also be realized in consolidating a fragmented search environment.
• Measuring Publication Reach => Minimizing Sunk Costs: in scenarios where content was specifically authored and published for an intended audience, you should be able to measure the ‘publication cost’ and compare this to the ‘reach’ of the content (again, based on call-to-actions or accurate ‘time on page’ measurements). In scenarios where the reach is below a certain threshold, there is a clear and measureable ‘sunk cost’ that can be avoided in the future.
• Reducing Call Center Volume => Headcount Reductions: assuming that source of call-center calls (both internal and external) are clearly classified (e.g. “I can’t find any information on…”), it should be possible to attribute a portion of call-center volume (by extension, head counts) to inadequate search implementations.

Can you think of others that affect your organization?

References:

[1] – Building the Business Case for Enterprise Search
http://www.nonlinearcreations.com/whitepaper/index.asp?id=23

[2] – In Search of ROI | Search Done Right
http://searchdoneright.com/2008/08/in-search-of-roi/

[3] – How search can add real ROI to eCommerce websites
http://googleenterprise.blogspot.com/2010/01/how-search-can-add-real-roi-to.html

[4] – KISS Insights - It’s so quick to respond that many of your customers will!
http://www.kissinsights.com/tour

[5] – The Problem With Measuring Time Spent on Page
http://blog.webanalyticsdemystified.com/weblog/2007/07/on-netratings-and-time-spent-on-site.html
http://www.marketingpilgrim.com/2007/07/the-problem-with-measuring-time-spent-on-a-web-site.html

[6] – Return on Information:  adding to your ROI with Google Enterprise Search
http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/en//enterprise/pdf/internal_search_roi.pdf

How to Remove the Evercookie?

One of my colleagues just sent this out – it’s truly amazing [1].

Check out the Web History link that uses a CSS trick to reveal your history (all on the latest FF).

From the author himself [2]:

evercookie is a javascript API available that produces extremely persistent cookies in a browser. Its goal is to identify a client even after they've removed standard cookies, Flash cookies (Local Shared Objects or LSOs), and others.

evercookie accomplishes this by storing the cookie data in several types of storage mechanisms that are available on the local browser. Additionally, if evercookie has found the user has removed any of the types of cookies in question, it recreates them using each mechanism available.

Specifically, when creating a new cookie, it uses the following storage mechanisms when available:

- Standard HTTP Cookies
- Local Shared Objects (Flash Cookies)
- Storing cookies in RGB values of auto-generated, force-cached
    PNGs using HTML5 Canvas tag to read pixels (cookies) back out
- Storing cookies in and reading out Web History
- Storing cookies in HTTP ETags
- Internet Explorer userData storage
- HTML5 Session Storage
- HTML5 Local Storage
- HTML5 Global Storage

Art is definitely in the eyes of the beholder!

This is a case of layering several techniques (some known, others new) to create an approach that requires some serious thought to defeat. Much like the MS vulnerability disclosed this week, I think this is more about bringing information to light to promote discussion and progress. As one comment put it, “the bad guys don’t make open source announcements, they keep the code to themselves.”)

[1] - Researcher Claims 'Evercookie' Can't Be Removed
http://threatpost.com/en_us/blogs/frankencookie-developer-builds-bulletproof-web-tracking-tool-092210

[2] - Evercookie -- never forget.
http://samy.pl/evercookie/

[3] - Evercookie: A cookie that undeletes itself from 8 different storages
http://news.ycombinator.com/item?id=1714446

ASP.NET Vulnerability Workaround Not Enough

Microsoft keeps calling this a ‘workaround’ but it’s mitigation at best – sure, for the majority of applications it may be all that’s necessary, but it falls short of cross-the-board prevention. It’s not clear why they’re not more open about the cases that aren’t covered by the suggested workaround but it doesn’t take more than simple reasoning to reveal them. If you’re really concerned about the security of your application, keep reading.

Let’s go back to basics and look at where this issue stems from – all you need to do is differentiate between these three cases…

When the application is passed an encrypted value, it responds in one of three ways:

• When a valid ciphertext is received (one that is properly padded and contains valid data) the application responds normally (200 OK)
• When an invalid ciphertext is received (one that, when decrypted, does not end with valid padding) the application throws a cryptographic exception (500 Internal Server Error)
• When a valid ciphertext is received (one that is properly padded) but decrypts to an invalid value, the application displays a custom error message (200 OK)

And depending on how your application uses encryption, you are still able to do this even with a constant error page – here’s one blogger’s explanation (misses the point, IMO):

How about Microsoft’s workaround?

Well, while the workaround contains a really valuable information, relevant for every system (as for not disclosing the real error), and it will prevent the automated tool released by the researchers to hack your system, it will, by far, NOT protect you from a potential attack!

How so? The workaround assumes that the potential attacker will look for an HTTP error response status (500), or for an error page containing a specific exception message. However, it is enough for attacker to recognize an abnormal, or just different system behaviour on certain requests.

Let’s get back to our ASP.NET system that stores an encrypted sensitive information in a cookie. Each request, the system will probably decrypt this information and use it. In case the ciphertext in a cookie is invalid, an exception will be thrown, and the system may act according to one of the following scenarios:

· Return a 500 error response  - very user unfriendly!

· Return a default ASP.NET YSOD exception page - extremely bad in production environment!

· Return a page stating only the exception’s message - also very bad!

· Return a constant page, stating there was an error, without providing details– a good practice, this is actually the Microsoft’s workaround

· “Swallow” the exception, and behave like the cookie does not exist. The response may be a redirect to another pager, or just a a slightly changed HTML (instead of user’s name, a “login” link) – This is the way ASP.NET Forms Authentication works.

Note that every one of the possible responses is different from the normal one. Even the last scenario I’ve described above, as clean as it is, still returns a distinctively different response. Therefore, an attacker can take advantage of it, and write a simple script that infers this abnormal behaviour to an Invalid Oracle’s answer. It is that simple!

That’s mostly right except that it’s not sufficient to detect any error condition – you need to be able to discern between two specific error conditions (ciphertext not correctly padded vs. ciphertext is correctly padded but decrypts to an invalid value).

If visitors to your site can do this, you’re still vulnerable. Here’s a scenario: you don’t rely on Forms Authentication, but instead have a custom authentication scheme that relies on encrypted cookies. If an invalid cookie is submitted, you treat the user as anonymous; but if an exception is thrown during decryption, Application_Error kicks in. This scenario, not entirely uncommon, still allows the attacker to replay the request and differentiate between the 3 possible replies.

How does your application respond in these scenarios and how confident are you of the answer?