/irc-logs / w3c / #webapps / 2009-11-02 / end

Options:

  1. # Session Start: Mon Nov 02 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [02:48] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  4. # [03:00] * Quits: smaug (chatzilla@82.181.150.24) (Client exited)
  5. # [06:31] * Joins: shepazu (schepers@128.30.52.169)
  6. # [06:53] * Joins: annevk (opera@12.197.88.10)
  7. # [07:15] * Quits: annevk (opera@12.197.88.10) (Quit: annevk)
  8. # [07:39] * Joins: arve (arve@212.251.179.162)
  9. # [08:33] * Joins: timeless_mbp (timeless@24.6.182.21)
  10. # [09:57] * Joins: smaug (chatzilla@82.181.150.24)
  11. # [11:21] * Joins: arve_ (arve@213.236.208.22)
  12. # [11:23] * Quits: arve (arve@212.251.179.162) (Ping timeout)
  13. # [12:01] * Quits: arve_ (arve@213.236.208.22) (Ping timeout)
  14. # [12:13] * Joins: arve (arve@212.251.179.162)
  15. # [13:28] * Quits: arve (arve@212.251.179.162) (Ping timeout)
  16. # [15:01] * Joins: arve (arve@212.251.179.162)
  17. # [15:01] <arve> which channels are being used?
  18. # [15:43] * Joins: aroben (aroben@71.58.77.15)
  19. # [16:22] * Joins: smaug_ (chatzilla@82.181.150.24)
  20. # [16:25] * Quits: smaug (chatzilla@82.181.150.24) (Quit: ChatZilla 0.9.85 [Firefox 3.7a1pre/20091021122508])
  21. # [16:36] * Joins: annevk (opera@72.254.112.194)
  22. # [16:52] * Quits: timeless_mbp (timeless@24.6.182.21) (Quit: timeless_mbp)
  23. # [17:08] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  24. # [17:11] * Joins: smaug (chatzilla@82.181.150.24)
  25. # [17:28] * Quits: annevk (opera@72.254.112.194) (Quit: annevk)
  26. # [17:33] * Joins: darobin (robin@72.254.116.7)
  27. # [17:34] * Quits: smaug (chatzilla@82.181.150.24) (Ping timeout)
  28. # [17:37] * Joins: tlr (tlr@128.30.52.169)
  29. # [17:40] <Hixie> anyone in the geo meeting or the webapps non-widget meeting?
  30. # [17:49] * Joins: anne (annevk@72.254.94.228)
  31. # [17:50] * Joins: shepazu (schepers@128.30.52.169)
  32. # [17:53] * Joins: chaals (chaals@72.254.116.154)
  33. # [17:53] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  34. # [17:53] <shepazu> http://www.w3.org/2008/webapps/wiki/TPAC2009APIs
  35. # [17:56] * Joins: weinig (weinig@72.254.116.49)
  36. # [18:01] * Joins: Travis (d8341cc8@128.30.52.43)
  37. # [18:02] * Joins: mjs (mjs@72.254.93.235)
  38. # [18:02] * Joins: shiki (sokasaka@72.254.84.7)
  39. # [18:03] * Joins: pererik (chatzilla@72.254.62.138)
  40. # [18:04] * Joins: RRSAgent (rrs-loggee@128.30.52.30)
  41. # [18:04] <RRSAgent> logging to http://www.w3.org/2009/11/02-webapps-irc
  42. # [18:04] <Travis> scribe: Travis
  43. # [18:04] <Travis> scribeNick: Travis
  44. # [18:04] * Joins: Marcos (Marcos@72.254.60.247)
  45. # [18:04] * Joins: adrianba (adrianba@72.254.109.40)
  46. # [18:04] <Travis> Topic: Introductions for Persons present at the WebApps TPAC Meeting
  47. # [18:04] * Joins: mmielke (48fe53a0@128.30.52.43)
  48. # [18:05] * Joins: myakura (myakura@114.163.221.102)
  49. # [18:06] * Joins: evlakat (chatzilla@72.254.59.5)
  50. # [18:06] * evlakat is now known as Vladimir
  51. # [18:06] * Joins: MikeSmith (MikeSmithX@mcclure.w3.org)
  52. # [18:07] * Joins: ArtB (48fe3886@128.30.52.43)
  53. # [18:07] * timeless is running a bit behind
  54. # [18:09] <chaals> Present: Chaals, Anne van Kesteren, SamW, Travis, Adrian, Satoshi, Frank, Maciej, Mike™, Rob, Marcus, Gondo, Vagner, Erik, Vladimir, Shigeo, Mark, Doug
  55. # [18:09] * Joins: Vagner-br (chatzilla@72.254.81.150)
  56. # [18:09] <chaals> Chair: Chaals
  57. # [18:09] * Joins: fo (48fe55d2@64.62.228.82)
  58. # [18:09] <MikeSmith> s/Shigeo/Shiki/
  59. # [18:10] * Parts: timeless (timeless@65.75.195.122) ((attending widgets))
  60. # [18:10] <pererik> s/Erik/Per-Erik/
  61. # [18:11] <chaals> Present+ Kai
  62. # [18:11] <chaals> http://www.w3.org/2008/webapps/wiki/TPAC2009APIs
  63. # [18:11] <MikeSmith> RRSAgent, make minutes
  64. # [18:11] <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith
  65. # [18:11] <shepazu> Agenda: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs
  66. # [18:12] <Travis> Topic: Progress Events
  67. # [18:12] * Joins: Kai (chatzilla@72.254.114.142)
  68. # [18:12] * anne wonders where the Mozilla gang is
  69. # [18:17] <Travis> chaals: Any additional items to add to the agenda?
  70. # [18:17] <chaals> Present+ PaulC, Sam, JohnG, Jeremy
  71. # [18:18] <Travis> chaals: Spec has been stalled for some time...
  72. # [18:18] * Joins: plh-webapps (plh@128.30.52.28)
  73. # [18:19] <chaals> Present+ Nikunj
  74. # [18:19] <chaals> Topic: Progress events
  75. # [18:19] <chaals> --> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.32 Editor's draft
  76. # [18:20] * Joins: johnnyg (johnnyg@72.254.61.41)
  77. # [18:20] <Travis> chaals: Progress events are events for showing progress :-)
  78. # [18:21] * Joins: JonathanJ (hollobit@72.254.116.68)
  79. # [18:21] * Joins: smaug (chatzilla@91.153.243.201)
  80. # [18:22] <Travis> ... Issue about what events must be defined in the spec itself.
  81. # [18:23] <Travis> ... Justification is that there is a definate pattern that must be followed when implementing these events.
  82. # [18:23] <Travis> ... Progress events have been implemented by SVG some years ago (there a bit of a legacy)
  83. # [18:24] <Travis> ... Considering making the events requirement a "SHOULD" instead of a MUST.
  84. # [18:24] <Travis> ... This text presumably makes it easier to integrate into other specs.
  85. # [18:24] * Quits: smaug (chatzilla@91.153.243.201) (Ping timeout)
  86. # [18:25] <Travis> Hixie: Main concern with the requirements able to be defined in other specs and the progress events spec is how do you test this?
  87. # [18:26] <Travis> shepazu: Can progress events be implemented outside of a host language?
  88. # [18:28] <Travis> Hixie: Would like to have a normative section for what the event objects look like, then a non-normative section for what other spec authors should generally follow.
  89. # [18:28] <Travis> shepazu: Concerned that an implementer wouldn't implement the non-normative parts.
  90. # [18:29] <Travis> chaals: With a spec only having SHOULDs, there's no normative requirement for implementors!
  91. # [18:29] <Travis> ... Would such an approach make sense?
  92. # [18:29] * Joins: arun (arun@72.254.57.36)
  93. # [18:30] <Travis> Hixie: From a UA point of view, the dispatch of the events section in Progress Events would be redundant with the definition in a host spec.
  94. # [18:32] * Quits: adrianba (adrianba@72.254.109.40) (Ping timeout)
  95. # [18:33] <Travis> chaals: Without a normative requirement, there's nothing to prevent anyone from completely ignoring the spec.
  96. # [18:35] <Travis> Rob: Would it make sense to have a section for reasons why the Progress events wouldn't be used as spec'd?
  97. # [18:36] <Travis> shepazu: Question about what the different use cases are for when scenarios might employ progress events.
  98. # [18:36] * Joins: smaug (chatzilla@91.153.243.201)
  99. # [18:37] * Joins: eric_uhrhane (48fe5926@64.62.228.82)
  100. # [18:37] <shepazu> for example, you could use progress events for computationally intensive progress
  101. # [18:37] <shepazu> s/progress/processes
  102. # [18:38] <Travis> mjs: Should have a section for how Progress events should "typically" be used (in a basic scenario), but to not overconstrain the spec.
  103. # [18:39] <Travis> chaals: I propose to take the MUST requirements off of the UA requirements, and change these to SHOULD, and include examples of when you might not want to follow the basic pattern.
  104. # [18:40] <Travis> anne: Don't think it makes sense to have user agent requirements in this spec.
  105. # [18:40] <Travis> Hixie: There are conflicting requirements must / must not depending on the spec.
  106. # [18:41] * Quits: mmielke (48fe53a0@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  107. # [18:41] <Travis> anne: XHR, AppCache, Media Elements all specify how these events are to be dispatched.
  108. # [18:41] <Travis> ... So don't see the point of a common model.
  109. # [18:43] <Travis> chaals: Rather than having a new spec author search through the various specs to find the common pattern, they could go to one place (the Progress Events spec) to have a template to copy.
  110. # [18:43] <Travis> Hixie: Great--as long as it's not normative, I love it.
  111. # [18:43] <Travis> shepazu: +1
  112. # [18:43] * Quits: johnnyg (johnnyg@72.254.61.41) (Quit: johnnyg)
  113. # [18:44] <Travis> anne: Seems pretty complicated to a make a generic model.
  114. # [18:44] <Hixie> specifically, what i thought i understood was that the progress events spec would have a section that can be copied and pasted into other specs, that would put requirements in those specs for queueing tasks to fire events, etc
  115. # [18:44] <Hixie> these requirements would not be normative at the progress events spec level
  116. # [18:44] <Travis> anne: No formal objection.
  117. # [18:45] <arun> If it is non-normative, issues behind objections can probably be mitigated (e.g. how complicated a general model might be).
  118. # [18:45] <chaals> Proposed resolution: Remove the User agent requirements and make them informative for the "default case", provide examples of how a spec would incorporate the default case and examples of where it would do something differently
  119. # [18:46] <chaals> RESOLUTION: Remove the User agent requirements and make them informative for the "default case", provide examples of how a spec would incorporate the default case and examples of where it would do something differently
  120. # [18:47] <MikeSmith> Hixie, so HTML5 has not normative dependency on Progress events currently, right?
  121. # [18:47] * Joins: johnnyg (johnnyg@72.254.61.41)
  122. # [18:47] <MikeSmith> s/has not/has not/
  123. # [18:47] <MikeSmith> s/has not/has no/
  124. # [18:47] * Parts: anne (annevk@72.254.94.228)
  125. # [18:47] <Travis> chaals: Issue 105
  126. # [18:47] <weinig> http://www.w3.org/2008/webapps/track/issues/105
  127. # [18:47] <Hixie> it has one for appcache
  128. # [18:48] * Joins: anne (annevk@72.254.94.228)
  129. # [18:49] * Joins: mmielke (48fe53a0@128.30.52.43)
  130. # [18:49] * Quits: myakura (myakura@114.163.221.102) (Quit: Leaving...)
  131. # [18:49] <Travis> ... Use cases for my "email scenario" and the Media streaming events were different.
  132. # [18:50] * Quits: plh-webapps (plh@128.30.52.28) (Client exited)
  133. # [18:51] <Travis> ... Was my addition of the attribute for tracking different transactions useful?
  134. # [18:51] <Travis> Hixie: The model you describe (with sub-transactions showing progress) leads to horrific UI.
  135. # [18:51] <Travis> chaals: Yes, but I like that UI.
  136. # [18:52] * Quits: arve (arve@212.251.179.162) (Quit: Ex-Chat)
  137. # [18:52] * Quits: johnnyg (johnnyg@72.254.61.41) (Quit: johnnyg)
  138. # [18:52] * Joins: smaug__ (chatzilla@80.186.206.52)
  139. # [18:53] * Joins: arve (arve@213.236.208.22)
  140. # [18:53] <MikeSmith> "The default action of these events must be, if the user agent shows caching progress, the display of some sort of user interface indicating to the user that a file is being downloaded in preparation for updating the application. [PROGRESS]" http://dev.w3.org/html5/spec/offline.html#downloading-or-updating-an-application-cache
  141. # [18:53] <Travis> shepazu: In the multiple items case, could I make a progress bar that handled X different items downloading at once and consolidate them?
  142. # [18:54] * Quits: smaug (chatzilla@91.153.243.201) (Ping timeout)
  143. # [18:54] * smaug__ is now known as smaug
  144. # [18:56] <Travis> Rob: Might want to make this very simple and keep the progress as percentages only.
  145. # [18:56] <Travis> chaals: On percentages: this can get tricky when you don't know how much data you're going to get.
  146. # [18:57] * Quits: eric_uhrhane (48fe5926@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
  147. # [18:58] <Travis> MichaelNan: In favor of simplifying the progress events.
  148. # [19:01] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  149. # [19:01] * Joins: johnnyg (johnnyg@72.254.61.41)
  150. # [19:01] * Joins: timeless_mbp (timeless@72.254.57.15)
  151. # [19:01] <Travis> weinig: May not need to define in the Progress Events for sub items, but leave it up to hosting specs to provide a means to define how unique progress events are tracked.
  152. # [19:03] * Joins: tlr (tlr@128.30.52.169)
  153. # [19:04] <Travis> chaals: The purpose of the two extra attributes was to allow the data for sub items to be tracked.
  154. # [19:05] <Travis> weinig: For the non-simple cases, an informative section describing how to handle these might be easier.
  155. # [19:06] <Travis> Hixie: Could look to XHR's upload concept.
  156. # [19:07] <anne> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-upload-attribute
  157. # [19:07] <Travis> Action: weinig to write up sample on what the multi-file progress informative text might look like.
  158. # [19:07] * trackbot noticed an ACTION. Trying to create it.
  159. # [19:07] * RRSAgent records action 1
  160. # [19:07] <trackbot> Created ACTION-431 - Write up sample on what the multi-file progress informative text might look like. [on Samuel Weinig - due 2009-11-09].
  161. # [19:09] <Travis> chaals: Issue 107 is largely redundant if we simplify.
  162. # [19:10] <Travis> chaals: There is another question: what does the total and loaded count mean?
  163. # [19:10] <Travis> ... Now is specifies the number of bytes.
  164. # [19:11] <Travis> ... In removing the normative requirement, the "bytes" requirement could totally go away.
  165. # [19:11] <Travis> ... Makes sense for me to recommend bytes as the default simple case.
  166. # [19:11] <Travis> Hixie: So far, the various specs interpret the values different already {files, bytes, objects}
  167. # [19:15] <Travis> chaals: Propose we drop the total bytes in favor of showing progress of "something".
  168. # [19:15] <MikeSmith> chaals, Ian Fette and Lachy came in, need to intro himself
  169. # [19:16] * Joins: Lachy (Lachlan@72.254.57.120)
  170. # [19:16] * Quits: Lachy (Lachlan@72.254.57.120) (Connection reset by peer)
  171. # [19:16] * Joins: Lachy (Lachlan@72.254.57.120)
  172. # [19:17] * Joins: mmani (c6980d43@128.30.52.43)
  173. # [19:18] <Travis> shepazu: Please keep existing text in place for a compare/contrast draft.
  174. # [19:18] * Quits: johnnyg (johnnyg@72.254.61.41) (Quit: johnnyg)
  175. # [19:19] <Travis> chaals: I think this wraps up what I had to discuss on Progress Events.
  176. # [19:21] * Quits: Lachy (Lachlan@72.254.57.120) (Connection reset by peer)
  177. # [19:22] * Quits: Kai (chatzilla@72.254.114.142) (Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458])
  178. # [19:23] * Joins: Lachy (Lachlan@72.254.57.120)
  179. # [19:23] <Travis> chaals: Let's break now, and reconvene at 11. We'll be in Salon 5 meeting with Device API.
  180. # [19:23] * Quits: Lachy (Lachlan@72.254.57.120) (Connection reset by peer)
  181. # [19:23] * Parts: Travis (d8341cc8@128.30.52.43)
  182. # [19:24] * Quits: weinig (weinig@72.254.116.49) (Quit: weinig)
  183. # [19:24] * Quits: pererik (chatzilla@72.254.62.138) (Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458])
  184. # [19:24] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  185. # [19:25] * Quits: fo (48fe55d2@64.62.228.82) (Quit: http://www.mibbit.com ajax IRC Client)
  186. # [19:26] * Quits: Vladimir (chatzilla@72.254.59.5) (Ping timeout)
  187. # [19:26] * Quits: mmielke (48fe53a0@128.30.52.43) (Quit: CGI:IRC (Ping timeout))
  188. # [19:29] * Joins: Lachy (Lachlan@72.254.57.120)
  189. # [19:31] * Quits: Vagner-br (chatzilla@72.254.81.150) (Ping timeout)
  190. # [19:35] * Quits: darobin (robin@72.254.116.7) (Ping timeout)
  191. # [19:40] * Joins: johnnyg (johnnyg@72.254.61.41)
  192. # [19:45] * Quits: johnnyg (johnnyg@72.254.61.41) (Quit: johnnyg)
  193. # [19:47] * Quits: ArtB (48fe3886@128.30.52.43) (Quit: CGI:IRC (EOF))
  194. # [19:49] * Quits: timeless_mbp (timeless@72.254.57.15) (Quit: timeless_mbp)
  195. # [19:50] * Quits: arun (arun@72.254.57.36) (Quit: arun)
  196. # [19:54] * Joins: johnnyg (johnnyg@72.254.61.41)
  197. # [19:55] * Quits: JonathanJ (hollobit@72.254.116.68) (Quit: JonathanJ)
  198. # [19:56] * Quits: mjs (mjs@72.254.93.235) (Quit: mjs)
  199. # [19:58] * Quits: johnnyg (johnnyg@72.254.61.41) (Quit: johnnyg)
  200. # [19:59] * Quits: Lachy (Lachlan@72.254.57.120) (Quit: This computer has gone to sleep)
  201. # [20:01] * Joins: tlr_ (tlr@72.254.89.250)
  202. # [20:01] * Quits: shiki (sokasaka@72.254.84.7) (Quit: shiki)
  203. # [20:02] * Joins: arun (arun@72.254.57.36)
  204. # [20:03] * Joins: darobin (robin@72.254.116.7)
  205. # [20:05] * Joins: johnnyg (johnnyg@72.254.61.41)
  206. # [20:06] * Joins: mjs (mjs@72.254.93.235)
  207. # [20:06] * Joins: weinig (weinig@72.254.116.49)
  208. # [20:06] * Joins: shiki (sokasaka@72.254.84.7)
  209. # [20:07] * Joins: pererik (chatzilla@72.254.62.138)
  210. # [20:07] * Joins: jorlow (jorlow@72.254.60.146)
  211. # [20:08] * Joins: Vladimir (chatzilla@72.254.59.5)
  212. # [20:08] * Joins: shepazu (schepers@128.30.52.169)
  213. # [20:09] * Quits: jorlow (jorlow@72.254.60.146) (Quit: jorlow)
  214. # [20:10] * Joins: jorlow (jorlow@72.254.60.146)
  215. # [20:10] * Joins: sicking (chatzilla@72.254.59.32)
  216. # [20:10] <chaals> rrsagent, make logs public
  217. # [20:10] <RRSAgent> I have made the request, chaals
  218. # [20:10] <chaals> rrsagent, draft minutes
  219. # [20:10] <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html chaals
  220. # [20:10] <chaals> rrsagent, this meeting crosses midnight
  221. # [20:10] <RRSAgent> I'm logging. I don't understand 'this meeting crosses midnight', chaals. Try /msg RRSAgent help
  222. # [20:11] <chaals> rrsagent, this meeting spans midnight
  223. # [20:11] <RRSAgent> ok, chaals; I will not start a new log at midnight
  224. # [20:11] * Joins: jorlow_ (jorlow@216.239.44.65)
  225. # [20:13] * Quits: jorlow (jorlow@72.254.60.146) (Ping timeout)
  226. # [20:13] * jorlow_ is now known as jorlow
  227. # [20:13] * Zakim excuses himself; his presence no longer seems to be needed
  228. # [20:13] * Parts: Zakim (rrs-bridgg@128.30.52.30)
  229. # [20:14] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  230. # [20:14] * Joins: Vagner-br (chatzilla@72.254.81.150)
  231. # [20:22] * Joins: tlr__ (tlr@72.254.89.250)
  232. # [20:22] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  233. # [20:22] * Quits: smaug (chatzilla@80.186.206.52) (Ping timeout)
  234. # [20:22] * Quits: tlr_ (tlr@72.254.89.250) (Connection reset by peer)
  235. # [20:23] * Joins: Marcos (Marcos@72.254.60.247)
  236. # [20:23] * tlr__ is now known as tlr_
  237. # [20:24] * Joins: tlr (tlr@128.30.52.169)
  238. # [20:25] * Quits: tlr_ (tlr@72.254.89.250) (Connection reset by peer)
  239. # [20:43] * Joins: gsnedders (gsnedders@83.252.229.211)
  240. # [20:47] * Parts: Vagner-br (chatzilla@72.254.81.150)
  241. # [20:48] * Joins: mmielke (cdf86653@128.30.52.43)
  242. # [20:48] * mmielke is now known as mielke
  243. # [20:53] * Joins: NEWTON_VAGNER_DIN (chatzilla@72.254.81.150)
  244. # [21:02] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
  245. # [21:04] * Quits: mmani (c6980d43@128.30.52.43) (Quit: CGI:IRC)
  246. # [21:04] * Joins: mmani (c6980d43@128.30.52.43)
  247. # [21:04] * Quits: mmani (c6980d43@128.30.52.43) (Quit: CGI:IRC)
  248. # [21:05] * Joins: smaug (chatzilla@82.181.150.24)
  249. # [21:07] * Joins: Hixie (ianh@129.241.93.37)
  250. # [21:09] * Joins: JonathanJ (hollobit@72.254.116.68)
  251. # [21:25] * Joins: timeless_mbp (timeless@216.239.45.19)
  252. # [21:28] * Quits: pererik (chatzilla@72.254.62.138) (Ping timeout)
  253. # [21:29] * Joins: pererik (chatzilla@72.254.62.138)
  254. # [21:36] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  255. # [21:38] * Quits: smaug_ (chatzilla@82.181.150.24) (Quit: ChatZilla 0.9.85 [Firefox 3.7a1pre/20091015073430])
  256. # [21:41] * Quits: mjs (mjs@72.254.93.235) (Quit: mjs)
  257. # [21:41] * Quits: NEWTON_VAGNER_DIN (chatzilla@72.254.81.150) (Ping timeout)
  258. # [21:51] * Joins: Marcos (Marcos@72.254.60.247)
  259. # [21:51] * Quits: shepazu (schepers@128.30.52.169) (Quit: shepazu)
  260. # [21:51] * Quits: tlr (tlr@128.30.52.169) (Quit: tlr)
  261. # [21:51] * Quits: weinig (weinig@72.254.116.49) (Quit: weinig)
  262. # [21:51] * Joins: jorlow_ (jorlow@72.254.60.146)
  263. # [21:51] * Quits: shiki (sokasaka@72.254.84.7) (Quit: shiki)
  264. # [21:52] * Quits: johnnyg (johnnyg@72.254.61.41) (Quit: johnnyg)
  265. # [21:52] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  266. # [21:52] * Joins: Marcos (Marcos@72.254.60.247)
  267. # [21:52] * Quits: jorlow_ (jorlow@72.254.60.146) (Connection reset by peer)
  268. # [21:52] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  269. # [21:52] * Quits: chaals (chaals@72.254.116.154) (Quit: chaals)
  270. # [21:54] * Quits: darobin (robin@72.254.116.7) (Ping timeout)
  271. # [21:54] * Quits: Vladimir (chatzilla@72.254.59.5) (Ping timeout)
  272. # [21:54] * Quits: pererik (chatzilla@72.254.62.138) (Ping timeout)
  273. # [21:54] * Quits: jorlow (jorlow@216.239.44.65) (Ping timeout)
  274. # [21:56] * Quits: JonathanJ (hollobit@72.254.116.68) (Quit: JonathanJ)
  275. # [21:56] * Quits: arun (arun@72.254.57.36) (Quit: arun)
  276. # [21:59] * Quits: sicking (chatzilla@72.254.59.32) (Ping timeout)
  277. # [22:00] * Quits: mielke (cdf86653@128.30.52.43) (Quit: CGI:IRC (EOF))
  278. # [22:24] * Quits: timeless_mbp (timeless@216.239.45.19) (Quit: timeless_mbp)
  279. # [22:38] * Joins: timeless_mbp (timeless@216.239.45.19)
  280. # [22:46] * Joins: Marcos (Marcos@72.254.60.247)
  281. # [22:46] * Joins: shiki (sokasaka@72.254.84.7)
  282. # [22:48] * Joins: shepazu (schepers@128.30.52.169)
  283. # [22:50] * Joins: weinig (weinig@72.254.116.49)
  284. # [22:51] * Joins: pererik (pe@72.254.62.138)
  285. # [22:53] * Joins: mjs (mjs@72.254.93.235)
  286. # [22:54] * Joins: NEWTON_VAGNER_DIN (chatzilla@72.254.81.150)
  287. # [22:59] * Joins: sicking (chatzilla@72.254.59.32)
  288. # [23:01] * Joins: ArtB (48fe3886@128.30.52.43)
  289. # [23:01] * Quits: pererik (pe@72.254.62.138) (Quit: ChatZilla 0.9.85 [Firefox 3.5.3/20090824101458])
  290. # [23:01] * Joins: pererik (pe@72.254.62.138)
  291. # [23:01] * Joins: darobin (robin@72.254.116.7)
  292. # [23:02] * Joins: plh (plh@128.30.52.28)
  293. # [23:02] * Joins: Vladimir (chatzilla@72.254.59.5)
  294. # [23:02] * ArtB changes topic to 'WebApps agenda Nov 2: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Monday.2C_November_2'
  295. # [23:02] * Joins: chaals (chaals@72.254.116.154)
  296. # [23:02] <ArtB> RRSAgent, pointer
  297. # [23:02] <RRSAgent> See http://www.w3.org/2009/11/02-webapps-irc#T22-02-40
  298. # [23:02] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  299. # [23:03] <ArtB> RRSAgent, make minutes
  300. # [23:03] <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html ArtB
  301. # [23:03] <chaals> Scribe: Chaals
  302. # [23:03] <chaals> ScribeNick: chaals
  303. # [23:03] <chaals> Topic: CORS
  304. # [23:04] * ArtB notes CORS agenda items: http://www.w3.org/2008/webapps/wiki/TPAC2009APIs#Monday.2C_November_2
  305. # [23:04] * Joins: Marcos (Marcos@72.254.60.247)
  306. # [23:05] * Quits: timeless_mbp (timeless@216.239.45.19) (Quit: timeless_mbp)
  307. # [23:05] * chaals wonders where TLR is
  308. # [23:05] <ArtB> Present+ ArtB
  309. # [23:05] * Joins: timeless_mbp (timeless@216.239.45.19)
  310. # [23:06] <chaals> AvK: Two open issues raised by mnot
  311. # [23:06] <chaals> ... one is naming, one is technical. And a missing issue MM is here to talk about - should we throw it all away...
  312. # [23:06] * ArtB notes CORS Editor's Draft: http://dev.w3.org/2006/waf/access-control/
  313. # [23:07] <chaals> MM: Suggesting the mechanism should not present authorising information in a ?? fashion. It's up to applications to decide what to do
  314. # [23:07] * Joins: DanC (connolly@128.30.52.169)
  315. # [23:07] <chaals> AvK: Also status of origins spec at IETF, and call for tutorials/use cases.
  316. # [23:07] * Joins: Magnus (chatzilla@72.254.111.212)
  317. # [23:07] * Quits: NEWTON_VAGNER_DIN (chatzilla@72.254.81.150) (Ping timeout)
  318. # [23:07] * Quits: timeless_mbp (timeless@216.239.45.19) (Quit: timeless_mbp)
  319. # [23:07] <chaals> ... let's begin with the big fat guy in the middle of the room
  320. # [23:07] * chaals notes he is towards the front left corner really
  321. # [23:08] <chaals> MM: Objection is that we know about confused deputy problems. Systems that do authentication by associating authority on the identity of the requesting identity creates vulnerabilities.
  322. # [23:09] <chaals> ... CORS links origin of requester from origin header, which fulfils requirements to make Confused Deputy problems.
  323. # [23:09] <chaals> ... discussion hasn't addressed the objection.
  324. # [23:09] <chaals> ... Not showed that it doesn't apply, doesn't matter, etc.
  325. # [23:09] <arun> q+ to ask about a sample attack...
  326. # [23:10] <chaals> ack arun
  327. # [23:10] <mjs> q+
  328. # [23:10] * Joins: tlr (tlr@128.30.52.169)
  329. # [23:10] <shepazu> q+ tyler
  330. # [23:10] <chaals> AR: Can anyone show a sample attack that demonstrates the nature of the problem?
  331. # [23:11] <chaals> MM: Tyler Close posted a 3-aparty interaction where each step is intuitive in CORS< and the result creates a confused deputy problem.
  332. # [23:11] <chaals> ack mjs
  333. # [23:11] * Joins: adrianba (adrianba@72.254.109.40)
  334. # [23:11] * Joins: jorlow (jorlow@216.239.45.4)
  335. # [23:11] <chaals> MJS: My reply was that this came from using arbitrary URIs rather than recognising that they are meant to be scoped to a specific subdomain. Don't think that is created by CORS
  336. # [23:12] <chaals> MM: What validation should the second party do to the URIs to ensure control?
  337. # [23:12] <chaals> MJS: Site 1 has photos, site 2 printing, site 3 has storage.
  338. # [23:12] <chaals> ... photo site wants printer to get things from storage.
  339. # [23:12] <Hixie> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html is Tyler's example
  340. # [23:12] <anne> example from Tyler: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html
  341. # [23:12] <chaals> ... etc.
  342. # [23:12] <shepazu> q+
  343. # [23:13] * Joins: ht (ht@128.30.52.169)
  344. # [23:13] <chaals> ... Right approach: Printing site creates one-time store, passes that, and the photo site uses a different API to pass it to the photo site.
  345. # [23:13] <chaals> TC: That is right, but you don't need CORS to do it
  346. # [23:13] * Joins: NEWTON_VAGNER_DIN (chatzilla@72.254.81.150)
  347. # [23:13] <chaals> MJS: How do you do it without server-server comms which is a goal of CORS
  348. # [23:14] <ht> ArtB -- TAG is coming, unless you say no. . .
  349. # [23:14] <MikeSmith> chaals, some TAG members will be joining in a minute
  350. # [23:14] * Joins: soonho (soonho@72.254.114.255)
  351. # [23:14] * NEWTON_VAGNER_DIN is now known as Vagner_W3C_Brasil
  352. # [23:14] * Vagner_W3C_Brasil is now known as NEWTON_VAGNER_DIN
  353. # [23:14] * Quits: jorlow (jorlow@216.239.45.4) (Ping timeout)
  354. # [23:14] * NEWTON_VAGNER_DIN is now known as Vagner_W3C_Brasil
  355. # [23:14] * chaals sure, step inside our dungeon...
  356. # [23:14] <arun> This is Tyler's Email: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1324.html
  357. # [23:15] * Quits: DanC (connolly@128.30.52.169) (Client exited)
  358. # [23:15] * Joins: Qiuling (panqiuling@72.254.91.36)
  359. # [23:15] <chaals> TC: We know in principle that using client authentication is vulnerable to CD. We have experienced this on the web - csrf, clickjacking.
  360. # [23:15] * Quits: ArtB (48fe3886@128.30.52.43) (Quit: CGI:IRC (EOF))
  361. # [23:16] <chaals> ... CORS proposes another way to use client auth on the web.
  362. # [23:16] <shepazu> q+ to ask if we are worried about malicious or accidental problems
  363. # [23:16] <chaals> q?
  364. # [23:16] * Joins: ArtB (48fe3886@128.30.52.43)
  365. # [23:16] * Joins: Zakim (rrs-bridgg@128.30.52.30)
  366. # [23:16] <chaals> DS: It seemed that the attacks are not malicious, but accidental. Ambient authority gets wrong access.
  367. # [23:17] <chaals> MM: My sense was that it is not accidental. The program issuing a command could, I think maliciously, "mis"direct information
  368. # [23:18] <chaals> DS: Think we could distinguish accidental cases (things people get wrong) from malicious attacks - the latter are ways people can hack you, the other is something that doesn't give malicious access.
  369. # [23:18] <chaals> MJS: CSRF lets people set up malicious attack
  370. # [23:18] <chaals> MM: I am happy that if we can solve the malicious cases we are fine.
  371. # [23:19] <chaals> TC explains his email example with a drawing.
  372. # [23:19] <shepazu> original confused deputy description: http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html
  373. # [23:20] <chaals> MJS: I think that this setup requires a shared secret, which requires server-server communication.
  374. # [23:20] <chaals> Present+ TAG
  375. # [23:21] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  376. # [23:22] * Joins: DanC (connolly@128.30.52.169)
  377. # [23:22] * Joins: johnnyg (johnnyg@216.239.45.4)
  378. # [23:22] <MikeSmith> q?
  379. # [23:22] * Zakim sees no one on the speaker queue
  380. # [23:22] * DanC wonders who (if anybody) is scribing
  381. # [23:22] * Joins: mmielke (mmielke@72.254.83.160)
  382. # [23:22] * Joins: noahm (noah_mende@72.254.93.185)
  383. # [23:22] * anne chaals is
  384. # [23:23] * anne but he's prolly not scribing what has already been said
  385. # [23:23] * Quits: mmielke (mmielke@72.254.83.160) (Quit: mmielke)
  386. # [23:23] <DanC> RRSAgent, poinger?
  387. # [23:23] <RRSAgent> I'm logging. Sorry, nothing found for 'poinger'
  388. # [23:23] <DanC> RRSAgent, pointer?
  389. # [23:23] <RRSAgent> See http://www.w3.org/2009/11/02-webapps-irc#T22-23-14
  390. # [23:23] <chaals> TC: 3 servers. 1 has photos, 2 is a printer, 3 is a storage service
  391. # [23:23] * Joins: htt (ht@128.30.52.169)
  392. # [23:23] * Joins: Marcos (Marcos@72.254.60.247)
  393. # [23:23] * Joins: mmielke (mmielke@72.254.83.160)
  394. # [23:23] * Quits: ht (ht@128.30.52.169) (Ping timeout)
  395. # [23:24] * htt is now known as ht
  396. # [23:24] <chaals> MJS: CORS tries to cut out the requirement that your servers have to talk to each other in order to allow the request. Request something from server A, then you can make a request to server B without having to ping back to server A and ask that to talk to B
  397. # [23:24] <MikeSmith> somebody who has a camera should please take a photo of Tyler's diagram
  398. # [23:25] <chaals> TC: I think you are explaning how people can use one-time tokens to solve that problem. We don't think you need to use CORS to do that, and if you do rely on CORS you are vulnerable to Confused Deputy
  399. # [23:25] <DanC> (what mjs said sounds like one of the CORS requirements... advancing the state-of-the-art from having to go thru the origin to get to (coorperating) 3rd parties)
  400. # [23:25] <chaals> MM: The key is that post-login the auth login is not ambient
  401. # [23:25] <shepazu> q+ rob
  402. # [23:25] * Zakim sees rob on the speaker queue
  403. # [23:25] * Quits: plh (plh@128.30.52.28) (Quit: always accept cookies)
  404. # [23:26] <chaals> MJS: Main reason for CORS is to bootstrap the one-time mechanism - only other known ways are shared secret on server side and require server-server communication to pass the tokens
  405. # [23:26] <chaals> s/ways/way/
  406. # [23:27] <chaals> ... (server can't send its secret via the client, because then it isn't secret)
  407. # [23:27] * Joins: JonathanJ (hollobit@72.254.116.68)
  408. # [23:27] <chaals> DS: Is the data otherwise secure?
  409. # [23:27] <chaals> TC: Yes.
  410. # [23:28] <DanC> (can't quite tell if that requirement is in http://www.w3.org/TR/access-control/#requirements or not. maybe it's in the use cases.)
  411. # [23:28] <chaals> ack rob
  412. # [23:28] * Zakim sees no one on the speaker queue
  413. # [23:28] <chaals> Rob: Seems there are disagreements on what CORS is. You see it as an auth system, and I don't think that it is - CORS says you can talk to this guy, but the auth sits on top of that.
  414. # [23:28] * DanC would like a clue... who's that in red?
  415. # [23:28] * Joins: mmani (c6980d43@128.30.52.43)
  416. # [23:29] <chaals> MM: You are not an origin...
  417. # [23:29] * DanC t
  418. # [23:29] * DanC tx
  419. # [23:29] <chaals> MJS: You can make a request, but you can't guarantee that it gets fulfilled
  420. # [23:29] * anne DanC Mark Miller
  421. # [23:29] <MikeSmith> q?
  422. # [23:29] * Zakim sees no one on the speaker queue
  423. # [23:29] * Joins: timeless_mbp (timeless@72.254.57.15)
  424. # [23:29] * ht danc, see #tagmem
  425. # [23:29] * Quits: adrianba (adrianba@72.254.109.40) (Ping timeout)
  426. # [23:30] <chaals> TC: CORS adds a header on origin, that sites will use (because they are encouraged to) as a mechanism for auth, and that leads them to be caught by confused deputy
  427. # [23:31] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  428. # [23:31] <DanC> (the security risks are clear enough to me; have alternative designs that avoid the risks been offered?)
  429. # [23:32] <chaals> MJS: Think that there are cases where CORS will be used, that do not introduce the problem. I want to see why we will run into problems.
  430. # [23:32] * ht believes that Mark and Tyler's proposal is exactly that, but only on circumstantial evidence
  431. # [23:32] * DanC pointer to proposal?
  432. # [23:32] * ht the flip chart
  433. # [23:32] * ht sorry
  434. # [23:33] * DanC thought the flip chart was a description of the problem. guess I'm not following
  435. # [23:33] <chaals> MM: Objection specifically applies to 3-party scenarios. 2-parties don't create a problem. But once you create the system, and people apply their 2-party system to 3-party cases, you *will* end up with problems.
  436. # [23:33] * anne ... I don't think the alternative has been explained fully yet
  437. # [23:33] <chaals> MJS: Classic CSRF problem is that the 2 parties are a site expecting a form, and the user giving it, and a 3rd-party making malicious use of the user's authority.
  438. # [23:33] * ht right
  439. # [23:33] <DanC> (seems to me all the relevant arguments are represented in the WG; if you just give me an issue # so I can tune in later and see what's decided, I'll happily go do other stuff.)
  440. # [23:33] <ht> +1
  441. # [23:34] <anne> DanC, there is no issue number
  442. # [23:34] <DanC> yeah, that seems like a bug
  443. # [23:34] <chaals> ... CORS lets you solve this by giving a secure mechanism for dealing with the transaction.
  444. # [23:34] <shepazu> q+ raman
  445. # [23:34] * Zakim sees raman on the speaker queue
  446. # [23:34] * Joins: Marcos (Marcos@72.254.60.247)
  447. # [23:34] * Quits: Marcos (Marcos@72.254.60.247) (Quit: Marcos)
  448. # [23:34] <DanC> easy to fix: ISSUE: confused deputy problem
  449. # [23:34] <anne> DanC, if we agree this is an issue there's no need for an issue number because we'd need to do something else
  450. # [23:35] <chaals> TC: Web browser is on a site that cmes from the photo manager. all interactions take place on that page.
  451. # [23:35] <DanC> anne, not at all.
  452. # [23:35] <noahm> Art: I'm seeing some sentiment that if the Webapps group would open a formal issue to explore confused deputy, the TAG would consider that a good step.
  453. # [23:35] <chaals> ... user hits a button to print a photo. a button asks a printer site to print a photo.
  454. # [23:35] <DanC> an issue is just a promise to make a decision; it doesn't presume which way the decision will go
  455. # [23:36] * chaals will open an issue if we don't solve this...
  456. # [23:36] * noahm Dan and Henry, that do it for you?
  457. # [23:36] * DanC would like you to open an issue even if you don't
  458. # [23:36] * chaals welcomes anyone else doing so in the meantime
  459. # [23:36] * ht put that on the record Chaals and we can go
  460. # [23:36] * chaals ok,cheers
  461. # [23:36] * noahm all set, TAG members?
  462. # [23:36] * ht waiting to see it on the record
  463. # [23:36] <chaals> ACTION: chaals to raise an issue for this question
  464. # [23:36] * trackbot noticed an ACTION. Trying to create it.
  465. # [23:36] * RRSAgent records action 2
  466. # [23:36] <trackbot> Created ACTION-432 - Raise an issue for this question [on Charles McCathieNevile - due 2009-11-09].
  467. # [23:36] * Quits: Qiuling (panqiuling@72.254.91.36) (Quit: Qiuling)
  468. # [23:36] * ht thanks!
  469. # [23:36] <MikeSmith> action-432?
  470. # [23:37] * trackbot getting information on ACTION-432
  471. # [23:37] <trackbot> ACTION-432 -- Charles McCathieNevile to raise an issue for this question -- due 2009-11-09 -- OPEN
  472. # [23:37] <trackbot> http://www.w3.org/2008/webapps/track/actions/432
  473. # [23:37] <anne> DanC, fair enough http://www.w3.org/2008/webapps/track/issues/108
  474. # [23:37] * noahm methinks s/this issue/confused deputy/ Modulo that, thanks much, Chaals!
  475. # [23:37] <anne> close ACTION-432
  476. # [23:37] * trackbot attempting to close ACTION-432.
  477. # [23:37] <trackbot> ACTION-432 Raise an issue for this question closed
  478. # [23:37] * Joins: Kai (chatzilla@72.254.114.142)
  479. # [23:37] <DanC> :) issue-108. thanks.
  480. # [23:37] <MikeSmith> ht, I will change that now
  481. # [23:37] * ht thanks Anne, Mike, Chaals
  482. # [23:38] * DanC is ready to head out... wonders what's the least disruptive way to do so
  483. # [23:38] <chaals> IH: How does the manager authorise printing?
  484. # [23:38] * ht stand up on 3..
  485. # [23:38] <ht> 2..
  486. # [23:38] * ht 2..
  487. # [23:38] * ht 1..
  488. # [23:38] * ht go!
  489. # [23:38] * Quits: DanC (connolly@128.30.52.169) (Client exited)
  490. # [23:38] <chaals> TC: Out of band, they made an agreement that the manager could ship jobs to the printer.
  491. # [23:38] * Joins: arun (arun@72.254.57.36)
  492. # [23:40] * Quits: noahm (noah_mende@72.254.93.185) (Ping timeout)
  493. # [23:40] <chaals> MJS: THe question is whether there is a sensible way to use CORS that doesn't have a vulnerability?
  494. # [23:40] <chaals> CMN: I think the question is whether there is an obvious way to use CORS that introduces a security risk
  495. # [23:41] <chaals> TC: We are objecting to the idea that the group is baking up a way that people will create security risks
  496. # [23:41] <chaals> MJS: I don't think that is an issue. CORS allows for 2-party transactions to be done that are secure.
  497. # [23:42] <chaals> MM: The 2-site model is OK. The problem is that the assumption that the request reflects only the requestor's intention, and it is actually formed using information coming from a third party, a set of decision each individually sensible will compose to create a 3-party interaction pattern that we know to be vulnerable.
  498. # [23:43] * Joins: noahm (noah_mende@72.254.93.185)
  499. # [23:43] <chaals> TC: You say it is unlikely, but we have seen it played out into cookies. and into clickjacking. How often do we repeat the pattern before we stop doing it?
  500. # [23:44] <chaals> [back to the example]
  501. # [23:44] <MikeSmith> issue-108?
  502. # [23:44] * trackbot getting information on ISSUE-108
  503. # [23:44] <trackbot> ISSUE-108 -- confused deputy problem -- RAISED
  504. # [23:44] <trackbot> http://www.w3.org/2008/webapps/track/issues/108
  505. # [23:44] * Quits: ht (ht@128.30.52.169) (Ping timeout)
  506. # [23:44] <chaals> TC: The page now sends a request to the printer page to get the spool file, then we send a request to the storage page to copy stuff into the printer spool.
  507. # [23:45] * Joins: DanC (connolly@128.30.52.169)
  508. # [23:45] <MikeSmith> RRSAgent, make minutes
  509. # [23:45] <RRSAgent> I have made the request to generate http://www.w3.org/2009/11/02-webapps-minutes.html MikeSmith
  510. # [23:46] <chaals> ... the user owns lots of sites on the storage site. If the printer site sends back a request for DontTouchMe, the file transferred goes into DontTouchMe instead of a spool file.
  511. # [23:46] <chaals> MM: Intuitive assumption for the developer is that the URL from teh printer site is a URLthe printer has access to.
  512. # [23:47] <chaals> ... problem arises because if the storage site checks access against the origin, it will check against the manager's access, not the printer's.
  513. # [23:47] <chaals> ... manager would want to make the decision based on whether the printer has access, but has no way to ask that.
  514. # [23:48] <chaals> TC: There is an access control problem. CORS is telling developers to use a solution that won't work. There are other solutions.
  515. # [23:48] <chaals> Rob: If manager was only talking direct to the client, direct to the printer, and direct to the store, no problem.
  516. # [23:48] <chaals> AR: The use case can be shoe-horned into other systems.
  517. # [23:49] <chaals> MM: Yes, into any situtation where auth is passed on behalf of the client. If the requestor can say "I want this if my request source had access" then you solve the problem.
  518. # [23:49] <chaals> DS: MM agreed there are ways to build secure applications with CORS< as well as building vulnerabilities.
  519. # [23:49] <chaals> MM: True.
  520. # [23:49] <chaals> q+
  521. # [23:49] * Zakim sees raman, chaals on the speaker queue
  522. # [23:50] <chaals> q- raman
  523. # [23:50] * Zakim sees chaals on the speaker queue
  524. # [23:50] <chaals> q+ Tyler
  525. # [23:50] * Zakim sees chaals, Tyler on the speaker queue
  526. # [23:50] <mjs> oh hey Zakim is back
  527. # [23:51] <mjs> q+
  528. # [23:51] * Zakim sees chaals, Tyler, mjs on the speaker queue
  529. # [23:51] <chaals> MM: Issue is primitives that compose data. Analogy - LISP was dynamically scoped, and that was useful in many ways. But there were a set of individual decisions where you can't know tha they are bad, compose together to create a problem.
  530. # [23:52] <chaals> CMN: If you can restrict the system to 2 servers, can you avoid the problem.
  531. # [23:52] <chaals> TC: No. You can still make the problem without the 3rd website.
  532. # [23:53] <chaals> ... e.g. combine the storage and manager here
  533. # [23:53] <chaals> IH: Why would the manager give the printer access to tell it to write something over closed content?
  534. # [23:53] <sicking> q+
  535. # [23:53] * Zakim sees chaals, Tyler, mjs, sicking on the speaker queue
  536. # [23:53] <chaals> MJS: it seems in the 2-party case you have to make it needlessly complicated to make the vulnerability work
  537. # [23:53] <chaals> ack chaals
  538. # [23:53] * Zakim sees Tyler, mjs, sicking on the speaker queue
  539. # [23:54] <mjs> q+ rob
  540. # [23:54] * Zakim sees Tyler, mjs, sicking, rob on the speaker queue
  541. # [23:54] <chaals> TC: If any auth data from site A came from site B, you create confused authority.
  542. # [23:54] <chaals> MM: If you are not using anything that didn't come from *you*, then you are not creating a vulnerability.
  543. # [23:55] <arun> q+
  544. # [23:55] * Zakim sees Tyler, mjs, sicking, rob, arun on the speaker queue
  545. # [23:55] <chaals> ack ty
  546. # [23:55] * Zakim sees mjs, sicking, rob, arun on the speaker queue
  547. # [23:56] <chaals> TC: If you can say "don't apply my authority to anything I didn't make myself" you solve the problem.
  548. # [23:56] <chaals> ack mj
  549. # [23:56] * Zakim sees sicking, rob, arun on the speaker queue
  550. # [23:56] <chaals> MJS: If making requests to yourself can have this problem, that already exists. XHR requests to you implicitly carry auth because you are the only one that can make a request to yourself.
  551. # [23:57] <chaals> ... so any request using info from a 3rd party exposes this.
  552. # [23:57] <chaals> TC: Yes
  553. # [23:57] <chaals> MJS: Self to self has client authority
  554. # [23:57] <chaals> TC: Yes, but we should be trying to reduce this.
  555. # [23:58] <chaals> MM: Guest XHR should not present auth even when it goes back to its own origin.
  556. # [23:58] * Quits: gsnedders (gsnedders@83.252.229.211) (Quit: gsnedders)
  557. # [23:58] <MikeSmith> Present+ timeless
  558. # [23:58] <chaals> MJS: So using guestXHR is similar to formulating requests in a way that you use guestXHR-like behaviour for requesting things with 3rd party data.
  559. # [23:59] * Joins: timeless (timeless@65.75.195.122)
  560. # [23:59] <chaals> MM: Yes. It is normally possible to make the mistake. Compat prevents us from retiring existing mechanisms that allow this, but not introduce new mechanisms that have the same problem, but a new mechanism that doesn't have this problem.
  561. # [23:59] <MikeSmith> q?
  562. # [23:59] * Zakim sees sicking, rob, arun on the speaker queue
  563. # [23:59] <chaals> ... guestXHR is a refolrmulation of CORS that addresses our security concerns.
  564. # Session Close: Tue Nov 03 00:00:00 2009

The end :)