11:13:19 RRSAgent has joined #client 11:13:19 logging to http://www.w3.org/2014/03/01-client-irc 12:16:42 jphillips has joined #client 12:53:31 jphillips has joined #client 13:05:51 cabo has joined #client 13:10:30 AndChat|372521 has joined #client 13:16:03 cheshire has joined #client 13:20:50 We are watching. 13:39:02 NSA: how much longer will you be able to? 13:47:57 its notable that I couldn't connect to this server with SSL 13:48:08 w3c == nsa pawns? 14:08:35 Where is expo 23? 14:09:07 Asking for later 14:22:30 cabo has joined #client 14:23:10 cheshire has joined #client 14:26:26 jphillips has joined #client 14:29:22 jphillips2 has joined #client 14:32:42 cabo has joined #client 14:33:14 Ok, it's the primary big room we've been in 14:34:52 Please shout out that everybody else should be $here instead… 14:35:55 DThaler has joined #client 14:37:10 npdoty has joined #client 14:37:19 rrsagent, pointer? 14:37:19 See http://www.w3.org/2014/03/01-client-irc#T14-37-19 14:37:26 rrsagent, make logs public 14:37:58 hildjj has joined #client 14:38:16 Meeting: STRINT breakout on clients 14:38:24 Chair: cheshire 14:38:39 scribenick: npdoty 14:38:58 cheshire: tentative title "Client changes to improve certificate quality" 14:39:15 ... has been described as "browser stuff" but lots of other clients will be very important too 14:39:20 donnelly has joined #client 14:39:37 ... like IM or calendar or other clients where you're about to send username/password and you have a cert error 14:39:39 bjoern has joined #client 14:39:50 ... common frustration over these certificate errors 14:40:36 ... a "blizzard of alerts" on an airport captive portal 14:41:23 barryleiba has joined #client 14:41:45 bht has joined #client 14:41:58 phb: worst case is accepting a certificate accidentally and storing it as a trusted entity going forward 14:42:06 Bert has joined #client 14:42:09 rigo has joined #client 14:42:24 @@: several failures aren't specific to certificates, shouldn't send credentials in the clear anyway 14:42:39 s/@@:/BenL:/ 14:43:06 sorry, should've said my name 14:43:17 torgo: we all have frustrations with captive portals, but is that really what we're here to solve? 14:43:23 which is Ben Laurie :-) 14:43:50 ... we're trying to determine when the user is being tricked 14:44:16 cheshire: hotspot interception is part of a general background of bogus certificate errors 14:44:43 ... fatigue for the user opens the door for surveillance, hard to spot the stand-out certificate error 14:44:54 ... each one individually isn't so bad 14:45:08 ... but with so many failures, why do we even bother? 14:45:31 DThaler: not just about sending password, but also just the username is an information disclosure 14:45:50 PHB has joined #Client 14:45:56 ... choice: get work done or try to be safe -- so users always click OK 14:46:31 ... captive portal case is arguably legitimate; misconfigured certificate; third case is an attack 14:46:49 ... make the first two cases less common, so users won't be trained to click OK 14:46:50 Ben: Do you know that gmail ONLY offers LOGIN and PLAIN (plus openid) for IMAP 14:47:21 ... captive portals are supposed to spoof HTTP, that's the only way to do it 14:48:08 wseltzer: are we asking users questions we can reasonably expect them to answer? 14:48:42 ... improve certificate quality OR improve interface/questions for the user 14:49:08 cheshire: paper on what is the right way to ask users 14:49:19 ... (except maybe the answers we get from them are just as bad) 14:50:16 xnyhps has joined #client 14:50:24 pde: all of these are incomprehensible, even to the experts 14:50:32 ... the only interface should be "none" 14:50:49 ... if we have to break use cases, then so be it 14:51:00 oleg has joined #client 14:51:15 q+ npdoty 14:51:49 @@: stop asking users questions they don't have an answer to 14:52:01 ... instead, just show them scary flashing red lights for all the time that they're using that website 14:52:16 ... so that they might question what that bad thing is 14:52:44 rbarnes has joined #client 14:53:08 cheshire: improving the UI might be getting rid of it 14:53:18 ... if we have consensus among browser makers, that would be useful 14:53:23 ... but are there other agenda items? 14:53:39 s/@@/Pritikin/ 14:54:37 [I agree the best UI could be no UI] 14:55:07 [don't ask users irrelevant questions, or questions to which they have no reason to know the answer] 14:55:34 @@@: @@@@ 14:55:47 @@@? 14:56:35 @@@: only well-educated scientific people in my family cared about the expressed privacy; others just trusted everything to work 14:56:36 hhalpin has joined #client 14:56:47 s/@@@:/Juan-Carlos Zuniga:/ 14:57:49 phb: regarding no UI, certificates include 4 parties: user, site, CA, browser 14:58:05 ... browser has the problem that they want users to be able to connect to everyone and quickly 14:58:30 ... instead you could choose your antivirus-for-web-provider when you start your browser 14:58:59 ... and that provider / broker would tell you the DNS and the appropriate cert 14:59:33 npdoty: I like the no UI or minimized UI idea. 14:59:59 ... self-signed certs, why the scary error, instead of saying, "this is just like HTTP"? 15:01:17 DThaler: can narrow down to cases where you know whether or not you're behind the captive portal 15:01:50 ... 2 cases, for captive portal, just fail safe 15:02:05 ... for misconfigured and attacker case, just provide scary UI but assume they want to continue 15:02:12 ... could change user behavior 15:02:45 hildjj has joined #client 15:03:21 pde: could have a flag day, a 9-month deadline at which point all hotel captive portals will break 15:03:53 ... if the browsers were all in it together, would that make you willing? 15:04:10 15:04:22 phb has joined #client 15:04:33 Better choice is often to degrade 15:04:52 BenL: while it's motivating to break broken stuff, if other UAs aren't going to do it, then the user will blame the specific browser and switch, we helps no one 15:05:30 To break stuff: FIRTS determine the requirement for the brokenness, SECOND meet it THIRD degrade the deprecated path FOURTH disable the deprecated path 15:06:05 ... if the user had typed/bookmarked HTTPS or if the site had redirected to it, then not getting HTTPS should be a warnable thing 15:06:47 wendyg has joined #client 15:07:18 DThaler: lots of very old hotel software that isn't going to change in time, it would have to be very far away 15:08:00 @@: flag day would get us pushback about being a cabal, and lots of very small hotels are using very old systems 15:08:50 ... a common interface for applications themselves to state what kind of failure in making an HTTP request they want 15:09:03 @@ = Brian Trammell 15:09:03 ... that is, solve this for more than just the browser 15:09:20 s/@@: flag/BrianTrammell: flag/ 15:10:17 Ted: symptom of a much larger problem -- users are presented with credentials that they can't verify 15:10:43 ... in the US, you probably bought a phone from a store cooperating with a particular carrier 15:10:52 ... and so your phone probably includes a root certificate from the carrier 15:12:15 ... user/app developer can't distinguish between valid certificate because actually the real site and valid certificate because of the installed root 15:12:37 ... have to fix the fundamental problem in the web security model (that any cert can apply to any name) 15:13:32 cheshire: 1) "do you look for this lock icon?" "why would my web browser connect me to the russian mafia?" 15:14:27 ... why does the browser think it's reasonable to connect to the wrong thing and just show a tiny indicator? 15:15:25 ... 2) regarding the older hotel software, Apple like many OSes was using a small fetch to its own site 15:16:02 ... ... which then created an arms race because some hotspots didn't like that, and they even reverse engineered the list of a couple hundred domains 15:16:33 ... 3) flag day proposal: 15:17:04 ... ... a) short term, do a more strongly worded warning to the user, harmonizing language across vendors 15:17:34 ... ... b) give dates and advance notice, that by, say, 2015, it won't be as easy for users to click through 15:18:03 ... ... and that by, say, 2016 it will no longer be possible 15:18:40 ... ... and provide simpler functionality for installing a new cert for a particular site 15:19:05 Ted: but that gives the authority to sign for any name (not just for the site referenced to in the email) 15:20:17 cheshire: telling user to install a new trust anchor is burdensome enough that it becomes easier for the site to do the right thing 15:21:03 @@: shouldn't specify user interface 15:21:25 ... shouldn't put the onus on the user to install something 15:22:33 ... currently, HTTPS is an entirely different mode for the browser 15:23:18 torgo: regarding stronger wording, ratcheting up the health warning language on cigarette packs, doesn't seem productive 15:23:39 ... more user Web interaction are in Web views not just the full-on browser 15:23:56 ... cutting-off makes more sense rather than scary UI 15:24:18 ... hotel operators reverse-engineering anecdote makes me depressed about humanity 15:24:44 ... should find out why they're doing this, have a workshop with them -- Captive Portal Workshop, where we understand their real needs 15:26:11 cheshire: our web sheet has limited functionality -- doesn't show video, which breaks the business model of those who want video ads 15:27:06 pete: both flag day and the no-UI put costs on the wrong place 15:27:19 ... support calls will go to ISP, browser vendor, friends/family 15:29:03 ... red flashing display in the fail case -- still see the web site content, and so they'll make the support call to the web site 15:30:34 wseltzer: should do some user research 15:30:52 @@@: flag day not likely to work at Internet scale 15:31:18 s/@@@/Marc Blanchet/ 15:32:26 ... access points don't feel the incentive to change; think browsers will give in and switch back very quickly 15:34:23 cheshire: why do captive portals modify HTTPS connections? 15:34:29 hildjj has joined #client 15:34:44 marc: what about kids who go to HTTPS-only Facebook as their first page, because they're trying to be secure 15:35:20 cheshire: but the first connection should be the OS-level captive portal detection request which is HTTP 15:35:44 ... also, why do these captive portals intercept my IMAP connection instead of just blocking it? 15:36:09 DThaler: setting a deadline isn't enough, have to make misconfiguration less likely 15:36:23 ... makes it worse to help the user install a root certificate 15:37:04 ... getting a certificate with no UI (like DANE / DNSSEC) would be better 15:38:10 ... layering problem, what should you surface to the next level of the code (not user interface) about certificate errors? 15:38:36 kaie: there are some browsers that already make it harder than one click (Firefox today is 3 clicks) 15:38:59 ... user research from @__apf__ on how users respond to security warnings 15:39:03 clarification: getting a certificate _scoped only to a given name_ with no UI would be better 15:39:47 ... go ahead and display the content anyway? but what if we leak secure cookies or important URL parameters 15:40:22 ... could instead invalidate session/cookies and URL parameters and then show some warning to the user along with content 15:41:10 pde: clarification: not proposing flag day for stronger warnings, but instead just breaking captive portals and other MITM 15:42:42 ... treat domains that have had valid certs in the past differently from those that hadn't (via a list in the client) 15:43:31 ... why not have clients just use a small sample of sites known to have a valid x509 cert? 15:44:09 cheshire: some portals aren't intercepting https; want sites with constant content to make testing straightforward 15:45:00 @@: +1 Ted on dangers of installing a new root ca; need to support confidential but without identity 15:45:54 @@@: browser should be able to distinguish between lists of certificates of different types (like hotspot providers) 15:45:59 rrsagent, please draft minutes 15:45:59 I have made the request to generate http://www.w3.org/2014/03/01-client-minutes.html rigo 15:46:35 ... assumes that users will update the browsers -- it's true that many browsers are now auto-updating, but old clients persist 15:47:04 cheshire: just need enough users that sites have an incentive to fix their problem 15:47:45 @@@: have to consider chromeless interfaces as browsers become more OS-like 15:48:24 phb: "click here and the kitten dies" 15:48:44 ... could instead increase the weight of the success signals 15:49:26 ... like putting brand logos as an extension for certificates, show the company logo in chrome that can't be faked 15:49:59 BenL: chrome that can't be faked is hard 15:50:11 ... like flag day idea and would be happy to champion it 15:50:36 ... +1 to pde about list of sites that should have certificates, but it's hard to install a very large list in the browser 15:51:00 ... installing a locally trusted cert that's only good for a particular site or a particular hierarchy is good, but UI needs to prevent trickery 15:51:16 ... skeptical about zero UI because aren't we trying to fix the CA problem we have now? 15:51:57 hhalpin: users currently have private browsing modes; what if they had a secure browsing mode with more details about certs etc. 15:52:42 carlos: overlap with on-by-default 15:52:56 hildjj has joined #client 15:53:40 rigo: I care about self-signed certificates, would we remove those too? makes users feel powerless 15:54:35 removing support for invalid certificates removes self signed certificates? => 80% of the certificates that matter to me are self signed => what is a valid cert and how can a user find out? => have a feeling that you are deciding for the user, not good IMHO 15:54:39 removing empowerment from the user. At least allow people who know what they 15:54:42 do to continue what they are doing. No UI means even less control 15:54:44 by the user who are already feeling powerless. 15:54:47 For PM we want TLS by default, will create more errors, how will 15:54:49 you communicate to the user. 15:54:59 crocker: stronger message to users may make them feel worse but not help 15:55:19 cabo has joined #client 15:55:20 ... flag day didn't work even as far back as 1983 15:56:30 ... assertions by fiat won't help; security has adoption problems because of lack of usability 15:57:12 cheshire: more like IPv6 Day, where coordinated voluntary action would reduce any potential pushback on one of them 15:57:53 ... I'm supportive; champion in Chrome; supporters from Firefox; etc. 15:58:34 A realistic solution that involves the rest of the browservendors W3C would be happy to help with. 15:58:43 Test-cases :) 15:59:16 rrsagent, please draft the minutes 15:59:16 I have made the request to generate http://www.w3.org/2014/03/01-client-minutes.html npdoty 15:59:42 rrsagent, bye 15:59:42 I see no action items