It’s time for Philly’s premier emerging tech conference, and I’m going to be speaking once again this year. The conference, Emerging Technologies for the Enterprise, is taking place March 26-27, 2008 in Philadelphia.

I’ll be giving a more technical talk this year than last, combining my interests in leading-edge web applications and security. The talk is called Securing Web 2.0 Applications:

The challenges of securing first generation web applications and infrastructure seem like a distant memory: immature technologies throughout the stack, coded in a culture that didn’t understand or value security. Today we have a much more security-conscious community producing components from operating systems to routers to web servers, and the basic architecture of the Internet application has had 10 years to mature under fire.

Even so, the security challenges of Web 1.0 were in many ways less daunting and harder to ignore than those of the current generation. This talk will review the challenges and lessons of the past, and survey security requirements, issues and techniques for dealing with a new generation of web frameworks and tools, massively multi-tenant applications and hosting environments, and loosely-coupled systems.

Its great to see Jeff coming to Philly for this; we have a small but vibrant and growing emerging tech and startup community here, and some people are already using S3, EC2 and the rest of AWS for new projects. For details on the meetup and to sign up, see the event page.

There does seem to be a general upswing in the visibility of math in the commercial world, starting with the extension of the quant revolution in the finance markets to the optimization of a diverse set of industries. The rise in the popularity of poker, and the influx of new players, has led to some new popular interest in math as well - books like The Mathematics of Poker (which I recommend) were hard to imagine on bookstore shelves a few years ago, but have been remarkably successful.

In the world of technology-driven startups, which was the context for Ann’s comment, I draw an imaginary line between two applications of math:

• Creation of a fundamentally new product, business or market
• Optimization of an existing business

The latter of these applications is the one that is driving the quant revolution in finance, poker, and a thousand other areas. In the online world, some big ideas have already broken ground and fundamentally changed the way a number of markets work. The mechanics of business online and the rush to market, however, mean that a lot of the decades of quant optimization in the offline world has been left behind.

I’m pretty excited about the opportunities that come from taking inefficiencies out of businesses that operate at Internet scale, as well as recapturing some of the subtleties of the offline markets. Math is cool again, and some very cool new answers are being created to the age-old question asked of math teachers - “But when will I ever use this?”

The goals of comScore’s research, of course, is to make the case for panel data in accurately measuring audience. Fred’s conclusion is more general:

You cannot rely on your own analytics data. You need third party data as well. That’s not to say that third party data (primarily panel data) is perfect either. You have to triangulate between all the numbers to get a decent view of what’s actually going on.

Undercounting conversions

All of that said, I titled this post “undervaluing web audiences” because I think there is an interesting flipside to the big “audience is overcounted by 2.5x” message of the study. If audiences are overcounted by this much, and those overcounts apply to ad impressions as well as overall unique visitor counts (according to the study, unique ad impressions were indeed part of the analysis), then there is likely some depression of conversion rates in many of the cookie-based analytics tools.

I’m sure that some simple conversion paths are exempt from this problems: a click on a search ad that results in a conversion during the same browser session is unlikely to suffer from any of the cookie-related issues outlined in the study. More complex paths, however, such as those based on brand impressions, repeated display ad impressions or deferred conversions, are likely to be undercounted by the same measure as the unique audience.

The behavioral ad networks are known for the application of their technology to targeting. Another key asset, however, is the ability to measure the value and ROI of online brand advertising. They use their networks, based largely on cookies, to track the deferred conversions that prove the value of a brand impression campaign.

If they are undercounting these conversions by 2.5x, perhaps current impressions are undervalued such that a correction for overcounting of audience would need to be somewhat offset by an adjustment to effective CPM for the brand ads run on the site. In any case, I’m sure advertisers doing brand impression campaigns, as well as the ad networks, will want to figure out how to more effectively measure deferred conversions if cookies present such significant accuracy problems. It sounds like Tacoda might be using comScore’s data to try to adjust.

‘On behalf of’ logins

LinkedIn and Plaxo are examples of sites doing this to import contact information. In fact, Plaxo makes this functionality available as a service to developers of other applications. Slide, RockYou, Photobucket and a bunch of other widget publishers do this to smooth the process of getting their widgets on users’ pages on MySpace, Bebo, Hi5 and the others. Also, some of the more interesting mashups involve data from the deep web, and require usernames/passwords to get it from 3rd party sites.

