| 14:44 | <hsivonen> | whoa! WebKit nightlies can already animate an element to full screen |
| 14:44 | <hsivonen> | when has that landed and has it been proposed to the CSS WG or any WG? |
| 14:44 | <Lachy> | hsivonen, how? |
| 14:45 | <hsivonen> | Lachy: I didn't go through view source yet |
| 14:45 | <Lachy> | demo? |
| 14:45 | <hsivonen> | Lachy: http://jilion.com/sublime/video |
| 14:46 | <Lachy> | oh, that's just full window zooming, not full screen |
| 14:46 | <hsivonen> | Lachy: alt-click in a nightly for full screen |
| 14:46 | <Lachy> | I suspect it's done with CSS transitions or CSS animations |
| 14:47 | <hsivonen> | Lachy: see docs on the page |
| 14:49 | <Lachy> | I guess my webkit version is a few days too old. |
| 14:49 | <Lachy> | upgrading now, will see if that works |
| 14:50 | <hsivonen> | webkitEnterFullScreen |
| 14:50 | <hsivonen> | http://code.google.com/p/chromium/issues/detail?id=16735#c30 |
| 14:50 | <Lachy> | nice. webkitEnterFullScreen() |
| 14:51 | <hsivonen> | 2009-11-12 Eric Carlson <eric.carlson⊙ac> |
| 14:51 | <Lachy> | I've long argued that we should drop that restriction in HTML5, and the bogus security note, about entering full screen |
| 14:51 | <Rik|work> | this demo uses webkit transitions |
| 14:52 | <hsivonen> | yay. secret rdar bug |
| 14:52 | <hsivonen> | Rik|work: how is the transition specified? |
| 14:52 | <hsivonen> | also, what's the UI spoofing security story for this stuff? |
| 14:52 | <zcorpan> | <source title='http://d31j8lt3uybmqs.cloudfront.net/sublimevideo/dartmoor.mp4'; type='video/mp4' /> - poor man's preload='none'? |
| 14:53 | <Rik|work> | with CSS transitions set in JS |
| 14:53 | <Lachy> | full screen doesn't work for me in the latest webkit on Mac |
| 14:53 | hsivonen | wonders if there's a spec |
| 14:54 | <hsivonen> | oddly, it's only for HTMLMediaElement |
| 14:54 | <hsivonen> | not for Element |
| 14:54 | <hsivonen> | but still, the overlaid custom controls are supported |
| 14:55 | <Lachy> | hsivonen, which platform are you using? |
| 14:55 | <Rik|work> | hsivonen: after running the full window version, I have -webkit-transition: -webkit-transform; set on the <video> style attribute |
| 14:56 | <Rik|work> | but I don't know how the alt+click triggers the full screen mode |
| 14:57 | <hsivonen> | Lachy: Snow Leopard |
| 14:57 | <Rik|work> | and the minified JS is not helping |
| 14:58 | <hsivonen> | Rik|work: seems to call webkitEnterFullScreen() on the video element |
| 15:00 | <hsivonen> | WebKit sure has long changeset messages |
| 15:00 | <Lachy> | hsivonen, ok. It's not working for me on Leopard. I'll try Snow Leopard later. It works on Windows though |
| 15:00 | <Rik|work> | didn't know there is a function for that |
| 15:01 | <hsivonen> | hmm. platform/mac-tiger/Skipped |
| 15:01 | <hsivonen> | does WebKit still support pre-Tiger Mac OS X? |
| 15:02 | <hsivonen> | http://trac.webkit.org/changeset/50893 |
| 15:03 | <AryehGregor> | Strict-Transport-Security: max-age=500 |
| 15:03 | <AryehGregor> | What kind of useless STS header is that? 500 seconds? |
| 15:03 | <AryehGregor> | I leave the tab open for ten minutes and MITM starts working again? |
| 15:04 | <AryehGregor> | It should be six months or something. Then browsers could ship it in a fixed list and avoid the bootstrapping problem. |
| 15:11 | <hsivonen> | what happens if an attacker spoofs DNS and sets a long STS time to live on a bogus cert? |
| 15:11 | <hsivonen> | will users then be locked out of the real service for a long time? |
| 15:11 | <AryehGregor> | He'd have to get a bogus cert first. |
| 15:11 | <AryehGregor> | In that case, you lose anyway. |
| 15:11 | <Rik|work> | hsivonen: webkitEnterFullScreen seems to be protected, I can't call it in the console, I think it's only available in an onclick event |
| 15:11 | <AryehGregor> | In theory, though, yeah, sure. |
| 15:12 | <AryehGregor> | You can probably manage your STS settings somewhere, though. |
| 15:12 | <hsivonen> | AryehGregor: isn't the CA lock feature's whole point that getting a bogus cert is a real threat scenario |
| 15:12 | <AryehGregor> | Rik|work, I should hope so! |
| 15:12 | <Rik|work> | yeah, document.querySelector('video').webkitEnterFullScreen(); doesn't work |
| 15:12 | <Rik|work> | but window.onclick = function () {document.querySelector('video').webkitEnterFullScreen()} works |
| 15:13 | <AryehGregor> | hsivonen, no, the whole point of STS is 1) attackers could intercept an HTTP request (e.g., from typing "paypal.com" into URL bar) before it gets promoted to HTTPS, 2) users can click through normal cert warnings, but not if STS is set. |
| 15:13 | <hsivonen> | Rik|work: yay for APIs that modify behavior depending on call stack |
| 15:13 | <AryehGregor> | hsivonen, well, popup windows already do that. |
| 15:13 | <Rik|work> | it throws Error: INVALID_STATE_ERR: DOM Exception 11 otherwise |
| 15:13 | <hsivonen> | AryehGregor: is the CA lock feature different from STS then? |
| 15:14 | <hsivonen> | AryehGregor: I'm pretty sure one of the strict SSL things that are emerging had a CA lock feature |
| 15:14 | <AryehGregor> | I think that's being left out of the first draft. |
| 15:14 | <AryehGregor> | http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-strict-transport-sec-05.plain.html#strict-transport-security-http-response-header-field |
| 15:14 | <hsivonen> | oh ok |
| 15:15 | <AryehGregor> | It would be even better, IMO, if you could lock it to your own organization's private key. That way you could switch CAs if you wanted. |
| 15:15 | <AryehGregor> | But let's start with the basics, making SSL actually effectively prevent MITM. :) |
| 15:16 | <hsivonen> | my bank uses EV when I log in through their front door to do banking |
| 15:16 | <hsivonen> | but they don't use EV when a merchant redirects to them for payment |
| 15:16 | <hsivonen> | FAIL |
| 15:16 | <AryehGregor> | EV isn't good for much anyway, as far as I can tell. |
| 15:17 | <AryehGregor> | I mean, it relies on what, someone actually clicking on some icon to show the certificate details? |
| 15:17 | <hsivonen> | AryehGregor: well, yeah, but if a bank is going to use EV at all, they should use it all the time and *especially* when the user enters through someone else's site |
| 15:18 | <hsivonen> | Paypal seems to get it |
| 15:18 | <hsivonen> | banks not so much |
| 15:18 | <hsivonen> | but even Paypal uses autocomplete='off' |
| 15:18 | <hsivonen> | which doesn't make sense |
| 15:18 | <AryehGregor> | Paypal is an online-only operation, it's typical that those have much more tech savvy than a brick-and-mortar place that also happened to put up a website. |
| 15:18 | <AryehGregor> | Why doesn't it make sense? |
| 15:19 | <hsivonen> | because my browser is better at telling if it is refilling a form on the real paypal.com than I am |
| 15:19 | <AryehGregor> | The point is so that it doesn't save the password where someone can look it up by clicking Preferences -> Privacy -> Show Saved Passwords or whatever. |
| 15:19 | <AryehGregor> | Although you're right that autofilling is a cue that you're on the right site. |
| 15:20 | <hsivonen> | I have a greasemonkey script that fixes that for me when I enter through paypal.com |
| 15:20 | <AryehGregor> | It should probably autofill the username but not the password, does it do that? |
| 15:20 | <hsivonen> | but for some reason, the script fails when I enter through the French front of Paypal |
| 15:20 | <hsivonen> | AryehGregor: no |
| 15:20 | <AryehGregor> | Oh well. |
| 15:20 | <hsivonen> | they can't control my Webmail autofill |
| 15:21 | <hsivonen> | and email is the single point of failure anyway |
| 15:21 | <AryehGregor> | The entire concept of passwords is broken anyway. |
| 15:21 | <hsivonen> | so unless they want to send me a one-time pad, they shouldn't bother with the autofill=off nonsense |
| 15:21 | <AryehGregor> | Failure of e-mail won't break PayPal, they require more than just an e-mail to do password resets. I think. My mother's account was recently disabled for some reason and I had to take a phone call to get it reset. |
| 15:21 | <hsivonen> | also, it's not good to make me carry the Paypal password on a piece of paper |
| 15:22 | <AryehGregor> | Passwords are really stupid, we should be logging in using some kind of public-key infrastructure where the private key isn't actually exposed to a programmable computer at any point. |
| 15:23 | <AryehGregor> | Like it's in a USB device that only provides an API to the computer to let it encode or decode things using the private key, but doesn't actually tell it what it is, so you need the physical device to use the key. |
| 15:23 | <AryehGregor> | That could replace all passwords and make it impossible to steal someone's login remotely, whether with phishing or anything else. |
| 15:23 | <AryehGregor> | But it would require a whole bunch of infrastructure. |
| 15:25 | <Philip`> | Everyone would lose their devices |
| 15:25 | <Philip`> | Also, it would make it too hard to share your login details with somebody else |
| 15:26 | <TabAtkins> | Password on brain states. You just have to wait for ubiquitous persocom implants, and mind emulation. |
| 15:26 | <hsivonen> | AryehGregor: hardware dongles FAIL for compatibility reasons |
| 15:26 | <TabAtkins> | Implementation details, really. |
| 15:27 | <AryehGregor> | Philip`, you can get around the "losing" part by entrusting a master copy to someone who won't lose it, like your bank vault. And have some setup where you can reclaim your accounts even if you lose the device, just like you can reclaim accounts if you forget the password today. |
| 15:27 | <AryehGregor> | Philip`, sharing login details is best accomplished by some form of explicit delegation, not just giving them your login. But you could share private keys with someone too. |
| 15:28 | <AryehGregor> | hsivonen, what? |
| 15:28 | <AryehGregor> | TabAtkins, once you have mind emulation, couldn't you use that to emulate the brain states? :) |
| 15:28 | <Philip`> | If you e.g. are in a business and need to process some financial transaction before the end of the day but the only person who is able to authorise it is on holiday, it's far easier if you just ask them for their login name and password before they leave |
| 15:28 | <AryehGregor> | Also, what's to prevent playback attacks? |
| 15:28 | <AryehGregor> | Replay attacks, I mean. |
| 15:29 | <TabAtkins> | AryehGregor: Not without the consent of the mind-state, obviously. And if you can do that, you can force the real person to give up whatever authent mechanism is used as well. |
| 15:29 | <AryehGregor> | Philip`, you're making assumptions about how easy it would be to delegate here. |
| 15:29 | <Philip`> | and that's a situation where normal people can understand the security model and risks, so it's probably going to be better than some complex fancy delegation system that's theoretically much more secure |
| 15:29 | <TabAtkins> | At least mind-states know that they're just copies. |
| 15:30 | <AryehGregor> | Meh, it would be a black box. You train people to do it and they can do it. The dongle is a magical device that lets them log in, don't let anyone else have it. If they want to let someone else use their account, they can make a file to send to them by clicking through a friendly GUI. |
| 15:30 | <AryehGregor> | It's a lot less complicated than many other things people have to do every day. |
| 15:30 | <AryehGregor> | Plus, normal people hate passwords and would welcome a bit of extra complexity if it meant they didn't have to use them. |
| 15:31 | <AryehGregor> | (geeks also hate passwords, of course) |
| 15:43 | <hsivonen> | AryehGregor: hardware dongles are OK if they show you a number and you write it into your device |
| 15:44 | <hsivonen> | AryehGregor: handware dongles that connect to your computing device are bad, because: |
| 15:44 | <hsivonen> | 1) people think they are more secure than the Windows malware signing stuff as you |
| 15:44 | <hsivonen> | 2) they limit competetition between desktop OSs, because driver availability for Mac and Linux will suck |
| 15:45 | <hsivonen> | 3) they don't work with your portable device that doesn't have the right interface form factor |
| 15:45 | <hsivonen> | so smart cards and USB dongles are bad |
| 15:45 | <AryehGregor> | 1) You mean like the things that cycle through new numbers every minute? Do those actually work if you don't want the one receiving the number to be able to figure out what the next number is? I always thought client and server were just running the same PRNG with the same seed, so it's basically a shared secret, which isn't as good as a public key. |
| 15:46 | <hsivonen> | Finland has wasted enormous amounts of tax payer money on a smart card system |
| 15:46 | <AryehGregor> | 2, 3) Just make it a USB standard, say, like mass storage devices. Portable devices usually have one of the mini-USB things, don't they? |
| 15:46 | <hsivonen> | AryehGregor: RSA has number generators. I don't know what their properties are and if they require you to trust your identity broker |
| 15:46 | <hsivonen> | AryehGregor: cheap phones don't have USB host mode |
| 15:47 | <AryehGregor> | Also, how long would the number have to be for real security? RSA normally relies on public keys that are a few thousand bits . . . |
| 15:47 | <AryehGregor> | hsivonen, they could pretty easily. I never said this wouldn't require infrastructure changes, that's the major problem with it. |
| 15:47 | <hsivonen> | anyway, the enormously expensive smart card system in Finland is a massive FAIL |
| 15:47 | <hsivonen> | and what really works is one-time pads (on paper) |
| 15:48 | <hsivonen> | and banks that issue the pads working as identity broker back ends |
| 15:48 | Philip` | 's bank has a thing where you have to put your card and PIN number into a device, then enter a number from the web site and type the result back into the site |
| 15:48 | <Philip`> | so it's not a PRNG thing |
| 15:48 | <hsivonen> | and a government site acting as a broker that connects identity consumers with the banks so that you don't need n times m integration |
| 15:48 | <AryehGregor> | Philip`, interesting. |
| 15:49 | <hsivonen> | anyway, the value added by an RSA thingy compared to a paper OTP is likely low |
| 15:49 | <TabAtkins> | So basically a government-run openid server? |
| 15:49 | <Philip`> | (The card is the important component, the devices are all the same) |
| 15:49 | <hsivonen> | TabAtkins: not OpenID, but kinda |
| 15:49 | <hsivonen> | say you want to check your pension situation |
| 15:49 | <TabAtkins> | Yeah, not the specific technology. Just making an analogy. |
| 15:49 | <hsivonen> | so you go to the pension site |
| 15:49 | <hsivonen> | it redirects you to the identity broker |
| 15:50 | <hsivonen> | the identity broker supports the smart card stuff |
| 15:50 | <hsivonen> | but no one uses it |
| 15:50 | <hsivonen> | so instead, you click the logo of your bank |
| 15:50 | <hsivonen> | get forwarded to your bank |
| 15:50 | <hsivonen> | give a number from your OTP to the bank |
| 15:50 | <hsivonen> | the bank redirects you to the broker |
| 15:50 | <hsivonen> | and the broker redirects you to the pension site |
| 15:51 | <hsivonen> | and the pension site gets your personal ID number |
| 15:51 | <hsivonen> | everyone has the ID number anyway |
| 15:51 | <hsivonen> | assigned at birth |
| 15:52 | <hsivonen> | or when becoming a resident if not born here |
| 15:53 | <hsivonen> | works with any browser |
| 15:53 | <hsivonen> | no hardware dongles |
| 15:53 | <hsivonen> | no barriers to launching new software or hardware browsing platforms |
| 15:53 | <hsivonen> | no South Korea situation |
| 15:54 | <TabAtkins> | Well, the government has to recognize you as an identity backend. |
| 15:54 | <TabAtkins> | But that's it, I guess. And backends can then use whatever stuff they want to id you. |
| 15:55 | <AryehGregor> | OTP? |
| 15:56 | <hsivonen> | one-time pad |
| 15:59 | Philip` | thought it was usually "one-time password" in this context |
| 15:59 | <hsivonen> | there's a whole pad of them |
| 15:59 | <hsivonen> | Wikipedia upholds my usage: http://en.wikipedia.org/wiki/OTP |
| 16:00 | <AryehGregor> | Interesting. |
| 16:00 | <hsivonen> | hmm. except http://en.wikipedia.org/wiki/One-time_pad seems to say the pad is a cipher |
| 16:00 | <hsivonen> | Philip`: so yeah, one-time password |
| 16:01 | <AryehGregor> | Right, a one-time pad is definitely a cipher. |
| 16:02 | <AryehGregor> | One-time passwords would be awkward to type in all the time, though. Fine for occasional use, but not for every time you log into your e-mail account. |
| 16:02 | <AryehGregor> | Passwords are a lousy tradeoff between convenience and security, they're both inconvenient and insecure. |
| 16:04 | <Sidnicious> | To quote Dan K., "passwords are used because they scale well, one at a time." |
| 16:05 | <hsivonen> | AryehGregor: if you can't trust your computer with your passwords and have a USB crypto dongle, wouldn't you have to enter a pin into the dongle to allow crypto operations at specific times? |
| 16:05 | <Sidnicious> | There's almost zero effort required to "secure" an account with a password. |
| 16:05 | <hsivonen> | AryehGregor: that's how those FAILed smart cards worked |
| 16:05 | <hsivonen> | AryehGregor: otherwise, your untrusted computer can poke at the dongle and perform actions as you |
| 16:06 | <hsivonen> | AryehGregor: just like untrusted software that hijacks your passwords on your computer can do |
| 16:06 | <AryehGregor> | hsivonen, it can only impersonate you as long as the crypto thing is in the machine. As opposed to forever. |
| 16:07 | <hsivonen> | AryehGregor: so you'd plug and unplug it all the time? |
| 16:08 | <AryehGregor> | Hmm. |
| 16:08 | <AryehGregor> | It's all very annoying, I guess. There's no easy solution short of, let's say, unsurmountable biometrics plus hardware DRM, all dirt-cheap. |
| 16:08 | <AryehGregor> | (unbreakable hardware DRM, obviously) |
| 16:10 | <Philip`> | It'd be a boring world if there easy perfect solutions to problems |
| 16:10 | <Philip`> | Much better when it's all about tradeoffs |
| 16:15 | <Sidnicious> | The solution to the dongle problem would be a physical button on the device that you press to enable it for a single transaction. |
| 16:16 | <TabAtkins> | What if malware sends transaction requests at the same time as your bank? |
| 16:16 | <Sidnicious> | Hrm. |
| 16:17 | <Philip`> | Mechanical buttons sound bad for cost and reliability |
| 16:17 | <TabAtkins> | Well, you need buttons if you want the "type in the code" thing anyway. |
| 16:18 | <Philip`> | True |
| 16:19 | <Sidnicious> | Lemme butt in with a quick spec question... is anyone familiar with why forminput and formchange events don't bubble? |
| 16:19 | Philip` | used to use a computer where the only USB ports were on the back, with a large desk between him and the machine, so USB dongles would be pretty inconvenient |
| 16:19 | <Sidnicious> | (<http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#event-dispatch>;) |
| 16:19 | <Philip`> | Clearly they should be wireless |
| 16:20 | <Philip`> | Sidnicious: Seems like not bubbling is the default behaviour |
| 16:20 | <Philip`> | Why should they bubble? |
| 16:20 | <Sidnicious> | Event delegation. |
| 16:22 | <Philip`> | Can't you do that with capturing instead? |
| 16:28 | <Sidnicious> | TBH I've been spoiled by using jQuery for all my event-related work in recent memory. It only supports binding to the bubbling phase, except in a couple of special cases. |
| 16:29 | <Sidnicious> | If capturing works just as well, I guess the libraries'll adapt. |
| 16:30 | <Philip`> | Hmm, strange that jQuery wouldn't support event capture |
| 16:30 | <Dashiva> | IE compat, surely |
| 16:31 | <Philip`> | Does IE not have any equivalent to capture? |
| 16:32 | <Dashiva> | I don't believe so |
| 16:33 | <Philip`> | That might explain it then |
| 16:34 | <Sidnicious> | All right. |
| 19:28 | <Dashiva> | I don't have any facts to back me up, but it is my impression that the people who participate in the telcons are already quite well informed and active on the mailing list |
| 20:03 | <jgraham> | Dashiva: I recall noticing people at telecons who have rarely posted to the mailing list |
| 20:07 | <Philip`> | Do they contribute in other ways? |
| 20:08 | <Philip`> | (It's not so useful having people well informed if they don't do anything with their informedness) |
| 20:12 | <john_fallows> | is websocket-protocol of empty string supported by draft-hixie-thewebsocketprotocol-68 ? |
| 20:13 | <john_fallows> | section 5.1 seems to indicate that server must send back empty string for /subprotocol/ when websocket-protocol header in client handshake is empty string (because it is non-null) |
| 20:15 | <Hixie> | how do you mean by "supported"? |
| 20:15 | <john_fallows> | i meant permitted by the specification |
| 20:15 | <john_fallows> | actually, as i'm trying to explain it, i found something relevant |
| 20:16 | <Hixie> | the API won't accept it |
| 20:16 | <john_fallows> | if there are any entries in the /headers/ list whose names are the empty string |
| 20:16 | <Hixie> | but if a (non-browser) client sends it, the server defines what should happen |
| 20:16 | <john_fallows> | this is for names, not values |
| 20:16 | <john_fallows> | yep, that's fine |
| 20:16 | <Hixie> | er, the protocol spec defines what should happen on the server, i mean |
| 20:17 | <john_fallows> | i think there might be a section further up that states the subprotocol value should be non-null and non-empty |
| 20:17 | <john_fallows> | yep, got it |
| 20:17 | <Hixie> | i guess i don't know what you mean by "permitted by the specification" |
| 20:17 | <Hixie> | which specification? there are two |
| 20:17 | <Hixie> | the API? the protocol? |
| 20:17 | <Hixie> | sent by the client? by the server? |
| 20:17 | <john_fallows> | sorry, i was discussing the wire protocol spec draft-hixie-thewebsocketprotocol-68 |
| 20:17 | <Hixie> | client->server? server->client? |
| 20:19 | <john_fallows> | the description of section 5.1 "Sending the server's handshake" /subprotocol/ says... |
| 20:19 | <john_fallows> | "Either null, or a string representing the subprotocol the server is ready to use." |
| 20:19 | <john_fallows> | ... |
| 20:19 | <john_fallows> | "The empty string is not the same as the null value for these purposes." |
| 20:19 | <john_fallows> | i read that to mean empty string was permitted, but it is not, as described elsewhere in the document |
| 20:20 | <Hixie> | there's no concept of what is permitted from the server in the subprotocol name |
| 20:20 | <Hixie> | the server just sends back what the client sends |
| 20:21 | <Hixie> | if the client sent the empty string, then the server will send the empty string |
| 20:22 | <Hixie> | (assuming it wants to accept the connection) |
| 20:22 | <john_fallows> | understood |
| 20:23 | <john_fallows> | so the constraint of non-empty protocol name is for client only, as described by section 4.1 Handshake (in section 4 Client-side requirements) |
| 20:23 | <john_fallows> | "The /resource name/ and /protocol/ strings must be non-empty strings of ASCII characters in the range U+0020 to U+007E." |
| 20:23 | <john_fallows> | ? |
| 20:24 | <Hixie> | right |
| 20:24 | <Hixie> | and the API also restricts it |
| 20:24 | <john_fallows> | ok, now it makes sense |
| 20:25 | <john_fallows> | the difference in strictness between client and server caused my temporary confusion :-) |
| 20:26 | <Hixie> | in practice there's no reason for a server to support the subprotocol "", since compliant clients can't send it |
| 20:26 | <john_fallows> | yes, agreed. |
| 20:27 | <john_fallows> | btw, i have some feedback regarding delivery of binary WebSocket frame payloads to JavaScript |
| 20:27 | <john_fallows> | should i send an email to the mailing list? |
| 20:27 | <Hixie> | yes please |
| 20:28 | <Hixie> | for binary i'm basically waiting for the text stuff to be widely implemented first though |
| 20:28 | <Hixie> | baby steps |
| 20:28 | <Hixie> | (also waiting for JS to have binary support) |
| 20:29 | <john_fallows> | i suspect that waiting for JS to have binary support is unnecessary and will explain the proposal in the email |
| 20:31 | <Hixie> | i think it's likely that JS binary support will come long before websocket is widely supported |
| 20:31 | <Hixie> | so it might be a moot point |
| 20:32 | <john_fallows> | that would be wonderful, will send the proposal and then we can discuss it |
| 20:33 | <john_fallows> | btw, I'll be at Google HQ later this afternoon, would like to stop by to say hi if you are around. |
| 20:33 | <Hixie> | =========================================== |
| 20:34 | <Hixie> | sure |
| 20:34 | <Hixie> | dunno when i'll get in, but i'll be on IRC so we can coordinate here |
| 20:34 | <john_fallows> | sure, or if you email me your phone number, i can give you a call when my meeting is done |
| 20:37 | <Hixie> | don't have a phone |
| 20:40 | <john_fallows> | hope to see you later, bye for now. |
| 20:46 | <Hixie> | later |
| 21:37 | <john_r_fallows> | Hixie: sent the WebSocket binary frame proposal to the mailing list - http://lists.w3.org/Archives/Public/public-html-comments/2010Jan/0009.html |