- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 14 Sep 2015 10:36:23 -0700
- To: www-tag@w3.org
- Message-ID: <CACvaWvZUcHhOE+azkV6YSG0MCkhF9__hmERuD9aRzg37Uah7Mw@mail.gmail.com>
> > A user should have the ability to save crypto data to their local OS > hosted keystore if they choose. Agreed. The question is whether it's the browser's responsibility to directly integrate with that choice. > There are no virtues in restricting that > to local browser storage, solely, at this stage in the game (browsers > with host OS interaction is already a common usage pattern). Unfortunately, this is where the core of the disagreement rests. Yes, there is significant reason, much in the same way that (secure) browsers do not allow direct interaction with the GPU or, for that matter, font rendering engines ( http://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html ). The keystores - and client certificate stores - are similarly problematic. > None of the > main operating systems (desktop or mobile) allow interactions with their > respective keystores without OS level authentication challenges, by > default. Unfortunately, this is not an accurate representation. Every desktop operation relevant for discussion allows direct interaction with the OS keystore w/o OS level authentication challenges. Additionally, two out of three of the mainline mobile operating systems allow such interaction w/o any OS level authentication challenges. One does not allow any interaction, period, except through system management utilities (iOS). Perhaps you're speaking of the addition of root certs, but that's irrelevant for the discussion as to the capabilities of keys and user certs, both of which can have levels of persistence, security, and privacy implications.
Received on Monday, 14 September 2015 17:36:51 UTC