API-based authentication

Contrast the ‘on behalf of’ approach with that of Facebook, which exposes APIs providing for access by 3rd party applications, on behalf of users, through a direct authentication by the user to Facebook. As long as the APIs support the access required, this eliminates the need for the 3rd party to collect usernames and passwords.

The fact that MySpace and others don’t have API access (or complete enough APIs) to their sites is what has driven developers to collect credentials and act on behalf of users.

Some sites actually have APIs but don’t take advantage of the fact that they could use them to tighten up security. While Salesforce could use the Facebook-style authentication for 3rd party apps, they instead have those apps solicit and store user credentials (by policy, they allow only “certified” apps to do so).

Why are ‘on behalf of’ logins a problem?

If the 3rd party site is deserving of users’ trust, and everything works properly, there should be nothing wrong with these logins. We don’t worry much about local applications doing this type of thing: blog editors, web design programs, browsers and countless other local apps all store user credentials for 3rd party apps and sites. In fact, this type of login is enabling startups to drive innovation in the new social network ecosystem; if they had to wait for the MySpaces of the world to publish APIs or enable new functionality, these companies would be dead in the water.

In reality, there are some real problems to think about. In addition to a couple of shared issues, the key differences from local applications are also the problems here:

• Trust of the application and vendor - an issue with both web and local applications. The decentralized and volatile nature of web applications, and the lack of user-centric security infrastructure (such as local anti-virus and anti-malware software), make this a tough problem for web applications.
• Authorization of the specific actions that apps take on behalf of their users - an issue with both web and local applications; if this is done really well, the problem of trust of the app and vendor is diminished.
• Location of user credentials - in web applications, these credentials live ‘in the cloud’ somewhere. The vendor claims and reality of the security of those credentials are at best hard to verify.
• Scale - the barriers of installing, and updating, local software limit the scale of this problem in that world. Web applications are easy to sign up for and can be updated multiple times a day, leading to a lot of complexity in managing overall user security.

It looks like a solution probably starts with a way to give users centralized control and management of:

• Authentication credentials
• Authorization of ‘on behalf of’ logins
• Authorization of specific ‘on behalf of’ actions

What about OpenID?

OpenID is a framework for decentralized identity. It supports decentralized authentication and structured sharing of personal information.

‘Decentralized’ in OpenID terms means decentralized from the perspective of web applications; this can in fact mean centralized from the user’s perspective. OpenID could be used to do logins on behalf of users without the collection of credentials, but it does not address the problem of authorization of those ‘on behalf of’ actions. The structured sharing of personal information involves a narrow kind of authorization, but too limited to solve this problem.

The transparency of ‘on behalf of’ action is itself a pretty complex problem - it requires giving the user a way to see and understand what the 3rd party app will go and do for them on the other site. I’m not sure whether this is a problem OpenID is interested in tackling. If it develops momentum as an identity standard, it would certainly be nice to see it go beyond authentication and identity to a more complete view of security (something Microsoft’s virtually dead Passport initiative and the Liberty Alliance project both failed to do).

Small buyers of technology, acting early in the technology adoption life-cycle, are motivated by hope (hope == ROI, opportunity, etc). Large buyers of technology, acting late in the life-cycle, are motivated by fear (fear == risk of loss or punishment).

A good example of this can be found in the typical upgrade cycle. Early, individuals and small groups upgrade to new hardware, operating systems and applications because they hope that access to new features and capabilities will be more than worth the effort and disruption of the upgrade. Large groups don’t upgrade until much later, even if the benefits of doing so are dramatic; they often wait until the fear of loss of support from vendors forces a transition.

I remember experiencing this dichotomy in the major changes to the practice of information security as the commercial Internet grew in the mid 1990’s. Security shifted from an operational part of IT, where purchases were motivated by fear of loss rather than ROI, to a source of enabling technology for new ways of doing business. Within startups and large existing enterprise, small teams tried to figure out how to build online businesses. Along the way, they pushed the nascent Internet security product companies into building the right pieces to enable and protect the new ecommerce ventures.

