Client-side storage: Allow certificates to identify owner

In reference to client side databases and session/global storage (I will
call this "storage" from here on out), although other issues have been
addressed, I believe there is one thing missing in specification which stem
from using domains as the owner identification mechanism which prevents fair
use. There should be an alternate way to identify owner's of data by
certificates as opposed to domains.

3rd-party content vendors who need to store simple preferences (such as
"show playback bar") across a huge slew of domains which use their services
have to currently store preferences on the server-side, which is very
expensive, or otherwisepoor user-experience will result because preferences
only apply to one domain and not all domains which use the same trusted
third-party widget service. An example of a widget used across multiple
publishers is a video player widget provided to online video sites by a
trusted 3rd party company in order to make video publishing easier for those
sites.

I believe that certificates would be a solution to this because regardless
of domain, they'd enforce that only the same party can read/write data,
since the certificate would identify the reader/writer of the data. The
certificate could be provided through some mechanism (I'm not a security
expert to present a suggested mechanism) on the call to set storage data,
and then be provided again when reading the storage data. This wouldn't
require a page to be secure, and the reader/writer of the data could be 3rd
party or on a different domain, since they wouldn't be reading/writing data
from the originating domain and no domains would have access unless they
were the certificate owners.

Summary of my proposal:
 * Domains would still be used if a certificate wasn't presented to identify
owner.
 * If certificate is provided, sign data with certificate that the writer of
the data owns.
 * If anyone needs to read-write this data in the future, they need to be
the owner of certificate.
 * Page doesn't have to be HTTPS, since the only data being stored is
through the client-side Javascript storage mechanism.
 * Additionally, I think the case of how restrictions affect widget vendors
for large publisher networks should be discussed within the spec as a "big
issue".

Here is the summary of the issues which prompted this proposal:
 * If I read things correctly, the origin of a script called from
somewidgetvendor.com/path/to/script.js is not somewidgetvendor.com. The
problem here is that somewidgetvendor.com may provide a tool used by
multiple publishers across multiple domains and users may expect consistent
preferences across all publishers that use that widget. Additionally, the
list of domains for publishers that use a tool from somewidgetvendor may be
long and constantly growing or changing. Since a lot of content on major
commercial publishers is a mix of components from various vendors, this
presents an issue that requires very expensive server-side clusters which
can read/write huge amounts of preference data quickly which can make the
solution provided by somewidgetvendor too expensive to be truly scalable.
Additionally, a client-side mechanism should be sufficient for user
preferences which contain no identifying data -- even though cookies fall
short of being able to do so, and it seems the new specs will as well.
Allowing client-side data owners to identify through certificates if they
prefer to use that method instead of domains would provide a good
compromise.
 * For preferences that don't reveal anything about the user, public storage
would work however I have a feeling browser makers are going to block data
not associated with a domain just as they block 3rd party cookies now. As
already mentioned as a possibility in
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-storage.html#security5
* The mechanism provided by storage to apply a list of domains will fall
short when the domain list is too long and dynamically changes.
* Client-side databases don't have a mechanism to allow multiple domains
like session/global storage do.
* Ambiguity on what the origin is for content served in an iframe on a
different domain and what constitutes "3rd-party" inside iframes. I know
that window DOM is outside the scope of the standards (at least the
currently implemented standards) and cookies in iframes on different domains
are usually considered a 3rd party context by browsers, however ambiguity
leaves each browser to handle this in their own way and I think it should be
addressed. For instance, it seems silly that scripts that don't have access
to content on the main page should be considered on that domain and not the
domain of the iframe's contentWindow's document.domain.

Slightly off topic, but why isn't P3P mentioned within HTML5 as a potential
method to apply privacy preferences for storage mechanisms?

References:
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-storage.html
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-sql.html

Thanks for considering my concerns. I believe moving more data storage to
client-side will decrease the cost of services on the web and benefit us
all.

-- Brian Bober