- From: Jeff Sayre <jeff@sayremedia.com>
- Date: Tue, 8 Mar 2011 05:47:40 -0800
- To: "WebID XG" <public-xg-webid@w3.org>
On 8 Mar 2011, at 3:22, Henry Story wrote: > 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. > > 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. Agreed. The issue of identity control and assurance really comes down to the level of the user, as it should. The software layer that most closely matches the level of a single user is the browser layer. Therefore, the browser level is a key player in implementing a user-centric, distributed identity mechanism. My main line of questioning with this thread is to make sure that we carefully consider the concerns of the enterprise owner as it pertains to letting users store and process data at the browser level. That was what I was trying to communicate when I asked: >> Can a WebID help sufficiently in alleviating those concerns so >> that enterprise apps even consider leveraging HTML5's >> client-side processing and storage features? I do understand the benefits a WebID offers but we need to make sure that we consider as many reasonable security concerns that an enterprise owner may have with client-side storage and processing and clearly demonstrate how a WebID can alleviate those concerns. Perhaps this is a moot point. But as I'm working on use cases, I need to make sure that I am looking at the picture from both sides--from that of the user and from that of the enterprise (website) owner. To succeed in our efforts, we need the enterprise owners to adopt the WebID. Jeff > > 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/ > >
Received on Tuesday, 8 March 2011 13:47:54 UTC