Today, it seems like information security has largely returned to the operational state: anti-malware technology is a cost of doing business online, regulatory requirements drive new security spending, and fear of public outcry and regulatory enforcement prompts increased scrutiny on the handling of customer data.

It is likely that large organizations will miss much of the benefit of web 2.0 technologies as well, as they wait for incumbent software vendors to deliver later in the adoption cycle, when they will buy out of fear of being left behind by competitors. Most of the startup companies I see trying to sell innovative technologies into the enterprise today through the IT organization haven’t really figured this out.

A few companies, however, are dealing with this really well. Most are SaaS plays, and Salesforce is among the first of the good examples. Salesforce established small, dedicated groups of customers who bought the service with company credit cards rather than purchase orders, and used it without the authorization of central IT. Companies like 37 Signals, Zoho, ConceptShare, and countless others are using roughly the same model.

Going back to the idea of hope vs. fear in the acquisition of technology, I think there are a few things these startups could be doing differently to scale sales to big organizations.

Enterprise Freemium

The freemium pricing plans offered by the three startups I mentioned above are structured in a way that makes sense for small teams, but breaks for very large ones. They all offer some kind of free trial, and then price their services based on the amount of use (number of users, amount of storage, etc). Within a large company, this means that a small number of initial users can evaluate the product, and probably pay for ongoing use on a credit card, but growth becomes more difficult at that point. After the trial period, new users typically can’t be added without moving up to a pricing plan that supports them. The team footing the bill, however, is only willing and able to pay for its own use, not the much higher prices that come with larger plans.

I think there could be an enterprise twist on the freemium model, with the following characteristics:

• Free trial for each additional user within a company
• Easy options for billing/payment by user or group, rather than for the whole company
• Premium options for IT

The last of these, ‘Premium options for IT,’ is the most important. Knowing that IT won’t make early technology buys to support their users’ hopes for opportunity and improvement, the startup should support broad grassroots adoption of their products at lower levels. When the motivators that drive IT purchasing, such as fear of losing central control over data, backups, users, access control, and management complexity, kick in due to the grassroots use, the startup needs to be there to directly support IT with purchase options.

For a SaaS product, these IT premiums might be things like onsite, appliance-based offerings of:

• Directory services integration for user accounts
• Enterprise backup integration
• Data integration with reporting, dashboard, data warehouse and other systems

There are plenty of examples of enterprise IT banning the emerging technologies that come onto their radar when they don’t have a way to mitigate their fears. The best way I can think of for the startup to deal with this is not the traditional attempt to convince IT that their fears are unfounded, but rather giving IT a way to purchase that mitigation in the way they are used to and comfortable with.

This isn’t a big shift for most startups. The model still provides early revenue and a short sales process, but also offers a level of scale previously available only to those selling to a central organization. From a product perspective, this approach requires some thinking about the needs of IT and perhaps some new development; chances are that the thinking and planning will have benefits for internal SaaS operations if done early, and the development can be done at the right time to fit in with the adoption and growth of the product. If startups continue to deliver these innovative SaaS products with direct application in the enterprise, there may even be a Feedburner or Mashery model here: a company could focus on providing the IT premium layer for SaaS offerings.

As promised, here are the slides from today’s presentation. We talked so much about each point that I’m not sure how much value these have to folks who weren’t in the room… maybe we can get the organizers to do audio or video next time.

1. The emerging technology is initially ignored as a lab project or toy.
2. As the technology is first applied to solve business problems, organizations often attempt to restrict or ban any meaningful use.
3. When the production status of systems or apps built on the new tech can no longer be ignored, security is typically enforced through controls on the legacy infrastructure, which are the systems of record for existing enterprise data used by the new apps.
4. Eventually the emerging technology matures, and adoption increases, to the point that its security role and context is understood and verified to the same level as legacy systems.

This pattern results in a series of enterprise security risks, and perhaps more unfortunately, a series of missed opportunities to improve protection and decrease cost with each generation of technical change in IT. I would love to see IT security getting involved with emerging technologies at stage 1 in the pattern above, thinking about how the new tech can be used in ways that improve security rather than threaten it. Attempts at banning emerging technology in stage 2 usually push the use under the radar, so that departmental systems exist outside of normal production boundaries, increasing the risks over sanctioned use. The first attempts at security controls in stage 3 discount the value of data that lives in the new systems, and leads developers of the new applications to create their own security models from scratch, or largely ignore security under the assumption that it is a legacy system problem. Finally, at stage 4, a massive task has built up. As formal security models are applied to the new systems and applications, large, costly changes have to be made that would have been almost free if thought about earlier.

