Managing Fourth Party Tags

“I know what third parties are present on my website.” This is the response from a typical website operator when TRUSTe recommends an audit of all third party tracking on their site. How surprised they are to discover third parties on their site to which they were not aware. When this happens, and it happens …

View full post

Through the looking Glass

By Clay Turk (@clayturk) Product Manager | TRUSTe   Let me start by saying I am very excited about the upcoming release of Google Glass, and everything this means for the future of ‘enhanced’ reality (AR was so 2011). I suppose I should caveat this statement and say that my enthusiasm lies not so much …

View full post

HTML5…I mean, Local…I mean, DOM…I mean, Web Storage!

By Kevin Trilli (@squawkt22) VP Product | TRUSTe As we have moved rather quickly into 2013, the subject of mobile privacy has brought a renewed focus to client-side storage of identifiers and attributes.  Initially, this was driven by the fact that mobile safari with its default-on cookie blocking policy is especially relevant in the huge …

View full post

Do Not Track and Preference Management

By Travis Pinnick User Experience Designer | TRUSTe @xtratrav The current industry standard of providing user preferences around ad-related tracking makes use of a script-based in-ad icon as specified by the DAA which links to a preference management tool. Newer browsers are also supporting the Do Not Track (DNT) header request as an alternate method …

View full post

Technical Analysis of the IOS6 Tracking Identifiers and Privacy System

The new release for IOS6 contains several improvements in the tracking and privacy systems for advertisers and consumers. The release features are definitely just a starting point in what appears to be a long term strategy to embed privacy controls into the platform.  Below is an analysis of what is included within the system along …

View full post
Managing Fourth Party Tags Through the looking Glass HTML5…I mean, Local…I mean, DOM…I mean, Web Storage! Do Not Track and Preference Management Technical Analysis of the IOS6 Tracking Identifiers and Privacy System

Mar
13

EU Cookie Consent Interfaces

Categories:

by

By Travis Pinnick
User Experience Designer | TRUSTe
@xtratrav

Cookies are a pervasive browser tool used for the purpose of creating stateful interactions (ie. keeping track of your preferences, analyzing site usage, or to show ads tailored to your interests.) This year a new law goes into effect in the European Union requiring user consent before cookies may be placed on a user’s machine. This requirement will have a significant impact on how users experience the internet, both tangible (consumers will potentially be presented with a myriad of consent options) and intangible (if requiring consent affects ad targeting opt-out, it could also affect how the ‘free’ web is monetized).

Cookie Consent Interfaces

Implementing privacy systems like what is described by the EU directive requires strong user experience considerations. We conducted an initial test of two versions of the interface, as well a conceptual assessment of users’ understanding of how cookies work and how users feel about being required to consent to their use.

Modal interface

The first design tested was ‘modal’ – ie. users are shown an alert message the first time they visit a site and are required to state a preference before using the site.

View interactive demo »

Passive interface

The second design tested was ‘passive’ – ie. the alert is fixed at the top of the screen, and though it is persistent until the user states a preference, the user is otherwise able to interact with the site.

View interactive demo »

User Preferences and How They Affect Implementation

Half of the users tested were UK citizens, and half were based in the US. Unsurprisingly the US-based users were universally resistant to a cookie consent requirement, while the UK-based users were more accepting of the idea. Regarding their likelihood to allow cookies when they encountered a consent notice, almost all users stated that they would simply allow cookies for sites they trust, and block them otherwise.

Of the two designs, users preferred the second ‘passive’ version of the consent interface 2 to 1, mostly because they like the idea of being able to interact with the site before making a decision. However users also universally stated the expectation that no cookies should be set during this interaction period until a cookie preference was stated. Users also stated they would be annoyed if cookie inhibitions affected site functionality, which would almost certainly be the case given this implementation.

Next Steps

We will be iterating and further testing this design and will share the results as we get them.  Our goal is to design systems that offer the right educational material and set of choices. This is a work in progress and feedback is encouraged.

Follow me on twitter at @xtratrav.

Tags: , ,

Leave comment

Feb
22

Mobile Tracking: How it works and why it’s different

Categories:

by

Introduction

The principles of tracking in mobile are fundamentally the same as those used in the online world.  Specifically, you want to have an identifier that works across different domains and if that identifier is short lived, you need to be able to tie it to domain specific identifiers that have greater persistence.  There are just a couple of wrinkles that make things a little more difficult in the world of mobile.

