- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
The Truth About Designing For Security
Security is an area of concern where value and cost are often difficult to estimate. While big mistakes made early on in many areas of an application may prove difficult to correct, this is especially true for security, since its specifications often model a direct reflection of an organizational structure.
And all too often, dysfunctional organizations create dysfunctional security requirements.
It is common knowledge then that a failure to account for security from the start can prove much more costly in the end. However, over-engineering security needs can require so much effort that your team may not have enough time left over to actually build the very features you are trying to secure.
I find the following two points very useful to keep in mind when participating in discussions concerning security regardless of the application, but especially when working under the assumption that a new application needs the same kind of security model as the old application:
- All security models are idiosyncratic
- Never underestimate the cost of being flexible
These two items work as polar opposites of each other: a flexible system can accommodate many types of organizations, but not without the added cost of training, installation, documentation or maintenance. On the other hand, a static model is cheap to build, but rarely captures the nuances of an organization's structure, particularly as business needs evolve over time.
Continue reading »
Topics: architecture, Design, Security
SMash - Something Useful from the OpenAjax Alliance?
In the announcement that the OpenAjax Alliance had released OpenAjax Hub 1.0, and would start to work toward 1.1, there was one thing that caught my interest: the news that 1.1 would support secure mashups. Given that proxies and JSONP are both pretty open to abuse by unscrupulous service providers, this was certainly welcome news? So, what exactly does this secure mashup support look like?
The nascent SVN repository at Sourceforge wasn't much help -- mostly just a placeholder for future work. A little digging reveals that the OpenAjax technology will be based on a technique known as 'SMash', developed at IBM for performing secure mashups. I was able to locate a copy of a research paper on SMash (not sure if this is meant to be public, so grab a copy).
Topics: Ajax Widgets, Mashups, Security
Ajax security surprises: web-aggregators, offline applications and frameworks
I'm still absorbing the densely packed information from "Ajax Security," the first-rate book by Billy Hoffman and Bryan Sullivan that I recently recommended in these pages. Here, in no particular order, are three of the most surprising lessons imparted by Messrs. Sullivan and Hoffman:
Web aggregators and SSL
This is probably a great big "duh" to some developers, but web aggregators such as iGoogle and NetVibes often compromise the security of otherwise SSL-encrypted web applications when funneling content from them to your personalized homepage:
Now, consider what happens when you use a Gmail widget on an aggregate site like NetVibes. Sharp-eyed readers will notice the URL for NetVibes ... is http://www.netvibes.com. This is not an encrypted connection! NetVibes sends user data in the clear from the aggregate to the user.... NetVibes makes an SSL connection to Gmail, and then NetVibes degrades the level of security by transmitting the data over an unencrypted connection. Our attacker ... can steal the data much more easily now. NetVibes is not providing the same level of security that a user would receive if he accessed Gmail directly. This situation is not unique to NetVibes and Gmail.... At the time of publication, every major aggregate Web site the authors examined downgraded security on data from secure sources. [emphasis theirs]
Topics: Best Practices, Books, Review, Security
Book recommendation: Ajax Security by Hoffman and Sullivan
Reviewers overuse the phrase "required reading," but no other description fits the new book "Ajax Security" (2007, Addison Wesley, 470p). This exhaustive tome from Billy Hoffman and Bryan Sullivan places the specific security concerns of the Ajax programming model in historical perspective. It demonstrates not only new security threats that are unique to Ajax, but established threats that have gained new traction in the Web 2.0 era. It then details both the specific technical solutions and - more importantly - the mindset that are necessary to combat such threats.
Because so many developers have historically overlooked the importance of security, the authors approach their topic for what it is: a remedial subject. They take pains to explain the basic mechanisms by which hackers have exploited insecure web applications over the last decade: cross-site request forgeries, denial of service attacks, cross-site scripting and SQL injection. Then they explain how those mechanisms have changed thanks to the rise of xmlHttpRequest, public APIs, mash-ups and aggregators. If you've ever read a Douglas Crockford rant about the "brokenness" of the web security model and wondered why the guy was such an alarmist, Hoffman and Sullivan are only too happy to provide you with a much-needed wake-up call.
Topics: Ajax Development, Security
GWT Security Talk
Billy Hoffman is a wild man when it comes to exploiting JavaScript and HTTP. Watching him twiddle the bits with Firebug was a pleasure. But this talk was more about Ajax security (and really, Browser/Webapp security) than GWT security.
Security is really about the nitty gritty -- dusty corners of technology that can be exploited to subvert an app. As such I might buy his book. It helps to have a big list of holes and tools for exploiting them. But in Billy's own words "these attacks are nothing new. They've been around for years. With Ajax, people are just finding new ways to screw up."
Most of the Ajax security issues are really about having too much state and logic on the client side. GWT, if anything, hides the details (see here and here about leaky business logic) and makes writing code on the client side so much easier (right?) that you are likely to have more state and logic on the server side.
Some good things out of the talk:
- don't make your web services API too granular.
- be careful of control logic DOS attacks, put control logic on server
- use locking on the server to prevent race conditions
- Be careful of third party widgets that can override the logic of other widgets.
Also, using a google gears worker thread, that continues running even after a tab is closed, injecting stuff into the SQLLite DB, you can fill up a 20GB hard drive in under an hour.
One thing I hadn't come across was the technique to make JSON safer, i.e. preventing JSON from being executed via a <script src=""> the way to do that is using the following:
for (;;); /* rest of JSON message */
Some quotes from Billy:
"SQL injection and cross site scripting is rampant, but exploiting applications is even easier and you can do it with just a browser."
"Ajax provides an increased attack surface."
>API Keys for Ajax Services
I'm sure not everyone is developing Ajax-based front end sites and applications. There must be someone who is developing XML, JSON and JSONP web services, right? So, if you are going to offer it as a commercial service, and even if you aren't, you still want to be able to control and measure access to it. Something like those Google and Yahoo service API keys, right? I'm sure we've all worked with MD5 and SHA-1 enough to have some ideas about how that would be done, but it helps to have an example to follow.
Well, check out this article over at java.net: Creating and Using API Keys with Java Based Ajax Services. It demonstrates the client and server side pieces to using an API key. Lots of code, and shows how to generate the key from the client web site address and a secret service token. (Note: the example relies on the now outmoded MD5 to generate the token, but that could easily be switched to SHA-1 or some other one-way hash.)
Technorati Tags: ajax, json, jsonp, api key
Topics: Ajax Development, JSON, Security, Web Services
Google Gears Security Thoughts
The new Google Gears comes with a long set of security warnings and disclaimers. Nitesh Dhanjani over at O'Reilly's ONLamp.com had some initial thoughts about the security of Google Gears:
If I had to pick ..., I’d guess that we are most likely to hear of existing XSS or browser vulnerabilities being abused to steal (or manipulate) Gears databases.
I agree with Nitesh: the attack vectors will remain the same, but the consequences will be much greater. Some folks, such as those working on the Dojo framework, are addressing some of the offline storage issues with encryption:
Right now Dojo offline adds a DES encryption library with functions to encrypt and decrypt. The example used encrypting/decrypting SSNs. He also pointed out that doing this in javascript can be computationally intensive and hasn’t been that feasible before. Right now though using Google Gears worker threads they can encrypt/decrypt in javascript at about 80k/second.
You could also roll your own from this implementation of AES, RC4, RSA and a number of other algorithms. While this approach solves the stolen laptop problem, it doesn't solve the XSS problem, i.e. as long as you can inject Javacript into a page, you can bypass this security. After all, the plain text has to pass through the sandbox, where it is fair game. In this case, Google Gears just papers over the shortcomings of browsers.
It is possible that WorkerPool could be used to limit the kinds of modifications that are made to the encrypted data:
The WorkerPool behaves like a collection of processes, rather than threads. Workers do not share any execution state. Changing a variable in one worker has no effect in any other worker. And created workers do not automatically inherit script code from their parents.
Members of a WorkerPool interact with each other only by sending message strings. Workers can also pass richer data types, by first converting objects to strings using JSON.
We can hide the encryption details in a WorkerPool member and communicate with it via messages. We still pass plain text data through the main browser execution context, but we can at least regulate the access to the encrypted database -- i.e. no bulk downloads or modification.
As a final thought, what's bad for ActiveX is also bad for Google Gears. The fact that the project is open source and thus not a black box, mitigates this criticism only somewhat. To make me comfortable with Google Gears, all of the XSS volnerabilities will have to be closed first.
Technorati Tags: ajax, google gears, security, dojo, encryption
Topics: Ajax Frameworks, BJAX, Dojo, Google, Security
The Problem with JSON
I've been tracking the whole insecure JSON debate over the past couple of weeks with some interest. I've been promoting the use of JSONP for a while, so I thought I'd provide a summary of all of the action and summarize what I myself plan to do.
Rob Yates originally proposed some best practices for the use of JSON in secure applications.
When developing a JSON api that contains data that should not be publically accessible to the world use Approach 1 i.e. return plain JSON.
Joe Walker then started the whole imbroglio with his article showing how to subvert JSON services that return arrays. In Joe's example you redefine the Javascript Array constructor, then call a JSON service using a script tag. He later blogged about how this could be done with objects, as well.
Right now these hacks only work on Firefox, and there are limits to the kind of JSON that can be eval'd outside of an assignment statement, but that is no reason to be complacent about this issue.
This guy tried his hand at defeating the above hack by grabbing a fresh copy of the Array object from an iframe, but in the end concluded that in an arms race between the hacker and the application developer on the client-side, the hacker will always win. As Joe Walker pointed out, "In the end you can't trust the environment that you are sending the data to, so you should only send data to people you trust, and that means having URLs that are not predictable."
A related topic (as pointed out in some of the posts above) is that of Cross-Site Request Forgery (CSRF).
Cross-site request forgery, also known as one click attack or session riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of malicious exploit of websites. Although this type of attack has similarities to cross-site scripting (XSS), cross-site scripting requires the attacker to inject unauthorized code into a website, while cross-site request forgery merely transmits unauthorized commands from a user the website trusts. Compared to XSS, CSRF attacks are not well understood by many web developers and few defense resources are available.
These two methods can be used in concert. For example, the JSON hijacking can be used to lift information such as account numbers, and then CSRF is used to construct a URL that causes some sort of malicious action in the application.
As for what I plan to do in my own secure web application development, it remains pretty consistent with what I did before the advent of Ajax:
- Use SSL, obviously.
- Don't rely on cookies for authentication and set short timeouts for user sessions. You can require a randomly generated chunk of the path of application url's for each unique session instead.
- Make sure that all of your URL's that modify data or have other side effects require POST. This doesn't eliminate risk, as an attacker can use Javascript to launch a form POST, but it does cut down on the opportunistic uses of image and other tags that perform a GET -- reducing the avenues of attack.
- Perform referrer checking. Again, this is no panacea, as an attacker can use flash or XHR to subvert this, but it raises the bar a little more and restricts the avenues of attack further.
- Use a request token that is dependent on the previous response (SHA-1, etc.) and includes a sequence number. If a request is made that is not valid, the user sessions should be immediately invalidated. (An attacker could theoretically compromise the user's machine so they could defeat even this approach, but at that point I'd have to throw up my hands.)
- Detect, log and notify on all suspicious activity.
- Use JSON only for publicly available information, i.e. if they can get it by hacking your browser, they can just as easily get it for themselves.
There are limits, however, to what can be done. As long as browsers have security holes and Javascript allows, well, what is allows, there will always be some new avenue of attack for hackers to exploit. (Let's not even get started on viruses and trojan horses on the client).
Further Reading:
You may want to read an article over at IBM on secure mashups which covers additional ground, such as the use of the fragment identifier (http://host/path#fragment). Also, some additional ideas around REST, HTTP Auth, and resetting the Javascript Array object to its original state through delete Array, can be found here.
Finally, the incomparable Bruce Schneier has a blog entry on a paper on JSON Hijacking. Read it and the comments.
Alert: Security Update for Firebug
Joe Hewitt has released a security update to his excellent FireBug Firefox addon.
About an hour ago I received word of a 0-day security exploit that has been discovered and reported. I have just released a new Firebug (version 1.03) with a fix for this bug, and I recommend that everyone install it as soon as possible.
The update has been published to addons.mozilla.org, so you can get it by updating Firebug from the Firefox Add-ons window. Alternatively, you can install the update using the big orange button on the getfirebug.com home page.
Topics: Ajax Tools, Firefox, Firefox Extensions, Security
IE7 Security Vulnerability Discovered
I've been on the road and had a little registry crapout (makes me feel all warm and fuzzy about the "all stick and no carrot" release of Vista), so I've been postponing the upgrade to IE7 until I've had a chance to get home and restore from backup. Right now I actually feel pretty fortunate that I've been unable to upgrade.
Is anyone surprised that a security vulnerability has been reported for IE7? This site claims that there is some sort of cross domain vulnerability in IE7. Reading the code a bit, it looks like the back end site can redirect an XHR request to a site of it's choice using a 302 HTTP redir. Why is this a security vulnerability? Imagine that you work for Goldman Sachs and you are accessing a nifty social bookmarking site villa.ino.us. This site makes an XHR request that redirects you to intranet.gs.com, or whatever the super secret internal intranet is. With a little bit of cleverness, you can adapt some of the http vulnerability scanning scripts to make use of this hole.
Scary business. This hole needs to be closed and quick.
Update: Looks like the actual attack vector is Outlook Express, not IE7. Still a problem, just a different source.
Securing Ajax
Scott Dietzen over at Zimbra has an interesting blog entry on Securing Ajax. He takes a somewhat unconventional approach, starting with the security advantages of Ajax:
- Dynamic Ajax client download - Ajax client code is downloaded on demand from the trusted server after a particular user logs-in, automatically ensuring client and server versions are in-sync (for public computers, a shift re-load is better in that it overwrites any Ajax code from that website leftover in the browser cache).
- No persistent client caching - An exposure with traditional web clients is that they cache HTML pages that can include user/application data on the client disk during normal operation. This can be a security vulnerability for access from public kiosks or other shared computers. Ajax applications like the Zimbra client cache no user data on disk.
- Server-side control of intranet and Internet mash-ups - Zimlets and other Ajax mash-ups are precluded from accessing arbitrary services on the Internet (unless they open a new iFrame, which can be determined at server deployment time), and must instead (like Java applets) make all invocations back to the originating server (in our case, the Zimbra server). This means the Ajax server can act as a secure, proxy gateway for accessing intranet applications, and can govern which external web services (if any) are accessible for mash-up within the Ajax client.
Among the downsides are the exposure of code on the browser. If you limit yourself to display logic, though, that is mitigated. An interesting article.
Topics: Best Practices, Security
Digging Behind the Numbers: 3 in 4 Use Ajax
By now you've probably already heard about the SD Times article summarizing a survey by their sister company, BZ Research, that claims that three in four developers have either launched or are planning to launch applications incorporating Ajax. It sounds like Ajax is spreading like a cold in an overworked development team. But you really have to look behind the numbers to understand who is answering the survey and exactly what use they are planning to make of Ajax.
SD Times is targeted at software development managers, so it isn't a developer focused nuts-and-bolts publication. You're mostly talking about corporate IT departments here. Just looking at their table of contents will tell you that they deal more with software business issues -- which vendor is releasing what, who is acquiring whom, what the government is doing about topic X -- and not at all with development, design, and architectural issues. You can almost hear these managers in their weekly status meetings say to their CTO, "yeah, sure, we've got Ajax in there."
So exactly what kind of Ajax is "in there?" A quote from the article is revealing:
"We are looking into using the technology for a Windows-like interface to our embedded system," said Wendi Whitcomb, a senior systems engineer at ZoZo Engineering, while Jeffrey Price, president of Price Performance, explained, "Customers demand desktop application look and feel. Citrix/Terminal server approach [is] becoming cost prohibitive due to licensing costs." Scott Finnerty, technical director of Barkley Evergreen & Partners Interactive, said, "We've embraced Rich Internet Application development as being key to the future of user experience for our clients."
These folks are from a class of companies who want to move their GUI desktop apps to the Web (see 10 Business Reasons to Use Ajax, reason #3). In particular, the number of companies that use Citrix to give remote access to their applications is legion. They most likely have a large development staff with expertise in VB or Visual C++, and were just getting comfortable with .NET when Ajax came along. These people are a long way off from re-architecting and re-implementing their systems as Ajax-based RIA's. It's easy to consider; it's harder to do.
I'm sure another large group of these enthusiastic adopters are those incrementally improving their webapp's user experience by folding edit forms into a single page. The barriers to entry for splicing an XMLHttpRequest into a page are not that high. Their users won't have to make as many clicks to get their work done, but it's a long way off from a true document based, direct manipulation application -- no desktop GUI here. Also, layering another technology like Ajax on top of your creaky struts/J2EE application, has its own hazards for productivity and software quality.
Last, a fair number will be scared off by sheer ignorance:
Security seems to be a common concern, with AJAX being "too much exposed for the client side: Some delegated checking should be double-checked in server, since in the client side it seems to be exposed to crack it," said Paulo Soares, general manager of Central Call.
It's not the Ajax, it's a poorly designed applications that let users persist executable artifacts, such as JavaScript and Flash, which can then be pushed to other users via their browsers, where the compromise occurs. And of course you validate data coming from the client in the server. Why wouldn't you?
What does this survey really tell us? Simply that Ajax has high buzzword awareness, that some major vendors like Microsoft and Tibco are lending credibility to its use, and that certain early adopters such as Google, Digg, and various e-commerce sites, have proven that it can be used to gain a competitive advantage. It's enough to make even a conservative software development manager feel the itch to make plans.
Topics: Ajax Development, Security, Trends
Major Security Hole Found in Rails
For all of you using Ruby on Rails, this announcement passed on as a public service:
We're still hard at work on Rails 1.2, which features all the new dandy REST stuff and more, but a serious security concern has come to our attention that needed to be addressed sooner than the release of 1.2 would allow. So here's Rails 1.1.5!
This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn't affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.
The issue is in fact of such a criticality that we're not going to dig into the specifics. No need to arm would-be assalients.
So upgrade today, not tomorrow. We've made sure that Rails 1.1.5 is fully drop-in compatible with 1.1.4. It only includes a handful of bug fixes and no new features
Update 1: A more extensive entry on the details behind the security hole.
Topics: Ruby on Rails, Security
The Bonehead File - Lousy Ajax Training
Whenever a new idea or technology springs up, someone will be happy to teach you -- for a price -- how to do it properly, whether its how to read a book or how to make money selling products from your home. With Ajax clearly still climbing the hype curve, there's apparently no shortage of people wanting to teach you how to write Ajax applications.Some of them are better than others. Over at Infosec and Politics, the self described "just another large corporate security guy" ran into one that was not so good.
I am in AJAX training this week learning the process of "properly formatted XML". They have us going through, writing code, getting data out of databases, all the things that you would normally do with tabulated code. Just one problem (spot the errors with this code set).
strConnstring = "server=(local); Driver=(SQL server); database=(DbCustomers); UID="name"; PWD="secret"
strSearch = "SELECT * FROM tblCustomers WHERE ustid=' " & strSearch & "'"
So this is Javascript. Aside from some syntax errors, putting sensitive data and business logic and backend details in the browser is about as boneheaded as you can get. And these are the trainers? Be sure to check out the bonifides of any Ajax training course before you drop a few grand on something worthless. Better yet, read one of the many great Ajax books (here, here, and here) so you can decide for yourself.
Ajax Security Basics
SecuirtyFocus has a decent article entitled Ajax Security Basics. A sample:
A second challenge relates to the difficulty involved in securing the increased attack surface. Ajax inevitably increases the overall complexity of the system. In the process of adopting Ajax, developers could code a great number of server-side pages, each page performing some tiny function (such as looking up a zip code for auto completing a user's city and state fields) in the overall application. These small pages will each be an additional target for attackers, and thus an additional point which needs to be secured to ensure a new vulnerability has not been introduced. This is analogous to the well known security concept of multiple point of entry into a house: the difficulty involved in securing a house with one door as compared to securing one with ten doors.
Good basic explanation of Ajax, and the new security vulnerabilities it exposes. The article also points out some pitfalls for current webapp testing methodology:
Applications may periodically send requests to the server to update information on the web page. For example, a financial application may use the XHR object to update parts of the web page that display current stock market information. The tester may not be aware of this process happening in the background if they do not catch the request at the right time, since there may not be visible links or buttons to suggest to the tester that there are requests being made in the background.
Well worth checking out.
Topics: Best Practices, Security, Tutorials
About Pathfinder
Recent
- Bandwidth profiling Flex projects and more with Charles
- iPhone SDK: UIViewController Testing & TDD
- Icons are evil; so are menus - unless you do them right
- The Truth About Designing For Security
- GWT, Gadgets and OpenSocial, Part 2
- Has Many has_many: A Refactoring Story
- The Hidden Power of Canvas
- Review of fixture_replacement2 plugin
- Chess Game Viewer in GWT
- From JSP to Ruby on Rails: First thoughts on front-end coding conventions
Archives
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
acts_as_ferret
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
apple
Application Architecture
Application Development
architecture
AS3
ASP.NET
Asynchronous Processing
awards
Azure
Back Button
bandwidth
bandwidth profiling
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
caching
Canvas
Case Studies
Charles
chess
Chesspresso
Chicago
Cloud Computing
CMS
COBOL
code
code art
Code Generation
Color
COMET
Conference
Confluence
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
design thinking
Desktop
Desktop RIA
Developer's Notebook
DHTML
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
fixtures
Flash
flash awards
flash player
flash player 10
Flex
flex css
flex skins
flexunit
Flickr
Flock
Flow
Frameworks
FriendFeed
front end
front end development
fulltext search
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gadgets
Google Gears
g phone
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
hardware
Healthcare
Hibernate
HTML
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
iGoogle
illustrator cs3
ILOG JRules
importing graphics to flex
Information Architecture
Innovation
Instructional Design
Interaction Design
interaction patterns design
Interview
iPhone
iPod
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSP
JSR-94
JsUnit
laptop
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
logging
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
minimalism
Mobile
Mootools
mouse
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
notebook
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
OpenSocial
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PGN
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
project management
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
resesign
Restlet
RETE
Review
ria
Rich Interactions
ruby
rubyamf
Ruby on Rails
Ruby on Rails testing role
S3
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
skins
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Standards
Startups
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
The Ajax Experience
throttling
Tilt Component
Tools
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Twitter
UI
UIViewController
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Venture Capital
Video
Vision
Visualization
VLC
Volta
Web/Tech
Web 2.0
Web Design
Web Development
Webkit
Weblogs
Web Services
Web Standards
Widgets
will_paginate
Windows
Wireframes
WordPress
workflow
work life balance
XML
XML Metadata
XU