There is a generational change happening today in the enterprise, and I think it is not too late to change the pattern. The technologies that are driving down the cost of starting Internet companies are having an impact in the enterprise as well: open source software such as Linux and MySQL, newer languages such as Python, Ruby, Erlang and PHP, frameworks such as Ruby on Rails, and other technologies like virtualization and outsourced web service infrastructure (EC2, S3, etc) are all enabling rapid, inexpensive development of production-capable apps by very small teams.

This generation of emerging technologies brings with it some wise principles: a core focus on testing, continuous integration, convention over configuration, and loose coupling via well-defined interfaces (among others). I think the opportunity presented here is a great one. If people who care about enterprise security get involved with these technologies and the communities behind them now, then security can be built into these frameworks in a way that makes it tough to build new applications that don’t do security well.

Using Ruby on Rails as as a simple example, if good security becomes the convention, it is built into every application and tested for at every stage. Simple investments in gem-based integration of enterprise security infrastructure such as single sign-on and role-based access control systems can create an environment where developers build and verify security by default. The enterprise can do this internally, and can also encourage or require outside vendors of security components to support emerging technologies much earlier than they do today.

This kind of investment is a big shift for most enterprise security organizations. It will require spending, managing and perhaps hiring a bit differently, but I believe the result is better security at a lower cost to both the security organization directly and to the enterprise in general.

Whether building a new company from scratch, or keeping a big company competitive, emerging technologies have changed the rules. Open source software, web services, mashups, AJAX, Ruby, Rails, and RSS… only a few of a seemingly endless list of technologies that have redefined what is possible for small teams. This talk will focus on startup experiences, lessons learned about technology choices and tradeoffs, and on building, funding and running a technology startup in the new environment.

The Emerging Technologies for the Enterprise folks are also putting on a pre-conference breakfast for CxO’s and executives on the 15th. I’ll be the keynote speaker for that event, talking about Tiger Team Innovation:

Startup companies use small teams beginning with a blank slate and the latest emerging technologies to build incredible value overnight. This talk will focus on using the same techniques, with a few twists, to deliver measurable value to the enterprise in new ways.

The main conference is open to everyone and seems to be quite reasonably priced compared to most such events; registration is here. I believe the breakfast is by invitation, so if you’d like to attend leave a comment or send me email and I’ll ask the organizers to include you.

I think this is the kind of thing that CIOs and CISOs will need to be thinking about as emerging technologies reshape the organizational and physical footprint of IT and add an order of magnitude more interconnections between applications and systems.

My good friend and long time co-conspirator Stephen Cobb recently asked what I thought were the emerging threats to enterprise security. There are a few threats that I’ve been giving some thought to lately that I haven’t seen addressed effectively; I’ll tackle one of these in this post and leave the others for later.

Security of Software as a Service

There is a lot of momentum behind the software as a service model; Salesforce.com is the poster child, but a big set of products that used to be delivered from inside the corporate datacenter are now bought as services and delivered from shared vendor resources outside. Some dismiss security concerns about SaaS as cynical, but I think there is a lot more to this story. The enterprise security issues can be broken down into a few sections:

Product security

The concerns about product security are much the same for SaaS as they are for traditional enterprise software purchases. Architecture, security features, and underlying implementation are all key factors in the overall security of the product.

There a couple of distinctions between the two that come into play: the evaluation of SaaS offerings is feature driven and does not typically include implementation detail, and the lack of an in-house integration phase (a key benefit of the SaaS approach) means that vendor claims are never put to the test in the way that happens during the real-world integration of software products in the enterprise.

Among the risk elements that come from these distinctions is the lack of visibility onto and control of scope of compromise and consequences of component failure. Essentially, without visibility onto implementation detail, and real-world verification of vendor claims, it is very difficult for the enterprise to understand the security impact of the failure of any part of the system.

Multi-tenancy