The following blog describes some of the techniques used in mobile and highlights the differences with the online world.  Being able to identify and track users is something under taken by a number of the entities in the delivery of a mobile advertisement.  For the sake of brevity, in this blog it is assumed the advertisement is coming from and the tracking being undertaken by ad networks.  This brevity is not meant to imply that ad networks are using practices not used by others in the delivery chain.  It should also be stated that due to some of the problems consumers have passing their privacy preferences to the various entities in the mobile advertising chain, those entities in general and for the purpose of this paper, ad networks specifically, do not necessarily use consumer identification for behavioral analysis and may limit its use for campaign frequency capping or unique user calculation.

Mobile Web and Applications

The main challenge that mobile ad networks face is that they deliver advertisements to consumers while the consumer is accessing content through both applications and mobile web sites. On mobile devices, applications and web sites are separate domains, in separate sandboxes, utilizing separate identifiers.  That means for the ad network, a single user may look like one or more separate individuals unless the ad network takes steps to try to tie the multiple identities together.  More on that later.

Initially, let’s confine the conversation to mobile applications.  In mobile apps, developers have been using an operating system (OS) identifier to uniquely identify the consumer.  Focusing on the two most popular mobile platforms Android and iOS, the identifiers are the Android_ID and UDID respectively. The Android operating system also allows other system identifiers to be made available.  These include the equipment identifier (IMEI, MEID or ESN depending on the cellular technology) and the subscriber identifier (IMSI from the SIM) if the android device is a phone as well as the WLAN MAC address if the device is WiFi capable (MAC address is also accessible on iOS).  The use of OS based identifiers has been good news for the ad networks since the same value will be passed regardless of which publisher created the application.  In effect, this means the ad network can track the individual across different applications.

This practice and the fact that consumers have little control over it, caused Apple to deprecate UDID in iOS5.  Deprecation doesn’t mean that it isn’t still available for use by developers and ad networks (they still do use it), but it means they should not use it and is an indication that it will be removed (made unavailable) in future versions of iOS very soon.

Instead of UDID, Apple recommends developers create a unique user identifier for their application.  Of course, this doesn’t help the ad networks as each app on a consumer’s mobile device could identify the user differently.  A number of alternate solutions have been proposed to help cross application tracking, while managing the privacy concerns that led to the UDID deprecation by Apple.

Moving the conversation onto mobile web, like online, third party cookies are used by ad networks to identify consumers across different mobile web sites.  Unlike online, the absence of security software on mobile devices means ad networks can count of third party cookies remaining on the device browser when they are able to write them.   Third party cookies are effective on Android devices.  However, on mobile devices consumers typically don’t use other browsers than the one the device shipped with or change the factory set defaults for those browsers.  As a default, Apple ships Safari browser with third party cookies disabled which means that ad networks cannot use them for cross domain tracking Apple devices.  Instead ad networks have developed a variety of techniques to track iphone and ipad users through their browser sessions.

