/irc-logs / freenode / #whatwg / 2010-10-03 / end

Options:

  1. # Session Start: Sun Oct 03 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:03] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  4. # [00:05] * Joins: wakaba_ (~wakaba_@130.139.210.220.dy.bbexcite.jp)
  5. # [00:05] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Quit: annevk)
  6. # [00:09] * Quits: wakaba_0 (~wakaba_@130.139.210.220.dy.bbexcite.jp) (Ping timeout: 252 seconds)
  7. # [00:25] * Joins: nessy (~Adium@143.55.1.230)
  8. # [00:26] * Joins: abarth (~abarth@c-67-169-42-39.hsd1.ca.comcast.net)
  9. # [00:30] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  10. # [00:33] * Quits: miketaylr (~miketaylr@85.19.196.182) (Remote host closed the connection)
  11. # [00:34] * Quits: paul_irish (~paul_iris@207-237-102-112.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) (Remote host closed the connection)
  12. # [00:48] * Quits: espadrine (~espadrine@AMontsouris-157-1-96-24.w90-46.abo.wanadoo.fr) (Ping timeout: 240 seconds)
  13. # [00:51] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  14. # [00:57] * Quits: nessy (~Adium@143.55.1.230) (Quit: Leaving.)
  15. # [00:58] * Joins: espadrine (~espadrine@AMontsouris-157-1-96-24.w90-46.abo.wanadoo.fr)
  16. # [01:04] * sean` is now known as seankoole
  17. # [01:06] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  18. # [01:11] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  19. # [01:42] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Remote host closed the connection)
  20. # [02:25] * Quits: expilicious (~zAyghip8@cpc2-ely02-0-0-cust338.5-1.cable.virginmedia.com) (Ping timeout: 264 seconds)
  21. # [02:41] * Quits: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de) (Quit: Now time for the weather. Tiffany?)
  22. # [03:02] * Joins: nessy (~Adium@216.194.44.151)
  23. # [03:09] * Quits: tndH (~Rob@cpc6-seac20-2-0-cust102.7-2.cable.virginmedia.com) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
  24. # [03:10] * Quits: ZombieLoffe (~e@unaffiliated/zombieloffe)
  25. # [03:16] * Quits: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net) (Remote host closed the connection)
  26. # [03:26] * Joins: jacobolus (~jacobolus@c-67-186-134-101.hsd1.ma.comcast.net)
  27. # [03:35] * Quits: Martijnc (~Martijnc@91.176.142.2) (Ping timeout: 264 seconds)
  28. # [03:40] * Joins: Martijnc (~Martijnc@91.176.141.195)
  29. # [03:40] * Quits: aho (~nya@fuld-4d00d097.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
  30. # [03:44] * Joins: espadrine_ (~espadrine@AMontsouris-157-1-96-24.w90-46.abo.wanadoo.fr)
  31. # [03:44] * Quits: espadrine (~espadrine@AMontsouris-157-1-96-24.w90-46.abo.wanadoo.fr) (Read error: Connection reset by peer)
  32. # [03:44] * espadrine_ is now known as espadrine
  33. # [04:54] * seankoole is now known as sean`
  34. # [05:00] * Quits: jacobolus (~jacobolus@c-67-186-134-101.hsd1.ma.comcast.net) (Ping timeout: 240 seconds)
  35. # [05:03] * Joins: espadrine_ (~espadrine@AMontsouris-157-1-89-175.w90-46.abo.wanadoo.fr)
  36. # [05:04] * Quits: espadrine (~espadrine@AMontsouris-157-1-96-24.w90-46.abo.wanadoo.fr) (Ping timeout: 264 seconds)
  37. # [05:04] * espadrine_ is now known as espadrine
  38. # [05:05] * Quits: sean` (~Sean@84-106-110-173.cable.quicknet.nl) (Read error: Connection reset by peer)
  39. # [05:05] * Joins: sean` (~Sean@84-106-110-173.cable.quicknet.nl)
  40. # [05:12] * Joins: jacobolus (~jacobolus@static-72-248-62-22.ma.onecommunications.net)
  41. # [05:18] * Quits: nessy (~Adium@216.194.44.151) (Quit: Leaving.)
  42. # [05:52] * Quits: romeo_ (~romeo__@x1-6-00-10-a7-28-f3-47.k561.webspeed.dk) (Quit: Leaving)
  43. # [06:03] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  44. # [06:19] * Quits: jacobolus (~jacobolus@static-72-248-62-22.ma.onecommunications.net) (Remote host closed the connection)
  45. # [06:25] * Joins: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net)
  46. # [06:58] * Joins: xuser (~xuser@unaffiliated/xuser)
  47. # [06:59] * Parts: xuser (~xuser@unaffiliated/xuser)
  48. # [08:26] * Joins: baba (~sallabanc@69.50.70.12)
  49. # [08:26] * Quits: baba (~sallabanc@69.50.70.12) (Changing host)
  50. # [08:26] * Joins: baba (~sallabanc@unaffiliated/cypha)
  51. # [08:28] * Parts: baba (~sallabanc@unaffiliated/cypha)
  52. # [08:29] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  53. # [09:25] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 272 seconds)
  54. # [09:39] * Joins: Amorphous (jan@unaffiliated/amorphous)
  55. # [09:43] * Joins: ROBOd (~robod@89.123.189.33)
  56. # [09:48] * Quits: JohnResig (~JohnResig@ejohn.org) (Ping timeout: 252 seconds)
  57. # [09:49] * Joins: JohnResig (~JohnResig@ejohn.org)
  58. # [09:49] * Joins: Ms2ger (~Ms2ger@91.181.27.197)
  59. # [10:26] * Joins: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  60. # [10:46] * Quits: Ms2ger (~Ms2ger@91.181.27.197) (Ping timeout: 245 seconds)
  61. # [10:48] * Joins: ZombieLoffe (~e@unaffiliated/zombieloffe)
  62. # [10:57] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  63. # [11:00] <espadrine> Never mind the bullets, so many html5 features! Font face loading,
  64. # [11:00] <espadrine> SVG background,
  65. # [11:00] <espadrine> "JavaScript acceleration" (this is a famous standard),
  66. # [11:00] <espadrine> CSS3 Multi-background,
  67. # [11:00] <espadrine> Editable content...
  68. # [11:03] * Quits: kig (~kig@dsl-lprbrasgw1-febafa00-103.dhcp.inet.fi) (Ping timeout: 252 seconds)
  69. # [11:18] * Joins: Ms2ger (~Ms2ger@91.181.27.197)
  70. # [11:25] * abarth is now known as abarth|crash
  71. # [11:26] * Quits: yutak_home (~kee@R222116.ppp.dion.ne.jp) (Quit: Ex-Chat)
  72. # [11:28] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  73. # [11:34] * Joins: nessy (~Adium@216.194.44.151)
  74. # [11:53] * Quits: nessy (~Adium@216.194.44.151) (Quit: Leaving.)
  75. # [11:54] * Quits: Anti-X (~duckmysic@c9E72BF51.dhcp.bluecom.no) (Ping timeout: 265 seconds)
  76. # [11:55] * Joins: homata (~homata@h219-110-13-055.catv02.itscom.jp)
  77. # [11:56] * Joins: tndH (~Rob@cpc6-seac20-2-0-cust102.7-2.cable.virginmedia.com)
  78. # [11:58] * Joins: Anti-X (~duckmysic@c9E72BF51.dhcp.bluecom.no)
  79. # [12:00] * Joins: riven` (~riven@53518387.cable.casema.nl)
  80. # [12:02] * Quits: riven (~riven@53518387.cable.casema.nl) (Ping timeout: 240 seconds)
  81. # [12:03] * Quits: homata (~homata@h219-110-13-055.catv02.itscom.jp) (Ping timeout: 240 seconds)
  82. # [12:27] * Joins: matjas (~matjas@ip-81-11-180-97.dsl.scarlet.be)
  83. # [12:31] * Quits: virtuelv (~virtuelv_@65.168.34.95.customer.cdi.no) (Quit: Ex-Chat)
  84. # [12:43] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  85. # [13:01] * Quits: matjas (~matjas@ip-81-11-180-97.dsl.scarlet.be) (Remote host closed the connection)
  86. # [13:06] * Joins: smaug____ (~chatzilla@cs181063178.pp.htv.fi)
  87. # [13:11] * Joins: ttepasse (~ttepasse@ip-109-90-161-169.unitymediagroup.de)
  88. # [13:18] * Quits: Ms2ger (~Ms2ger@91.181.27.197) (Read error: Connection reset by peer)
  89. # [13:20] * Joins: Ms2ger (~Ms2ger@91.181.27.197)
  90. # [13:29] * Joins: nessy (~Adium@216.194.44.151)
  91. # [13:29] * Quits: micheil (~micheil@220-235-101-140.dyn.iinet.net.au) (Quit: micheil)
  92. # [13:29] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
  93. # [13:38] * Joins: matjas (~matjas@ip-81-11-180-97.dsl.scarlet.be)
  94. # [13:48] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
  95. # [13:51] <annevk> reddit is great
  96. # [13:51] <annevk> http://www.youtube.com/watch?v=Vxd08Sp_FdI
  97. # [13:51] <annevk> http://www.youtube.com/watch?v=dd_X-C5g29o
  98. # [13:51] <annevk> http://www.youtube.com/watch?v=eXXntgq6hTE
  99. # [13:51] <annevk> http://www.youtube.com/watch?v=FKrsAFWPnl4
  100. # [13:51] <annevk> http://www.youtube.com/watch?v=Phn0S9EVWjo
  101. # [13:53] * Joins: henrikbjorn (~henrik@c83-249-65-238.bredband.comhem.se)
  102. # [13:57] <Rik`> the second scene from hard ticket to hawaii is awesome
  103. # [13:57] * Joins: maikmerten (~maikmerte@port-92-201-96-131.dynamic.qsc.de)
  104. # [13:58] * Joins: romeo_ (~romeo__@x1-6-00-10-a7-28-f3-47.k561.webspeed.dk)
  105. # [13:58] <annevk> yeah wtf is that
  106. # [13:58] <annevk> I think I have to see that movie now
  107. # [13:58] <Rik`> I've already seen it before
  108. # [13:59] <Rik`> (this specific scene, not the movie)
  109. # [13:59] <Rik`> the other one with a freesbee is cool too, great way to kill bad guys
  110. # [14:00] <Rik`> Machete is a must see btw
  111. # [14:03] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 265 seconds)
  112. # [14:04] <annevk> Machete is indeed awesome
  113. # [14:13] <daedb> man, those are some badass videos :D
  114. # [14:16] * Joins: Amorphous (jan@unaffiliated/amorphous)
  115. # [14:25] <karlcow> is it the htmlwg showers ? ;)
  116. # [14:28] * Quits: nessy (~Adium@216.194.44.151) (Quit: Leaving.)
  117. # [14:29] <karlcow> Rik`: and the gesture at the end. "Score!". Un excellent navet il semble
  118. # [14:33] * annevk is looking forward to Machete Kills
  119. # [14:35] <annevk> so saying that I wondered whether he's actually planning to make them
  120. # [14:35] <annevk> http://uk.movies.ign.com/articles/111/1118833p1.html
  121. # [14:36] * Joins: homata (~homata@h219-110-13-055.catv02.itscom.jp)
  122. # [14:40] <Rik`> the weirdest part of Machete is that Danny Trejo is 66 !
  123. # [14:40] <annevk> did not know
  124. # [14:40] <Rik`> karlcow: hmm, ça doit être du niveau de Mega Shark VS Giant Octopus
  125. # [14:40] <annevk> that's great
  126. # [14:42] <Rik`> he could be my grand father…
  127. # [14:42] <karlcow> heureusement il nous reste la poésie :p
  128. # [14:44] * Quits: homata (~homata@h219-110-13-055.catv02.itscom.jp) (Ping timeout: 240 seconds)
  129. # [14:46] * Joins: peterhil (~peterhil@a91-153-127-82.elisa-laajakaista.fi)
  130. # [15:05] * Quits: matjas (~matjas@ip-81-11-180-97.dsl.scarlet.be) (Remote host closed the connection)
  131. # [15:11] * Joins: matjas (~matjas@ip-81-11-180-97.dsl.scarlet.be)
  132. # [15:15] * Quits: Ms2ger (~Ms2ger@91.181.27.197) (Read error: Connection reset by peer)
  133. # [15:17] * Quits: matjas (~matjas@ip-81-11-180-97.dsl.scarlet.be) (Remote host closed the connection)
  134. # [15:18] <jgraham> http://behindthecurtain.us/2010/06/12/my-first-week-with-the-iphone/
  135. # [15:18] <jgraham> """In my more excitable moments, I consider the iPhone as the greatest thing to have ever happened to the blind"""
  136. # [15:23] * Joins: Ms2ger (~Ms2ger@91.181.27.197)
  137. # [15:28] * Quits: espadrine (~espadrine@AMontsouris-157-1-89-175.w90-46.abo.wanadoo.fr) (Quit: espadrine)
  138. # [15:29] * Joins: espadrine (~espadrine@AMontsouris-157-1-89-175.w90-46.abo.wanadoo.fr)
  139. # [15:42] * Quits: wakaba (~wakaba@130.139.210.220.dy.bbexcite.jp) (Quit: Leaving...)
  140. # [15:42] * Joins: aho (~nya@fuld-4d00d3c3.pool.mediaWays.net)
  141. # [15:43] * Joins: wakaba (~wakaba@130.139.210.220.dy.bbexcite.jp)
  142. # [15:46] * Joins: foolip (~philip@83.218.67.122)
  143. # [15:46] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  144. # [15:48] * riven` is now known as riven
  145. # [15:55] * Quits: foolip (~philip@83.218.67.122) (Quit: leaving)
  146. # [15:57] * Joins: philip__ (~philip@83.218.67.122)
  147. # [15:57] * philip__ is now known as foolip
  148. # [16:29] * Joins: yutak_home (~kee@R222116.ppp.dion.ne.jp)
  149. # [16:38] * Joins: kennyluck (~kennyluck@114-25-208-73.dynamic.hinet.net)
  150. # [16:53] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  151. # [17:04] * Quits: kennyluck (~kennyluck@114-25-208-73.dynamic.hinet.net) (Quit: kennyluck)
  152. # [17:06] * Quits: romeo_ (~romeo__@x1-6-00-10-a7-28-f3-47.k561.webspeed.dk) (Quit: Leaving)
  153. # [17:13] * bl4ckcomb_ is now known as bl4ckcomb
  154. # [17:16] * Quits: yutak_home (~kee@R222116.ppp.dion.ne.jp) (Quit: Ex-Chat)
  155. # [17:26] * Joins: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net)
  156. # [17:26] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
  157. # [17:33] * Quits: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net) (Remote host closed the connection)
  158. # [17:35] <AryehGregor> Like every tenth commit at http://dvcs.w3.org/hg/html/shortlog is "Merge". Lame.
  159. # [17:35] <AryehGregor> There is an hg rebase, you know.
  160. # [17:37] <Dashiva> The tools should save us
  161. # [17:37] <Philip`> One merge is mine but I was just copying jgraham
  162. # [17:37] <Philip`> so blame him
  163. # [17:37] <AryehGregor> Although hg has this crazy idea that it should call some basically arbitrary subset of its features "extensions" and disable them by default.
  164. # [17:38] <AryehGregor> So you have to add a line to your .hgrc to make it work.
  165. # [17:38] * AryehGregor also thinks that throwing up a Python backtrace when he hits Ctrl-C is lame
  166. # [17:38] * Philip` tries enabling rebase
  167. # [17:40] * Philip` fails to figure out how to actually use it, from the help page
  168. # [17:40] <AryehGregor> Just do "hg pull --rebase" instead of "hg pull" from now on. That should do it.
  169. # [17:40] <AryehGregor> Or do "hg pull; hg rebase".
  170. # [17:41] <AryehGregor> Or if that doesn't work, "hg rebase -b thelastrevisionIcommitted".
  171. # [17:45] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  172. # [17:47] <AryehGregor> When there are no actual conflicts, merge commits are just useless.
  173. # [17:48] <AryehGregor> And they make it harder to track down errors even where there are conflicts (see also git bisect).
  174. # [17:51] * Philip` agrees
  175. # [17:51] <Philip`> (I just wasn't aware there was an easy way to rebase)
  176. # [17:54] <AryehGregor> http://mercurial.selenic.com/wiki/GitConcepts
  177. # [17:55] <AryehGregor> I like how "git pull" is the same as "hg fetch" and "git fetch" is the same as "hg pull".
  178. # [17:55] <AryehGregor> Very clever.
  179. # [17:56] <AryehGregor> The equivalent of git commit --amend is apparently a sequence of three longish commands requiring an extension.
  180. # [17:56] <AryehGregor> LAME.
  181. # [17:56] <AryehGregor> That's one of my most-often used git commands.
  182. # [17:56] * Joins: paul_irish (~paul_iris@207-237-102-112.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com)
  183. # [17:57] <Philip`> "hg out" is one that I use pretty frequently, and the git equivalent looks hard to remember
  184. # [17:57] * Joins: exp (~zAyghip8@cpc2-ely02-0-0-cust338.5-1.cable.virginmedia.com)
  185. # [17:58] <AryehGregor> It's not hard at all. git log just accepts a revision range.
  186. # [17:58] <AryehGregor> So origin..HEAD means "all revisions between origin and HEAD".
  187. # [17:58] <AryehGregor> Where HEAD is what hg calls tip, and origin is upstream (dunno what hg calls it if anything).
  188. # [17:58] <espadrine> Today's git vs hg is yesterday's vi vs emacs!
  189. # [17:58] <AryehGregor> Usually I just look at git log, though.
  190. # [17:59] <AryehGregor> I mean, the ones I just committed are right on top, after all.
  191. # [17:59] <AryehGregor> espadrine, yeah, except indications so far look like git is going to win. At least it seems to be the one that open-source projects are switching to, much more so than hg or bzr.
  192. # [18:00] <AryehGregor> Maybe I'm wrong, but in MediaWiki, for example, I don't think anyone's even suggested switching from SVN to anything but git. Also GNOME just switched to git, I think . . .
  193. # [18:00] <AryehGregor> Although git is sometimes way too complicated.
  194. # [18:01] <AryehGregor> Like the staging area can be pretty confusing, although it's occasionally useful.
  195. # [18:01] <AryehGregor> (Like if you want to commit only some of your current changes, while leaving others alone.)
  196. # [18:01] <AryehGregor> (I've done that when, e.g., I found that I want to fix some typos and keep them in a separate commit from functional changes. git add -i, yay.)
  197. # [18:02] <espadrine> True. Complex management requires complex tools.
  198. # [18:03] <espadrine> But Git's got great docs! So it is, say, "less" an issue...
  199. # [18:03] <AryehGregor> Cheap local branching can be really confusing, too.
  200. # [18:03] <AryehGregor> It's nice, but . . . I've sometimes found myself committing to release branches when I meant to commit to trunk.
  201. # [18:03] <AryehGregor> Because there's no obvious indication.
  202. # [18:03] <AryehGregor> So I'm not sure that's a plus. (Although you could always just not use it, if you don't like it.)
  203. # [18:04] <AryehGregor> http://whygitisbetterthanx.com/ :)
  204. # [18:05] <espadrine> Wow, perforce is everywhere!
  205. # [18:05] <Philip`> Git's staging area sounds somewhat like Hg's mq
  206. # [18:05] * AryehGregor notes that the "git add" thing is not really a fair comparison, since "git add" does something very different from "hg add": it actually records all changes to the staging area, it doesn't just mark the file as tracked
  207. # [18:06] <AryehGregor> I haven't used mq, but I don't think so. There's only one staging area in git, it just stores all the stuff that you're planning to commit but haven't yet.
  208. # [18:06] <AryehGregor> So "git commit" will commit whatever's in the staging area, by default.
  209. # [18:06] * Joins: FireFly (~firefly@unaffiliated/firefly)
  210. # [18:06] <AryehGregor> "git add" adds changes from a file to the staging area. "git commit -a" is like running "git add" on all tracked files followed by "git commit".
  211. # [18:06] <AryehGregor> You can do "git add -i" to add only certain changes from a file to the staging area.
  212. # [18:07] <AryehGregor> Mostly it's an unnecessary extra abstraction, which can be confusing.
  213. # [18:07] <AryehGregor> E.g., "git diff" diffs the working copy against the staging area, not against HEAD.
  214. # [18:07] <AryehGregor> So it doesn't tell you what "git commit" will commit.
  215. # [18:07] <AryehGregor> It tells you the stuff you haven't staged yet.
  216. # [18:09] <AryehGregor> I do think git is harder to learn, even these days. The man pages are colossal.
  217. # [18:10] <AryehGregor> $ git help log | wc -l
  218. # [18:10] <AryehGregor> 1016
  219. # [18:10] <AryehGregor> $ hg help log | wc -l
  220. # [18:10] <AryehGregor> 46
  221. # [18:10] <AryehGregor> And it's not because there are tons of examples in the git help page, either.
  222. # [18:11] * Quits: paul_irish (~paul_iris@207-237-102-112.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) (Remote host closed the connection)
  223. # [18:11] * Quits: smaug____ (~chatzilla@cs181063178.pp.htv.fi) (Ping timeout: 264 seconds)
  224. # [18:11] <AryehGregor> git log just has more than 100 command-line options.
  225. # [18:15] * AryehGregor reads http://krijnhoetmer.nl/irc-logs/whatwg/20090714#l-102, where everyone rediscovers things that he's known for months
  226. # [18:16] <AryehGregor> Some browsers wrap out-of-range values (mainly WebKit), some clamp (mainly IE and Opera), some ignore the value and use default (mainly Gecko).
  227. # [18:17] <AryehGregor> Wait, this was well over a year ago.
  228. # [18:17] <AryehGregor> So I didn't know it at the time.
  229. # [18:17] <AryehGregor> Crazy dates.
  230. # [18:17] * Quits: espadrine (~espadrine@AMontsouris-157-1-89-175.w90-46.abo.wanadoo.fr) (Read error: Operation timed out)
  231. # [18:19] * Joins: espadrine (~espadrine@AMontsouris-157-1-89-175.w90-46.abo.wanadoo.fr)
  232. # [18:28] * Joins: Dashimon (Dashiva@wikia/Dashiva)
  233. # [18:28] <Philip`> Yeah, dates are a silly idea
  234. # [18:28] <jgraham> AryehGregor: Your opinion that dates are crazy somewhat undermines your opinion that hg is crazy
  235. # [18:28] <Philip`> Everything should happen simultaneously
  236. # [18:28] * Quits: Dashiva (Dashiva@wikia/Dashiva) (Ping timeout: 240 seconds)
  237. # [18:28] * Dashimon is now known as Dashiva
  238. # [18:28] <jgraham> Philip`: All you need to do it become a massless particle
  239. # [18:28] <jgraham> and your ish will be granted
  240. # [18:28] <jgraham> *wish
  241. # [18:29] <jgraham> (to avert any further flaming, I should note I like both hg and git)
  242. # [18:29] <AryehGregor> jgraham, come on, you have to agree that dates are crazy.
  243. # [18:29] <AryehGregor> Our units of temporal measurement, from seconds on up to months, are so complicated, asymmetrical and disjunctive so as to make coherent mental reckoning in time all but impossible. Indeed, had some tyrannical god contrived to enslave our minds to time, to make it all but impossible for us to escape subjection to sodden routines and unpleasant surprises, he could hardly have done better than handing down our present system. It is like a set o
  244. # [18:29] <AryehGregor> f trapezoidal building blocks, with no vertical or horizontal surfaces, like a language in which the simplest thought demands ornate constructions, useless particles and lengthy circumlocutions. Unlike the more successful patterns of language and science, which enable us to face experience boldly or at least level-headedly, our system of temporal calculation silently and persistently encourages our terror of time.
  245. # [18:29] <AryehGregor> … It is as though architects had to measure length in feet, width in meters and height in ells; as though basic instruction manuals demanded a knowledge of five different languages. It is no wonder then that we often look into our own immediate past or future, last Tuesday or a week from Sunday, with feelings of helpless confusion. …
  246. # [18:29] <AryehGregor> — Robert Grudin, Time and the Art of Living.
  247. # [18:29] <AryehGregor> http://www.gnu.org/software/automake/manual/tar/Date-input-formats.html
  248. # [18:30] <jgraham> Well date *formats* might be crazy
  249. # [18:31] <jgraham> Butmeasuing time is a surprisingly complex problem
  250. # [18:31] <espadrine> I love the definition of a second.
  251. # [18:32] <jgraham> and has legacy compatibility issues that make HTML look like a joke by comparison
  252. # [18:33] <AryehGregor> So does that mean the French revolutionaries who tried to introduce decimal time are like the XHTML WG?
  253. # [18:33] <Philip`> Do people who have to deal with relativity (measuring time precisely in satellites etc) have some clever new time system that doesn't make assumptions about it being absolute, or do they just use normal UTC dates/times and then hack it to cope with some drift?
  254. # [18:33] <aho> decimal time is awesome :>
  255. # [18:34] <aho> just like having 13 months with exactly 4 weeks each (and 1-2 extra days at the end of the year)
  256. # [18:35] <Druide__> hm
  257. # [18:36] <Druide__> does anyone know how the different browsers handle chunked transfer encoding when it comes to download content (javascript / css)?
  258. # [18:36] <Druide__> for ob_flush after the head content
  259. # [18:41] <AryehGregor> Philip`, cosmologists deal with relativity by just not talking about distances, don't they? They give the redshift of a star to tell you how far away it is, I think.
  260. # [18:42] <AryehGregor> (and then all the popular sources use some fairly arbitrary means of converting from redshift to light-years, which sometimes winds up to be well over 15 billion light-years, which is confusing)
  261. # [18:57] * Quits: eighty4 (~eighty4@unaffiliated/eighty4) (Quit: ZNC - http://znc.sourceforge.net)
  262. # [19:04] * Quits: exp (~zAyghip8@cpc2-ely02-0-0-cust338.5-1.cable.virginmedia.com) (Read error: Connection reset by peer)
  263. # [19:32] * Quits: dglazkov (~dglazkov@75-37-194-175.lightspeed.lsatca.sbcglobal.net) (Quit: dglazkov)
  264. # [19:33] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  265. # [19:36] * Joins: smaug____ (~chatzilla@KCMXXXII.gprs.sl-laajakaista.fi)
  266. # [19:38] * Joins: paul_irish (~paul_iris@NYUFGA-GUESTS-01.NATPOOL.NYU.EDU)
  267. # [19:43] * Quits: paul_irish (~paul_iris@NYUFGA-GUESTS-01.NATPOOL.NYU.EDU) (Remote host closed the connection)
  268. # [19:48] * Joins: eighty4 (~eighty4@unaffiliated/eighty4)
  269. # [19:55] * Joins: justinhjohnson (~justinjn@c-76-120-71-255.hsd1.co.comcast.net)
  270. # [19:56] * Joins: paul_irish (~paul_iris@NYUFGA-GUESTS-01.NATPOOL.NYU.EDU)
  271. # [19:56] <AryehGregor> Hmm, WebP.
  272. # [19:56] * Quits: justinhjohnson (~justinjn@c-76-120-71-255.hsd1.co.comcast.net) (Client Quit)
  273. # [19:56] * AryehGregor shrugs
  274. # [19:56] <AryehGregor> It'll be a long time till it's worth using over JPEG, with no fallback support.
  275. # [20:02] <Philip`> No need for fallback, just add the format into the Accept header
  276. # [20:04] <Philip`> It'll make every HTTP request about 16 bytes bigger but it'll save Google 20% of their bandwidth on some images, so it's a sacrifice the world should happily make
  277. # [20:04] * Joins: erlehmann (~erlehmann@dslb-094-223-087-097.pools.arcor-ip.net)
  278. # [20:06] <Philip`> (Seems the only advantage it has over any other better-than-JPEG format is that browsers with built-in WebM will already have the code for WebP)
  279. # [20:06] <Philip`> (and I don't know if that's a particularly significant advantage)
  280. # [20:07] * Quits: espadrine (~espadrine@AMontsouris-157-1-89-175.w90-46.abo.wanadoo.fr) (Quit: espadrine)
  281. # [20:10] <aho> sort of. reading binary data in c/c++ is error prone and leads to really awful security issues. having less code which does this kind of thing is better
  282. # [20:11] <aho> a few weeks ago they found yet another vuln in firefox's png loader for example... that's pretty amazing, given how old that code is
  283. # [20:13] <Philip`> The alternative here is to stick with JPEG, which is even less code than supporting WebP
  284. # [20:14] <AryehGregor> Accept headers are fine if you want to bother with configuring your web server, so I guess it'll work for Google, but not for random web apps.
  285. # [20:15] <AryehGregor> Unless they serve the images from a script anyway.
  286. # [20:15] <Philip`> Most of Google's web performance work seems to be aimed towards working for Google, not for random web apps
  287. # [20:16] * AryehGregor can't think of an immediate counterexample
  288. # [20:17] <AryehGregor> Does it have to be an extra 16 bytes on every HTTP request? Couldn't you do it just for image requests?
  289. # [20:17] <AryehGregor> Actually, come to think of it, they could just do UA sniffing.
  290. # [20:17] <AryehGregor> Which isn't a big problem for Google.
  291. # [20:17] <AryehGregor> Although it's a real pain for regular web app developers who aren't testing 24/7, feature-testing is much better for them.
  292. # [20:18] <AryehGregor> You could do feature-testing too if you wanted, using JS, I guess. Maybe set a cookie.
  293. # [20:18] <Philip`> Regular web app developers can use JPEG and be done with it, and if they really care about performance then they can make sure they're using sensible JPEG quality settings and probably save 50% of their filesize
  294. # [20:19] <AryehGregor> It's kind of awkward to make the Accept header bigger forever when if it works out, everyone will support it five or ten years from now anyway.
  295. # [20:19] <AryehGregor> Yeah, random web apps probably have much bigger performance problems than large JPEGs anyway.
  296. # [20:23] <Philip`> (I think Google's shared dictionary compression thing sounds like one of the more extreme examples of a proposed standard feature that nobody except Google is likely to use, since it looks extremely complex to set up properly and likely to give very little gain in most cases)
  297. # [20:23] <Philip`> (but since they've got Chrome now they can make up these features and get them deployed unilaterally)
  298. # [20:23] <AryehGregor> Yes, that's true.
  299. # [20:24] * Joins: romeo_ (~romeo__@x1-6-00-10-a7-28-f3-47.k562.webspeed.dk)
  300. # [20:24] <AryehGregor> SDCH sounds too complicated for even Google to use effectively except in special cases.
  301. # [20:24] <AryehGregor> But there are other things that could be just written into web servers, like HTTPS performance improvements.
  302. # [20:24] <Philip`> Maybe the most useful thing for performance is profiling tools
  303. # [20:25] <Philip`> rather than new technologies that people don't know when to use
  304. # [20:25] <AryehGregor> That's only good for people who are spending lots of time trying to improve performance. For random websites, improving the web server or programming language or browser will provide better gains.
  305. # [20:25] <AryehGregor> Particularly the browser, there's lots of stuff to be done there.
  306. # [20:26] <AryehGregor> Steve Souders' last blog post basically pleaded with browser implementers to do something like Opera has an experimental mode for, where you render the whole page before or while you run scripts instead of waiting for scripts to finish before rendering HTML after them.
  307. # [20:27] <aho> well, there is this "fast by default" thing. i.e. a server could do some optimizations out of the box. and a CMS can do even more.
  308. # [20:27] <Philip`> If people writing random websites spent five seconds looking in a profiling tool to see that their page loads are being delayed by five seconds by embedding a dozen buttons and widgets from third-party sites, they could easily make huge improvements
  309. # [20:27] <aho> SPDY is one of those things. if support is there, things would be faster. 0 effort required :>
  310. # [20:28] <AryehGregor> Yes, SPDY has a lot of potential.
  311. # [20:28] <AryehGregor> Although of course it only works over SSL.
  312. # [20:28] <AryehGregor> There goes your whole "random websites" thing.
  313. # [20:28] * Joins: maikmerten_ (~maikmerte@port-92-201-192-125.dynamic.qsc.de)
  314. # [20:28] <aho> ye, that ssl thing is also bugging me
  315. # [20:29] <AryehGregor> Actually, maybe browsers could support SPDY over HTTP by doing an SSL handshake with dummy authentication, and treating it as HTTP for all purposes (cookies, UI, etc.).
  316. # [20:29] <AryehGregor> So you wouldn't need an actual certificate to deploy it, but it would be encrypted to foil dumb proxies.
  317. # [20:30] <AryehGregor> Or maybe HTTPS could be updated to support sane methods of authentication that normal sites can actually deploy.
  318. # [20:30] <AryehGregor> You know, just a thought.
  319. # [20:31] * Quits: maikmerten (~maikmerte@port-92-201-96-131.dynamic.qsc.de) (Ping timeout: 276 seconds)
  320. # [20:31] <AryehGregor> DNSSEC will be an improvement, when browsers support getting certificate signatures from there instead of CAs, but it still will require significant configuration.
  321. # [20:32] <variable> duno if this is exactly on topic - but I HATE when web browsers put all these "broken website" alerts when HTTPS certs fails. Its still better than nothing
  322. # [20:32] <AryehGregor> variable, not if the reason the certificate is wrong is because a MITM is intercepting your connection.
  323. # [20:32] <variable> AryehGregor, its still better than pure http.
  324. # [20:33] <AryehGregor> If there's a MITM, it's worse than failing the connection.
  325. # [20:33] <variable> its either "its possible that one person is MITMing you" or "anyone in the world could mitm you"
  326. # [20:33] <AryehGregor> Look at it from the browser's point of view, not the site's.
  327. # [20:33] <AryehGregor> The point of SSL is that there can be no MITM.
  328. # [20:33] <variable> so in the event that SSL fails go to pure http?
  329. # [20:33] <AryehGregor> No, fail completely.
  330. # [20:34] <AryehGregor> Which is what browsers do.
  331. # [20:34] <variable> if browsers put up the same warning for pure http pages I wouldn't have a problem
  332. # [20:34] <AryehGregor> They don't try to switch to HTTP.
  333. # [20:34] <variable> I'd rather have the encryption
  334. # [20:34] <variable> and have the chance for /one/ person to MITM me
  335. # [20:34] <variable> than have the chance for /anyone/ to mitm me
  336. # [20:34] <AryehGregor> That's different. Pure HTTP means "we have no reason to believe this site ever intended to be secure". HTTPS with bad cert might mean "this site is supposed to be secure but someone is MITMing it".
  337. # [20:35] <AryehGregor> If a site is being accessed over HTTP in the first place, the assumption is that there's not anything much worth MITMing, e.g., credit card numbers.
  338. # [20:35] <AryehGregor> And hmm? HTTPS without a signed cert means anyone can MITM you, same as HTTP.
  339. # [20:35] <AryehGregor> Now, I agree that the UI here is terrible.
  340. # [20:35] <AryehGregor> Generally it's an outright lie.
  341. # [20:35] <variable> AryehGregor, but - that means that only /one/ person can sniff the data instead of /everyone/
  342. # [20:36] <variable> perhaps there can be something like httpE which means "use ssl and ignore failing certificates. also don't show the padlock but please be encrypted"
  343. # [20:36] <AryehGregor> I'd think everyone could still sniff it. You'd just have to chain the attacks. But it's immaterial -- multiple MITMs are no worse than one.
  344. # [20:36] <AryehGregor> variable, http://tcpcrypt.org
  345. # [20:36] <AryehGregor> That's the solution I'd like to see for encryption-without-authentication.
  346. # [20:36] * Quits: hjjaa (~ghe@132.150.124.56) (Read error: Connection reset by peer)
  347. # [20:37] <AryehGregor> Its goal is to encrypt all TCP traffic, at the transport layer, transparently to applications, in a way that makes implementing auth on top of it very easy.
  348. # [20:37] * Joins: hjjaa (~ghe@132.150.124.56)
  349. # [20:37] <AryehGregor> In a fashion that can be deployed now, with existing routers and so on that try to interfere with traffic.
  350. # [20:37] <AryehGregor> All adding no more overhead than one round-trip on the first connection to a site.
  351. # [20:37] <AryehGregor> (plus encryption/decryption, which is typically negligible)
  352. # [20:38] <variable> AryehGregor, multiple MITMs can be worse than one. I'd like to see tcpcrypt as well. in terms of not failing SSL connections its a shorter term solution
  353. # [20:38] <AryehGregor> tcpcrypt is a short-term solution.
  354. # [20:38] <AryehGregor> It could theoretically be deployed now.
  355. # [20:38] * Quits: foolip (~philip@83.218.67.122) (Ping timeout: 240 seconds)
  356. # [20:38] <AryehGregor> On Linux, you just have to compile and run the provided user-space daemon, you don't even need kernel changes.
  357. # [20:39] * Joins: foolip (~philip@83.218.67.122)
  358. # [20:39] <variable> but it requires that both sides agree to deploy it. allowing SSL connections to not fail (but not showing the padlock/good ssl signs) would only require one side to change
  359. # [20:39] <variable> I agree that tcpcrypt is a better long term solution
  360. # [20:39] <AryehGregor> Allowing unsigned certs also requires both sides to deploy it: the browser to accept the cert, the site to provide the cert.
  361. # [20:39] <AryehGregor> Not really any different.
  362. # [20:40] <AryehGregor> Anyway, I'm hoping that when STS is widely used, implementers can be persuaded to downplay error messages from bad certs if STS isn't present.
  363. # [20:40] * Quits: maikmerten_ (~maikmerte@port-92-201-192-125.dynamic.qsc.de) (Remote host closed the connection)
  364. # [20:40] <AryehGregor> On the theory that all sites that really need SSL should be using STS.
  365. # [20:40] <AryehGregor> SSL without STS has pretty huge holes, as commonly implemented.
  366. # [20:40] <AryehGregor> Since usually then the HTTP version of the site will just redirect to the HTTPS version, so just MITM it at that point . . .
  367. # [20:41] * Quits: Druide__ (~druid@p5B134CD2.dip.t-dialin.net) (Ping timeout: 276 seconds)
  368. # [20:41] * AryehGregor notes Strict-Transport-Security:max-age=500 on paypal.com
  369. # [20:41] <AryehGregor> That's way too short, it should be like a year.
  370. # [20:41] <variable> AryehGregor, perhaps there can be some server side header x-fail-bad-ssl or x-really-need-to-be-secure. while regular SSL could be intrepreted to be "just encrpyption"
  371. # [20:42] <variable> meh
  372. # [20:42] <AryehGregor> variable, that's Strict-Transport-Security.
  373. # [20:42] <AryehGregor> Currently being deployed.
  374. # [20:42] <variable> AryehGregor, I was about to mention that
  375. # [20:42] <variable> then I look up
  376. # [20:42] <variable> and saw you did ;-)
  377. # [20:42] <variable> meh
  378. # [20:42] * AryehGregor is surprised to see that amazon.com forces HTTP for browsing
  379. # [20:42] <AryehGregor> I guess they switch to HTTPS for checkout, but still.
  380. # [20:43] <variable> switching to ssl for checkout is silly
  381. # [20:44] <variable> you could still MITM it before then
  382. # [20:44] <variable> imho all sites that need it should be using SSL from homepage until the user leaves the site
  383. # [20:44] <AryehGregor> That's true.
  384. # [20:44] <AryehGregor> Just spoof the checkout link.
  385. # [20:44] <AryehGregor> Easy to do.
  386. # [20:44] * Joins: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net)
  387. # [20:44] <variable> for sites that can't handle the load I am not against developing some pre-encrypted home page type thing
  388. # [20:44] <AryehGregor> Of course, you could just spoof the whole site.
  389. # [20:45] * Joins: Druide__ (~druid@p5B1364EE.dip.t-dialin.net)
  390. # [20:45] <variable> which is why a lot of banks don't use SSL on the homepage
  391. # [20:45] <AryehGregor> In which case this is all useless.
  392. # [20:45] <variable> AryehGregor, I was thinking of sslstrip
  393. # [20:45] <Philip`> On Amazon I thought you rarely typed in any sensitive information, since the site remembers your login name and payment details etc
  394. # [20:45] <AryehGregor> Which is why what I really want to see is something like Mozilla Account Manager becoming standard in all browsers, then possibly add some way to force SRP.
  395. # [20:46] <Philip`> so it'd be quite suspicious if it was MITMed and you went to checkout and it asked you to type everything in again
  396. # [20:46] <variable> AryehGregor, are you phycic? I was about to say that ;-)
  397. # [20:46] <variable> *psychic
  398. # [20:46] <AryehGregor> Philip`, users are used to typing their passwords when asked. So I don't think it's suspicious.
  399. # [20:46] <AryehGregor> variable, including SRP?
  400. # [20:46] <AryehGregor> Not many people seem to know about SRP or PAKE.
  401. # [20:46] <variable> Philip`, I rarely tell amazon to remember my addrss/CC numbers - mostly cause it changes so often
  402. # [20:46] * Philip` rarely has any idea what his password is, he just expects the browser to autofill it
  403. # [20:46] <AryehGregor> My crypto professor covered it in the last class (PAKE generally, not SRP).
  404. # [20:47] <variable> AryehGregor, the stanford project?
  405. # [20:47] <AryehGregor> It's an RFC.
  406. # [20:47] <variable> heh - didn't know that
  407. # [20:47] <AryehGregor> http://en.wikipedia.org/wiki/Secure_remote_password_protocol
  408. # [20:47] <variable> AryehGregor, I knew of SRP - but I thought it was a stanford thing
  409. # [20:47] <AryehGregor> Is it a Stanford projecT?
  410. # [20:47] <AryehGregor> project?
  411. # [20:48] <AryehGregor> Seems so.
  412. # [20:48] <AryehGregor> Unfortunately, it's useless unless you have some way to ensure that attackers can't substitute UI that will submit the passwords in cleartext.
  413. # [20:48] <AryehGregor> Anyone who makes a new application protocol that uses any password authentication that permits an MITM to gain any information about the password should be shot.
  414. # [20:49] <variable> Philip`, I tell my browser the password currently. soon I'm going to switch to having the browser generate it now that mozilla has a sync option
  415. # [20:49] <AryehGregor> variable, I'd do that if different browsers would sync passwords between each other.
  416. # [20:49] <variable> AryehGregor, well - they shouldn't be desining the protocalls
  417. # [20:49] <variable> *designing the protocalls if they don't know what they are doing
  418. # [20:50] <AryehGregor> Chrome and Firefox both have some type of sync, now why can't they sync with each other?
  419. # [20:50] <AryehGregor> I don't think Chrome syncs passwords at all, though.
  420. # [20:50] <variable> AryehGregor, chrome syncs p/wds
  421. # [20:50] <variable> but not between FF & chrome
  422. # [20:50] <variable> Xmarks used to do that
  423. # [20:50] <variable> but they failed :-(
  424. # [20:50] <AryehGregor> Is that under "Autofill"?
  425. # [20:50] <variable> I'm not sure
  426. # [20:50] <variable> I rarely use chrome
  427. # [20:50] * Joins: WHATWG (~apermanen@cpe-76-168-89-210.socal.res.rr.com)
  428. # [20:50] <AryehGregor> I don't want to sync my passwords to Windows machines. I treat all Windows machines as potentially compromised.
  429. # [20:50] <variable> and I don't have it on this compy
  430. # [20:51] <AryehGregor> Easier that way.
  431. # [20:51] <variable> AryehGregor, are you in the "Linux/macs can't get viruses" club ?
  432. # [20:51] <AryehGregor> I'm in the "Linux/Mac is very unlikely to get viruses in practice" club.
  433. # [20:51] * abarth|crash is now known as abarth
  434. # [20:51] <AryehGregor> Of course they *can*.
  435. # [20:52] <variable> AryehGregor, slightly unrelated: do you know of google's autocomplete SSL-packetsize info leakage vuln? its quite fun
  436. # [20:52] <AryehGregor> Fun recent blog post: http://tstarling.com/blog/2010/09/desktop-linux-security-complacency/
  437. # [20:52] <AryehGregor> I don't think I've heard of it. Is it your standard "SSL leaks info about keystrokes if you send them as soon as you type" kind of thing?
  438. # [20:52] <variable> AryehGregor, yeah
  439. # [20:53] <variable> most linux distros use sudo for root tasks which is stupid from a security point of view
  440. # [20:53] <AryehGregor> Well, there's really no way to completely prevent that kind of attack unless you just saturate the channel with noise. For a low-bandwidth thing like autosuggest that might be feasible, though, if you impose a very low maximum bandwidth.
  441. # [20:53] <AryehGregor> Stupid compared to what?
  442. # [20:53] <variable> AryehGregor, you should be using su for root tasks
  443. # [20:53] <variable> and delete sudo
  444. # [20:53] <AryehGregor> Why?
  445. # [20:54] <AryehGregor> su means I leave root shells lying open.
  446. # [20:54] <variable> no - use su -c if you really need to
  447. # [20:54] <variable> because sudo uses your password and su uses roots
  448. # [20:54] <AryehGregor> So?
  449. # [20:54] <variable> and that means you lose the double-factor authentication of root
  450. # [20:54] <AryehGregor> (It can be configured to use root's password, by the way.)
  451. # [20:54] <AryehGregor> (sudo, I mean.)
  452. # [20:54] <AryehGregor> In what circumstances would that double-factor authentication make any difference at all on a typical mostly-one-user desktop?
  453. # [20:54] <variable> AryehGregor, its not by default. If they did that it wouldn't be bad
  454. # [20:55] <AryehGregor> It's not by default, but you can easily change it if you like.
  455. # [20:55] <AryehGregor> On a single-user machine, I don't see the point at all.
  456. # [20:55] <variable> AryehGregor, the reason for asking for a password is typically so that if somone managed to guess/crack your SSH password they can't get root without a second password
  457. # [20:55] <AryehGregor> On a multi-user machine, it means you have to change the root password whenever an admin enters or leaves, which is a pain.
  458. # [20:56] <variable> AryehGregor, the best possibility is to allow multiple root passwords
  459. # [20:56] <variable> and give each account their own root p/w
  460. # [20:56] <AryehGregor> On a single-user machine, getting user access is practically equivalent to getting root access anyway.
  461. # [20:56] <variable> and then just delete it when they leave
  462. # [20:57] <AryehGregor> You get all the user's data and can mess with their programs however you like.
  463. # [20:57] <AryehGregor> Once you control a user's account, just alter $PATH so that they use your hacked sudo or su or whatever.
  464. # [20:57] <AryehGregor> Then they get the root password too.
  465. # [20:57] <AryehGregor> You can even change their shell if you like.
  466. # [20:57] <AryehGregor> And there are GUI equivalents here too.
  467. # [20:57] <variable> AryehGregor, I have all my single user machines configured in a very specific way: a) if you compromise my user account you get my data but then I just restore from backup and go on with life. b) if you compromise root it is likely that I need to reinstall from scratch
  468. # [20:58] <AryehGregor> And you prevent them from getting the root password how, once they get access to your regular user account?
  469. # [20:58] <variable> if I thought my account was compromised I'd probably boot into single user mode to get root
  470. # [20:58] <variable> if they altered my path - and I used su during that time - I'm probably screwed
  471. # [20:58] <variable> the root password is encrypted?
  472. # [20:58] <AryehGregor> Doesn't help if they alter $PATH.
  473. # [20:59] <AryehGregor> You could improve things a bit, of course.
  474. # [20:59] <variable> yeah - I could probably harden my machine a bit
  475. # [20:59] <AryehGregor> I meant from the perspective of sudo's developers.
  476. # [20:59] <variable> yeah
  477. # [20:59] <AryehGregor> Like make "sudo" a shell built-in that refers to a binary that has to have a particular digital signature, and make the actual sudo binary check what program is invoking it and bail out if it's not a recognized shell.
  478. # [21:00] <AryehGregor> That doesn't stop this: while ! sudo -n true </dev/null >/dev/null 2>&1 ; do sleep 1; done ; sudo id </dev/null 2>&1 | cat
  479. # [21:00] <variable> AryehGregor, the sudo idea of giving selective root access is a fine idea - I just don't like that it is tied to the user's password
  480. # [21:00] <variable> AryehGregor, ""while ! sudo -n true </dev/null >/dev/null 2>&1 ; do sleep 1; done ; sudo id </dev/null 2>&1 | cat" will fail if sudo " will fail if su is used over sudo
  481. # [21:00] <AryehGregor> Because su forces you to type your password every single time?
  482. # [21:00] <variable> yes
  483. # [21:01] <AryehGregor> sudo can be configured that way too, but then people will just leave root shells open.
  484. # [21:01] <AryehGregor> Which makes physical security much worse.
  485. # [21:01] <variable> a root shell open is fine
  486. # [21:01] <variable> for me
  487. # [21:01] <variable> cause I just do lock -npv
  488. # [21:01] <variable> meh - I'd like to see something like sudo which gives selective root access based on a /second/ non-root's password
  489. # [21:02] <variable> along with somethinh like tsu
  490. # [21:02] <variable> which gives you a root shell for say 5 minutes
  491. # [21:02] <variable> and then closes it
  492. # [21:02] * variable made up tsu now
  493. # [21:02] * variable writes tsu now
  494. # [21:02] <variable> AryehGregor, that article you linked to above is a very interesting read
  495. # [21:04] * Quits: mamund (mamund@frost.nullshells.net) (Ping timeout: 240 seconds)
  496. # [21:06] <variable> AryehGregor, do you know of any other secrurity oriented blogs? I have my stock but I'm looking for less newsy and more technical oriented blogs
  497. # [21:07] <variable> *security
  498. # [21:07] <AryehGregor> tstarling.com isn't security-oriented, theoretically.
  499. # [21:07] <AryehGregor> It's just the blog of a MediaWiki developer, who's sometimes interested in security (and who happens to almost never post).
  500. # [21:07] <Philip`> AryehGregor: Isn't physical security already terrible, since someone could reboot your machine with a bootable CD and access all your files, just as easily as they could use one of the root shells you've left open?
  501. # [21:07] <AryehGregor> Bruce Schneier's blog is a fairly standard one, although it's high-traffic and somewhat noisy.
  502. # [21:08] <AryehGregor> Philip`, not just as easily. One of those two can be done instantly, the other requires several minutes and looks much more suspicious.
  503. # [21:08] <variable> I read Bruce Schneieir - but that is far more newsy than I'm looking for
  504. # [21:08] <AryehGregor> Particularly if you configure BIOS to have a password and not boot from CDs, in which case they'll have to take apart your computer to reset the BIOS.
  505. # [21:08] <variable> he used to have better - more in depth articles
  506. # [21:09] * AryehGregor looks over his blog subscription list
  507. # [21:09] <AryehGregor> imperialviolet.org is good, although it doesn't have so many posts.
  508. # [21:09] <AryehGregor> (more than tstarling.com)
  509. # [21:10] * Joins: mamund (mamund@66.90.103.125)
  510. # [21:10] * AryehGregor sees no others offhand
  511. # [21:10] <variable> I like xor eax eax a lot
  512. # [21:10] <AryehGregor> They haven't gotten promoted to xor rax rax yet? :)
  513. # [21:11] <AryehGregor> I'm getting only noise Googling for "xor eax eax", what's the URL?
  514. # [21:12] <variable> sorry - its xorl eax eax
  515. # [21:12] <variable> https://xorl.wordpress.com/
  516. # [21:12] <AryehGregor> Bah, the L is redundant.
  517. # [21:13] <AryehGregor> Looks rather low-level for me (although maybe I should have guessed from the name).
  518. # [21:13] * AryehGregor subscribes anyway, why not
  519. # [21:15] <variable> https://xorl.wordpress.com/2010/01/13/cve-2001-0053-openbsd-ftpd-remote-off-by-one-overwrite/ --> he exlains one the few openBSD security bugs
  520. # [21:16] * Quits: mamund (mamund@66.90.103.125) (Ping timeout: 264 seconds)
  521. # [21:16] * Joins: mamund (mamund@66.90.103.125)
  522. # [21:16] <AryehGregor> Who cares about OpenBSD security bugs? They're too small a target for anyone to attack in practice anyway.
  523. # [21:16] <variable> Imperial Violiate looks interesting
  524. # [21:17] <AryehGregor> Serious hackers go after profitable targets.
  525. # [21:17] <AryehGregor> If you're not huge, then you only have to worry about script kiddies.
  526. # [21:17] <variable> AryehGregor, cause /a lot/ of other projects use OpenBSD software. And cause it was an interesting one ;-)
  527. # [21:17] <variable> imagine a security bug in openSSH
  528. # [21:17] <variable> meh - I just thought it was interesting
  529. # [21:18] <AryehGregor> These C/C++ bugs mostly look repetitive to me. If you play with fire, you're going to get burned.
  530. # [21:18] <AryehGregor> Same with XSS in a typical PHP app. The setup practically guarantees the vulnerabilities.
  531. # [21:18] <variable> in certain cases you need a low level language (kernel anyone?)
  532. # [21:19] <AryehGregor> Yes, true.
  533. # [21:19] <variable> using the wrong language for the wrong type of project is silly - I agree
  534. # [21:19] <AryehGregor> At least for some parts of the kernel.
  535. # [21:19] <variable> no very high level project should be using C
  536. # [21:19] <variable> heck - I'd even like to see kernels written in embedded C++
  537. # [21:20] <AryehGregor> Microsoft's Singularity project has a kernel written in C#, with a few extensions, including the ability to use inline assembly.
  538. # [21:20] <AryehGregor> (which apparently is used roughly in the places where you'd use it in a C kernel)
  539. # [21:20] <AryehGregor> Unfortunately, the performance/security tradeoff just doesn't work out in favor of more secure languages for a lot of programs.
  540. # [21:20] <AryehGregor> You'd think you could at least avoid pointer arithmetic most of the time, though. That's the real killer.
  541. # [21:21] <AryehGregor> (as far as I can see)
  542. # [21:22] <variable> It would be interesting to see a probably secure microkernel
  543. # [21:22] <variable> IIRC there was a project to write one
  544. # [21:22] <AryehGregor> Then you just move all the security bugs to userspace.
  545. # [21:22] <AryehGregor> Doesn't help much to eliminate them.
  546. # [21:22] <variable> yeah - but they do a lot less damage that way
  547. # [21:23] <variable> of course - its a lot slower
  548. # [21:23] <AryehGregor> Not really. A memory management or filesystem daemon can do just as much damage as a kernel.
  549. # [21:23] <AryehGregor> Stuff like network drivers could profitably be pushed to userspace, from a security perspective.
  550. # [21:23] <AryehGregor> But it's sort of pointless for stuff like the scheduler, as far as I can tell.
  551. # [21:24] <AryehGregor> If you control that sort of thing, you control the system, or close enough.
  552. # [21:24] <AryehGregor> It's like running X as a non-root user but still giving it direct access to keyboard and mouse input. Great, so you have to wait till someone types a password.
  553. # [21:26] <Philip`> variable: "a probably secure microkernel" - did you mean "provably"? (That letter makes quite a difference...)
  554. # [21:26] <variable> Philip`, erm - yes
  555. # [21:28] <variable> that was a bad typo
  556. # [21:28] * variable has to get better at typing
  557. # [21:33] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  558. # [21:34] <Hixie> probably more accurate as "probably", as per the rest of the discussion :-)
  559. # [21:34] * Parts: AryehGregor (~Simetrica@mediawiki/simetrical) ("Leaving")
  560. # [21:34] * Joins: AryehGregor (~Simetrica@mediawiki/simetrical)
  561. # [21:35] <AryehGregor> Man, I hate XChat.
  562. # [21:35] <AryehGregor> I don't even know what key combination I pressed to make me /part.
  563. # [21:35] <AryehGregor> There should not *be* any key combination that makes you /part.
  564. # [21:37] * Joins: sebmarkbage (d5506daa@gateway/web/freenode/ip.213.80.109.170)
  565. # [21:37] <variable> Hixie, I was thinking of a /provably/ secure kernel
  566. # [21:37] <AryehGregor> Doesn't help much without a provably secure userspace.
  567. # [21:38] <AryehGregor> I think Chrome OS's approach is sounder in practice, although it's not as theoretically nice.
  568. # [21:38] <variable> I don't know much about how chrome os works
  569. # [21:38] <Philip`> "Beware of bugs in the above code; I have only proved it correct, not tried it."
  570. # [21:38] <AryehGregor> Basically a chain of trust.
  571. # [21:38] <AryehGregor> It has read-only firmware that checks the signature of the read-write firmware, which checks the signature on the kernel, which checks the signature on every block of the root filesystem as it reads it.
  572. # [21:39] <AryehGregor> All signed by Google.
  573. # [21:39] <AryehGregor> If any signature doesn't match, the user is asked if they want to reinstall the OS.
  574. # [21:39] <Philip`> What if the user says no?
  575. # [21:39] <AryehGregor> All data is stored in the cloud, so data is just wiped.
  576. # [21:39] <variable> Philip`, the idea of a provable kernel is that you could match the code to the theory
  577. # [21:39] <AryehGregor> Then they can keep using it.
  578. # [21:39] <AryehGregor> As long as they say no every single time they boot the machine.
  579. # [21:40] <AryehGregor> Or they can possibly open up the machine and fiddle with jumpers to install their own read-only firmware (it's not meant to protect against physical attacks, yet).
  580. # [21:40] <Philip`> AryehGregor: That sounds like a security hole, since users are being a choice between two buttons of which one means "yes, please spend some minutes doing nothing visible while downloading some code" and the other means "just let me get on with my work"
  581. # [21:41] <AryehGregor> Philip`, yeah, but a) it will probably strongly advise them to say "yes", and they don't know that "no" means "let me get on with my work"; and b) they'll get sick of the nagging eventually.
  582. # [21:41] <Philip`> so the people who don't guess a response at random are more likely to pick the second option
  583. # [21:42] <AryehGregor> The point isn't to make attacks impossible, that's always overkill. You just need to make them too difficult to be worth the payoff.
  584. # [21:42] <Dashiva> AryehGregor: Isn't it enough for the attacker if they say no once?
  585. # [21:42] <AryehGregor> You're drastically reducing the number of machine-hours you can steal.
  586. # [21:42] <AryehGregor> Dashiva, no, because then it will happen again when they reboot, since the signature still won't match.
  587. # [21:42] <AryehGregor> The read-only firmware doesn't know that they said no before (how could it?).
  588. # [21:43] <Dashiva> But the attacker will have had a whole session to do whatever he wanted
  589. # [21:43] <AryehGregor> Sure, but they can't compromise the machine for longer than one session, in the normal case.
  590. # [21:43] <AryehGregor> So it makes attacks drastically less attractive than in the usual desktop case.
  591. # [21:43] <Dashiva> He just needs to steal your password once :)
  592. # [21:44] <AryehGregor> Did I mention that absolutely everything in userspace uses every single Linux sandboxing technique in existence?
  593. # [21:44] <AryehGregor> Process namespacing, chroot, etc. Like Chrome itself.
  594. # [21:45] <AryehGregor> And users can't install normal programs, only web apps.
  595. # [21:45] <AryehGregor> So it's going to be very difficult to get user-level access to begin with.
  596. # [21:45] <AryehGregor> And once you have it, it's wiped out on reboot.
  597. # [21:45] <AryehGregor> Nothing's perfect, but this raises the bar enormously.
  598. # [21:45] <Dashiva> If it's going to be a very rare occurence to begin with, why give the user a choice to do the insecure option?
  599. # [21:46] <AryehGregor> Plus, of course, everything silently auto-updates.
  600. # [21:46] <AryehGregor> Dashiva, because maybe the user wants to install their own custom unsigned firmware and OS.
  601. # [21:46] <AryehGregor> I.e., it's to allow jailbreaking the device.
  602. # [21:46] <Philip`> The read-only firmware doesn't auto-update
  603. # [21:47] <AryehGregor> Well, no, but all it does is verify the read-write firmware. That doesn't need much updating.
  604. # [21:47] <Philip`> Doesn't it have to have most of an OS in it, in order to re-download the rest of the system?
  605. # [21:47] <AryehGregor> (for all I know this has all been rewritten since Chrome OS launched, by the way, I haven't been following it closely)
  606. # [21:47] <AryehGregor> No, it instructs the user how to download and install a new OS copy via USB or something, IIRC.
  607. # [21:48] <Philip`> Oh, okay, that part's not very auto then
  608. # [21:48] <AryehGregor> No.
  609. # [21:48] <Dashiva> AryehGregor: That should be as simple as Google providing a read-write firmware that allows jailbreaking, shouldn't it?
  610. # [21:48] <AryehGregor> In principle that's avoidable. Like keep a pristine OS copy on a separate partition, and make the read-only firmware decide which partition to expose to the read-write firmware.
  611. # [21:48] <AryehGregor> Dashiva, well, yes, but they wouldn't sign it, because then they can't guarantee your security.
  612. # [21:49] <AryehGregor> An attacker could just load that firmware and install their evil app.
  613. # [21:49] <AryehGregor> The signed firmware will not allow installing anything at all except web apps.
  614. # [21:49] <Philip`> What happens when someone steals Google's key?
  615. # [21:49] <AryehGregor> Then the entire scheme collapses, obviously.
  616. # [21:49] <Dashiva> Chrome OS allows any program to replace the firmware?
  617. # [21:50] <AryehGregor> Dashiva, no, but if you can install a program to begin with, you have illicit root access, so you can presumably also replace the firmware.
  618. # [21:50] <variable> Philip`, then chrome OS becomes as secure as any other peice of software ?
  619. # [21:50] <AryehGregor> Since programs can't normally be installed at all. The entire root filesystem is signed by Google, every block, and probably other filesystems are mounted noexec.
  620. # [21:50] <AryehGregor> (and probably they've hacked the script interpreters to not run stuff in noexec filesystems)
  621. # [21:50] <AryehGregor> Or whatever.
  622. # [21:51] <AryehGregor> I don't know, go read the design docs.
  623. # [21:51] <AryehGregor> http://www.chromium.org/chromium-os
  624. # [21:51] <AryehGregor> http://www.chromium.org/chromium-os/chromiumos-design-docs
  625. # [21:51] <AryehGregor> http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
  626. # [21:56] <AryehGregor> "Avoiding replay/rollback attacks is non-trivial since the firmware can't guarantee the local clock is not changed." Whee.
  627. # [21:56] <AryehGregor> Didn't think of that.
  628. # [22:00] <Philip`> CPUs should include an embedded GPS receiver to provide a secure accurate time source
  629. # [22:01] <Dashiva> What if you're indoors?
  630. # [22:02] <Philip`> Cut a hole in your ceiling
  631. # [22:03] <Dashiva> The attacker could cover the hole
  632. # [22:04] <Philip`> Then the CPU would self-destruct
  633. # [22:05] * Philip` wonders if GPS satellites use good encryption, or whether an attacker could launch their own fleet of GPS satellites to trick receivers
  634. # [22:07] * AryehGregor bets they use no encryptionl
  635. # [22:07] <AryehGregor> encryption.
  636. # [22:08] <Dashiva> It's military, of course there's no encryption
  637. # [22:08] <AryehGregor> Well, I guess they support the capability, right? The US can turn on encryption so only military personnel get the full accuracy.
  638. # [22:08] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  639. # [22:08] <AryehGregor> But Clinton turned it off. Or something.
  640. # [22:09] * Quits: paul_irish (~paul_iris@NYUFGA-GUESTS-01.NATPOOL.NYU.EDU) (Remote host closed the connection)
  641. # [22:09] <AryehGregor> Oh, Chrome OS supposedly has a stable version next month?
  642. # [22:09] <variable> AryehGregor, there is a fuzz factor in GPS that is currently set to 0
  643. # [22:09] <variable> I'm not sure how the millitary gets accurate data when that is set to > 0
  644. # [22:11] <AryehGregor> They can do it somehow.
  645. # [22:11] <AryehGregor> Maybe they just get told what the fuzzing algorithm is, so they can reverse it.
  646. # [22:12] * Quits: Ms2ger (~Ms2ger@91.181.27.197) (Ping timeout: 245 seconds)
  647. # [22:13] * Joins: gratz|home (~gratz@cpc1-brig9-0-0-cust27.3-3.cable.virginmedia.com)
  648. # [22:14] <AryehGregor> http://en.wikipedia.org/wiki/GPS_signals
  649. # [22:14] <AryehGregor> Apparently they emit two signals, a C/A-code and a P-code, and the P-code is encrypted.
  650. # [22:16] <AryehGregor> Oh, wait, I have to read longer.
  651. # [22:16] <AryehGregor> Yeah, well, anyway, it's complicated.
  652. # [22:17] <AryehGregor> But at least the military gets unspoofable (or hard-to-spoof) signals.
  653. # [22:19] * Quits: gratz|home (~gratz@cpc1-brig9-0-0-cust27.3-3.cable.virginmedia.com) (Quit: Leaving)
  654. # [22:23] * Quits: sebmarkbage (d5506daa@gateway/web/freenode/ip.213.80.109.170) (Ping timeout: 265 seconds)
  655. # [22:26] * Joins: Ms2ger (~Ms2ger@91.181.38.57)
  656. # [22:36] * Quits: Ms2ger (~Ms2ger@91.181.38.57) (Quit: nn)
  657. # [22:42] * Joins: JoePeck (~JoePeck@c-76-102-33-198.hsd1.ca.comcast.net)
  658. # [22:43] * Quits: romeo_ (~romeo__@x1-6-00-10-a7-28-f3-47.k562.webspeed.dk) (Quit: Leaving)
  659. # [22:46] * Joins: matjas (~matjas@ip-81-11-180-97.dsl.scarlet.be)
  660. # [22:48] * Joins: paul_irish (~paul_iris@207-237-102-112.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com)
  661. # [22:53] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  662. # [22:58] * Quits: ROBOd (~robod@89.123.189.33) (Quit: .)
  663. # [23:07] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  664. # [23:13] * Joins: heycam (~cam@203-97-204-82.dsl.clear.net.nz)
  665. # [23:24] * Quits: annevk (~annevk@5355737B.cable.casema.nl) (Quit: annevk)
  666. # [23:31] * Quits: jacobolus (~jacobolus@c-24-128-189-152.hsd1.ma.comcast.net) (Remote host closed the connection)
  667. # [23:36] * Quits: paul_irish (~paul_iris@207-237-102-112.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) (Remote host closed the connection)
  668. # [23:36] * Quits: Maurice (copyman@5ED573FA.cm-7-6b.dynamic.ziggo.nl)
  669. # [23:39] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  670. # [23:46] <heycam> hi
  671. # [23:47] <heycam> anyone know if there's an html version of the ES5 spec anywhere?
  672. # [23:49] <Lachy> heycam, sadly, I don't think so
  673. # [23:50] <heycam> ok
  674. # [23:50] <heycam> good to see you Lachy and everyone else, after a long break from here!
  675. # [23:50] <Lachy> where have you been?
  676. # [23:51] <heycam> i took some time off to finish my thesis
  677. # [23:51] <heycam> finished it is not, but it's just a matter of writing now
  678. # [23:51] <heycam> on weekends and after work and so...
  679. # [23:51] <heycam> :)
  680. # [23:51] <variable> heycam, thesis on what topic?
  681. # [23:52] <heycam> variable, "adaptive diagrams". ones that can change their presentation according to where/how/to whom they're being presented.
  682. # [23:52] <heycam> worked on an authoring tool for such diagrams, did some minimal user testing
  683. # [23:53] <variable> cool
  684. # [23:53] <heycam> yeah it was sometimes enjoyable :)
  685. # [23:56] <Philip`> heycam: http://sideshowbarker.github.com/es5-spec/ ?
  686. # [23:56] <Philip`> though I think MikeSmith didn't want it advertised too widely yet
  687. # [23:57] <heycam> Philip`, excellent. and that's complete is it?
  688. # [23:57] <heycam> although the picture of the smirking planet is disturbing
  689. # [23:57] <Philip`> "it does include the full text of the spec"
  690. # [23:58] <heycam> good good
  691. # Session Close: Mon Oct 04 00:00:00 2010

The end :)