A set of security issues unfamiliar to the enterprise is introduced by a key component of the SaaS model: the hosting of multiple customers on shared infrastructure. Multi-tenancy takes a variety of forms:

• application level divisions between customers

The most basic form of multi-tenancy is implemented by SaaS vendors as an application construct. This means that the divisions between customers are unique to the application, and are not subject to outside scrutiny. A bug at the application level can result in a failure of separation, meaning that other customers or even the general public may have access to enterprise data.

This option requires custom development by SaaS vendors, typically provides for the most attractive customer density and scalability profiles, and presents the most difficult security challenges for the enterprise.

• logical separation between customers

Separation implemented below the application level relies on integration mechanics to keep the divisions between customers intact. For example, individual web server instances (running on shared hardware) mapped to different hostnames might provide a front-end separation. This can be continued through routing of requests to similarly configured middleware instances and database servers. Often some components will still be fully shared, such front-end load balancing / caching and back-end storage networks.

Since this option depends on features of 3rd party components, and implements multi-tenancy through integration and component configuration rather than software development, it is both easier to validate from a security perspective and involves less up-front cost to the SaaS vendor. Customer density and scalability, as well as complexity of new customer deployment, can be impacted.

Security issues can sometimes be severe in this case as well, when the failure of an infrastructure component threatens a key assumption about logical separation. Failure of VLAN separation due to a bug in Cisco’s switching software, for example, could compromise logical separation between customers if those protections are not implemented in a layered way.

• physical or pseudo-physical separation between customers

An extreme case of the integration-level separation described above is the use of virtual OS instances or physically separate systems to provide independent instances of applications and supporting infrastructure such as database servers. This case provides the most easily validated architectural security; as OS virtualization matures and server hardware is designed for these workloads, the scalability, density, and deployment cost/complexity challenges of physical separation will likely improve.

The security impact of multi-tenancy, along with core product security, comprise the directly technical part of the challenge for the enterprise.

Operations

The operational issues stemming from the use of SaaS are not particularly technical, but can be difficult to manage and control. At the heart of the issue is the fact that critical enterprise data must exist, for an extended time, on systems controlled by a third party.

• Direct Operational Issues

The employees of the SaaS vendor manage its systems; they have access, ultimately, to the data of their enterprise customers. While not unmanageable, the potential for access by employees not subject to direct monitoring and control by the enterprise presents a significant risk.

• Organizational Issues

Custody of enterprise data by a 3rd party presents some broader challenges as well. Since the 3rd party has access, they could faced with subpoenas or other challenges that might be handled differently by the enterprise directly. Business relationships, changes of control, or even acquisition of directly competitive customers can create real or perceived misalignments of interest.

Essentially, the law recognizes certain providers of business services, such as legal counsel or accounting services, as having a special or protected relationship with their clients. It remains to be seen how the law evolves to handle these new types of service provider whose access is no less sensitive.

SaaS isn’t going anywhere, but the fact that there haven’t been any front-page losses yet isn’t a reason to put off thinking about these security issues. I think that there are probably some opportunities for technical solutions to control some of this risk, and make the process of ensuring and validating security of SaaS deployments much more manageable for the enterprise.

In the mean time, I think an exploration of these issues by the enterprise in looking at SaaS deployments will lead to more sophisticated requirements and vendor selection, and better understanding and control of risk today.

Looking at the technically innovative startup pitches I’ve heard from this perspective, I can break them down into two basic categories.

Horse before the cart: we have built this really incredible technology. Here’s what it is and how it works. Take a look at our demo, which proves that we have built this technology. Here’s a list of amazing things we can do better with this new technology.

Cart before the horse: we are doing this amazing thing. it wasn’t possible before, and doing this thing enables an awesome new business. Take a look at our demo, which proves that are doing this amazing thing. It works because of this really incredible technology we have built.

Yahoo, and other big companies, can afford to occasionally build and launch a new horse without putting a clear, focused application of the technology out in front. In fact, doing so can help them maintain their influence and claim leadership in new areas. Some successful startup companies have built technology first without a narrow application guiding the business, but I’d argue that these are the exception rather than the rule.

