/irc-logs / freenode / #whatwg / 2010-01-27 / end

Options:

  1. # Session Start: Wed Jan 27 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [14:39] * Attempting to rejoin channel #whatwg
  4. # [14:39] * Rejoined channel #whatwg
  5. # [14:39] * Topic is 'WHATWG: http://www.whatwg.org/ -- logs: http://krijnhoetmer.nl/irc-logs/ -- stats: http://gavinsharp.com/irc/whatwg.html -- Please leave your sense of logic at the door, thanks!'
  6. # [14:39] * Set by annevk42 on Mon Oct 19 22:03:06
  7. # [14:39] * Quits: ray (i=ray@drong.notacat.org) (leguin.freenode.net irc.freenode.net)
  8. # [14:39] * Quits: syp (n=syp@lasigpc9.epfl.ch) (leguin.freenode.net irc.freenode.net)
  9. # [14:39] * Quits: gsnedders (n=gsnedder@204.232.194.186) (leguin.freenode.net irc.freenode.net)
  10. # [14:39] * Quits: tiglionabbit (n=nick@67-207-136-95.slicehost.net) (leguin.freenode.net irc.freenode.net)
  11. # [14:39] * Quits: Philip` (n=philip@zaynar.co.uk) (leguin.freenode.net irc.freenode.net)
  12. # [14:39] * Quits: hober (n=ted@unaffiliated/hober) (leguin.freenode.net irc.freenode.net)
  13. # [14:39] * Quits: shepazu (n=schepers@adsl-150-130-9.rmo.bellsouth.net) (leguin.freenode.net irc.freenode.net)
  14. # [14:39] * Quits: sebmarkbage (n=miranda@213.80.108.29) (leguin.freenode.net irc.freenode.net)
  15. # [14:39] * Quits: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com) (leguin.freenode.net irc.freenode.net)
  16. # [14:39] * Joins: tigliona1bit (n=nick@67-207-136-95.slicehost.net)
  17. # [14:39] * Joins: syp_ (n=syp@lasigpc9.epfl.ch)
  18. # [14:40] * Joins: gsnedder1 (n=gsnedder@204.232.194.186)
  19. # [14:40] * Joins: Philip` (n=philip@zaynar.co.uk)
  20. # [14:40] * Joins: ray (i=ray@drong.notacat.org)
  21. # [14:42] * Joins: TabAtkins (n=chatzill@70-139-15-246.lightspeed.rsbgtx.sbcglobal.net)
  22. # [14:57] * Joins: Chris|UNC (n=blahness@152.2.194.196)
  23. # [15:00] * Quits: takoratta (n=takoratt@202.171.161.131) (Client Quit)
  24. # [15:00] * Chris|UNC is now known as Chris|Work
  25. # [15:00] * Quits: Chris|Work (n=blahness@152.2.194.196) (Client Quit)
  26. # [15:01] * Joins: ChrisLTD|Work (n=blahness@152.2.194.196)
  27. # [15:07] * Quits: MikeSmith (n=MikeSmit@EM114-48-82-170.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  28. # [15:08] * Joins: MikeSmith (n=MikeSmit@EM114-48-82-170.pool.e-mobile.ne.jp)
  29. # [15:10] * Joins: BlurstOfTimes (n=blurstof@168.203.117.66)
  30. # [15:10] * Quits: MikeSmith (n=MikeSmit@EM114-48-82-170.pool.e-mobile.ne.jp) (Client Quit)
  31. # [15:10] * Joins: MikeSmith (n=MikeSmit@EM114-48-82-170.pool.e-mobile.ne.jp)
  32. # [15:13] * Quits: hish (n=chatzill@p57B7F29F.dip.t-dialin.net) (Remote closed the connection)
  33. # [15:14] * Quits: danbri (n=danbri@unaffiliated/danbri) (Read error: 110 (Connection timed out))
  34. # [15:17] * Quits: MikeSmith (n=MikeSmit@EM114-48-82-170.pool.e-mobile.ne.jp) ("Tomorrow to fresh woods, and pastures new.")
  35. # [15:17] * Joins: MikeSmith (n=MikeSmit@EM114-48-82-170.pool.e-mobile.ne.jp)
  36. # [15:19] * Quits: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com) (Remote closed the connection)
  37. # [15:22] * Joins: danbri (n=danbri@ip176-48-210-87.adsl2.static.versatel.nl)
  38. # [15:22] * Joins: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com)
  39. # [15:31] * Joins: miketaylr (n=miketayl@38.117.156.163)
  40. # [15:34] * Joins: vvv (n=vvv@mediawiki/VasilievVV)
  41. # [15:46] * Joins: shepazu (n=schepers@adsl-150-130-9.rmo.bellsouth.net)
  42. # [15:52] <hsivonen> whoa! WebKit nightlies can already animate an element to full screen
  43. # [15:52] <hsivonen> when has that landed and has it been proposed to the CSS WG or any WG?
  44. # [15:52] <Lachy> hsivonen, how?
  45. # [15:53] <hsivonen> Lachy: I didn't go through view source yet
  46. # [15:53] <Lachy> demo?
  47. # [15:53] <hsivonen> Lachy: http://jilion.com/sublime/video
  48. # [15:54] <Lachy> oh, that's just full window zooming, not full screen
  49. # [15:54] <hsivonen> Lachy: alt-click in a nightly for full screen
  50. # [15:54] <Lachy> I suspect it's done with CSS transitions or CSS animations
  51. # [15:55] <hsivonen> Lachy: see docs on the page
  52. # [15:57] <Lachy> I guess my webkit version is a few days too old.
  53. # [15:57] <Lachy> upgrading now, will see if that works
  54. # [15:58] <hsivonen> webkitEnterFullScreen
  55. # [15:58] <hsivonen> http://code.google.com/p/chromium/issues/detail?id=16735#c30
  56. # [15:58] <Lachy> nice. webkitEnterFullScreen()
  57. # [15:58] * Quits: paul_irish (n=paul_iri@c-71-192-163-128.hsd1.nh.comcast.net) ("Leaving...")
  58. # [15:59] <hsivonen> 2009-11-12 Eric Carlson <eric.carlson@apple.com>
  59. # [15:59] <Lachy> I've long argued that we should drop that restriction in HTML5, and the bogus security note, about entering full screen
  60. # [15:59] <Rik|work> this demo uses webkit transitions
  61. # [16:00] <hsivonen> yay. secret rdar bug
  62. # [16:00] <hsivonen> Rik|work: how is the transition specified?
  63. # [16:00] <hsivonen> also, what's the UI spoofing security story for this stuff?
  64. # [16:00] <zcorpan> <source title='http://d31j8lt3uybmqs.cloudfront.net/sublimevideo/dartmoor.mp4' type='video/mp4' /> - poor man's preload='none'?
  65. # [16:01] <Rik|work> with CSS transitions set in JS
  66. # [16:01] <Lachy> full screen doesn't work for me in the latest webkit on Mac
  67. # [16:01] * hsivonen wonders if there's a spec
  68. # [16:02] <hsivonen> oddly, it's only for HTMLMediaElement
  69. # [16:02] <hsivonen> not for Element
  70. # [16:02] <hsivonen> but still, the overlaid custom controls are supported
  71. # [16:03] <Lachy> hsivonen, which platform are you using?
  72. # [16:03] <Rik|work> hsivonen: after running the full window version, I have -webkit-transition: -webkit-transform; set on the <video> style attribute
  73. # [16:04] <Rik|work> but I don't know how the alt+click triggers the full screen mode
  74. # [16:05] <hsivonen> Lachy: Snow Leopard
  75. # [16:05] <Rik|work> and the minified JS is not helping
  76. # [16:06] <hsivonen> Rik|work: seems to call webkitEnterFullScreen() on the video element
  77. # [16:08] <hsivonen> WebKit sure has long changeset messages
  78. # [16:08] <Lachy> hsivonen, ok. It's not working for me on Leopard. I'll try Snow Leopard later. It works on Windows though
  79. # [16:08] <Rik|work> didn't know there is a function for that
  80. # [16:09] <hsivonen> hmm. platform/mac-tiger/Skipped
  81. # [16:09] <hsivonen> does WebKit still support pre-Tiger Mac OS X?
  82. # [16:10] <hsivonen> http://trac.webkit.org/changeset/50893
  83. # [16:10] * Quits: GarethAdams|Work (n=GarethAd@pdpc/supporter/active/GarethAdams)
  84. # [16:10] * gsnedder1 is now known as gsnedders
  85. # [16:11] <AryehGregor> Strict-Transport-Security: max-age=500
  86. # [16:11] <AryehGregor> What kind of useless STS header is that? 500 seconds?
  87. # [16:11] <AryehGregor> I leave the tab open for ten minutes and MITM starts working again?
  88. # [16:12] <AryehGregor> It should be six months or something. Then browsers could ship it in a fixed list and avoid the bootstrapping problem.
  89. # [16:19] <hsivonen> what happens if an attacker spoofs DNS and sets a long STS time to live on a bogus cert?
  90. # [16:19] * Quits: boblet (n=boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  91. # [16:19] <hsivonen> will users then be locked out of the real service for a long time?
  92. # [16:19] <AryehGregor> He'd have to get a bogus cert first.
  93. # [16:19] <AryehGregor> In that case, you lose anyway.
  94. # [16:19] <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
  95. # [16:19] <AryehGregor> In theory, though, yeah, sure.
  96. # [16:20] <AryehGregor> You can probably manage your STS settings somewhere, though.
  97. # [16:20] <hsivonen> AryehGregor: isn't the CA lock feature's whole point that getting a bogus cert is a real threat scenario
  98. # [16:20] <AryehGregor> Rik|work, I should hope so!
  99. # [16:20] <Rik|work> yeah, document.querySelector('video').webkitEnterFullScreen(); doesn't work
  100. # [16:20] <Rik|work> but window.onclick = function () {document.querySelector('video').webkitEnterFullScreen()} works
  101. # [16:21] <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.
  102. # [16:21] <hsivonen> Rik|work: yay for APIs that modify behavior depending on call stack
  103. # [16:21] <AryehGregor> hsivonen, well, popup windows already do that.
  104. # [16:21] * Joins: foolip (n=philip@h-63-95.A163.priv.bahnhof.se)
  105. # [16:21] <Rik|work> it throws Error: INVALID_STATE_ERR: DOM Exception 11 otherwise
  106. # [16:21] <hsivonen> AryehGregor: is the CA lock feature different from STS then?
  107. # [16:22] <hsivonen> AryehGregor: I'm pretty sure one of the strict SSL things that are emerging had a CA lock feature
  108. # [16:22] <AryehGregor> I think that's being left out of the first draft.
  109. # [16:22] <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
  110. # [16:22] <hsivonen> oh ok
  111. # [16:23] <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.
  112. # [16:23] <AryehGregor> But let's start with the basics, making SSL actually effectively prevent MITM. :)
  113. # [16:24] <hsivonen> my bank uses EV when I log in through their front door to do banking
  114. # [16:24] * Quits: KevinMarks (n=KevinMar@c-67-161-44-219.hsd1.ca.comcast.net) (Client Quit)
  115. # [16:24] <hsivonen> but they don't use EV when a merchant redirects to them for payment
  116. # [16:24] <hsivonen> FAIL
  117. # [16:24] <AryehGregor> EV isn't good for much anyway, as far as I can tell.
  118. # [16:25] <AryehGregor> I mean, it relies on what, someone actually clicking on some icon to show the certificate details?
  119. # [16:25] <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
  120. # [16:26] <hsivonen> Paypal seems to get it
  121. # [16:26] <hsivonen> banks not so much
  122. # [16:26] <hsivonen> but even Paypal uses autocomplete='off'
  123. # [16:26] <hsivonen> which doesn't make sense
  124. # [16:26] <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.
  125. # [16:26] <AryehGregor> Why doesn't it make sense?
  126. # [16:27] <hsivonen> because my browser is better at telling if it is refilling a form on the real paypal.com than I am
  127. # [16:27] <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.
  128. # [16:27] * Joins: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  129. # [16:27] <AryehGregor> Although you're right that autofilling is a cue that you're on the right site.
  130. # [16:28] <hsivonen> I have a greasemonkey script that fixes that for me when I enter through paypal.com
  131. # [16:28] <AryehGregor> It should probably autofill the username but not the password, does it do that?
  132. # [16:28] <hsivonen> but for some reason, the script fails when I enter through the French front of Paypal
  133. # [16:28] <hsivonen> AryehGregor: no
  134. # [16:28] <AryehGregor> Oh well.
  135. # [16:28] <hsivonen> they can't control my Webmail autofill
  136. # [16:29] <hsivonen> and email is the single point of failure anyway
  137. # [16:29] <AryehGregor> The entire concept of passwords is broken anyway.
  138. # [16:29] <hsivonen> so unless they want to send me a one-time pad, they shouldn't bother with the autofill=off nonsense
  139. # [16:29] <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.
  140. # [16:29] <hsivonen> also, it's not good to make me carry the Paypal password on a piece of paper
  141. # [16:30] <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.
  142. # [16:31] <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.
  143. # [16:31] <AryehGregor> That could replace all passwords and make it impossible to steal someone's login remotely, whether with phishing or anything else.
  144. # [16:31] <AryehGregor> But it would require a whole bunch of infrastructure.
  145. # [16:33] <Philip`> Everyone would lose their devices
  146. # [16:33] <Philip`> Also, it would make it too hard to share your login details with somebody else
  147. # [16:34] <TabAtkins> Password on brain states. You just have to wait for ubiquitous persocom implants, and mind emulation.
  148. # [16:34] <hsivonen> AryehGregor: hardware dongles FAIL for compatibility reasons
  149. # [16:34] <TabAtkins> Implementation details, really.
  150. # [16:35] <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.
  151. # [16:35] <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.
  152. # [16:36] <AryehGregor> hsivonen, what?
  153. # [16:36] <AryehGregor> TabAtkins, once you have mind emulation, couldn't you use that to emulate the brain states? :)
  154. # [16:36] <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
  155. # [16:36] <AryehGregor> Also, what's to prevent playback attacks?
  156. # [16:36] <AryehGregor> Replay attacks, I mean.
  157. # [16:37] <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.
  158. # [16:37] <AryehGregor> Philip`, you're making assumptions about how easy it would be to delegate here.
  159. # [16:37] <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
  160. # [16:37] <TabAtkins> At least mind-states know that they're just copies.
  161. # [16:38] <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.
  162. # [16:38] <AryehGregor> It's a lot less complicated than many other things people have to do every day.
  163. # [16:38] <AryehGregor> Plus, normal people hate passwords and would welcome a bit of extra complexity if it meant they didn't have to use them.
  164. # [16:39] <AryehGregor> (geeks also hate passwords, of course)
  165. # [16:39] * Quits: miketaylr (n=miketayl@38.117.156.163) (Excess Flood)
  166. # [16:39] * Joins: miketaylr (n=miketayl@38.117.156.163)
  167. # [16:45] * Joins: Sidnicious (n=Sidney@pdpc/supporter/professional/sidney)
  168. # [16:51] <hsivonen> AryehGregor: hardware dongles are OK if they show you a number and you write it into your device
  169. # [16:52] <hsivonen> AryehGregor: handware dongles that connect to your computing device are bad, because:
  170. # [16:52] <hsivonen> 1) people think they are more secure than the Windows malware signing stuff as you
  171. # [16:52] <hsivonen> 2) they limit competetition between desktop OSs, because driver availability for Mac and Linux will suck
  172. # [16:53] <hsivonen> 3) they don't work with your portable device that doesn't have the right interface form factor
  173. # [16:53] <hsivonen> so smart cards and USB dongles are bad
  174. # [16:53] <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.
  175. # [16:53] * Joins: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com)
  176. # [16:54] <hsivonen> Finland has wasted enormous amounts of tax payer money on a smart card system
  177. # [16:54] <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?
  178. # [16:54] <hsivonen> AryehGregor: RSA has number generators. I don't know what their properties are and if they require you to trust your identity broker
  179. # [16:54] <hsivonen> AryehGregor: cheap phones don't have USB host mode
  180. # [16:55] <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 . . .
  181. # [16:55] <AryehGregor> hsivonen, they could pretty easily. I never said this wouldn't require infrastructure changes, that's the major problem with it.
  182. # [16:55] <hsivonen> anyway, the enormously expensive smart card system in Finland is a massive FAIL
  183. # [16:55] <hsivonen> and what really works is one-time pads (on paper)
  184. # [16:56] <hsivonen> and banks that issue the pads working as identity broker back ends
  185. # [16:56] * 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
  186. # [16:56] <Philip`> so it's not a PRNG thing
  187. # [16:56] <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
  188. # [16:56] <AryehGregor> Philip`, interesting.
  189. # [16:57] <hsivonen> anyway, the value added by an RSA thingy compared to a paper OTP is likely low
  190. # [16:57] <TabAtkins> So basically a government-run openid server?
  191. # [16:57] <Philip`> (The card is the important component, the devices are all the same)
  192. # [16:57] <hsivonen> TabAtkins: not OpenID, but kinda
  193. # [16:57] <hsivonen> say you want to check your pension situation
  194. # [16:57] <TabAtkins> Yeah, not the specific technology. Just making an analogy.
  195. # [16:57] <hsivonen> so you go to the pension site
  196. # [16:57] <hsivonen> it redirects you to the identity broker
  197. # [16:58] <hsivonen> the identity broker supports the smart card stuff
  198. # [16:58] <hsivonen> but no one uses it
  199. # [16:58] <hsivonen> so instead, you click the logo of your bank
  200. # [16:58] <hsivonen> get forwarded to your bank
  201. # [16:58] <hsivonen> give a number from your OTP to the bank
  202. # [16:58] <hsivonen> the bank redirects you to the broker
  203. # [16:58] <hsivonen> and the broker redirects you to the pension site
  204. # [16:59] <hsivonen> and the pension site gets your personal ID number
  205. # [16:59] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) (Remote closed the connection)
  206. # [16:59] <hsivonen> everyone has the ID number anyway
  207. # [16:59] <hsivonen> assigned at birth
  208. # [17:00] * Joins: BlurstOfTimes (n=blurstof@168.203.117.66)
  209. # [17:00] <hsivonen> or when becoming a resident if not born here
  210. # [17:01] <hsivonen> works with any browser
  211. # [17:01] <hsivonen> no hardware dongles
  212. # [17:01] <hsivonen> no barriers to launching new software or hardware browsing platforms
  213. # [17:01] <hsivonen> no South Korea situation
  214. # [17:02] <TabAtkins> Well, the government has to recognize you as an identity backend.
  215. # [17:02] <TabAtkins> But that's it, I guess. And backends can then use whatever stuff they want to id you.
  216. # [17:03] * Quits: dglazkov (n=dglazkov@c-67-188-0-62.hsd1.ca.comcast.net)
  217. # [17:03] * Joins: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi)
  218. # [17:03] <AryehGregor> OTP?
  219. # [17:04] <hsivonen> one-time pad
  220. # [17:06] * Quits: breakmau5 (n=breakz@erft-4db7d631.pool.mediaWays.net) (Read error: 113 (No route to host))
  221. # [17:06] * Quits: Maurice (n=ano@a80-101-46-164.adsl.xs4all.nl) ("Disconnected...")
  222. # [17:06] * Joins: MikeSmithX (n=MikeSmit@EM114-48-42-128.pool.e-mobile.ne.jp)
  223. # [17:07] * Philip` thought it was usually "one-time password" in this context
  224. # [17:07] <hsivonen> there's a whole pad of them
  225. # [17:07] <hsivonen> Wikipedia upholds my usage: http://en.wikipedia.org/wiki/OTP
  226. # [17:08] <AryehGregor> Interesting.
  227. # [17:08] <hsivonen> hmm. except http://en.wikipedia.org/wiki/One-time_pad seems to say the pad is a cipher
  228. # [17:08] <hsivonen> Philip`: so yeah, one-time password
  229. # [17:09] <AryehGregor> Right, a one-time pad is definitely a cipher.
  230. # [17:10] <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.
  231. # [17:10] <AryehGregor> Passwords are a lousy tradeoff between convenience and security, they're both inconvenient and insecure.
  232. # [17:12] <Sidnicious> To quote Dan K., "passwords are used because they scale well, one at a time."
  233. # [17:13] <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?
  234. # [17:13] <Sidnicious> There's almost zero effort required to "secure" an account with a password.
  235. # [17:13] <hsivonen> AryehGregor: that's how those FAILed smart cards worked
  236. # [17:13] <hsivonen> AryehGregor: otherwise, your untrusted computer can poke at the dongle and perform actions as you
  237. # [17:14] <hsivonen> AryehGregor: just like untrusted software that hijacks your passwords on your computer can do
  238. # [17:14] <AryehGregor> hsivonen, it can only impersonate you as long as the crypto thing is in the machine. As opposed to forever.
  239. # [17:15] <hsivonen> AryehGregor: so you'd plug and unplug it all the time?
  240. # [17:15] * Joins: FireFly (n=firefly@unaffiliated/firefly)
  241. # [17:16] <AryehGregor> Hmm.
  242. # [17:16] <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.
  243. # [17:16] <AryehGregor> (unbreakable hardware DRM, obviously)
  244. # [17:18] <Philip`> It'd be a boring world if there easy perfect solutions to problems
  245. # [17:18] <Philip`> Much better when it's all about tradeoffs
  246. # [17:23] <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.
  247. # [17:24] <TabAtkins> What if malware sends transaction requests at the same time as your bank?
  248. # [17:24] <Sidnicious> Hrm.
  249. # [17:25] * Joins: dglazkov (n=dglazkov@nat/google/x-pjajgtsbtqjoewqn)
  250. # [17:25] <Philip`> Mechanical buttons sound bad for cost and reliability
  251. # [17:25] <TabAtkins> Well, you need buttons if you want the "type in the code" thing anyway.
  252. # [17:26] <Philip`> True
  253. # [17:27] <Sidnicious> Lemme butt in with a quick spec question... is anyone familiar with why forminput and formchange events don't bubble?
  254. # [17:27] * 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
  255. # [17:27] <Sidnicious> (<http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#event-dispatch>)
  256. # [17:27] <Philip`> Clearly they should be wireless
  257. # [17:28] * Quits: MikeSmith (n=MikeSmit@EM114-48-82-170.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  258. # [17:28] <Philip`> Sidnicious: Seems like not bubbling is the default behaviour
  259. # [17:28] <Philip`> Why should they bubble?
  260. # [17:28] <Sidnicious> Event delegation.
  261. # [17:29] * Joins: breakmau5 (n=breakz@erft-4db7d631.pool.mediaWays.net)
  262. # [17:30] <Philip`> Can't you do that with capturing instead?
  263. # [17:35] * Joins: JonathanNeal (n=Jonathan@76-219-69-134.lightspeed.breaca.sbcglobal.net)
  264. # [17:36] <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.
  265. # [17:37] <Sidnicious> If capturing works just as well, I guess the libraries'll adapt.
  266. # [17:38] <Philip`> Hmm, strange that jQuery wouldn't support event capture
  267. # [17:38] <Dashiva> IE compat, surely
  268. # [17:39] <Philip`> Does IE not have any equivalent to capture?
  269. # [17:40] <Dashiva> I don't believe so
  270. # [17:41] <Philip`> That might explain it then
  271. # [17:42] * Quits: roc (n=roc@121-72-171-11.dsl.telstraclear.net)
  272. # [17:42] <Sidnicious> All right.
  273. # [17:44] * Quits: dglazkov (n=dglazkov@nat/google/x-pjajgtsbtqjoewqn)
  274. # [17:50] * Joins: dglazkov (n=dglazkov@nat/google/x-bdxakwverxgvtuih)
  275. # [17:51] * Quits: Lachy (n=Lachlan@pat-tdc.opera.com) ("Leaving")
  276. # [17:58] * Quits: pesla (n=retep@procurios.xs4all.nl) ("( www.nnscript.com :: NoNameScript 4.21 :: www.esnation.com )")
  277. # [18:05] * Quits: JonathanNeal (n=Jonathan@76-219-69-134.lightspeed.breaca.sbcglobal.net) ("Leaving")
  278. # [18:09] * Quits: Phae (n=phaeness@gateb.mh.bbc.co.uk)
  279. # [18:09] * Joins: dbaron (n=dbaron@nat/mozilla/x-lhumalrqrzzeidbt)
  280. # [18:15] * Joins: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  281. # [18:18] * Joins: jorlow_ (n=jorlow@c-67-164-97-172.hsd1.ca.comcast.net)
  282. # [18:21] * Quits: mhausenblas (n=mhausenb@wg1-nat.fwgal01.deri.ie)
  283. # [18:23] * Joins: jg (n=jg@c-98-229-106-42.hsd1.ma.comcast.net)
  284. # [18:25] * Quits: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com) (Client Quit)
  285. # [18:25] * Joins: Lachy (n=Lachlan@85.196.122.246)
  286. # [18:27] * Joins: dave_levin (n=dave_lev@74.125.59.65)
  287. # [18:33] * Joins: cying (n=cying@70.90.171.153)
  288. # [18:34] * Joins: sbublava (n=stephan@77.118.36.229.wireless.dyn.drei.com)
  289. # [18:37] * Joins: boogyman (n=boogyman@unaffiliated/boogyman)
  290. # [18:38] * Joins: JonathanNeal (n=Jonathan@rrcs-76-79-114-213.west.biz.rr.com)
  291. # [18:40] * Quits: jg (n=jg@c-98-229-106-42.hsd1.ma.comcast.net) (Read error: 110 (Connection timed out))
  292. # [18:40] * Joins: jg (n=jg@proxy.lucent.com)
  293. # [18:44] * Quits: mat_t (n=mattomas@91.189.88.12) (Client Quit)
  294. # [18:47] * Joins: sebmarkbage (n=miranda@213.80.108.29)
  295. # [18:48] * Parts: boogyman (n=boogyman@unaffiliated/boogyman)
  296. # [18:50] * Joins: KevinMarks (n=KevinMar@157.22.22.46)
  297. # [18:55] * Joins: myakura (n=myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp)
  298. # [19:01] * Joins: jonpierce (n=jonpierc@209-6-91-231.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)
  299. # [19:07] * Joins: hober (n=ted@unaffiliated/hober)
  300. # [19:08] * Quits: jorlow_ (n=jorlow@c-67-164-97-172.hsd1.ca.comcast.net) (Client Quit)
  301. # [19:20] * Joins: jorlow_ (n=jorlow@67.218.107.51)
  302. # [19:21] * Quits: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at) (Client Quit)
  303. # [19:28] * Joins: drunknbass_work (n=aaron@cpe-76-173-195-145.socal.res.rr.com)
  304. # [19:29] * workmad3 is now known as wm3|food
  305. # [19:37] * Joins: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com)
  306. # [19:49] * Quits: jorlow_ (n=jorlow@67.218.107.51) (Read error: 104 (Connection reset by peer))
  307. # [19:50] * Joins: jorlow_ (n=jorlow@67.218.107.51)
  308. # [19:58] * Joins: cpearce (n=cpearce@ip-118-90-40-252.xdsl.xnet.co.nz)
  309. # [19:59] * Quits: dbaron (n=dbaron@nat/mozilla/x-lhumalrqrzzeidbt) ("8403864 bytes have been tenured, next gc will be global.")
  310. # [20:05] * Joins: cying_ (n=cying@70.90.171.153)
  311. # [20:05] * Quits: jorlow_ (n=jorlow@67.218.107.51) (Client Quit)
  312. # [20:10] * Joins: jorlow_ (n=jorlow@nat/google/x-hulhqxhdfofcvfuv)
  313. # [20:10] * Quits: jorlow (n=jorlow@nat/google/x-okxwgwczunehpqcy)
  314. # [20:16] * Quits: jorlow_ (n=jorlow@nat/google/x-hulhqxhdfofcvfuv) (Client Quit)
  315. # [20:16] * Joins: Omnipotent (n=youshoul@unaffiliated/dor)
  316. # [20:17] * Joins: GarethAdams|Home (n=GarethAd@pdpc/supporter/active/GarethAdams)
  317. # [20:21] * Quits: cying (n=cying@70.90.171.153) (Read error: 110 (Connection timed out))
  318. # [20:21] * cying_ is now known as cying
  319. # [20:24] * Joins: tametick (n=chatzill@chello084114134061.3.15.vie.surfer.at)
  320. # [20:24] * Joins: jorlow (n=jorlow@nat/google/x-tgyjkyvosuvpcler)
  321. # [20:32] * Joins: Steve^ (n=steve@92.40.140.35.sub.mbb.three.co.uk)
  322. # [20:35] * Joins: roc (n=roc@121-72-171-11.dsl.telstraclear.net)
  323. # [20:36] <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
  324. # [20:41] * Joins: ap (n=ap@17.246.19.5)
  325. # [20:43] * Quits: cpearce (n=cpearce@ip-118-90-40-252.xdsl.xnet.co.nz) ("ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.15/2009101909]")
  326. # [20:47] * Parts: jonpierce (n=jonpierc@209-6-91-231.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com)
  327. # [20:49] * Joins: jwalden (n=waldo@nat/mozilla/x-oaecueydpkxlfftj)
  328. # [21:01] * Quits: starjive (i=beos@81-233-16-19-no30.tbcn.telia.com) (Client Quit)
  329. # [21:05] * Joins: Craig` (n=craig@host81-141-118-158.wlms-broadband.com)
  330. # [21:08] * Joins: jacobolus (n=jacobolu@h-66-166-3-76.lsanca54.static.covad.net)
  331. # [21:10] * Joins: dbaron (n=dbaron@nat/mozilla/x-qsvmgzixzldtship)
  332. # [21:10] * Quits: Craig` (n=craig@host81-141-118-158.wlms-broadband.com) (Remote closed the connection)
  333. # [21:11] <jgraham> Dashiva: I recall noticing people at telecons who have rarely posted to the mailing list
  334. # [21:13] * Quits: sbublava (n=stephan@77.118.36.229.wireless.dyn.drei.com) (Client Quit)
  335. # [21:13] * Joins: cpearce (n=cpearce@203-97-204-82.dsl.clear.net.nz)
  336. # [21:15] <Philip`> Do they contribute in other ways?
  337. # [21:16] <Philip`> (It's not so useful having people well informed if they don't do anything with their informedness)
  338. # [21:18] * Quits: cying (n=cying@70.90.171.153) (Remote closed the connection)
  339. # [21:18] * Joins: john_fallows (n=j_r_fall@adsl-75-61-86-190.dsl.pltn13.sbcglobal.net)
  340. # [21:18] * Joins: cying (n=cying@70.90.171.153)
  341. # [21:20] <john_fallows> is websocket-protocol of empty string supported by draft-hixie-thewebsocketprotocol-68 ?
  342. # [21:21] <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)
  343. # [21:23] <Hixie> how do you mean by "supported"?
  344. # [21:23] <john_fallows> i meant permitted by the specification
  345. # [21:23] <john_fallows> actually, as i'm trying to explain it, i found something relevant
  346. # [21:24] <Hixie> the API won't accept it
  347. # [21:24] <john_fallows> if there are any entries in the /headers/ list whose names are the empty string
  348. # [21:24] <Hixie> but if a (non-browser) client sends it, the server defines what should happen
  349. # [21:24] <john_fallows> this is for names, not values
  350. # [21:24] <john_fallows> yep, that's fine
  351. # [21:24] <Hixie> er, the protocol spec defines what should happen on the server, i mean
  352. # [21:25] <john_fallows> i think there might be a section further up that states the subprotocol value should be non-null and non-empty
  353. # [21:25] <john_fallows> yep, got it
  354. # [21:25] <Hixie> i guess i don't know what you mean by "permitted by the specification"
  355. # [21:25] <Hixie> which specification? there are two
  356. # [21:25] <Hixie> the API? the protocol?
  357. # [21:25] <Hixie> sent by the client? by the server?
  358. # [21:25] <john_fallows> sorry, i was discussing the wire protocol spec draft-hixie-thewebsocketprotocol-68
  359. # [21:25] <Hixie> client->server? server->client?
  360. # [21:26] * Quits: Steve^ (n=steve@92.40.140.35.sub.mbb.three.co.uk) ("Leaving")
  361. # [21:27] <john_fallows> the description of section 5.1 "Sending the server's handshake" /subprotocol/ says...
  362. # [21:27] <john_fallows> "Either null, or a string representing the subprotocol the server is ready to use."
  363. # [21:27] <john_fallows> ...
  364. # [21:27] <john_fallows> "The empty string is not the same as the null value for these purposes."
  365. # [21:27] * Quits: myakura (n=myakura@p3213-ipbf4202marunouchi.tokyo.ocn.ne.jp) ("Leaving...")
  366. # [21:27] <john_fallows> i read that to mean empty string was permitted, but it is not, as described elsewhere in the document
  367. # [21:28] * Quits: othermaciej (n=mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  368. # [21:28] <Hixie> there's no concept of what is permitted from the server in the subprotocol name
  369. # [21:28] <Hixie> the server just sends back what the client sends
  370. # [21:29] <Hixie> if the client sent the empty string, then the server will send the empty string
  371. # [21:30] <Hixie> (assuming it wants to accept the connection)
  372. # [21:30] <john_fallows> understood
  373. # [21:31] <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)
  374. # [21:31] <john_fallows> "The /resource name/ and /protocol/ strings must be non-empty strings of ASCII characters in the range U+0020 to U+007E."
  375. # [21:31] <john_fallows> ?
  376. # [21:32] * Quits: drunknbass_work (n=aaron@cpe-76-173-195-145.socal.res.rr.com) (Client Quit)
  377. # [21:32] <Hixie> right
  378. # [21:32] <Hixie> and the API also restricts it
  379. # [21:32] <john_fallows> ok, now it makes sense
  380. # [21:33] <john_fallows> the difference in strictness between client and server caused my temporary confusion :-)
  381. # [21:34] <Hixie> in practice there's no reason for a server to support the subprotocol "", since compliant clients can't send it
  382. # [21:34] <john_fallows> yes, agreed.
  383. # [21:35] <john_fallows> btw, i have some feedback regarding delivery of binary WebSocket frame payloads to JavaScript
  384. # [21:35] <john_fallows> should i send an email to the mailing list?
  385. # [21:35] <Hixie> yes please
  386. # [21:36] <Hixie> for binary i'm basically waiting for the text stuff to be widely implemented first though
  387. # [21:36] <Hixie> baby steps
  388. # [21:36] <Hixie> (also waiting for JS to have binary support)
  389. # [21:37] <john_fallows> i suspect that waiting for JS to have binary support is unnecessary and will explain the proposal in the email
  390. # [21:39] <Hixie> i think it's likely that JS binary support will come long before websocket is widely supported
  391. # [21:39] <Hixie> so it might be a moot point
  392. # [21:40] <john_fallows> that would be wonderful, will send the proposal and then we can discuss it
  393. # [21:41] <john_fallows> btw, I'll be at Google HQ later this afternoon, would like to stop by to say hi if you are around.
  394. # [21:41] <Hixie> ===========================================
  395. # [21:41] * Quits: jg (n=jg@proxy.lucent.com) (Remote closed the connection)
  396. # [21:42] <Hixie> sure
  397. # [21:42] <Hixie> dunno when i'll get in, but i'll be on IRC so we can coordinate here
  398. # [21:42] <john_fallows> sure, or if you email me your phone number, i can give you a call when my meeting is done
  399. # [21:43] * Quits: roc (n=roc@121-72-171-11.dsl.telstraclear.net)
  400. # [21:44] * wm3|food is now known as workmad3
  401. # [21:45] <Hixie> don't have a phone
  402. # [21:47] * Joins: erlehmann (n=erlehman@dslb-088-075-184-232.pools.arcor-ip.net)
  403. # [21:48] <john_fallows> hope to see you later, bye for now.
  404. # [21:49] * Quits: plainhao (n=plainhao@mail.xbiotica.com)
  405. # [21:54] <Hixie> later
  406. # [21:54] * Quits: tigliona1bit (n=nick@67-207-136-95.slicehost.net) (Client Quit)
  407. # [22:02] * Joins: drunknbass_work (n=aaron@71.107.253.243)
  408. # [22:11] * Quits: ROBOd (n=robod@89.122.216.38) ("http://www.robodesign.ro")
  409. # [22:14] * Quits: jacobolus (n=jacobolu@h-66-166-3-76.lsanca54.static.covad.net) (Read error: 60 (Operation timed out))
  410. # [22:14] * Quits: jwalden (n=waldo@nat/mozilla/x-oaecueydpkxlfftj) ("ChatZilla 0.9.85-rdmsoft [XULRunner 1.9.2/20100122095031]")
  411. # [22:16] * Joins: jacobolus (n=jacobolu@h-66-166-3-76.lsanca54.static.covad.net)
  412. # [22:16] * Quits: mlpug (n=mlpug@a88-115-164-40.elisa-laajakaista.fi) (Remote closed the connection)
  413. # [22:19] * Joins: mackstann_ (n=death@216-20-152-177-dsl.hevanet.com)
  414. # [22:22] * Joins: othermaciej (n=mjs@17.246.19.82)
  415. # [22:25] * Joins: jwalden (n=waldo@nat/mozilla/x-qxhopmyjzbkkqilp)
  416. # [22:44] * Joins: john_r_fallows (n=j_r_fall@adsl-75-61-86-190.dsl.pltn13.sbcglobal.net)
  417. # [22:45] <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
  418. # [23:04] * Quits: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com) (Remote closed the connection)
  419. # [23:06] * Joins: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com)
  420. # [23:07] * Joins: mpavel (n=pavel@cpc1-dund3-0-0-cust363.sgyl.cable.virginmedia.com)
  421. # [23:08] * Quits: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com) (Remote closed the connection)
  422. # [23:09] * Quits: mpavel (n=pavel@cpc1-dund3-0-0-cust363.sgyl.cable.virginmedia.com) (Client Quit)
  423. # [23:10] * Joins: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com)
  424. # [23:10] * Quits: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com) (Remote closed the connection)
  425. # [23:14] * Quits: miketaylr (n=miketayl@38.117.156.163) (Remote closed the connection)
  426. # [23:17] * Joins: nessy (n=Adium@124-171-43-189.dyn.iinet.net.au)
  427. # [23:17] * Joins: boblet (n=boblet@p1072-ipbf36osakakita.osaka.ocn.ne.jp)
  428. # [23:18] * Quits: ChrisLTD|Work (n=blahness@152.2.194.196) (Client Quit)
  429. # [23:23] * Quits: peol (n=peol@unaffiliated/peol) (Remote closed the connection)
  430. # [23:23] * Quits: MikeSmithX (n=MikeSmit@EM114-48-42-128.pool.e-mobile.ne.jp) (Read error: 110 (Connection timed out))
  431. # [23:28] * Joins: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com)
  432. # [23:31] * Quits: Maurice (i=copyman@5ED548D4.cable.ziggo.nl)
  433. # [23:31] * Quits: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com) (Remote closed the connection)
  434. # [23:34] * Joins: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com)
  435. # [23:38] * Quits: BlurstOfTimes (n=blurstof@168.203.117.66) (Client Quit)
  436. # [23:45] * Quits: dave_levin (n=dave_lev@74.125.59.65)
  437. # [23:46] * Quits: othermaciej (n=mjs@17.246.19.82) (Remote closed the connection)
  438. # [23:46] * Joins: othermaciej (n=mjs@nat/apple/x-ocmsprgiccbcqocz)
  439. # [23:50] * Quits: zcorpan (n=zcorpan@90-224-190-71-no135.tbcn.telia.com) (Remote closed the connection)
  440. # [23:51] * Joins: slightlyoff (n=slightly@72.14.229.81)
  441. # [23:55] * Joins: Rik` (n=Rik`@pha75-2-81-57-187-57.fbx.proxad.net)
  442. # Session Close: Thu Jan 28 00:00:00 2010

The end :)