«

»

Mar
26

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

By Kevin Trilli (@squawkt22)
VP Product | TRUSTe
View Kevin Trilli's profile on LinkedIn

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 adoption of IOS devices. Firefox has since elevated this discussion on the desktop side with their recently announced change in cookie policy. Classic third party http cookies can not be used for traditional uses that help facilitate the ad ecosystem and in particular the behavioral advertising systems.  As such, there has been a push to look at alternative methods to accomplish device identification within a browser.

This post will investigate one of those methods, the use of HTML5 or Web Storage, compare the current state of browsers and then make some recommendations around how they can be used to provide better operational processes, but also balance user privacy.

Web Storage
To start, we should all get on same page with what to call this thing, as initially it was derived from the HTML5 specification, but has subsequently been moved to a more general Web Storage specification in the W3C.  Many people still refer to this as “HTML5 storage” (inside TRUSTe also) but we are officially going with “Web Storage” so we do not have to keep using multiple names when we bring it up. Additionally, the term “DOM Storage” is also used but less so, especially by Mozilla and Microsoft and only appears in IE browsers externally.

The storage facility is similar to traditional HTTP cookie storage but offers some benefits commonly understood as:

  1. Storage capacity:  Browsers have enabled a minimum of 5Mb of storage inside a web storage object (IE has allowed 10Mb but it varies by storage type and browser).
  2. Data transmission:  Objects are not sent automatically with each request but must be requested.
  3. Client side access:  Servers cannot directly write to web storage which provides some additional controls from client-side scripting.
  4. Data storage:  Array level name/value pairs provides a more flexible data model

Privacy Implications
As has been discussed in the W3C spec and other forums, there are some considerations for privacy in place both within the spec design and implemented in the variable user agent controls present today in common web browsers.   Within the spec, there are options for user agents to:

  1. Restrict access to local storage to “third party domains” or those domains that do not match the top-level domain (e.g., that sit within i-frames).  Sub-domains are considered separate domains unlike cookies.
  2. Session and time-based expirations can be set to make data finite vs. permanent.
  3. Whitelist and blacklisting features can be used for access controls.

Consumer Controls
The immediate privacy controls exist within the user agents, and as with any user control, the degree to which the feature has been deployed and in what manner varies across the major browser in use.  This next section will provide a comparison of the four major browsers: (Note: This data is current as of the date of the post) 

Chrome Safari Firefox IE
Version Tested 24.0.1312.56 6.0.2 (8536.26.17) 19.02 10.0.9200.16521
Location Advanced>Privacy>
Content>Cookies
Privacy>Cookies and Other
Website Data; “Details”
Tools> Clear Recent History
> Cookies
Internet Options> General>
Browsing History>Delete>
Cookies and Website Data
Nomenclature “local data”, “Database
storage”
“Website Data”, “cache” “cookies” “Browsing History”, “Website Data”,
“DOM Storage”
Ability to see presence of Web objects Yes Yes No No
Ability to see contents of Web objects Yes No No No
Ability to block setting of Web storage objects Yes No No Yes (Internet Options>
Advanced>Security)
Separate control Yes Yes
Combined with cookie control No – 3rd party cookie
setting separate
No
Default Off (Allowed) Off (Allowed)
Ability to delete content of Web Storage objects Yes Yes Yes Yes(2)
On exit of browser (Multiple) Yes Yes Yes(1) Yes
Individually Yes Yes No No

(1) DOM Storage can be cleared via “Tools -> Clear Recent History -> Cookies” when Time range is “Everything”. DOM Storage is not cleared via Tools -> Options -> Advanced -> Network -> Offline data -> Clear Now

(2) Included in the “Cookies and Website Data” setting.


Discussion
I have to admit, this was a fairly intensive exercise, requiring some effort to discover and understand these different controls across the different browsers.  Most users only use one browser, but it is quite difficult to offer specific general guidance to consumers as it varies so widely by browser.

However, the general behavior of the web storage objects is trending towards that of cookies. It is expected that user agents will ultimately treat them the same way to ensure the willing and motivated consumer can feel that their expectations were met when turning on cookie controls or similar settings.

Generally, Chrome offers the best set of features in terms of clarity and advanced features.

 

Conclusion
Usefulness of Storage.  In some ways, Web storage provides a better long term solution to cookies, as the amount of information that can be stored allows for more uses.  One area this can be helpful is around storing multiple preferences across multiple third parties for privacy.  Another would be to store preferences a user has provided with intent and permission to be shared.  For example, “I allow my favorite brand, Burton Snowboards, to present me with their new snowboard advertising as I am in the market for a new board next season.  Also, they can share my info with different providers of boots and bindings as I would want to look at those also.”

Performance.  The usual trade-off of (1) unique client-side identifiers that point to server-side data vs. (2) heavier client side data plays an interesting role in performance optimization, especially in dynamic exchanges and other real-time operations.  Having a better option for richer client side data can help present additonal options for client-side optimization.

Privacy.  There are still some gaps from a consumer’s perspective depending on the browser used, as illustrated above.  But, generally, web storage objects are non-permanent so they can be deleted just like cookies and thus are as “safe” as cookies.  But, some degree of standardization is needed in terms of either merging controls with cookies or educating users that these also behave like cookies and need appropriate controls.  This is all trending towards happening in the coming short-to-medium time frame, so generally, the threat level is low around web storage objects in the medium term.

For the immediate term for those that want to use Web Storage, the high road should be taken on transparency of their use and providing an opt-out system similar to the industry transparency programs (e.g., AdChoices).  TRUSTe has already developed such system for those already using this approach in the mobile world, but it also applies for desktop users.  Clearly, a DNT-like approach can work once that spec reaches a landing point.

Finally, websites should regularly monitor their sites for the use of these technologies similarly to cookies and other tracking technologies.

 

 

 

More Resources:

Comments