| 01:31 | <tabatkins> | I once again justified my position by being "the guy who knows what specs are out there". |
| 01:48 | <llrcombs> | HTML5 has some of the best ideas I've ever seen in the web |
| 01:48 | llrcombs | can't wait for addContentHander+<device> in WebKit |
| 01:49 | <llrcombs> | *register |
| 01:50 | <Hixie> | tabatkins: wait, if you're that guy, who the heck am i?! |
| 01:50 | <tabatkins> | "The guy who's never in a predictable location". |
| 02:02 | <llrcombs> | hmmmmmmm |
| 02:02 | <llrcombs> | if I have a <select multiple> |
| 02:02 | <llrcombs> | in a form |
| 02:03 | <llrcombs> | and I select 2 values and hit submit |
| 02:03 | <llrcombs> | assuming it's a GET form, what should the query string look like? |
| 02:03 | <llrcombs> | example: |
| 02:03 | <llrcombs> | data:text/html,%3Cform%20action=%22http://combsconnections.tk/request.php%22%20method=%22GET%22%3E%3Cselect%20name=%22test%22%20multiple%3E%3Coption%20value=%221%22%3E1%3C/option%3E%3Coption%20value=%222%22%3E2%3C/option%3E%3C/select%3E%3Cinput%20type=%22submit%22%3E%3C/form%3E |
| 02:03 | <llrcombs> | WebKit sends both values (test=1&test=2) |
| 02:03 | <llrcombs> | the PHP script grabs the second one |
| 02:03 | <llrcombs> | (http://combsconnections.tk/request.php?test=1&test=2 just print_r's $_REQUEST) |
| 03:18 | <Maxdamantus> | am I allowed to scale one of the canvas transformation dimensions by 0? |
| 03:24 | <llrcombs> | sure! |
| 03:24 | <llrcombs> | it'll just not change anything! |
| 03:24 | <llrcombs> | iirc |
| 03:24 | <Maxdamantus> | It won't? |
| 03:24 | <Maxdamantus> | I'd think that scaling by 0 would make drawing operations do nothing. |
| 03:25 | <Maxdamantus> | Hm. Firefox doesn't seem to let me do it. |
| 03:25 | <llrcombs> | wait, did you mean scaling something by 0px? |
| 03:25 | <llrcombs> | maybe I misunderstood |
| 03:25 | <Maxdamantus> | No, 0 |
| 03:25 | <Maxdamantus> | ctx.scale(0, 1) |
| 03:26 | <llrcombs> | ohwait |
| 03:26 | <llrcombs> | my fault |
| 03:26 | <llrcombs> | I'm 100% wrong |
| 03:26 | <llrcombs> | I must be tired |
| 03:26 | <llrcombs> | scaling with one arg at 0 sounds like a bad plan |
| 03:27 | <llrcombs> | I was thinking pixel transforms |
| 03:27 | <llrcombs> | you were thinking decimal-percent-thingy transforms |
| 03:28 | <Maxdamantus> | Ratio, maybe. |
| 03:28 | <llrcombs> | yeah, that'd be it! |
| 03:28 | llrcombs | sounds like an idiot about now |
| 03:28 | <llrcombs> | aww, it's 9:30 here |
| 03:28 | <llrcombs> | I have an excuse |
| 03:28 | <llrcombs> | (also, being 13 is one in and of itself) |
| 03:29 | <llrcombs> | well, back to hoping more people will try/report-issues-with http://code.google.com/p/plugin-blocker/ |
| 03:32 | <Maxdamantus> | http://ntus.uni.cc/canv.htm mmm.. doesn't work on Firefox. |
| 03:33 | <Maxdamantus> | Hm. Firefox seems to be strange about canvas.. My canvas-driven application runs super-fast in Firefox (compared to Chrome, suprisingly), but only when it's doing about 1276x960 or less |
| 03:33 | <Maxdamantus> | as soon as I put it fullscreen (~1280x1024) it lags alot :\ |
| 03:35 | <Maxdamantus> | Hm, seems to have to do with the actual fullscreen state of the browser window.. or not |
| 03:36 | <Maxdamantus> | I'm using a tiling WM, and when I tell the WM to make Firefox a borderless full screen window (but the normal Firefox controls are still there, because I didn't hit F11) it lags |
| 03:36 | <llrcombs> | so try ##javascript or #firefox |
| 03:37 | <Maxdamantus> | Not laggy after pressing F11 then forcing it out of fullscreen via the WM (but the controls are still gone, so Firefox appears to still think it's fullscreen) |
| 03:37 | <Maxdamantus> | Mmm, yeah I'll ask on irc.mozilla.org |
| 04:42 | <zcorpan_> | llrcombs: you can either parse the query string yourself in php, or use a name like test[] to make php turn it into an array, iirc |
| 04:42 | <llrcombs> | ahh, k |
| 04:47 | <llrcombs> | thanks |
| 04:51 | <zcorpan_> | np |
| 05:32 | <roc> | ta |
| 05:32 | <roc> | oops |
| 06:59 | <hsivonen> | AryehGregor: the parser code I've written is full of switch fall-thru |
| 06:59 | <hsivonen> | AryehGregor: though always with a comment // fall through |
| 07:06 | <othermaciej> | fallthrough is handy at times, but it can be a somewhat dangerous default |
| 08:10 | hsivonen | has trouble locating the processing rules for <base target> |
| 08:11 | <hsivonen> | aargh. I'm accidentally reading the multipage version |
| 08:11 | <hsivonen> | no wonder I don't find anything |
| 08:12 | <hsivonen> | found it |
| 08:18 | <hsivonen> | XML FTW! Minefield update failed due to a failure to parse an update file. |
| 08:45 | <bblfish> | hi |
| 08:45 | <hsivonen> | bblfish: hi |
| 08:46 | <bblfish> | There is a browser security issue that affects every browser and that is very easy to fix |
| 08:46 | <bblfish> | hi hsivonen |
| 08:46 | <bblfish> | I am wondering if this is something I could bring to the attention of the group here |
| 08:47 | <Hixie> | is it something that could harm users if attackers learnt of it? |
| 08:47 | <hsivonen> | bblfish: if it's not already publicly known, it would probably be more appropriate to report it via the security bug mechanism of the top browsers |
| 08:47 | <bblfish> | well it's an anonymity issue to do with ssl |
| 08:48 | <bblfish> | as well as a useability issue |
| 08:49 | <hsivonen> | Hixie: btw, it turned out that there's a software package whose output breaks with HTML5-compliant <base> handling |
| 08:49 | <hsivonen> | (hyperlatex) |
| 08:49 | <bblfish> | It's not an exploit |
| 08:49 | <hsivonen> | I'm treating it as evang, though, since the output already breaks in IE8 |
| 08:50 | <hsivonen> | kinda sucks though, since there is hyperlatex output in the long tail of Web sites on multiple sites |
| 08:50 | <bblfish> | (though perhaps it could be used as an exploit: but really it's stopping the adoption of client side SSL) |
| 08:50 | <Hixie> | hsivonen: yeah, we know it might break things |
| 08:50 | <Hixie> | if it's not something that could be used to attack users, it's fine to talk about it here |
| 08:51 | <bblfish> | ok, it's very simple. Imagine you want a site to be completely behind SSL |
| 08:51 | <Hixie> | we just don't want attackers hearing about bugs that they can then turn around and use to install malware on a million machines tomorrow (or whatnot) |
| 08:51 | <Hixie> | at least not before we've had a chance to fix them :-) |
| 08:51 | <bblfish> | and imagine that you want to use SSL for client side auth |
| 08:52 | <bblfish> | currently the client will be asked for his certificate before he sees the first page |
| 08:52 | <bblfish> | which is a bad UI experience |
| 08:52 | <hsivonen> | bblfish: client-side certs indeed have a ridiculously bad UX |
| 08:53 | <bblfish> | also the client if he choose a client side cert, will not be able to change it later |
| 08:53 | <bblfish> | ie: he can't logout |
| 08:53 | <bblfish> | so the solution is very very simple, and fixes both issues |
| 08:54 | <bblfish> | in the URL bar of the browser the browser should show the server cert used, but also the client cert |
| 08:54 | <bblfish> | and the first login to a site it should allow the client to be logged in anonymously |
| 08:55 | <bblfish> | ie: if the server asks for a cert anonymously, the browser should not send one (if the user chooses that as a general preference) |
| 08:55 | <bblfish> | and the browser should show the anonymous cert in the tool bar |
| 08:55 | <bblfish> | then the user should be able to click on the client cert, and login by choosing his certificate |
| 08:56 | <hsivonen> | bblfish: that's probably worth filing as a UI feature request for each browser |
| 08:56 | <bblfish> | if you do that, then client side certs become useable, and extreemly useful, and you don't have the danger that a server track a user without his knowledge |
| 08:56 | <hsivonen> | bblfish: however, I'd expect client-side certs to be very, very low in the UI teams' priorities |
| 08:57 | <bblfish> | hsivonen: I have file this with Firefox, Chromium, Safari, Opera |
| 08:57 | <hsivonen> | bblfish: great |
| 08:57 | <Hixie> | do people still use client-side certs? |
| 08:57 | <bblfish> | but I think that perhaps if I bring it up here, then people can follow up on it |
| 08:57 | <Hixie> | (have people ever used client certs?) |
| 08:58 | <bblfish> | Hixie: with the WebID protocol, we believe that we can make client side certs and every day experience |
| 08:58 | <Hixie> | what problem do they solve? |
| 08:58 | <bblfish> | the login problem |
| 08:58 | <Hixie> | what login problem |
| 08:59 | <bblfish> | the one that OpenId is trying to solve |
| 08:59 | <Hixie> | isn't that solved by, like, entering a username and password |
| 08:59 | <bblfish> | the nice thing with client certs is that you don't need to enter a username/password |
| 08:59 | <bblfish> | you can just click a cert |
| 08:59 | <bblfish> | and it's secure |
| 09:00 | <bblfish> | and built right in the browser |
| 09:00 | <Hixie> | doesn't that mean i'm stuck if i ever use another computer? |
| 09:00 | <bblfish> | nope :-) |
| 09:00 | <Hixie> | or if i poor water into my laptop as i did recently |
| 09:00 | <Hixie> | pour even |
| 09:00 | <hsivonen> | bblfish: isn't Firefox Account Manager solving the login problem without client-side certs? |
| 09:01 | <bblfish> | here is a 4 minute video that shows how easy it is to create a cert http://www.youtube.com/watch?v=S4dlMTZhUDc |
| 09:01 | <bblfish> | and get a new one for each browser |
| 09:01 | <bblfish> | it's just a one click affair |
| 09:01 | <Hixie> | that you need a 4 minute video is a little disconcerting :-) |
| 09:01 | <bblfish> | Hixie: I am not a video artist |
| 09:02 | <hsivonen> | bblfish: does WebID also rely on FOAF/RDF in addition to client-side certs? |
| 09:02 | <Hixie> | i've never had to show someone a video to explain how to use a password ;-) |
| 09:02 | <bblfish> | hsivonen: It does not need to |
| 09:02 | <bblfish> | Hixie: I think in the early days of the web you probably had to show people a video |
| 09:03 | <Hixie> | in the early days of the web you were lucky to get images, let alone a video |
| 09:03 | <hsivonen> | in 2003 I had to help my superiors use smartcard-resident client-side certs with IE |
| 09:03 | <Hixie> | but that's another story |
| 09:03 | <hsivonen> | the experience was even worse than it necessarily had to be |
| 09:03 | <bblfish> | the point here is that you asked me if it was difficult, and a video makes the point clearly. It saves typing |
| 09:03 | <Hixie> | i don't really see what's wrong with typing in a password to be honest |
| 09:04 | <Hixie> | i mean, for secure sites you want some sort of second factor authentication, obviously |
| 09:04 | <hsivonen> | (IE copied the public part of the cert to its local storage, so on subsequent logins there were two identically-titled certs to choose from but only the one that was actually coming from the smartcard worked) |
| 09:05 | <bblfish> | Hixie: if you look at the video you'll see that in our use case we still have one site with passwords |
| 09:05 | <Hixie> | wait so you have passwords AND certs? |
| 09:05 | <Hixie> | wouldn't it be better just to use OAuth |
| 09:06 | <bblfish> | Well why not fix the browser bug? |
| 09:06 | <bblfish> | and get real identity in the browser |
| 09:07 | <bblfish> | it's a minor UI fix frankly, and the browser vendors would get maximum benefit, as well as allowing real security on the internet |
| 09:07 | <bblfish> | and it's a bug |
| 09:07 | <Hixie> | what's the benefit of "real identity"? |
| 09:08 | <bblfish> | as I said, no username password. On cell phones that is really cool |
| 09:08 | <bblfish> | one cert to login to any site you want to |
| 09:09 | <Hixie> | you just said that you did have a username and password |
| 09:09 | <bblfish> | and the browser anyway, should show the user what information he is sending to the site |
| 09:09 | <Hixie> | i don't want different sites to be able to tell i'm the same person! |
| 09:09 | <bblfish> | Hixie: not necessarily - and only for one site |
| 09:09 | <Hixie> | that'd be terrible |
| 09:09 | <Hixie> | if you want to just have central login, just use oauth |
| 09:09 | <bblfish> | Hixie: exactly: that is why the browser should show you what idenitty you are using when you log in |
| 09:09 | <boblet> | hey all, re: nav, I received a question about having a duplicate main nav in the page footer — logically seems to be appropriate for <nav> but duplicate so I wouldn’t… |
| 09:10 | <wirepair> | my understanding of client side certs is *only* for 2 factor auth |
| 09:10 | <wirepair> | you seem to be wanting to use it for something different |
| 09:10 | <wirepair> | it's mainly for the servers protection |
| 09:10 | <boblet> | …worth adding something to spec about major navigation blocks being unique, or is this something that AT should automatically filter? |
| 09:10 | <bblfish> | wirepair: it can also be used for client side auth |
| 09:10 | <wirepair> | but why |
| 09:11 | <wirepair> | ? |
| 09:11 | <bblfish> | because then you have identity in the browser |
| 09:11 | <wirepair> | why do i want identity in the browser? |
| 09:11 | <Hixie> | that's not something i want |
| 09:11 | <wirepair> | exactly |
| 09:11 | <Hixie> | it's actively something i don't want |
| 09:11 | <wirepair> | i'd rather be anonymous unless i *chose* |
| 09:11 | <Hixie> | exactly |
| 09:11 | <wirepair> | to i dunno, Login. |
| 09:11 | <wirepair> | ;) |
| 09:11 | <Hixie> | boblet: not sure i follow |
| 09:11 | <bblfish> | wirepair: that's exactly what the point of the fix I am proposing would do |
| 09:12 | <bblfish> | alow you to be anonymous unless you choose |
| 09:12 | <boblet> | hixie: main nav links duplicated in page header and footer |
| 09:12 | <wirepair> | but i'm already doing that |
| 09:12 | <bblfish> | and also *show* you what you logged in as |
| 09:12 | <Hixie> | bblfish: why is it better to pick a cert rather than have the browser remember my username/password? |
| 09:12 | <Hixie> | boblet: what about them? |
| 09:12 | <bblfish> | because username/pass are the biggest security hole on the internet |
| 09:12 | <bblfish> | it's well known |
| 09:12 | <wirepair> | and what makes a cert better? |
| 09:13 | <bblfish> | it uses cryptography |
| 09:13 | <Hixie> | a cert is better than a password because it's essentially a longer password |
| 09:13 | <bblfish> | the same reason the web took off after 1997 when SSLv3 came out |
| 09:13 | <Hixie> | (a much, much longer password) |
| 09:13 | <boblet> | Hixie: if both use <nav> then there’d be two items in an AT-constructed list of <nav> with identical content (well, theoretically, one day) |
| 09:13 | <wirepair> | it really comes down to what are you protcting against |
| 09:14 | <wirepair> | i mean if i pop your box, i don't really care if you use a cert |
| 09:14 | <wirepair> | i'll just either extract your keys |
| 09:14 | <bblfish> | it is much better than a password. It is asymetrical |
| 09:14 | <wirepair> | or setup a sniffer |
| 09:14 | <boblet> | I guess if the titles are identical the user can guess the content is duped |
| 09:14 | <bblfish> | you don't send the private key to the server |
| 09:14 | <wirepair> | pop your box == exploit a vulnerability and gain access to your system |
| 09:15 | <bblfish> | you get authentication without the server being able to reuse the password or try it out on another site |
| 09:15 | <wirepair> | i mean, most sites when i go to login, i do it over SSL anyways, not sure what a client cert would give me |
| 09:15 | <Hixie> | boblet: it seems silly to have the same content twice on the page, ideally we'd use CSS to duplicate content if we had to, but in the absence of that, i see nothing wrong with having it twice in the page |
| 09:15 | <Hixie> | boblet: you can hide it from ATs if you really want to by saying role=presentational or some such |
| 09:15 | <Hixie> | wirepair: passwords are insecure in practice because people pick terribly bad predictable passwords |
| 09:16 | <bblfish> | wirepair: if you pop someone's box then of course things are always in the air: with crypto it is possible to go further and put the private key on a hardware device |
| 09:16 | <wirepair> | hixie, i'm a security professional i'm playing devils advocate here ;) |
| 09:16 | <Hixie> | ah ok |
| 09:16 | <Hixie> | just checking :-) |
| 09:16 | <Hixie> | personally i think a cert is dumb because it's tied to the machine |
| 09:16 | <bblfish> | wirepair: did you check the video I sent? |
| 09:16 | <boblet> | Hixie: aah interesting. thanks |
| 09:16 | <Hixie> | i don't want to have to create a new cert on each device i have |
| 09:16 | <wirepair> | i mean i've worked with client certs before they are a pain |
| 09:16 | <Hixie> | let alone devices that aren't mine |
| 09:16 | <wirepair> | for *everyone* involved |
| 09:16 | <bblfish> | Hixie: in that video I show that it is cheap to create a cert |
| 09:16 | <wirepair> | not just the client |
| 09:17 | <wirepair> | create != distribute |
| 09:17 | <wirepair> | and manage |
| 09:17 | <Hixie> | bblfish: it's a step i don't have to do if i just use username+password+2ndfact+oauth |
| 09:17 | <Hixie> | 2ndfactor even |
| 09:17 | <bblfish> | Hixie: I know you are in love with oauth |
| 09:17 | <bblfish> | but perhaps it's blinding you to some obvious solution |
| 09:18 | <bblfish> | I mean obvious solutions can be very difficult to see |
| 09:18 | <wirepair> | i'll bite and watch your movie ;) |
| 09:18 | <Hixie> | actually if you knew me you'd know my like of oauth is minimal |
| 09:18 | <bblfish> | ah ok |
| 09:18 | <bblfish> | sorry don't know everyone here |
| 09:18 | <bblfish> | (probably know hardly anyone) |
| 09:18 | <Hixie> | but maybe your love of certs is blinding you to the same thing :-) |
| 09:19 | <Hixie> | why are certs superior to having a site be your oauth login provider? |
| 09:19 | <bblfish> | Hixie: I know oauth, and the advantage of certs is that you can do the same as oauth in 1-2 connections that oauth/openid would take a lot more |
| 09:19 | <hsivonen> | Hixie: Firefox Sync solves the device problem |
| 09:19 | <Hixie> | (actually yeah i guess i really mean openid, not oauth) |
| 09:19 | <bblfish> | ah ok |
| 09:20 | <Hixie> | (shows how much i love them) |
| 09:20 | <hsivonen> | (as long as all your devices run Firefox Sync-compatible browsers) |
| 09:20 | <hsivonen> | I guess in theory, Firefox Sync could sync client-side certs, too |
| 09:20 | <Hixie> | hsivonen: given how often i (a) nuke profiles, (b) change browsers, and (c) use computers that aren't mine, cloud sync wouldn't help me at all |
| 09:20 | <bblfish> | yes. But if you look at the video you don't really need to sync client side certs: they are cheap to make |
| 09:21 | <hsivonen> | but then you'd end up encrypting your private key with a shorter Firefox Sync pass phrase |
| 09:21 | <Hixie> | they're not cheap to make compared to typing in a username and password |
| 09:21 | <wirepair> | then what does it gain you if they're cheap to make? |
| 09:21 | <bblfish> | (though this brings in WebID. And I was hoping not to bring that one also into this debate) |
| 09:21 | <wirepair> | i mean i just watched it and you'd have to put in your username/password to generate a new cert no? |
| 09:21 | <Hixie> | since you'd have to type in a username and password to get the cert associated with your account in the first place |
| 09:21 | <wirepair> | exactly ehe |
| 09:21 | <Hixie> | basically it would be entirely inferior to not having a cert |
| 09:21 | <hsivonen> | Hixie: if you wear your tinfoil hat properly, you should expect everything to have been compromised at c) |
| 09:21 | <bblfish> | yes, you have 1 site you need some id for - perhaps one time password |
| 09:21 | <Hixie> | in every way |
| 09:22 | <Hixie> | hsivonen: they're not random computers |
| 09:22 | <bblfish> | but once you have that you can log into every site |
| 09:22 | <wirepair> | bblfish, then the backend server *still* needs to store my username and password |
| 09:22 | <wirepair> | right? |
| 09:22 | <hsivonen> | Hixie: ok |
| 09:22 | <wirepair> | so ... your earlier threat scenario, doesn't really matter |
| 09:22 | <bblfish> | wirepair: the back end server could send you a password via phone |
| 09:23 | <wirepair> | so now i need an sms provider |
| 09:23 | <bblfish> | you have one identity provider site (you could have a few). you use that to create your cert in one click. |
| 09:23 | <Hixie> | bblfish: what you are describing is username+password+click a few buttons to make a cert+openid or oauth to get the 3rd party site to know who the new cert represents |
| 09:23 | <wirepair> | i'll stick with username/passwords ;/ |
| 09:23 | <Hixie> | bblfish: how is that in any way superior to username+password+2nd factor+openid or oauth to get the 3rd party site to know who the new cookie represents? |
| 09:24 | <Hixie> | bblfish: (ways in which it is inferior: the security is no better than the password in your model) |
| 09:24 | <Hixie> | bblfish: (and it takes ten times longer) |
| 09:24 | <Hixie> | bblfish: (and it doesn't work today with any sane UI) |
| 09:24 | <Hixie> | bblfish: (and it doesn't have 2 factors) |
| 09:25 | <bblfish> | the security is better than password. because you only have one site that you send a password to. All other sites can then be logged into in one click |
| 09:25 | <bblfish> | and you only need to do that once |
| 09:25 | <Hixie> | that is the same as with what i'm suggesting |
| 09:25 | <bblfish> | you need to do the same with Firefox sync btw |
| 09:25 | <Hixie> | except that i'm suggesting you have to send _more_ than just the password to the original site |
| 09:25 | <bblfish> | you need to remember the password of the sync file |
| 09:25 | <Hixie> | you have to send a second factor |
| 09:25 | <bblfish> | what is the second factor? |
| 09:25 | <Hixie> | (i am not suggesting anyone use firefox sync) |
| 09:26 | <Hixie> | the second factor can be whatever you want, e.g. a code sent by SMS, or a password calculator |
| 09:26 | <bblfish> | Well firefox sync could be the solution to not even having to have any site know your password |
| 09:26 | <bblfish> | making things even more secure |
| 09:26 | <bblfish> | I am trying to work with what we have |
| 09:26 | <Hixie> | what do you mean, what we have? |
| 09:26 | <hsivonen> | bblfish: with Firefox Sync, to be secure, you make up a long string of random characters, write it on paper, type it into each of your Firefox Sync instance and put the paper into a safe |
| 09:26 | <bblfish> | well the vieo is what works in current browsers |
| 09:27 | <Hixie> | my main authentication provider today uses two factors, a password and a code calculator |
| 09:27 | <bblfish> | cool. So it can use that too |
| 09:27 | <bblfish> | it all depends on how secure you want to be |
| 09:27 | <Hixie> | ok but how is the cert helping any? |
| 09:27 | <bblfish> | it allows you once in the browser to log into any site |
| 09:27 | <Hixie> | if i have an auth provider that's secure, what more do i need? |
| 09:28 | <Hixie> | i have that today with openid |
| 09:28 | <bblfish> | well openid requires 7 ssl connections |
| 09:28 | <bblfish> | http://blogs.sun.com/bblfish/entry/the_openid_sequence_diagram |
| 09:29 | <bblfish> | that means there are plenty of cases where it can break down |
| 09:29 | <Hixie> | well if you want to argue for moving openid up into the browser so we can get it down to 2, i'm all for it |
| 09:29 | <Hixie> | but that's far better than trying to use client certs imho |
| 09:29 | <bblfish> | and if openid wants to avoid physching, it also needs the client side cert part |
| 09:29 | <Hixie> | how so |
| 09:30 | <bblfish> | because you could go to a site, and it redirect you to a site that looks very much like your openid provider |
| 09:30 | <Hixie> | (what you described would be emminently susceptible to phishing, btw -- just send the user an e-mail asking the user to go to the attacker's site and type in the cert password, so the attacker can create a cert for himself as if he was the user on a new machine) |
| 09:30 | <bblfish> | Also OpenId is not restful |
| 09:31 | <bblfish> | Hixie: that only happens once in a user's browser lifetime. A user would rarely create a certificate |
| 09:31 | <bblfish> | openid requires you to go to the openid site every time |
| 09:31 | <Hixie> | openid only requires you to log in once |
| 09:32 | <Hixie> | after that the redirects are all silent |
| 09:32 | <bblfish> | yes, but every time you login you end up at that site |
| 09:32 | <Hixie> | so? |
| 09:32 | <Hixie> | the user doesn't see that |
| 09:32 | <bblfish> | well with client certs that is not the case |
| 09:32 | <Hixie> | so? |
| 09:32 | <Hixie> | who cares |
| 09:33 | <Hixie> | it works fine |
| 09:33 | <bblfish> | well if the user wishes his attributes to be updated then it is a problem |
| 09:33 | <Hixie> | i can't recall ever having wanted to Update my Attributes when using OpenID |
| 09:34 | <bblfish> | so Hixie: what is your problem? A fix to the SSL stack is easy, and it could allow certain things to happen, which should be fixed anyway |
| 09:34 | <Hixie> | i have no problem, that's my point |
| 09:34 | <Hixie> | everything works fine today |
| 09:34 | <Hixie> | no need to change anything :-) |
| 09:34 | <bblfish> | not really |
| 09:34 | <Hixie> | in fact we should just nuke the whole client cert feature |
| 09:34 | <bblfish> | you cannot use client side certs to their full potential |
| 09:35 | <Hixie> | simplify browsers |
| 09:35 | <bblfish> | and it would be easy to fix |
| 09:35 | <Hixie> | using client certs at all is not a goal, imho |
| 09:35 | <Hixie> | it's an antigoal |
| 09:35 | <bblfish> | that's because you don't understand their potential |
| 09:35 | <Hixie> | users in general do not understand cryptography |
| 09:35 | <Hixie> | it's like trying to get them to understand RDF |
| 09:35 | <Hixie> | it's a lost cause |
| 09:35 | <bblfish> | users don't understand html Hixie but they can use browsers |
| 09:36 | <Hixie> | users understand HTML well enough to use it |
| 09:36 | <Hixie> | you can fail to understand 90% of HTML yet still succeed at it |
| 09:36 | <bblfish> | Hixie: you are clutching on straws |
| 09:36 | <Hixie> | but if you only understand 95% of crypto, you'll shoot yourself in the foot |
| 09:36 | <bblfish> | you are using "Users" in two different ways |
| 09:36 | <Hixie> | which two ways? |
| 09:37 | <bblfish> | once you mention developers and then end users (mom, pops) |
| 09:37 | <Hixie> | (i've had the same person in mind every time i've said users so far) |
| 09:37 | <bblfish> | you uses a very generic term |
| 09:37 | <Hixie> | no, i actually meant end users when i mentioned HTML, as I thought you did |
| 09:37 | <bblfish> | if you mean developers say so |
| 09:37 | <Hixie> | in this particular case, i was thinking of someone blogging on livejournal |
| 09:37 | <bblfish> | ok, so end users don't understand html |
| 09:37 | <Hixie> | where they'd understand little bits of HTML, enough to make their text emphasised or add a link |
| 09:38 | <bblfish> | that's why there is wiki syntax |
| 09:38 | <bblfish> | those same users have no problem understand client side certs. It's a UI presentation issue |
| 09:38 | <bblfish> | that's all |
| 09:38 | <Hixie> | lol |
| 09:38 | <Hixie> | please |
| 09:39 | <bblfish> | I am not joking |
| 09:39 | <bblfish> | the issue is completely solved by the fix I am proposing |
| 09:39 | <Hixie> | then you should do some usability studies |
| 09:39 | <bblfish> | I bet you 10000 dollars that I am right |
| 09:39 | <bblfish> | your useability studies are missing some key issues |
| 09:40 | <Hixie> | i challenge you to walk out to your nearest bar, pick someone randomly from the dance floor, and ask them to explain what a "Client Certificate" is |
| 09:41 | <bblfish> | who cares. I challenge you to go into the nearest bar and ask them to explain what html is |
| 09:41 | <Hixie> | i live in mountain view so that's likely to get a different effect than you want |
| 09:42 | <bblfish> | well then the guy will probably also know what client certs are |
| 09:42 | <bblfish> | too |
| 09:42 | <Hixie> | one of us is dramatically out of touch with your average user, or even with average power user |
| 09:42 | <Hixie> | it could be me |
| 09:42 | <Hixie> | but i doubt it |
| 09:42 | <bblfish> | anyway - the reason most people won't know is just that people don't use them. And the reason they don't use them is complex, but it is not because they are difficult to use |
| 09:43 | <Hixie> | it's because they are easy to misuse |
| 09:43 | <bblfish> | I mean web sites don't use them |
| 09:43 | <bblfish> | passwords are a lot easier to misuse |
| 09:43 | <Hixie> | and users don't even understand the importance of passwords |
| 09:43 | <bblfish> | a good reason to remove passwords altogether |
| 09:43 | <bblfish> | and to move to certs |
| 09:44 | <Hixie> | so getting them to understand asymetric crypto, private and public keys, etc... |
| 09:44 | <Hixie> | your solution doesn't get rid of passwords! |
| 09:44 | <bblfish> | you don't have to get them to understand that! |
| 09:44 | <bblfish> | you just make sites that use that |
| 09:44 | <bblfish> | simple |
| 09:44 | <Hixie> | anyway, i have to return to work |
| 09:44 | <Hixie> | so, good luck |
| 09:44 | <bblfish> | nice talking to you Hixie. I should come to mountain view and give a talk |
| 09:45 | <bblfish> | It's a bit odd: the issue is one of perception only |
| 09:46 | <Hixie> | i hear the same from the RDFa guys :-) |
| 09:46 | <bblfish> | I like RDFa but btw, WebID would work with normal XML too |
| 09:46 | <Hixie> | rather than give a talk, i recommend deploying it and proving me (us) wrong |
| 09:47 | <Hixie> | XML is another technology that's basically dead on the web |
| 09:47 | <bblfish> | well have a look at the video: that proves you wrong. we are working on deployments |
| 09:47 | <bblfish> | Ok, it could work with json too |
| 09:47 | <bblfish> | we have defined the protocol so we don't take syntax sides |
| 09:47 | <bblfish> | no syntax wars here |
| 09:47 | <hsivonen> | "could work with JSON" isn't good enough |
| 09:47 | <Hixie> | what will prove me wrong is facebook, twitter, gmail, etc, using client certs as a default (or only) login mechanism. |
| 09:48 | <hsivonen> | only uses JSON is ok |
| 09:48 | <bblfish> | Hixie: ok. So you are not a path burner |
| 09:48 | <zcorpan_> | Hixie: didn't you have work to do? :) |
| 09:48 | <hsivonen> | unfortunately, the Web Finger stuff relies on an XML monstrosity |
| 09:48 | <hsivonen> | which could very well be JSON |
| 09:48 | <Hixie> | bblfish: no, i'm a paver of cowpaths :-) |
| 09:48 | <Hixie> | quite the opposite |
| 09:48 | <hsivonen> | but since the XML format is there, now every implementation has to support the XML thing even if a JSON alternative were possible |
| 09:49 | <bblfish> | well in this case it would be very minimal effort to fix a few bugs |
| 09:49 | <Hixie> | bblfish: so do it and submit patches :-) |
| 09:49 | <Hixie> | standardisation is about finding what trails were blazed, and building ducts and highways and so forth to use them |
| 09:49 | <Hixie> | it's not about innovation |
| 09:49 | <bblfish> | well the reason I am here is to chat to people who have access to browser vendors |
| 09:49 | <Hixie> | innovation is what happens before you get standards |
| 09:50 | <bblfish> | good, we are innovating with WebID - and again what I am proposing was just a use case for why I thought those patches would be useful |
| 09:50 | <Hixie> | bblfish: best to just approach the browsers directly and submit running code (especially for something like certs, which have nobody working on them at all) |
| 09:50 | <bblfish> | yes. I have done that. But sometimes it can be good to have other entry points |
| 09:51 | <bblfish> | there are other players who can find this interesting: banks, security agencies, governments, and other hackers |
| 09:51 | <bblfish> | and I thought perhaps this group here could be interested |
| 09:52 | <Hixie> | i'm afraid most of us are probably too joded by past experience with client side certs at this point to believe in anything until we've seen it actually used by millions of regular users daily |
| 09:53 | <bblfish> | the very nice thing about certs bytw is that it is completely standardised . No intellecutal property |
| 09:53 | <bblfish> | Hixie: We are working on getting that done. While doing it we found an issue that would be easy to fix. I reported it to browser vendors. |
| 09:53 | <Hixie> | so you said :-) |
| 09:53 | <bblfish> | then I thought it could be a good channel to bring this up here |
| 09:54 | <Hixie> | well you're definitely welcome to discuss it here :-) |
| 09:54 | <Hixie> | but that doesn't mean we have to think it's a good idea :-) |
| 09:54 | <bblfish> | of course: freedom of thought |
| 09:55 | <bblfish> | Hixie: if you look at my two videos you'll see that at least part of your issues are solved - it is easy to create a cert, and to have a different one for each browser |
| 09:55 | <bblfish> | did you know that before seeing the video? |
| 09:56 | <Hixie> | yes, i specced <keygen> |
| 09:56 | <bblfish> | ah cool |
| 09:56 | <Hixie> | i am actually pretty familiar with this topic |
| 09:56 | <Hixie> | whence my jadedness |
| 09:56 | <bblfish> | ok. Did you see the possibility of creating on the fly client certs? |
| 09:56 | <bblfish> | that could be used across web sites? |
| 09:57 | <Hixie> | as opposed to what? |
| 09:57 | <Hixie> | i do understand what you're proposing |
| 09:57 | <bblfish> | well currently people have to go to a CA |
| 09:57 | <bblfish> | which is very tedious |
| 09:57 | <bblfish> | and costly |
| 09:57 | <Hixie> | how so? |
| 09:57 | <bblfish> | we don't require CAs |
| 09:57 | <Hixie> | <keygen> doesn't require CAs |
| 09:57 | <bblfish> | no, but until now keygen has created certs that only work for 1 web site |
| 09:58 | <bblfish> | I think that is the way they are usually used |
| 09:58 | <Hixie> | um, no? |
| 09:58 | <Hixie> | oh well it's often only used that way, yes |
| 09:58 | <Hixie> | but there's no inherent limitation |
| 09:58 | <bblfish> | no: no limitation in keygen. You did an excellent job |
| 09:58 | <bblfish> | I love keygen |
| 09:58 | <Hixie> | i hate it personally :-) |
| 09:58 | <Hixie> | had to spec it because people use it for some ungodly reason |
| 09:59 | <bblfish> | but the limitation is in the way Certs are used: because either they are tied to a single site, or they have to be signed by a CA - that's how people have been thinking of certs up till now |
| 09:59 | <bblfish> | and furthermore: there is very little flexibility in what you can put in a cert |
| 09:59 | <bblfish> | nobody is going to put their buddies in the cert |
| 10:00 | <bblfish> | or their telephone number |
| 10:00 | <bblfish> | etc. |
| 10:00 | <bblfish> | but if you go across sites that is what is important |
| 10:00 | <bblfish> | you want to login and have the site know something about you |
| 10:00 | <Hixie> | to you |
| 10:00 | <bblfish> | (as OpenId does) |
| 10:00 | <bblfish> | (with attribute exchange) |
| 10:00 | <Hixie> | i desperately do not want the site to know anything about me except what i tell it, personally |
| 10:00 | <hsivonen> | bblfish: fwiw, pretending to be a casual user, I had no idea what was going on in the video |
| 10:01 | <hsivonen> | bblfish: how should the user know the magic that happened is safe? |
| 10:01 | <bblfish> | hsivonen: It's not for a casual user, but for hackers like you |
| 10:01 | <hsivonen> | bblfish: how would the user know how to back up a cert like Firefox said? |
| 10:01 | <bblfish> | there is no need to back up the cert |
| 10:01 | <bblfish> | that is a firefox UI issue |
| 10:02 | <Hixie> | no, because anyone with the password can just generate a new one! |
| 10:02 | <Hixie> | security = awesome |
| 10:02 | <hsivonen> | Hixie: wait, what? |
| 10:02 | <Hixie> | hsivonen: ask him how you get a new cert if you move to another computer |
| 10:02 | <hsivonen> | maybe I should have followed along more carefully |
| 10:03 | <bblfish> | you get a new cert by having a shared secret with the identity provider. That can be a one time password, a password, something sent by sms, or whatever |
| 10:03 | <bblfish> | or that information could be backed up using firefox sync |
| 10:03 | <bblfish> | or some similar mechansim |
| 10:04 | <bblfish> | or if you want full protection you have a USB crypto stick |
| 10:04 | <Hixie> | hsivonen: basically this is just creating a much more expensive (in terms of CPU) cookie |
| 10:05 | <bblfish> | Hixie: TLS has the equivalent of cookies with SSL sessions |
| 10:05 | <Hixie> | hsivonen: (plus it provides a one-click solution to accidentally uploading your personal details to porn sites that use login) |
| 10:05 | <bblfish> | but the point of this is to allow you to login to new sites |
| 10:05 | <Hixie> | s/login/this mechanism for login/ |
| 10:06 | <bblfish> | well that is why browsers should show the user what client cert he is using when logging into a site |
| 10:06 | <hsivonen> | bblfish: If this is just and expensive cookie, why is it user-visible unlike cookies? |
| 10:06 | <Hixie> | bblfish: it's too late by then, isn't it :-) |
| 10:06 | <bblfish> | cookies should also be user visible |
| 10:07 | <bblfish> | that is what Firefox Weave is working on http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox |
| 10:07 | <Hixie> | i believe you've just gone past the edge of the local overton window |
| 10:07 | <bblfish> | overton? |
| 10:07 | <jgraham> | window |
| 10:07 | <Hixie> | http://en.wikipedia.org/wiki/Overton_window |
| 10:08 | <bblfish> | well the firefox weave people don't think that is a problem |
| 10:08 | <bblfish> | As I say it's a UI issue |
| 10:08 | <hsivonen> | bblfish: don't think what exactly is a problem? |
| 10:08 | <bblfish> | Aza Raskin has some very good ideas there |
| 10:09 | <bblfish> | well Hixie is suggesting that I went too far by suggesting that the user should be able to see the cookied |
| 10:09 | <bblfish> | if you look at the prototypes here: http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox |
| 10:09 | jgraham | doesn't understand how the linked screenshot implies users should be able to see the cookies |
| 10:09 | <bblfish> | that is what the FF team is doing |
| 10:09 | <bblfish> | ok. You see how you can see what you are logged in as? |
| 10:10 | <Hixie> | i'm not saying you went too far, i'm saying that most people here think it's a crazy idea |
| 10:10 | <bblfish> | you can see the server you are logged in and the identity you are logged in as |
| 10:10 | <hsivonen> | Account Manager shows that you have logged in. it doesn't make you choose from a list of certs of cookies. |
| 10:10 | <jgraham> | That doesn't imply "user visible cookies" to me |
| 10:10 | <bblfish> | good. Of course: cookies should be tied to your identity |
| 10:10 | <hsivonen> | *certs or cookies |
| 10:11 | <bblfish> | so to show the users identity is to show indirectly the cookies |
| 10:11 | <bblfish> | and it will allow you to go to a site and notice that you are logged in and under what id |
| 10:12 | <Hixie> | what sites don't already do that? |
| 10:12 | <bblfish> | the sites show you. What we want is the browser to tell us. |
| 10:12 | <bblfish> | so the site can't snoop |
| 10:12 | <Hixie> | can't snoop what? the site is the one that decised what it means to be logged in |
| 10:13 | <bblfish> | The browser can help for example to let you decide if you send cookies |
| 10:13 | <bblfish> | that is why chrome has anonymous mode |
| 10:13 | <bblfish> | for example |
| 10:14 | <Hixie> | chrome's anonymous mode is to allow you to "buy gifts for your spouse" without them finding out |
| 10:14 | <jgraham> | Hixie: Different anonymous mode I think |
| 10:14 | <Hixie> | has nothing to do with showing cookies |
| 10:14 | <Hixie> | wait, we have two anonymous modes? |
| 10:15 | <bblfish> | ah. I need to look into anonymous mode. Sorry, I had a talk about that this morning, and thought it also did cookies |
| 10:15 | <bblfish> | but anyway. It would be an idea |
| 10:15 | <jgraham> | Hixie: I man I assume the thing in Account Manager is not just the normal anonymous mode |
| 10:15 | <bblfish> | to be able to choose one's cookie set |
| 10:15 | <jgraham> | Hixie: I could be wrong, I don't really know |
| 10:15 | <Hixie> | i have really no idea what we're talking about any more |
| 10:16 | <bblfish> | in the picture here http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox |
| 10:16 | <jgraham> | Oh, sorry I missed the change of topic to chrome |
| 10:16 | <Hixie> | i thought we were talking about having the site be able to tell the browser that the user was logged in, and for the browser to display that somewhere prominent and pretty |
| 10:16 | <bblfish> | it shows the user logged in as |
| 10:16 | <bblfish> | yes. The web site can do it. But the browser could do that in a secure way |
| 10:16 | <Hixie> | which doesn't add anything to do with security, it's just prettifying the current UI since each page does it differently |
| 10:17 | <bblfish> | Ie: depending on what your browser shows, it would or not send cookies |
| 10:17 | <Hixie> | cookies aren't only about being logged in |
| 10:17 | <bblfish> | so you could select what you want to be logged in as |
| 10:17 | <Hixie> | are you going to break all uses of cookies if you're not logged in? |
| 10:17 | <Hixie> | what if the site supports multiple simultaneous logins? |
| 10:17 | <bblfish> | well if you are not logged in, you get new cookies for your anonymous mode |
| 10:18 | <Hixie> | what if the site doesn't have a concept of user login? |
| 10:18 | <bblfish> | I suppose |
| 10:18 | <Hixie> | but uses something else? |
| 10:18 | <Hixie> | this is again far too confusing to ever make sense to a random user |
| 10:18 | <Hixie> | you really should spend more time in usability studies to get an appreciation of how far this is from how users think |
| 10:18 | <bblfish> | well I am not sure how the Weave team intend this to work in detail |
| 10:19 | <bblfish> | Aza Raskin is a UI guy |
| 10:19 | <bblfish> | I suppose he does see useability studies too |
| 10:20 | <bblfish> | with client side certs this can be just done even better. That's my argument in the blog post anywya. It would also be much simpler |
| 10:21 | <Hixie> | well, let me know when you get to a few million 7-day actives |
| 10:21 | <bblfish> | I think I won't have to ping you when it gets that far |
| 10:21 | <Hixie> | and i'll be happy to retract my pessimism |
| 10:21 | <bblfish> | pessimism should be justified. Otherwise it becomes a habit |
| 10:22 | <bblfish> | :-) |
| 10:22 | <Hixie> | i'm confident it is amply justified here, but i've already said my piece :-) |
| 10:23 | <Hixie> | no need to beat you over the head with it :-) |
| 10:23 | <bblfish> | well, my point is that there have been a few developments that you could not have forseen. |
| 10:23 | <bblfish> | so you will need to re-assess your pessimism |
| 10:24 | <Hixie> | i do not believe anything you have said so far in this conversation is new to me as far as certifications go |
| 10:24 | <Hixie> | certificates, even |
| 10:25 | <bblfish> | ah yes: did you see the potential of being able to login with one self-signed certificate to any number of sites globally, without using CAs? |
| 10:26 | <Hixie> | sure, there's never been a limitation there, it's just not been done before because it's not especially useful or a good idea |
| 10:26 | <zcorpan_> | new framing: http://www.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-01.txt |
| 10:26 | <bblfish> | there was no technical limitation. From the talks on the subject I give around the world, there was a psychological limitation |
| 10:27 | <bblfish> | relating primarly to Distinguished Names coming from X.500 and not being global identitiers |
| 10:27 | <Hixie> | i encourage you to give fewer talks and to spend more time getting it implemented :-) |
| 10:27 | <bblfish> | ie, that is the technical limitation that lead to the impossibility of the intial vision being workable |
| 10:28 | <bblfish> | we have implemetnations in every language http://esw.w3.org/Foaf%2Bssl |
| 10:28 | <Hixie> | if this is as good as you think it is, you won't need talks to get people adopting it |
| 10:28 | <Hixie> | they'll start adopting it before you want them to |
| 10:28 | <Hixie> | as is happening with html5 :-/ |
| 10:28 | <bblfish> | the issue is psychological as I say |
| 10:28 | <bblfish> | but I suppose the html5 wg never meet |
| 10:28 | <jgraham> | zcorpan_: And now people want versioning :( |
| 10:29 | <bblfish> | because it's so good they don't need to? |
| 10:29 | <Hixie> | bblfish: the whatwg has never had a face-to-face meeting or a teleconference meeting |
| 10:29 | <bblfish> | well I travel, because I can too |
| 10:30 | <bblfish> | It's fun to travel, and I get to see the world |
| 10:30 | <bblfish> | discussing this with people in security has been very helpful |
| 10:30 | <bblfish> | email is not always the best medium |
| 10:31 | <bblfish> | it helps understand what their issues are. And they ALWAYS come up with the same issues |
| 10:31 | <zcorpan_> | hmm, -01 doesn't include Hixie's recent changes to the handshake (like subprotocol negotiation) |
| 10:31 | <Hixie> | oh, hey, this means i should strip out websockets from the html spec huh |
| 10:32 | <hsivonen> | zcorpan_: are all the relevant vendors on board with http://www.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-01.txt ? |
| 10:32 | <bblfish> | and they are all related to the X.500 problem in the end. |
| 10:32 | <zcorpan_> | Hixie: could you check with fette about your changes after -00 which don't seem to be included in -01? |
| 10:32 | <jgraham> | zcorpan_: No, see Ian Fette's message |
| 10:32 | <zcorpan_> | hsivonen: no idea |
| 10:33 | <Hixie> | zcorpan_: he said there wasn't consensus on them in the wg, so he wanted to discuss them first |
| 10:33 | <hsivonen> | I had hoped for the protocol to freeze in time for Firefox 4 |
| 10:33 | <jgraham> | hsivonen: It isn't even clear that all the relevant vendors are *participating* |
| 10:34 | <jgraham> | e.g. I don't recall seeing anyone from Mozilla comment recently |
| 10:34 | <zcorpan_> | Hixie: ok |
| 10:35 | <roc> | I thought sayre was commenting |
| 10:35 | <Hixie> | is anyone from microsoft involved? |
| 10:35 | <zcorpan_> | are microsoft implementing websocket? |
| 10:35 | <Hixie> | they sent lots of comments a while back |
| 10:35 | <jgraham> | There is someone from microsoft that has commented a few times at least |
| 10:36 | <jgraham> | Presumably they are quietly implementing, but that is pure speculation |
| 10:36 | <zcorpan_> | Hixie: personally i'd prefer if you didn't nuke websockets from the html spec just yet |
| 10:36 | <jgraham> | roc: He at least posted some messages at the start of the month suggesting to cut scope and keep things simple |
| 10:37 | <jgraham> | Doesn't really seem to have worked |
| 10:37 | <Hixie> | zcorpan_: why? |
| 10:38 | <zcorpan_> | Hixie: because then i don't know where to look. -01 doesn't include the recent changes |
| 10:38 | <Hixie> | nor does the whatwg version |
| 10:38 | <Hixie> | since it doesn't have -01's stuff |
| 10:40 | <zcorpan_> | i guess our impl mostly matches -00 anyway |
| 10:40 | <jgraham> | I don't like the appearance of lots of SHOULDs in the draft |
| 10:41 | <jgraham> | I don't even know what some of them mean "Ping frames MAY be sent as a keep-alive mechanism, but if so the interval SHOULD be configurable. |
| 10:41 | <jgraham> | " |
| 10:41 | <jgraham> | Is that supposed to be a UI requirement? |
| 10:43 | <Hixie> | send feedback to the hybi list |
| 10:44 | <jgraham> | Sure |
| 10:45 | <jgraham> | Just being generally grumpy here first |
| 10:45 | <Hixie> | ian hasn't got much experience writing specs, so feel free to school him in proper use of rfc2119 :-) |
| 10:47 | <Hixie> | btw something to be careful about is checking whether terms in the ptocol spec and the api spec remain in sync |
| 10:47 | <Hixie> | since the two are no longer in the same document i won't get warning when i gen the spec and break xrefs |
| 10:48 | <Hixie> | or when ian breaks them |
| 10:49 | <jgraham> | Am I missing something or is the spec not clear on what happens if you get something that looks like a fragmented message but out of order |
| 10:49 | <bblfish> | anyway, thanks for listening Hixie. I'll go work on some more implementations in the mean time. Btw. WebId can also work with microdata |
| 10:50 | <jgraham> | e.g. just more=0 opcode=0 |
| 11:22 | hsivonen | wonders how much Yellow Box for Windows has been resurrected to enable Safari and iTunes on Windows |
| 13:56 | <MikeSmith> | anybody know, is Anne away on vacation or something? |
| 13:56 | <MikeSmith> | was he around yesterday? |
| 13:57 | <jgraham> | MikeSmith: anne is around |
| 13:57 | <jgraham> | just never at the same time as you |
| 13:58 | <MikeSmith> | ah OK |
| 13:58 | <MikeSmith> | I've just been sleeping |
| 13:58 | <MikeSmith> | because of the summer heat |
| 13:58 | <MikeSmith> | I just sleep all day long |
| 13:58 | <MikeSmith> | and all night long |
| 13:59 | <KaOSoFt> | No offense, but that sounds like anything but a human. |
| 13:59 | <KaOSoFt> | ,_, |
| 13:59 | <MikeSmith> | hey, it's human -- I get up for a couple hours to check my facebook wall |
| 13:59 | <KaOSoFt> | ;_; |
| 14:00 | <MikeSmith> | and send mass "this is the funniest thing I have ever read" e-mail messages with big attachments to all my friends |
| 14:00 | <KaOSoFt> | You don't qualify to human, then. |
| 14:00 | <KaOSoFt> | ._. |
| 14:01 | <MikeSmith> | watch a little youtube, make some xtranormal videos of my own, of teddy bears cursing at each other |
| 14:01 | <KaOSoFt> | That's... enough. |
| 14:01 | KaOSoFt | walks away slowly... |
| 14:01 | <MikeSmith> | basically, pretty much the same stuff all you all are doing |
| 14:01 | <MikeSmith> | the stuff the Web was designed for |
| 14:01 | KaOSoFt | is walking away |
| 14:01 | <KaOSoFt> | >_> |
| 14:02 | MikeSmith | yawns |
| 14:02 | <jgraham> | Teddy bears cursing at each other? |
| 14:03 | <MikeSmith> | yeah |
| 14:03 | <MikeSmith> | it's the funniest thing |
| 14:03 | <KaOSoFt> | That's where I started walking away. |
| 14:03 | <KaOSoFt> | Just me and my cat... |
| 14:03 | <MikeSmith> | you can make the little bears say anything you want |
| 14:03 | <jgraham> | Sounds like Adam Nad Joe |
| 14:03 | <jgraham> | *And |
| 14:04 | <MikeSmith> | http://www.xtranormal.com/ |
| 14:04 | <MikeSmith> | you can choose characters |
| 14:04 | <MikeSmith> | of you're gonna choose the bears |
| 14:04 | <MikeSmith> | I don't know why they even bother to give other choices |
| 14:05 | <MikeSmith> | the bears are all that's needed |
| 14:05 | jgraham | was thinking more of http://www.youtube.com/watch?v=O89IEks9VPo |
| 14:05 | <rubys> | jgraham: any update on anolis? |
| 14:06 | <MikeSmith> | http://nosql.mypopescu.com/post/1016320617/mongodb-is-web-scale |
| 14:06 | <jgraham> | rubys: Not really. I didn;t have any time last night. Hopefully tonight I can test my changes and push them live |
| 14:06 | <rubys> | thanks! |
| 14:06 | <kbrosnan> | red: userChrome.css possibly |
| 14:06 | <kbrosnan> | er |
| 15:42 | <hsivonen> | http://hsivonen.iki.fi/test/moz/move-during-parse-parent.html |
| 15:43 | <hsivonen> | (crashes Chrome content process during reload) |
| 15:44 | <hsivonen> | interestingly, IE9 has been modified from IE8 to specifically support this crazy case |
| 15:44 | <hsivonen> | also, the HTML5 parser in Firefox 4 gets CSS frame construction right |
| 15:45 | <hsivonen> | the old parser moves the node into parent but doesn't let the CSS frame constructor know that they are there |
| 15:45 | <jgraham> | hsivonen: Nice test |
| 15:46 | <jgraham> | BTW it is theoretically possible to make tests like this (modulo the iframe but; but that could be worked around of course) |
| 15:46 | <jgraham> | html5lib tests |
| 15:46 | <jgraham> | no use to html5lib but maybe a convenient format and a good way for browser vendors to share |
| 15:47 | <hsivonen> | I expect Gecko to get things wrong once I add an external script and a style sheet that blocks scripts |
| 15:47 | <jgraham> | convenient in the sense that you already have all the machinary for specifying what the output DOM should look like |
| 15:52 | <zcorpan_> | jgraham: you could make the iframe src a data url, although then it's no longer convenient of course |
| 15:53 | <jgraham> | zcorpan_: Yeah, and you have to teach the comparison code to walk the contentDocument of the iframe |
| 15:53 | <jgraham> | So the case with <iframe>s is quite hard |
| 15:53 | <zcorpan_> | if you care about the dom of the nested document yeah |
| 15:53 | <hsivonen> | as predicted, Gecko fails: both old and new: http://hsivonen.iki.fi/test/moz/move-during-parse-parent2.html |
| 15:54 | <jgraham> | The case with scripts modifying the dom and no iframe is quite easy |
| 15:54 | <hsivonen> | Chromium crashes (content process) |
| 15:54 | <hsivonen> | as does Chrome |
| 15:54 | <zcorpan_> | wonder what ie9 does in xhtml |
| 15:54 | <hsivonen> | Opera works the same |
| 15:55 | <hsivonen> | IE9 doesn't run the alert |
| 15:55 | <jgraham> | Chromium doesn't crash for me |
| 15:55 | <jgraham> | Could be a differnet verion of course |
| 15:55 | <jgraham> | *different |
| 15:55 | <hsivonen> | jgraham: I have Linux 64-bit from yesterday or the day before |
| 15:55 | <hsivonen> | and 64-bit beta channel Chrome |
| 15:55 | <hsivonen> | on Linux |
| 15:56 | <zcorpan_> | crashes for me on reload on mac |
| 15:56 | <zcorpan_> | dev channel |
| 15:56 | <jgraham> | Oh on reload |
| 15:56 | <espadrine> | latest opera doesn't crash, does it? |
| 15:56 | <jgraham> | I though you meant this case crashed on initial load |
| 15:56 | <zcorpan_> | espadrine: no |
| 15:56 | <hsivonen> | espadrine: nope. I meant Opera runs test 2 the same as the first test |
| 15:56 | <jgraham> | Opera doesn't crash for me |
| 15:57 | <espadrine> | Indeed |
| 15:57 | <hsivonen> | I'm calling it a day and will fix Gecko tomorrow |
| 15:57 | <hsivonen> | should be easy enough for external scripts |
| 15:58 | <hsivonen> | and a bit more annoying for style sheets blocking scripts |
| 15:59 | <hsivonen> | the spec should probably say what style sheets that block scripts block when the <link> moves between documents between insertion and the completion of the style sheet load |
| 16:20 | <zcorpan_> | hsivonen: afaict the spec doesn't ban utf-16le, it just requires the encoding to be specified in content-type |
| 16:23 | <zcorpan_> | Hixie: please please please remove the :target styling or at least remove the yellow shadow |
| 16:24 | <espadrine> | Some browsers deal with it better than others |
| 16:24 | <espadrine> | Firefox goes fine |
| 16:24 | <zcorpan_> | my problem is that it distracts me from reading the text |
| 16:24 | <zcorpan_> | not a browser problem |
| 16:24 | <espadrine> | ^^ |
| 16:25 | <zcorpan_> | well i guess if i was using a browser without shadow support then it wouldn't be a problem |
| 17:05 | <tabatkins> | llrcombs: Did you ever figure out your <select multiple> issue? The query string should be consistent across all browsers (test=1&test=2). PHP will normally only let you at the last value, since previous values get overwritten. The solution is to set your @name to have a [] at the end - then the PHP variable will be an array of all the values. |
| 17:06 | <variable> | which leads to some fascinating security issues if you don't expect an array btw ;) |
| 17:09 | <mike][inq> | *security* issues? |
| 17:11 | <variable> | mike][inq, if in PHP you attempt to read variable that you thought was a scalar but really was an array - you can get into some nasty issues |
| 17:11 | <variable> | espically if you use splicing to operating on "one" character at a time |
| 17:12 | <variable> | $_GET["foo"][0]; // I thought this was a string and I was getting the first character but I'm really getting an array |
| 17:12 | <mike][inq> | so you should probably validate your input |
| 17:13 | <mike][inq> | doesn't sound like a security issue, though |
| 17:13 | <variable> | mike][inq, can lead to - doesn't mean it always is one |
| 17:13 | <variable> | mike][inq, I've seen one issue where someone validated their input by going through each character and checking to make sure it was an allowed character at that point.... but it failed when passed an array |
| 18:58 | <annevk> | defined CharacterData methods |
| 18:58 | <annevk> | what a bunch of useless methods by the way |
| 18:58 | <annevk> | make no sense at all in ECMAScript context |
| 19:07 | <Ms2ger> | Yay Acid3 |
| 19:07 | <smaug____> | annevk: defined where? and why do they not make sense in ECMAScript context? (just wondering :) ) |
| 19:08 | <smaug____> | Ms2ger: ? |
| 19:09 | smaug____ | is just fixing an ACID 3 bug |
| 19:09 | smaug____ | hopes that ACID 3 would tests things only the way they are defined in the specs :p |
| 19:11 | <annevk> | smaug____, http://bitbucket.org/ms2ger/web-dom-core/ |
| 19:11 | <annevk> | smaug____, insertData, replaceData, etc. are all not needed and seem kind of pointless if you have immutable strings |
| 19:12 | <smaug____> | annevk: but if you just want to change textnode without replacing them... |
| 19:12 | <smaug____> | textnodes |
| 19:12 | <annevk> | you can just assign data, no? |
| 19:13 | <annevk> | I suppose implementations can have some special kind of string for text nodes that is mutable... |
| 19:13 | <smaug____> | implementations could optimize things... |
| 19:14 | <smaug____> | like not re-generate all the lines |
| 19:14 | <smaug____> | only the ones which changed |
| 19:14 | <annevk> | sure |
| 19:14 | <annevk> | they could also do that if the entire string changed |
| 19:14 | <smaug____> | sure |
| 19:14 | <annevk> | but is that what Mozilla does? |
| 19:14 | <annevk> | it has special optimizations for these methods that nobody uses? |
| 19:15 | <smaug____> | it has some optimizations |
| 19:15 | <smaug____> | apparently |
| 19:15 | <smaug____> | just looking at the code |
| 19:16 | <smaug____> | it does search for the first rendering object which needs to be changed |
| 19:16 | <smaug____> | hmm |
| 19:16 | <annevk> | o_O |
| 19:17 | <annevk> | I have to go now, but if you're interested in helping out writing tests for the Web DOM Core project let me know |
| 19:17 | <annevk> | I'll email public-webapps when I have some more time to write the whole idea down |
| 19:17 | <smaug____> | I mean it doesn't remove and recreate all the objects related to text layout |
| 20:14 | <Hixie> | zcwhat? the :target styling is awesome! makes it really easy to tell what you're supposed to look at! |
| 20:14 | <Hixie> | er, that was supposed to be "zcorpan: what?" but zcorpan is gone |
| 20:14 | <Hixie> | oh well |
| 20:39 | <AryehGregor> | Why do people use the term "regrets" to mean "could not attend"? |
| 20:39 | <AryehGregor> | It vaguely annoys me. |
| 20:39 | <AryehGregor> | Seems like unnecessary jargon. |
| 20:40 | <gavin> | they regret not being able to attend |
| 20:48 | <AryehGregor> | Well, I get the etymology. |
| 20:49 | <Philip`> | What term do you suggest using instead? |
| 20:50 | <AryehGregor> | In the case I was looking at, there was a list of "Attending" and "Regrets". I would have said "Attending" and "Not attending". |
| 20:50 | AryehGregor | can be picky about language, but guesses that's true of most programmers. |
| 20:50 | <AryehGregor> | Another random gripe: why do the HTMLWG and CSSWG often have e-mail subject lines containing an issue number, without any summary of what the issue is about? Are we supposed to memorize all the issue numbers? |
| 20:52 | <Philip`> | "Not attending" seems misleading, unless you want to put seven billion people in the list |
| 20:52 | <Philip`> | You need something to express that someone would have attended but didn't |
| 20:53 | <Steve^> | assuming you regret it |
| 20:54 | <AryehGregor> | It's clear that the latter list only includes people whose non-attendance could not have been taken for granted a priori. |
| 20:54 | <AryehGregor> | Steve^, you can be polite and say you regret it if you don't, I don't mind that part. |
| 21:08 | <AryehGregor> | "If the IANA registry were hard to use because its servers went down on a monthly basis due to being struck by meteors because a former IANA executive was the subject of a gypsy curse, it would still be hard to use, and we would want to look for alternatives." |
| 21:08 | <AryehGregor> | I like colorful phrasing like that, don't you? |
| 21:13 | <Philip`> | So if I understand you right, we should blame gypsies for the status of image/svg+xml? |
| 21:14 | <AryehGregor> | That's one possible interpretation. |
| 21:54 | <jgraham> | Hixie: The :target styling makes it look vaugely like someone vomited on the part of the page that you want to look at |
| 21:55 | <jgraham> | Which is one way of drawing attention to it, but perhaps not the best one |
| 22:02 | <AryehGregor> | Yeah, target styling in the spec is really ugly. |
| 22:04 | <espadrine> | Kind of like the blinking tag... flashy. |
| 22:05 | <espadrine> | But I do like the idea of "knowing immediately where to look" |
| 22:06 | <espadrine> | Maybe a black border 2px wide would be enough for that |
| 22:14 | <AryehGregor> | It would possibly be less annoying if it were a solid color. |
| 22:37 | <Hixie> | jgraham: does it look different in opera or something? looks fine in chrome and firefox... |
| 22:42 | <AryehGregor> | Hixie, by "fine" do you mean "an ugly yellow haze surrounding some part of the page for no obvious reason"? |
| 22:42 | <AryehGregor> | (It took me quite a while to figure out it was :focus.) |
| 22:43 | <Hixie> | i'm certainly open to better ideas, but i have to say i really like it |
| 22:43 | <Hixie> | it's like a spotlight |
| 22:43 | <Hixie> | it's been massively helpful for me |
| 22:43 | <AryehGregor> | I'd go with a paler color and ditch the blur. |
| 22:44 | AryehGregor | experiments |
| 22:44 | <AryehGregor> | Ditch the text-shadow for sure. |
| 22:45 | <espadrine> | black 2px border, maybe? |
| 22:45 | <AryehGregor> | I think it would look much better if you got rid of the text-shadow, and either got rid of or massively toned down the box-shadow. |
| 22:45 | <AryehGregor> | I think a border would interfere. |
| 22:46 | <espadrine> | Maybe a yellow background-color is enough |
| 22:46 | <AryehGregor> | That's my vote, yeah. |
| 22:46 | <AryehGregor> | Just change the background. |
| 22:46 | AryehGregor | is looking at that right now, much better |
| 22:46 | <AryehGregor> | The text-shadow is particularly hideous. |
| 22:46 | <Hixie> | how are you even seeing the text-shadow |
| 22:46 | <Hixie> | i only used that to make the colours work better |
| 22:47 | <AryehGregor> | It looks like an ugly blur around all the text. |
| 22:47 | <AryehGregor> | It looks way crisper if I ditch it. |
| 22:47 | <AryehGregor> | Also, the shadow doesn't match the color of the background. Shadow is yellow, background is #FFA. |
| 22:47 | <AryehGregor> | There's a clear boundary between them. |
| 22:47 | <AryehGregor> | I vote we enlist an actual designer. |
| 22:47 | <jgraham> | Also, the yellow and green are a bit much |
| 22:47 | AryehGregor | lassos tabatkins |
| 22:48 | <AryehGregor> | What green? Should I be thankful I'm not seeing any green? |
| 22:48 | <jgraham> | Dude he is like a cowboy |
| 22:48 | <jgraham> | The green of the rest of the page |
| 22:48 | <AryehGregor> | Oh. |
| 22:48 | jgraham | assumes all people from Texas are naturally born cowboy even if they have never left the city |
| 22:48 | <AryehGregor> | The rest of the page is mostly black on white, so I think it's okay. |
| 22:49 | AryehGregor | agrees with jgraham |
| 22:49 | AryehGregor | always treats his friends from Kansas like that, even though they're from Kansas City, which has a population >1 million |
| 22:49 | <cheeser> | that's a big farm... |
| 22:50 | <AryehGregor> | (To be fair to me, they do have broken cars sitting on their untrimmed lawn all the time, plus an unhealthy interest in firearms and explosives, and other distinguishing features of rubes.) |
| 23:51 | <Philip`> | http://code.google.com/edu/ajax/tutorials/intro-to-js.html |
| 23:51 | <Philip`> | http://code.google.com/edu/ajax/tutorials/samples/dhtmltest.html |
| 23:51 | <Philip`> | What century was this written in? |
| 23:52 | <Philip`> | At least they've been thoughtful enough to handle the case of browsers that don't implement document.getElementById |