From the founder perspective, I think that focusing on a technology, however cool, can lead to some problems. When the technology comes first in my thinking, I can fall into a trap of not diligently evaluating even one of the many potential market opportunities. Focusing on one little application of the cool new technology means thinking about things like who, exactly, will buy it… what will they pay for it… how will they use it… how will it change their lives. Cool technology is really exciting to a few people, but the thing it does is what makes it exciting to lots of people.

Looking at companies from the outside, as an investor or otherwise, I find the technology/application focus question to be even more important. Founders may have a grand vision for an eventual application of the technology, but if they are focused on building a business around a focused, narrow application first then they will make better decisions about how much money to raise, how much to build before launching, and how to measure success. The focus on an initial application makes business decisions, external and internal, quite a bit easier. It also turns the technology into a key asset and competitive advantage, rather than the company’s raison d’être.

Funding or starting this type of company means that the initial, focused application stands on its own as a business that should be built. If that business is successful, the company can leverage its technology assets in tackling larger opportunities.

There is no question that the advancements in search have profoundly changed how users interact with the web. It can be argued that Google is the start page for most users, and some are extending that argument by stating that Google is on its way to taking over the Internet not just in search market share, but in a fundamental economic sense.

Looking at things from a slightly different angle, I wonder about the impact of these changes. If the web (the html/http application layer) is itself a network, it is interesting to look at that network in some detail. I suppose the nodes are individual web pages (hypertext documents, actually), and the connections between those nodes are the links between pages. As with the synaptic connections between neurons in the brain, the links between web pages are critically important to the web’s status as a network, rather than simply a repository of information. I think it could be argued that those links play a similar role to the synapses of the brain; the set of pathways between chunks of information and specialized processing capabilities contains the “intelligence” of the network.

Even if you don’t take it quite that far, those links are certainly important when you look at the web from the perspective of Metcalfe’s law. Metcalfe states that the value of a network is proportional to the square of the number of nodes in the network; this value is based on the exponential (or at least superlinear if you side with recent skeptics) increase in the potential number of interconnections between those nodes, and has been used to justify the business plans of countless dot-com and web 2.0 startups.

Do the changes in the use of the web, namely the use of Google as a start page and basic navigational component, change the structure of the web as a network? For the majority of users, the links between pages are decreasing in importance as the navigational pattern involves an increasing number of returns to Google as the start page. Even with this change, however, the links between pages are still important in the ranking of pages by the search engine.

The diminishing role of links for the average user and the increasing role of Google leads to a hub and spoke experience; each use starts from that central start page. More importantly, each navigation is enabled not by the inherent capabilities of the network, but of the capabilities of the central application. I think that the net result of this change may be a shift in value, in a Mecalfe sense, from the network to Google.

Google’s OneBox is a good example of how this shift in value might be happening. Where a generic search might return a variety of results, both related and unrelated to the searcher’s intent, OneBox attempts to simplify the results by guessing at intent and presenting information based on a set of rules and supported structured data sources. Josh Kopelman points out that this effectively makes OneBox a vertical search engine.

I think this is the case, but it creates a different kind of search engine from what we have become used to; the OneBox capability is essentially a query engine onto structured data, rather than a search engine onto a distributed network of connected nodes each containing largely unstructured data. The value of a set of structured data does not seem to increase superlinearly with the number of data entries available, in contrast to the network value of the web as discussed above.

These changes in the importance of links between web pages, and the shift to querying of structured data in place of exploration of linked data, represent what I’m thinking of as a flattening of the web. I’m not sure this is a bad thing; perhaps the value of the underlying web is not diminished by these changes, and sections of that web just become valuable enough that they warrant being made available in more direct ways. It is also possible that there is merely an apparent shift in value, as the AdWords/AdSense advertising economy brings the value of certain of the underlying nodes to market. On the other hand, perhaps this flattening of the web represents a real, and not just apparent, shift in value from the web of linked nodes to the central engine. That central engine, by decreasing the importance of the connections between nodes, may be decreasing the total value of the network in order to control a larger part of that value.

The blogosphere, and all of the various forms of user-generated content in other media, is certainly a rich source of new nodes and links, and new network value added to the web. The importance of the link today is clear as a storm runs its course over the topic of linking between blog posts. Even so, I think it makes sense to be aware of how changes in technology and the use patterns of the majority of users impact the value of the network itself.