On 8 Mar 2011, at 00:33, Jeff Sayre wrote:
> I am aware of the webid.info site but did not know that it uses
> client-side storage and Web Sockets.
That's the only implementation we have that does not interoperate with others as
I understand, which has no peer review, and of which I am very skeptical.
First of all it requires OAuth to be run in the background, because of the
security context issues. 2 It only works with very recent browsers,
3 it requires work in iFrames I think.
The reason it is that complicated is because it needs to place public keys on the
client, and only communicate that information with the site it got it from - otherwise
there would be a massive security hole. So there has to be complex song and dance done
in the background to get what we get with TLS in the browser: a database of certificates
that can be sent to *any* site.
I am also initially skeptical with any security system not done at the browser level, because
there is too much room for spoofing attacks. Only the browser can implement non spoofable
security information.
And as you point out correctly, storing information on the client is itself
a big security problem that has not yet been addressed. Especially for the
case people use so often as an example of an issue with WebID: the public
terminal case.
> The question I have is, as it at least pertains to enterprise apps, what
> are the security risks of trusting browser-processed data? Can a WebID
> help sufficiently in alleviating those concerns so that enterprise apps
> even consider leveraging HTML5's client-side processing and storage
> features?
That is a good question. But why not. If the browser is in charge of the user's identity
it could partition the databases of information per user identity. A good browser would
allow this information to be merged on user request.
So this is another case in favour of the browser being in charge of user identity.
That is what Firefox has been working on here
http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox
But this can be done very lightly
>
> I realize that it is possible to offer some semblance of security, but
> what are the issues that we need to consider, to address in this scenario?
>
> Jeff
>
>> Hi Jeff
>>
>> Just wondering if you have looked at the demo at
>>
>> http://webid.info/
>>
>> Uses .js crypto, client side storage and sockets ...
>>
>> Best
>> Melvin
>>
>> On 7 March 2011 22:37, Jeff Sayre <jeff@sayremedia.com> wrote:
>>> As I was working on the WebID use cases document this afternoon, it
>>> occurred to me that we will soon see HTML5-powered applications offering
>>> client-side data storage and processing using HTML5Ã­s Web Storage and
>>> Web
>>> SQL Database APIs. We need to consider the implications.
>>>
>>> What will it mean for WebID as Web applications can be built that
>>> persist
>>> data entirely on the client, or at least store data on the client for
>>> processing and even offline consumption?
>>>
>>> HTML5 will in essence make it possible to preserve state and allow for
>>> application processing to occur on client-side devices. Instead of a fat
>>> application server entirely responsible for CRUD operations, it will be
>>> possible to create web apps that turn browsers into fat-clients.
>>>
>>> Is there a way for WebID to allow for enterprise applications to trust
>>> the
>>> browser to process application logic securely?
>>>
>>> I searched W3C resources to see what I could find regarding the new
>>> HTML5
>>> client-side storage specifications. I found this defunct W3C XG (
>>> http://www.w3.org/TR/webdatabase/ ) that has splintered into two active
>>> groups: http://www.w3.org/TR/webstorage/ and
>>> http://www.w3.org/TR/IndexedDB/ However, this are not directly tied to
>>> the
>>> HTML5 specification.
>>>
>>> On a side note, I want to draw attention to an important potential point
>>> of confusion. The above two specifications (working drafts) both refer
>>> extensively to the Web interface definition language called WebIDL (
>>> http://www.w3.org/TR/2008/WD-WebIDL-20081219/ ). This is disconcertingly
>>> close to the name of our effort--WebID.
>>>
>>> We need to be cognizant of the fact that some people may confuse these
>>> terms. When appropriate, we need to make our best effort to clearly
>>> distinguish our work from this nearly-identical nomenclature that refers
>>> to something vastly different.
>>>
>>> Jeff
>>>
>>>
>>>
>>
>
>
>
Social Web Architect
http://bblfish.net/