Re: Please define user interests/priorities and the main question for smart cards.

+1!


*--*


*Siva G. Narendra Ph.D. CEO - Tyfone, Inc.Portland | Bangalore |
Taipeiwww.tyfone.com <http://www.tyfone.com>*
*Voice: +1.661.412.2233*


On Tue, Feb 3, 2015 at 1:19 PM, Martin Paljak <Martin.Paljak@ria.ee> wrote:

>  Brad (and Ryan),
>
>
>  Please explain how your claim "It is more important that we consider the
> priorities (or interests) of the user" is backed with real life evidence of
> documented user priorities/interests? It reminds me of the Gnome 3 story,
> where the outcome - which was  "designed for the needs and habits of users"
> - was nothing many *actual users*, with their needs, habits, requirements
> and wishes, wanted. It was rather something designed for a thought up,
> wished-for, lab-created abstract user and implemented as "lets just make
> what we want, we know better and the user will have get used to it
> eventually, ".
>
>
>  Let me tell you an anecdote, well known in Estonia. A man visits a
> foreign country and sees that there are ATM style machines for shaving the
> beard with razors: just insert your chin and ZAP-done. Feeling surprised,
> he asks his host: "but how does this work, aren't the chins of all men
> different?" "Of course they are", answers his host. "The first time at
> least ..."
>
>
>  Doing architecture astronautics "for the web" and assuming that
> everybody shall want to - and have to - build their devices and systems
> according to "the web" is similar to the chin problem. I like my chin, I
> like my smart cards and I'm happy with the way those applications are built
> from the cryptography and privacy point of view. Please don't tell me that
> I must like WebCrypto or FIDO because it "caters to my needs and priorities
> better" than what I currently have. FIDO (or only authentication in
> general) can't cater to my needs. It is really useful for running
> cloud-services, but not enough. Legally binding non-repudiation
> ("signature") is a real life use case that by definition relates to privacy
> differently than signing in to random pet forum.
>
>
>  Not saying that there is no room and need for better solutions to
> problems dealing with high privacy, authentication,
> attestation/non-repudiation or identity in general, just please don't
> assume that it is realistic to make a "web identity" and that everybody
> shall build their lives around it (one reason being that  "identity" is
> such an ambiguous and mis-used term, it has no realistic single universal
> implementation)
>
>
>  Actual users (lets name them "persons") have actual priorities and real
> lives that has real life (attested identity) solutions and services, built
> for the web and currently delivered through the web. Users *want* to solve
> their real life problems (banking, school, digital paperwork, taxes, telco
> arrangements, whatnot) conveniently through the web, the same way they can
> conveniently kill their time on FB: by not leaving the couch. I don't want
> to judge which activity is "best for the user", I just describe the facts
> of the world and web.
>
>
>  For example, the assumption that whatever "comes from the government, in
> post-snowden world" equals no privacy, no consent and is generally bad
> stuff by all means by default, more likely draws from someone's personal
> experience from his/her relations to his/her government than it does from
> practical evidence. As an example, take the German eID that has created a
> technological beast taking into account near paranoid privacy assumptions
> and user controlled attribute releasing, so that the system is basically
> unusable due to complexity (and, in fact, not used significantly in real
> life).
>
>
>  While the web of course targets the planet and beyond, I must repeat a
> nitty comment from some identity related event more than 10 years ago: "the
> difference between running an online service in US and EU is that in EU
> your user database (and everything collected) is a liability. Whereas in US
> it is an asset."
>
>
>  IMHO there are are sensible solution proposal descriptions from vendors
> that are for some reason outright labelled as "not good for user, not in
> user interests, not a priority, utter legacy", a response that makes me
> wonder why should I want to achieve W3C membership and work openmindedly
> with the "web platform" target if it really seems to be easier to become a
> "legacy browser" vendor that also "knows best about user priorities and
> interests" and just get the stuff done.
>
>
>  Anyway, I wish we could get back to technical problems and technical
> solutions rather than close to political rhetoric and dogmatic assumptions.
> Lets not deal with architecture astronautics and try to re-invent
> everything for the web or think what the users should want or not want or
> what is best for them, without asking them.
>
>
>  ----------------------------
>
>
>  Technical task to solve: how to bridge cryptographic material from smart
> cards and similar tokens to web applications via browsers, on all relevant
> platforms, in an open, meaningful (to users, browser vendors and web
> developers), effective and secure (including privacy) way.
>
>
>  The most important question (actually the answer) is: do browser vendors
> agree that this is something that should be possible and are willing to
> work on creating something or working with the "smart card community" to
> get things implemented via browsers, on most platforms?
>
>
>  If the answer is "YES", there are a few technical decisions to be made
> and W3C can have a role, read below.
>
>
>  If the answer is a "NO" from browser makers, there is no point in
> keeping up the discussion. Browser makers are currently actively moving
> away from previous de facto mechanism to bridge local native platforms
> components to web applications (NPAPI on the desktop, but mobile is the
> second problem source with nothing available) which the sector has happily
> used without working on usable standardisation efforts (something that
> plagues this sector unfortunately).  And there is no clear communication
> from browser makes about what should be used instead to get a comparable
> stable, supported solution. It should be made very clear if this is active
> resistance to any kind of efforts to achieve the necessary functionality or
> it is just lack of communication or lack of listening capability.
> Especially because any kind of standardisation effort, if at all possible
> through w3c, shall take years both from web software vendors as well as any
> real life rollouts if the only thinkable way forward for browser makers
> would be "web compatible hardware". The hiatus in availability of current
> web based services would render the web that affected users know "broken"
> for them and we better then turn to plan B and make adequate communication
> to users ASAP. But I'm sure that there exists a software solution rather
> than being a hardware issue.
>
>
>  The technical decisions would be, at least:
>
>
>  1. Decoupling of the problem from WebCrypto, which seems to be married
> to SOP and which is probably a good idea for current target. The question
> is discussed in webcrypto context only because it seems to be the forum
> where browser makers and smart card vendors/sector cross paths. A solution
> is needed to the soon broken use cases on desktop and hard-to-implement use
> cases on mobile platforms rather than something necessarily in WebCrypto.
> By nature it is more like geolocation/video/microphones with proper
> permissions and privacy considerations for implementors than SOP.
>
>
>  2. The question is where the support shall be implemented and from whom
> comes the necessary extra code to support device specific details.
> *Something* shall be necessary from browser makers in the first place,
> either generic (like NPAPI/ActiveX/NaCl) or domain specific (similar to
> what secure-element/openmobile/sconnect APIs or HID/Gemalto proposals
> assume).
>
>
>  3. I really like the web and most of the things I do over the internet I
> do with a "standard" web browser. The best would be if I could continue to
> use the web with a generic a browser instead of another dedicated "internet
> enabled" application. The same way it would be nice if the web on a mobile
> would work via a single browser, not jumping between apps. Anyway...
>
>
>  I know a few methods that can be - and in fact are - used to solve the
> problem *right now* but I don't like any of them. This includes: Native
> Client with Chrome or talking to a web servers on localhost which is done
> by a few countries in EU, probably could figure out a trick or two that
> could be used to bridge the two worlds without being affected by
> rent-seeking/gate-keeping by browser makers but at a considerable usability
> expense for the users.
>
>
>
>  Unless there is a clear understanding about the nature of the question
> and response from affected parties,  it would make more sense for me to
> stop trying to build upon the "web platform" and start a dedicated web
> browser project "that knows better" (EuroFox, anyone?) or just go with the
> flow and resort to dedicated apps. Balkanization achieved.
>
>
>  Thanks,
>
>  Martin
>