W3C home > Mailing lists > Public > public-xg-webid@w3.org > March 2011

opera widgets, EV UI, and https; desktop trust model

From: peter williams <home_pw@msn.com>
Date: Sat, 12 Mar 2011 07:13:15 -0800
Message-ID: <SNT143-ds118D70DB91E24B6DDFDF8392CA0@phx.gbl>
To: <public-xg-webid@w3.org>
I've been trying to understand EV, 'green' address bars, and possible client
cert markup per tabs. Im starting to question of the issue on UI and
browsers is formulated correctly. Either its too limited in scope, or an
additional issue is needed, for "non-browser" UI

 

So, I stopped working for a bit, and installed some fun opera
browser/desktop widgets, noting the claim that they can run even if the
Opera browser is not executing.

 

What is the webid UI model here? What is the EV world model? What is the
security UI? What are consumers supposed to believe? Is there a trust
assumption that the PC platform itself - vs the browser - is an element of
the belief system?

 

Presumably, those widgets use Opera's http(s) connection middleware (vs.
that of Windows). If a client cert was demanded on referencing an https URI,
presumably it is Opera's crypto container and SSL implementation in its
middleware that would respond,

 

But, in the multi-farious UI designs of the widgets, I notice that the
metaphor of the "address bar" is missing - as is the metaphor of the green
address bar (for safer sites); as are notions such as tabs. None the less,
would we not expect those widgets to be presenting webids (and cite foaf
cards)?

 

Surely, yes. Webid is supposed to be a universal. It works 80% of where the
web usually works as usual, with particular emphasis on semantic web
applications. 

 

Is that true? I know I keep saying it; but this doesn't make it true.
Perhaps, it is only supposed to work REALLY in semantic web applications?

 

Obviously, webid  cannot have "universal UI", in the widget world. Neither
can the non-universal metaphor of the EV address bar be present either.
Surely one doesn't expect the widget to present a client certs dialog box,
for manual inspect of server cert chains from semi-authorized SSL MITMing ?

 

What this seems to mean is that should a widget app using a webid talk to an
https site (being spoofed by a proxy - corporate-anchored, ISP-anchored, or
public social networking MITM-enabled IDP with SSL server cert bearing
cert-minting key usage rights), even the vaunted EV "UI" assurances don't
hold water.

 

My interim conclusions were: 

 

1.       well even if one fixed UI in 10 dominant tab-based browsers for
webids, there is no way to fix in all the widgets. 

2.       The widgets basically assume a secure platform (the https
middleware of the Opera install), and this seems to be a desktop vs a
browser metaphor. The desktop changes the belief context of the user; and
may exist in parallel to a browser belief context

3.       If a semantic web widget that is webid-enabled opened 4 https
connections when processing a graph with arbitrary URIs, there is a phishing
space, since the EV'ness at the UI cannot be conveyed

4.       If 5 widgets are on a PC desktop each talking to one of several
sites, much like the hypermedia document in a browser page, there are now
several SSL sessions and thus several webid presentations. The desktop is in
a sense a page (think like early activeDesktops and channels, pre RSS). If a
single client cert has multiple webids, the desktop has an inconsistent
model of which webid is in effect at which site/widget - since the site gets
to choose (without notice) which one is active, and which one's access
controls are being enforced.

 
Received on Saturday, 12 March 2011 15:13:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 12 March 2011 15:13:51 GMT