One technique relies on exploiting a security hole in the Safari browser that allows cookies to be written if the ad network writes a form in an invisible iframe to the browser.  This technique was widely reported from the work of Stanford graduate Jonathan Mayer (http://webpolicy.org/2012/02/17/safari-trackers/ ).  Another approach is to collect information disclosed by the browser itself to build up a “fingerprint” for that device.  Depending on the browser, whether javascript is enabled and how heavily the consumer uses the browser, accuracy over 94% is readily achieved (https://panopticlick.eff.org/browser-uniqueness.pdf ).

Another technique is to rely on domain specific persistent identifiers being made available to the ad network and tying that identifier with a transient cross domain identifier.  The persistent identifier is typically passed to the ad network as a UID in the ad request and is related (one to one mapping) to the first party cookie.  The transient binding could be the IP address that typically remains the same during a consumer’s browsing sessions or an identifier passed by the mobile carrier’s WAP gateway (all browsing sessions pass through a network element called the WAP gateway).  Depending on the carrier and the relationship between the carrier and the publisher(s), the gateway identifier may be long lived (even always the same in the extreme case) or short lived.  Obviously this technique is only effective for identifying a user across sites that they regularly visit and it takes time for an ad network to build up their view.  This technique may be used with the device fingerprint technique to either increase the accuracy of the fingerprint or reduce the number of times a fingerprint has to be calculated.  This technique is illustrated in the following diagram.

 

Tying Mobile Web and Application identities together

As the preceding sections have already stated, mobile web and application are separate domains, with separate identifiers.  From the ad network’s point of view, this means one individual, using one device can look like two different people.  From a consumer’s point of view, this means that any opt-out (of tracking and behavioral analysis) preference expressed in one domain (e.g. opt-out cookie or do not track preference in the browser), may not be respected in the other domain simply because the ad network doesn’t recognize it as the same individual.  This gets confusing for the consumer as they may not understand the interplay between mobile web and mobile apps as they often bounce between each other.

The most common method to tie identifiers across application and mobile web domain only works when the user clicks on an ad within an application.  The click through URL is unique to the user, containing a parameter that has a one to one mapping with the application domain user identifier.  When the consumer is redirected to the advertiser’s mobile web site, the ad network is able to tie the application domain identifier passed in the click through URL with the web domain identifier(s).   Ad networks may use a myriad of techniques to map in the alternate direction (a key use case for ad networks is when a consumer clicks on a mobile web ad for a new application such as the latest, coolest game and the ad network wants to see if the ad click resulted in the game being downloaded).  These techniques rely on the ad network having access to shared storage between the two domains which is easier on some OS compared to others.

Privacy by Design

It is hard to talk about targeting without privacy. The inventive solutions developed to overcome default factory settings and application sandboxes indicates the industry needs to rethink its approach to privacy and the persistent identifiers that enable tracking.  The consumer should be faced with a simple choice of whether they want content and advertisements delivered that are tailored to their interests and be able to control it.  That control should extend across the browser and application domains.  It should be easy for them to find out who has what information about them.  By taking such a fundamental approach to privacy management and tying it to a revocable identifier, the industry will win by having a reliable identifier for those consumers happy to be tracked and consumer will win by finally having true privacy transparency, choice and control.

Tags: , , ,

1 comment

Feb
22

Top 10 Challenges in Mobile Privacy

Categories:

by

Top 10 challenges in Mobile Privacy

Every week we hear about a new privacy scandal with a mobile company involved. Google, Apple, Pandora, Carrier IQ, Path and Hipster are only a few examples. So who is next? And why anybody should be next? Why is it so difficult for companies to achieve privacy-by-design on mobile? This blog outlines some of the reasons.

 

Apps are now tracking.

Unlike in the old desktop word where a web browser is a “single point of data leakage,” in mobile, apps are meant to be “connected” by design and are commonly supported by advertising. As a result, almost all apps collect and transfer user data in a numerous ways.

Best practice: App developers should seek independent third-party verification of their apps if they want to increase consumer trust and lower regulatory risks.

 

Advertisers provide in-app SDKs that Publishers cannot control.

An Ad Network SDK incorporated into a mobile app can do everything the app can do. This makes it much tougher for the app developers to provide consumers with full transparency. They cannot control in-app SDK activity nor even disclose it properly in the app privacy policy.

Best practice: App developers should consider working only with the SDKs of certified third-parties whose data collection and usage practices have been independently verified.

 

The mobile ecosystem is much more diverse.

It is not just regular apps who collect user data. There are also ad networks, ad aggregators, mobile carriers, platform vendors, ad network in-app SDKs, and data aggregators – all technically able to access a device in a multitude of uncommon and technically diverse ways.

Best practice: Ad Networks and app developers should collect and honor consumer privacy preferences in a way that is uniform and consistent across multiple ecosystem players.

 

There are several different platforms.

Apple iOS, Google Android, Blackberry and Windows 7 – all have a sizable market share, yet different architecture, privacy and permissions systems. That makes establishing uniform privacy guidelines very difficult.

Best practice: The companies who work with different mobile platforms should adequately describe the privacy-related peculiarities of these platforms in their privacy policies, which they should display in a consistent format.

 

There are no reliable cross-platform identifiers.

Mobile opt-out cookies can no longer be relied upon for an opt-out mechanism when browsers like Safari disable them by default, and after Apple announced the deprecation of UDID identifier the industry has considered using all sorts of other identifiers: MAC Address, IMEI equipment identifier, IMSI subscriber identifier, device fingerprints (BlueCava’s, 41st Parameter’s, AdTruth’s), and custom identifiers (AppsFire’s OpenUDID, OpenFeint OFUID single-sign on, and Mobclix’s ODIN.)

Best practice: Developers and Ad Networks should consider adopting a uniform and private-by-design identifier that would allow consumers to express an opt-out or opt-in preference based on their jurisdiction. (US vs EU)

 

Tracking now is happening in both app and web.

When a consumer opts-out from tracking by a particular company, he or she usually expects to opt-out from it across both app and web. However, this is often impossible because the browser cannot read system identifiers such as UDID or MAC Address, and applications cannot read browser cookies that are not from their domain.

Best practice: Companies should rely on a user identification mechanism that would be accessible from both the regular mobile apps and browser web sites.

 

Mobile web Publishers are often involved into the ad chain.

Because of smaller bandwidth, lower Javascript processing power, and limited third-party cookies support, mobile web Publishers often make ad calls directly from their servers and then serve web content with ads and third-party cookies incorporated in it. However, this makes the third-party cookies technically look like first-party ones for the browser.

Best practice: Mobile web publishers should thoroughly examine the third-parties they work with to vet that the privacy practices of those third parties are consistent with the practices the publisher describes in their policies.

 

Applications transmit user information in ad calls.

Mobile Ad Networks normally require Publisher apps to transmit unique identifiers, such as UDID or Android ID, in an ad call. Even if UDID is the only thing that an Ad Network receives from the apps, it can still build an “anonymous” profile containing the information about what apps a person uses, how often, at what time, for how long and from what IP addresses. In practice, app developers pass much more data. Transferring zip code, age, gender is common practice now.

Best practice: Publishers should list the types of data that they transfer to the Ad Networks and Data companies in their privacy policies.

 

Mobile phones know users’ location.

Regardless of whether users enable or disable precise location services, the carrier will still know users’ approximate location and wireless access points’ IP addresses. An unscrupulous app can ask users for access to their location over and over again until they succumb, which is when compliant apps may inadvertently get access to it too and assume that users are ok with them using it.

Best practice: Applications should disclose whether they use location services, and provide information on how to disable precise location services indicting whether it can be done at the app level or must be done at the device level.

 

The size of mobile screens makes complicates disclosure.

Screen size presents challenges for companies to effectively communicate their privacy practices. Most apps either do not have a privacy policy or link to a long privacy policy hosted on a website that is difficult to navigate and read on a small screen.

Best practice: Companies should create a mobile optimized versions of their privacy policies so it would be easy for users to read and get the information they are looking for.

 

The proliferation of mobile devices quadrupled the privacy challenges previously attributable to desktops. Every week companies from Google to Path, from Carrier IQ to Pandora find themselves in the middle of a new privacy debate. So who is next? When Path was recently caught uploading users’ address books to its servers, its CEO Dave Morin noted in his blog that it was the “best industry practice.”  As controversial as that comment was, he was right – it is the “best industry practice,” along with many other practices established without privacy in mind. It is time for the app developers, ad networks and platform vendors to wake up. Unless the companies take consumer privacy seriously and address it with proper disclosures and control mechanisms, the frequency of these scandals will only increase over time.

This post has no tag

Leave comment

Feb
21

‘Do Not Track’ Ad Tag Integration

Categories:

by

By Travis Pinnick
User Experience Designer | TRUSTe
@xtratrav

Browsers traditionally provide basic privacy protections usually focused around cookie management, but newer browsers are also supporting the Do Not Track (DNT) header request as an alternate method of indicating user preferences. Until the industry fully adopts DNT, a temporary solution could be to integrate DNT recognition mechanisms into existing cookie-based systems.

Cookie-Based Opt-out Tools

Cookie-based opt-out tools use cookies to indicate to tracking companies’ opt-out mechanisms that a user wishes to be opted-out of behavioral advertising. While this method of control is relatively easy to implement, it places the burden of control on the user (who may encounter large numbers of tracking domains), and even with a centralized opt-out database this can prove cumbersome. This method also relies on cookies to signal user preferences to the tracking companies – therefore deleting cookies (a common consumer approach for controlling privacy) also deletes the opt-out preferences.

There are a number of providers of cookie-based opt-out services which aggregate opt-outs for multiple tracking companies (including the TRUSTe preference manager). Unfortunately it’s unlikely that consumers can digest a large list of networks and data providers and select a few from which to opt-out. The complexity of the ad ecosystem therefore renders this level of transparency slightly less useful.

‘Do Not Track’ Header

The ‘Do Not Track’ header is a browser feature that appends a header to http requests that expresses a user’s preference not to be tracked, placing the burden for compliance on trackers (currently implemented in newer versions of Firefox and IE). This creates the possibility for the header to provide much broader-based protection against tracking than the other mechanisms if tracking companies abide by it.

A strong advantage of the DNT header is that it makes it clear and simple for companies to comply with the law – and to send a straightforward signal to users that their company is compliant and trustworthy. Plus, it makes it easy for consumers to take a stance and state a clear preference regarding tracking.

An Integrated Solution

The current industry standard makes use of a script-based in-ad icon, from which consumers who are interested in stating ad preferences can follow a link to a cookie-based opt-out tool. The EU (which stresses an opt-in model) and US (which takes the opposite stance with opt-out) are also converging, and as they do it is becoming more obvious that future systems need to be simply ‘preference based’, not necessarily just opt-in or opt-out.

While in-ad tags are a great transparency mechanism, the cookie-based service which it supports is only a moderately useful choice mechanism. Conversely DNT settings provide consumers a decent global choice mechanism, but offer little in the way of transparency. There needs to be a linkage between the in-ad tags and browser-based DNT settings. Cookie-based systems, the current industry standard, are not going away anytime soon, but an ideal solution should integrate DNT standards into existing cookie-based systems as well as any future preference-stating systems as the industry evolves.

view live demo »

TRUSTe has developed a DNT-integrated ad tag solution – one that is capable of acknowledging a user’s DNT preference but can leverage the transparency afforded by the in-ad icon. The ad tag script is capable of acknowledging a user’s DNT browser preference and can leverage the transparency afforded by the in-ad ‘AdChoices’ icon to reflect this preference. If DNT is set, the ad tag temporarily displays an altered state icon acknowledging the preference. Since it can also be assumed that a user who has stated a ‘Do Not Track’ preference does not wanted to be targeted, the system can automatically record the user’s preference by triggering opt-outs for all tracking entities associated with the ad tag, similar to the action the user could take by following the link to the cookie-based preference manager. This can serve as an interim bridge between DNT and cookie-based preference systems until DNT gains mainstream adoption, combining the global choice of DNT with the transparency of the current industry ad choices icon.

Tags: , ,

Leave comment

Feb
02

Product Prioritization Part 1 of 2: A Prioritization Schema

Categories:

by

This is a topic that is near and dear to anyone involved in product development and something that spans across both the Product Management and the Engineering/Product Development side.  What I originally wanted to cover in this post was the issue of internal vs. “external” projects and some things to think about when having to prioritizing them.  Of course this requires a precedent discussion around a prioritization framework, so I’ll handle this topic in two parts.  The first will discuss our framework for prioritizing product resources defined as PM and development resources.

A product team’s first job is building a list of impactful projects that can lead to addressing the business’ operational and financial goals.  Ideation is key to some degree, but hopefully these ideas are coming from real conversations with customers. Once that list does appear is really when the work begins:

  • How do you assign the best list of projects across a fixed pool of resources?
  • How do you define a “project” in the right increment?
  • How do you pick the right ones relative to each other?
  • How do you reject ideas, yet still foster the flow of ideas to keep the innovation fire a-burning?
All questions that can vary by company and personality, but there is a separate discussion of lean/agile development that I’ll leave for another post someday.

But once you have your list, the next step is clearly to have a process by which you can compare each idea and prioritize the list in execution order, which means assigning the list to your fixed pool of resources.

Most people have to do this in some way, shape or form in their lives with their to-do lists, spending time with friends or spending money, so it isn’t a high level concept.  But, it is a discipline that is often not followed, which leads to second guessing and other issues down the road.  Remembering that this is a process and not a point in time is critical framing.

As such, documenting the process, the full candidate list and rationale for the final list helps keep the team participating in building the products informed and educated on what the final decision was and why. This takes resources and time and needs to be done right.  I have always used a Program Manager to drive and maintain the process as a neutral third party that sits between Product and Dev.  Maintain the list as a backlog that is visible for everyone to see is also critical as it needs to be consulted frequently.

From there the process can be as follows:

  1. Anyone can submit an idea, small or large.
  2. All ideas are added to a database where they can be edited collaboratively (Confluence, Google Docs, etc…).  We like a combination of the two.
  3. Each project should have the following info associated with it:
    • Project Name
    • Description
    • Justification
    • Timing dependencies
  4. Each project should then hyperlink to any product documentation that further explains business rationale and requirements.  Pictures are worth a thousand words.
    • We use the concept of a minimum “one pager “ for each project, but clearly larger efforts require more strategic analyses and business cases.
    • I really like “business model canvas” framework from Alex Osterwlader as a high level model to star new larger concepts.
    • Clearly all projects need some vetting with live prospects and customers so existing UX and demos are the rule vs. long text documents.  Clearly the Lean Startup stuff applies here in many ways.
    • We are also a whiteboard and camera phone group, but are experimenting with Balsamiq

Then, the fun part, picking the order and allocating scare resources. From a high level there are three grades of projects.

P1
Strong impact projects that are directly meeting business goals and can demonstrate obvious benefits based on strategic goals.  These projects have seen external verification and often times have immediate timing needs.  They can range from vetting a new strategy or concept or starting to build code.  There is also something called P1* which is something that is deal dependent that when it hits becomes a disruption usually without any controversy.

P2
Projects that are important but do not have immediate timing needs relative to P1’s.  Or, their ultimate contribution is smaller relative to a P1.

P3
Ideas are too early for proper definition or that have future timing needs.

The subtext on P1′s get personal.  The person requesting it has to make a very convincing, passionate argument as to why this is a P1.  These ideas need to be pretty obvious as important, which requires a person to make the case.

Inevitabily, the first round will probably end up with too many P1′s.  So, there is usually a second round to cut the P1′s down in number.  So, the passion usually needs to be there to make the final cut.

After that you have your list and depending on your planning cycle, you will repeat this as needed.  It is time for execution and the process to track these projects and manage the next list of projects, which will be covered in a subsequent post.

So this is all well in good for a company showing strong revenue growth in a large market working on projects mostly connected with revenue.  But, what happens when that internal platform you are using becomes so old that no one knows how to work on it and it was put together by a developer who didn’t know Java from Java script?

Well that is the topic of the next post….

Kevin
@squawkt22

 

Tags: , , ,

Leave comment

Dec
02

Data Transparency in Product Design

Categories:

by

By Travis Pinnick
User Experience Designer | TRUSTe
@xtratrav

As a technologist how do you decide what privacy considerations are important when designing your products? After designing consumer-facing privacy-related products for several years, I have reached the conclusion that the majority of consumers have little understanding of privacy on the web. Most admit they take little action to protect themselves, or at least don’t see managing their privacy as a primary task. I attribute this to the fact that privacy is an intangible concept and harms are not salient. The collection and sharing of customer data are invisible, and for the most part consumers have little insight into what information is collected about them or how it is used.

But I think even with this information the majority of consumers would continue with their current behavior, using the same services, and allowing for the same kinds of data exchange. And that’s probably good news. The modern web is built on data collection and its monetization – it’s the reason we as users are afforded free content. The inherent bargain we strike when we use web services is the exchange of our personal information (usually in the form of our preferences and behavior that can be monetized by advertising) for free content we can consume. This ecosystem is based on the assumption that we are comfortable with this arrangement, and I suspect that given full disclosure, most of us probably are.

It’s the full disclosure part that’s so critical. While I think most consumers are probably comfortable with the idea of data monetization (such as being anonymously profiled for targeted ads) in exchange for a (mostly) free web, the reality is few consumers really understand how this process works, who the players are, and exactly how their data is involved.

Products should be desingned to provide transparency around how data is collected, who is doing the collection, and when possible offer choices around collection and use. This is always a work in progress. Cookie-based behavioral advertising opt-out preferences will evolve in the near future, new device considerations like mobile require new mechanisms of control, and new tracking technologies require new technical solutions.

When designing your products think about transparency as a must-have component. I don’t think users will necessarily alter their online behavior given full disclosure around the use of their data, but I think everyone is entitled to this information.

This post has no tag

Leave comment

Oct
18

Scale-up vs. Scale-out

Categories:

by

We’ve seen many changes over the years in the way that computers, computing power and the effects of the internet have changed the way that we do business and as a result build and scale computer systems infrastructure.  Going from large specialty machines in small quantities (scale-up) to using commodity computer equipment in large numbers (scale-out) has changed the way that companies are operating their businesses today.  It is now easier and quicker than ever for a 2-person startup to build a web-based business with little to no risk in capital and without the burden of burning hours or hiring additional manpower to focus on tasks that are not relevant to the intricacies, needs or interests of a new business.  Cloud-based services, virtualization and the move away from enterprise-grade computing equipment have made that possible and have allowed businesses to focus on what they do best.  They can spend more energy on making an idea a reality instead of worrying about how many cables they need to order.

The old school of thought was that if you wanted a computer to do a lot of work you had to acquire a machine with a very powerful CPU, with a lot of memory, with lots of storage and very fast i/o.  You also had to make sure that this system was upgradeable so that if the volume of work increased, the system would be able to scale-up to handle the additional work.  When the capacity of that system had been reached, you had to replace it with the latest (and sometimes untested) technology with similar upgradeable characteristics as its predecessor.  In addition, you had to have at least another one or more of these devices if you wanted uninterrupted service and high availability.

Google was a pioneer in utilizing commodity hardware to do the job that the aforementioned systems once did.  Instead of relying on very expensive upgradeable specialty hardware and building in expensive redundancy into every aspect of the infrastructure, why not rely on a lot of cheap machinery that was easily attainable and replaceable and when used in large numbers could just as effectively do the job?  For that matter, why even put in graphics cards and other peripheral devices that only add cost to these “disposable” resources?  Using only what you really needed and only replacing systems as they died or became obsolete was a paradigm shift.  Of course there were debates as to whether or not these systems could be relied upon.  In the end, more and more businesses began to realize that this model really made sense.

Efficiencies from parallelization and reduction of bottlenecks allow for more work to get done and with reduced risk of failure in a scale-out solution.   In a scale-up environment if a machine were to die, it would be very costly to repair or replace it.  It’s not an easy task to upgrade a large piece of equipment when there isn’t much redundancy built into the infrastructure and very costly to build in that redundancy in the first place.  During an upgrade, in most cases machinery would have to come off line.  At times tradeoff between availability and the cost of doing business had to be made.

Today you can actually lease computing power short or long term or pay as you use.  Similar to the car leasing/rental industry, there are many different offerings.  You can lease a car long-term or rent one for a single or few days.  Zipcar has taken it one step further and lets you rent it just when you need it.  Just like the car rental business has been changed by Zipcar so has the computing industry with companies like Amazon, Microsoft, Google and IBM.  Interestingly, all of these businesses started from very differing positions but soon converged on the same underlying theme.  In some cases, just offering and extending the very same infrastructure that was used to build their own businesses and in other cases offering services that were diametrically opposed to their original business models, they all seem to agree that the distributed computing model is here to stay.  The prevalence of online advertising, streaming video and content-heavy and free services necessitated a change in the way that these systems evolved.  It seems that many businesses are moving in the direction of thinking of computing resources as a utility.  It’s much easier to plug into a grid than it is to generate your own power.  Public cloud infrastructure offerings have become mainstream.

There are now technologies that allow you to combine a public cloud offering with a private cloud offering depending on how much control you want over your infrastructure.  You can also go it alone using the same technologies to offer you complete control.  Obviously having to staff up to build out your own data center may outweigh the benefits of maintaining that control.  The fact that you have this kind of flexibility makes it a business decision.

Now that the industry has established that the scale-out solution is a solid foundation to build upon, there are companies specializing in ways to make managing software on those platforms more efficient.  Beyond virtualization and utilizing only what you need, solutions are moving even further up the stack and beyond physical hardware allowing spanning of a software application across multiple machines.  It will be interesting to see how things will evolve over time in this space.

In summary, there are many choices available to build and scale a business today and many factors need to be considered before deciding upon the ultimate strategy.  That said, it’s very easy to start out in the cloud and you can always transition over to a platform and strategy that will ultimately work for you with the many tools and technologies available to make that transition easy.

This post has no tag

Leave comment

Oct
03

Open Standards and Privacy

Categories:

by

Privacy is clearly something that affects the whole ecosystem of users on the web. Any implementation of privacy must take into consideration important trade-offs between business models and end user rights to transparency and choice. As such, standards play an important role in any consideration of a privacy system for the web and mobile web.

TRUSTe has long participated within a number of policy-based industry groups. Recently, TRUSTe has joined two technical standards groups that are actively working on defining concepts that can be applied to important privacy systems at the infrastructure and architectural level.  This post provides a quick overview of each group.

OASIS

TRUSTe had joined OASIS due to the leadership in starting to address the difficult issue of operationalizing privacy. We understand this very well through our rich history with our customers, some of which are some of the largest most complex data-centric organizations in the world.

OASIS features a technical committee called the Privacy Management Reference Model (PMRM) whose charter explains the goals of the group quite well.

As part of that program, I had the opportunity to discuss my views on how open standards, and particularly OASIS fit in at TRUSTe.  You can see the video at http://www.youtube.com/oasisopen#p/u/3/E0gEsvyWEyk.

Additionally, we are thankful for OASIS’ Executive Director Laurent Liscia’s recognition of TRUSTe’s involvement:

“As a Sponsor of OASIS, TRUSTe demonstrates genuine commitment to open standards and interoperability. TRUSTe plays a major role in operationalizing privacy through its contributions to the OASIS Privacy Management Reference Model (PMRM) Technical Committee. We value the expertise and insight the company brings to our organization.”

We look forward to participating and helping this important work evolve.

W3C 

TRUSTe very recently joined the W3C to take an active role in the development of web standards around tracking protection.  There are many other great efforts occurring in the W3C, but standardizing privacy controls is a topic we have followed very closely over the last several years.  The work is been an obvious next step to the self-regulatory programs that TRUSTe has been so deeply involved in with the online advertising industry. Also, many of us at TRUSTe have been very active in browser-based trust systems in our past-lives and of course see the critical role browsers play in helping consumers manage their online privacy.

TRUSTe has been participating in evolution of this working group through the first two working groups and submitted a position paper to the IAB’s Internet Privacy Workshop at MIT in December of 2010 and also a position paper to the Workshop on Web Tracking and User Privacy at Princeton in April 2011.

The tracking protection group is chartered with a very difficult task of improving on past, and admittedly unsuccessful, consumer privacy protocols that can bring transparency and choice to data collection and advertising.  It is designed to simplify user interaction around notice and choice, to bring methods for accountability to those collecting data, and to enable the benefits of that data collection, such as relevant advertising or improved site performance, to those users that want them.

We appreciate the statement of support from Thomas Roessler, T&S Domain Leader for the W3C for TRUSTe’s participation in the W3C:

“I am pleased that Truste has joined the W3C to participate in the Tracking Protection Working Group. One key to the success of this group is participation by diverse stakeholders, including solutions providers.”

We look forward to a busy year working with these groups and sharing our thoughts and perspectives to help build better standards and resulting operations that all users of the web can enjoy.

Kevin
@squawkt22 

Tags: , ,

Leave comment

Sep
26

TRUSTe New Technology Blog

Categories:

by

Welcome to TRUSTe’s new blog focused on privacy for developers and technologists. This blog will feature a technology bent to privacy versus the classical policy perspective that exists in many other forums.

There are a couple of reasons why we at TRUSTe decided to start this.  First, we think there is an equally important dialog about privacy that should be focused around privacy technology, deployment of privacy technologies and privacy as a core element of the Internet infrastructure.  Frankly, this gets lost in discussions of policy and warrants it own forum.  There has been some start to this in some of the standards groups, but even these groups don’t discuss important aspects of technology deployment like user experience, scale and operational challenges.

Second, like many of you out there, we have great technical minds thinking about the practicality of privacy technology and how it needs to be operationalized in such a way that all members of the ecosystem can participate in it and find it useful:  businesses, consumers, and platform operators. We’d like to share some of that thinking that we have accumulated over the last several years and get some feedback on that.  We are constantly amazed by the dichotomy of conversations we get into with our customers and partners that range from “Wow, that is really cool stuff!” to “What technology do you have exactly?”  TRUSTe has built a world class product and technology organization and we like to provide better clarity on that and use that as basis of evolving thinking of the industry.

Third and finally, we think like minds attract like thinkers.  We’d like to continue our outbound dialog to continue to find other technologists that like privacy and want to get involved.  Privacy is a large scale, global issue which needs an active community to provide solutions to improve it – it being transparency, control and accountability for the whole ecosystem.  We welcome conversations and working relationships of just about any manner to help think about this hard problem and come up with new innovative ways to improve it.  We’re 100% dedicated on this topic and are always looking for others to share new ideas.

Feel free to reach out to us and ask a question or give us some feedback on what we are working on.

On that note, we will have a series of topics we are working on from various members of our technology teams.  Look forward to posts starting to appear very soon and each of these folks introducing themselves.

Also, we created a new TRUSTe Labs area where we can showcase a few concepts that we are working on to get feedback.  These will be in various stages of development, but the point is to share thinking and start a conversation.

With that, we’ll get back to putting up some content that we hope you will find interesting.

Kevin Trilli
Vice President, Product
Twitter: @SquawKT22

Ken Okumura
Vice President, Engineering

Tags:

Leave comment

» Newer posts