/irc-logs / w3c / #webapps / 2009-04-13 / end

Options:

  1. # Session Start: Mon Apr 13 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:00] * Joins: Lachy (Lachlan@93.158.28.130)
  4. # [00:00] * Quits: Lachy (Lachlan@93.158.28.130) (Client exited)
  5. # [00:06] * Joins: Lachy (Lachlan@93.158.28.130)
  6. # [01:27] * Quits: Lachy (Lachlan@93.158.28.130) (Quit: This computer has gone to sleep)
  7. # [04:20] * Quits: shepazu (schepers@128.30.52.30) (Client exited)
  8. # [04:20] * Joins: shepazu (schepers@128.30.52.30)
  9. # [04:23] * Quits: nico (nico@133.27.247.181) (Ping timeout)
  10. # [04:27] * Joins: nico (nico@133.27.247.181)
  11. # [04:41] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  12. # [08:48] * Joins: Lachy (Lachlan@93.158.8.176)
  13. # [09:27] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  14. # [09:39] * Quits: Lachy (Lachlan@93.158.8.176) (Quit: Leaving)
  15. # [09:50] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  16. # [12:36] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  17. # [12:49] * Joins: ArtB (d0309a43@128.30.52.43)
  18. # [13:00] * Quits: heycam (cam@210.84.37.90) (Ping timeout)
  19. # [13:06] * Joins: heycam (cam@124.168.119.97)
  20. # [13:19] * Quits: smaug (chatzilla@82.181.146.100) (Ping timeout)
  21. # [13:30] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  22. # [13:35] * Joins: smaug (chatzilla@88.192.219.38)
  23. # [13:58] <ArtB> Marcos, what is the security risk in http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0018.html ?
  24. # [13:59] <Marcos> Artb, "The problem in a nutshell is that by allowing multiple signatures,
  25. # [13:59] <Marcos> >> which is something we want to do, we create a situation in which not
  26. # [13:59] <Marcos> >> all of a signed widget's files are covered by the signature"
  27. # [14:01] <Marcos> This might be ok, so long as you cannot sneak additional XML elements into the top signature
  28. # [14:01] <ArtB> how could that be done in practice?
  29. # [14:01] <ArtB> that is, how can someone tamper with the sig files?
  30. # [14:02] <Marcos> e.g., (not itself signed) <signature> .... <script> evil = xhr()...</script> </signature>
  31. # [14:02] <Marcos> then, at runtime, you use XHR to read the signature
  32. # [14:02] <Marcos> extract the script
  33. # [14:02] <Marcos> I know, it's all a bit silly
  34. # [14:03] <Marcos> One can effectively change the top level signature because it is not itself signed
  35. # [14:04] <ArtB> When I see "It's not a big hole and the attacks require some "assistance" fromdevelopers, but unless there's a reason not to it should be pretty easyto close. "
  36. # [14:04] <ArtB> I don't get the sense this is critical to address
  37. # [14:05] <Marcos> I agree. I think we need to push Mark a bit more on it.
  38. # [14:05] <Marcos> I'm not too phased by it, which is why I did not put the text into the spec.
  39. # [14:06] <Marcos> However, if we can see it's a pretty easy security hole to close, then we should close it
  40. # [14:06] <ArtB> do you have any feedback from the people that would need to implement the requirement you proposed?
  41. # [14:06] <Marcos> no
  42. # [14:07] <Marcos> apart from Arve, saying, "WTF is this?" :)
  43. # [14:07] <ArtB> I wonder about an impl where things get unpacked such that this would not be an easy req to address
  44. # [14:07] <Marcos> I don't follow
  45. # [14:08] <Marcos> ok, I kinda do follow
  46. # [14:08] <Marcos> visualizing where such a thing could be a prob
  47. # [14:08] <ArtB> doesn't this say that at runtime, the UA must make sure the app never opens a sig file?
  48. # [14:08] <Marcos> exactly
  49. # [14:09] <ArtB> Yet the sig files may have been unpacked and placed in the FS somewhere outside of the zip
  50. # [14:09] <Marcos> that is also correct
  51. # [14:09] <ArtB> what if an impl wanted to delete the sig files after the zip is installed
  52. # [14:10] <Marcos> why would it want to do that?
  53. # [14:10] <ArtB> s/is installed/is verified/
  54. # [14:10] <ArtB> space
  55. # [14:11] <Marcos> seems like a strange thing to do. the imp would have to be pretty sure that another app could not then go in and modify the files
  56. # [14:11] <ArtB> but I guess if the sig files were deleted after initial verification this wouldn't be a prob :)
  57. # [14:12] <Marcos> that's true, but does not seem like a very smart thing to do. Seems better that if the UA detects that files have been changed or modified, it should revalidate
  58. # [14:12] <ArtB> is it your expectaion that a signed widget must be verified every time the widget is run?
  59. # [14:12] <Marcos> no, but it's probably a good idea to verify then every so often
  60. # [14:12] <ArtB> why?
  61. # [14:13] <Marcos> s/then/them.... in case they were changed via other means
  62. # [14:13] <Marcos> e.g., a widget somehow found another security hole
  63. # [14:13] <Marcos> and changed bank.wgt's content by adding a script
  64. # [14:14] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Tomorrow to fresh woods, and pastures new.)
  65. # [14:14] <Marcos> engines should protect their widgets. it would be like one web page changing the cookies of another web page... or worst
  66. # [14:15] <Marcos> i don't think sigs should be seen as one offs
  67. # [14:15] <ArtB> so you expect the UA to allow widgets to share file space with other widgets?
  68. # [14:15] <Marcos> yes, so long as they are careful to not allow those widgets to be tempered with
  69. # [14:15] <Marcos> s/those widgets/the content of those widgets/
  70. # [14:16] <ArtB> seems like a UA should effectively create a separate sandbox for each widget
  71. # [14:17] <Marcos> right
  72. # [14:18] <Marcos> and the UA could use the sig as the way of sandboxing
  73. # [14:19] <Marcos> I gotta go.. can we pick this up tomorrow
  74. # [14:19] <Marcos> ?
  75. # [14:20] <ArtB> l8r
  76. # [14:22] <Marcos> I need to read Frederick's responses again
  77. # [14:22] <Marcos> lets put in on the agenda for this week for discussion
  78. # [14:22] <Marcos> is that ok?
  79. # [14:22] <ArtB> I'll responde to your latest email; would prefer to close this before the meeting
  80. # [14:22] <ArtB> we got a *ton* of other higher priority things for this week's call
  81. # [14:23] <Marcos> ok
  82. # [14:23] <Marcos> sounds good
  83. # [14:58] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
  84. # [15:00] * Joins: taf2 (taf2@65.210.82.235)
  85. # [15:37] <Marcos> Artb, lets talk priorities :)
  86. # [15:49] <ArtB> hi Marcos
  87. # [15:49] <Marcos> hi
  88. # [15:50] <ArtB> Let's start with P+C; OK?
  89. # [15:50] <Marcos> ok, sounds good
  90. # [15:50] * ArtB goes to Inbox ...
  91. # [15:50] * Marcos loads up spec
  92. # [15:51] * ArtB looks for darobin :-(
  93. # [15:51] <ArtB> <access> is one open issue
  94. # [15:51] <ArtB> Robin proposed http://www.w3.org/mid/24A3E8BD-03B4-43FB-88D0-45600872E25F@berjon.com
  95. # [15:51] <ArtB> I presume you can live with Robin's proposal, right?
  96. # [15:52] <Marcos> I can... I will work with him on it over the next 3 weeks. He was finishing off some other client projects last week. He will now be 100% full time on this
  97. # [15:52] <Marcos> this = <access>
  98. # [15:53] <ArtB> how close is Robin's proposal to what's in the P&C ED?
  99. # [15:53] <Marcos> give me a minute to re-read his proposal...
  100. # [15:53] <Marcos> just so I'm clear... it's been a while
  101. # [15:54] <ArtB> I think this is an area where new related work will be done in the context of the security work that follows-on from last December's workshop
  102. # [15:54] <Marcos> artb, it's fairly aligned
  103. # [15:56] <Marcos> like robin says, it just needs to be written in "spec-ese"
  104. # [15:59] * Marcos checks open issues DB
  105. # [16:00] <ArtB> Do you know if BONDI has any inputs on the <access> model?
  106. # [16:00] <Marcos> I can't comment on that
  107. # [16:00] <Marcos> because I don't know
  108. # [16:01] <ArtB> I was just wondering about the probability of any substantial new inputs
  109. # [16:02] <ArtB> I'll put this on the April 16 widgets agenda
  110. # [16:02] <Marcos> it is highly unlikely
  111. # [16:02] <Marcos> they will propose something new
  112. # [16:02] <ArtB> do you see this "something new" coming as a proposal for the Security WG?
  113. # [16:02] <ArtB> I think this is what Thomas and Nick mean by "API Bindings" in ...
  114. # [16:03] <ArtB> http://www.w3.org/2008/security-ws/report
  115. # [16:03] <ArtB> s/API Bindings/API Patterns/
  116. # [16:03] <ArtB> but I'm not sure
  117. # [16:06] <Marcos> having a look
  118. # [16:06] <Marcos> I don't think there will be anything new coming
  119. # [16:07] <Marcos> I think our APIs and Bondi's ones align
  120. # [16:08] <ArtB> Seems like we want an extremely simple model for v1
  121. # [16:09] <ArtB> I'm pretty sure TLR and the new Security WG are going to spend a lot of time in this area ...
  122. # [16:09] <Marcos> well, they can do that for 2.0
  123. # [16:09] <ArtB> but that WG won't even start until late summer at best
  124. # [16:09] <ArtB> bingo!
  125. # [16:09] <Marcos> exactly
  126. # [16:10] <Marcos> I'm happy to see we only have 4 outstanding issues
  127. # [16:10] <Marcos> in the issues DB
  128. # [16:10] * Joins: aroben (aroben@71.58.77.15)
  129. # [16:11] <ArtB> http://www.w3.org/2008/webapps/track/products/8
  130. # [16:12] <ArtB> what's the status of your I18N document, Marcos?
  131. # [16:13] <Marcos> Almost done
  132. # [16:13] <Marcos> hopefully finish today
  133. # [16:14] <Marcos> I bought myself some coke zero to help me with the job
  134. # [16:14] <Marcos> :)
  135. # [16:14] <Marcos> however, it's grown to 21 pages :(
  136. # [16:14] <Marcos> Hopefully the i18n WG will be able to help us out quickly
  137. # [16:16] <ArtB> maybe we need a simple albeit feature challenged model for v1 and a plan to add richness for v2
  138. # [16:17] <Marcos> ArtB: maybe we need to drop it all together
  139. # [16:17] <Marcos> then bring it back in v2
  140. # [16:17] <Marcos> it might be ok if we can get agreement quickly
  141. # [16:18] <Marcos> it's not that complex... there is just lots of ways of doing i18n and each has subtly different effects
  142. # [16:18] * Quits: smaug (chatzilla@88.192.219.38) (Client exited)
  143. # [16:19] * Joins: smaug (chatzilla@88.192.219.38)
  144. # [16:20] <ArtB> when do you expect to complete your proposal?
  145. # [16:21] <Marcos> hopefully tonight
  146. # [16:21] <Marcos> if not, tomorrow.
  147. # [16:22] <Marcos> parts 1,2,3 are done
  148. # [16:22] <Marcos> and could potentially be reviewed
  149. # [16:22] <ArtB> please ping me when done and I will review it
  150. # [16:22] <ArtB> and add it to the agenda
  151. # [16:22] <Marcos> ok great
  152. # [16:23] <ArtB> The next P+C open work item is the base folder and xml:base
  153. # [16:23] <Marcos> that's part of the i18n
  154. # [16:23] <Marcos> proposal
  155. # [16:24] <ArtB> ok; I don't rember that but I read the proposal on the 7th
  156. # [16:24] <Marcos> might have added it after
  157. # [16:25] <ArtB> does bcp47 sub-lang handling?
  158. # [16:26] <Marcos> yep
  159. # [16:26] <Marcos> bcp47 defines the algorithm
  160. # [16:27] <ArtB> right, sorry, that's what I was asking
  161. # [16:28] <Marcos> np, I'm having lunch, but have 1 eye on IRC
  162. # [16:28] <ArtB> are there other issues for P&C?
  163. # [16:28] * Marcos thinks...
  164. # [16:28] <Marcos> um, no. that's it for P&C... other stuff is just work that needs to be done
  165. # [16:29] <Marcos> i.e., once we have a solutions to issues, then they just need to be spec'ed
  166. # [16:30] <Marcos> that's not a lot of work
  167. # [16:30] <ArtB> Re A+E, do you have an ETA from Arve on his proposal to address the various Issues identified in the latest ED?
  168. # [16:31] <ArtB> Storage and preferences are separate ...
  169. # [16:32] <Marcos> bb in 5... we should ask the guy from access to take over that spec
  170. # [16:32] <Marcos> he is good
  171. # [16:32] <ArtB> Marcos, I need to leave for a bit too; TTYL
  172. # [16:33] <Marcos> np :)
  173. # [16:51] * Quits: ArtB (d0309a43@128.30.52.43) (Client exited)
  174. # [18:04] * Joins: ArtB (d0309a43@128.30.52.43)
  175. # [18:25] * Quits: taf2 (taf2@65.210.82.235) (Ping timeout)
  176. # [18:38] * Joins: taf2 (taf2@65.210.82.235)
  177. # [18:42] * Quits: taf2 (taf2@65.210.82.235) (Quit: taf2)
  178. # [18:46] * Joins: taf2 (taf2@65.210.82.235)
  179. # [19:27] * Quits: Marcos (Marcos@84.215.160.79) (Quit: Marcos)
  180. # [19:48] * Joins: Marcos (Marcos@84.215.160.79)
  181. # [21:03] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Ping timeout)
  182. # [21:07] * Quits: smaug (chatzilla@88.192.219.38) (Ping timeout)
  183. # [21:20] * Joins: shepazu_ (schepers@128.30.52.30)
  184. # [21:24] * Quits: shepazu (schepers@128.30.52.30) (Ping timeout)
  185. # [22:00] * Quits: shepazu_ (schepers@128.30.52.30) (Ping timeout)
  186. # [22:13] * Joins: shepazu (schepers@128.30.52.30)
  187. # [22:32] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  188. # [23:54] * Quits: taf2 (taf2@65.210.82.235) (Quit: taf2)
  189. # [23:56] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  190. # Session Close: Tue Apr 14 00:00:00 2009

The end :)