Using W3C widgets in a web container: two implementations contrasted
All, Two EU-funded projects have implemented the draft W3C Widgets specifications, both the packaging and API parts. What is notable from these projects have been the adaptations used to enable widgets conforming to the draft to be used in a web environment rather than in a dedicated platform such as a browser, OS or device widget layer. We've documented and discussed the extensions and implementation approaches here: http://groups.google.com/group/talk-about-widgets/web/implementating-the-w3c-widget-specification In brief, the Palette project has added W3C widgets functionality through developing the engine as part of an open-source portal web application, whereas the TenCompetence project developed a standalone open-source engine for adding widgets to multiple web applications, rather similar in approach to the Apache Shindig project for implementing Google OpenSocial. In addition, both projects wanted to add additional functionality to the API; this has included state coupling and shared states to enable richer interaction between (a) widgets in the same user context and (b) instances of the same widget from different users (i.e. collaborative applications such as chat and voting). Note that though both were funded by the EC IST programme, Palette and TenCompetence had not been collaborating prior to a recent event where members of both were asked to provide papers, when we discovered we had undertaken parallel efforts at solving the same problems with the same specifications! Hopefully this gives others an opportunity to learn from our different approaches. Both projects are focussed on networked learning solutions and research, for which Widgets provided an elegant solution to a number of issues in reaching learners and co-ordinating access to functionality. For more background on the projects themselves, see: http://www.tencompetence.org http://palette.ercim.org/ Cheers, Scott /-/-/-/-/-/ Scott Wilson Assistant Director, JISC CETIS University of Bolton scott.bradley.wil...@gmail.com http://www.cetis.ac.uk/members/scott
Re: [widgets] Minutes from 8 January 2009 Voice Conference
On Thu, Jan 8, 2009 at 7:51 PM, Arthur Barstow art.bars...@nokia.com wrote: JS: there is a protocol for helping sort out a chain if something is missing ... Gecko has some new suport for this it's indeed AIA - Authority Information Access
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
Maciej Stachowiak wrote on 1/15/2009 12:47 AM: So one thing to keep in mind is that any POST-based form would not be vulnerable to this kind of attack unless the victim site actually submits a form to an untrusted site. There is no way for a GET request to be redirected to a POST, and it seems to me the practice of Site A submitting a form to untrusted site B is likely to be quite rare and easily avoidable. Using XSS, an attacker could change the target of a login form to a MitM site, then redirect back to the original target, hiding the attack from the user. If we use Access Control Origin exclusively, then the Origin would be the original log-in page, not the attacker's MitM site (or NULL), so the attack would be invisible to the site too. Furthermore, HTML5 specifies that the XXX-Origin (or whatever it might get renamed to) header should not be sent for GET requests, the only kind of request where it would plausibly help anything. I disagree with the implementation within HTML5; I think it should be sent when the GET is going back to the same Origin, so a site can confirm that the request came from itself. I have other ideas about redirects, but that's another discussion. Thus, the difference in behavior of the CSRF-prevention Origin does not do any good, and so we may as well use just one Origin header. The Origin header (as defined in Access Control) will always be the page that made the initial request; redirects would be invisible. That in itself effectively neuters the CSRF protections. The only way to combine them isn't an option (per this list), so we now need two headers to address the specific requirements of each. - Bil
Re: Fwd: SVG 1.1 Java interface license
Hi Rigo. Rigo Wenning: it is not clear to me what you are exactly asking for. The Apache XML commons files now contain the right text in http://svn.apache.org/repos/asf/xml/commons/trunk/java/external/ Yes, Michael Glavassevich updated the text there just recently, but I pointed out to him since that not all of the files within that directory are licensed under that text (only the DOM (Core, Events, etc.) Java files, and not, for example SVG). There is no HTML file anymore, but the file LICENSE.dom-software.txt contains the right text. Yes, sorry, I meant to say txt instead of html. With respect to the cosmetic change of wording between the DOM3 license text and the SVG 1.1 license text, I do not think they were intended to carry any change in meaning: http://www.w3.org/TR/SVG11/copyright-notice.html http://www.w3.org/TR/DOM-Level-3-Core/copyright-notice.html Ah, in fact I hadn’t noticed that page, /TR/SVG11/copyright-notice.html. It does seem to have the Java package renaming clause there. So SVG is consistent with DOM (although I guess it would be better if this copyright-notice.html were included in the zip file; we can address this when we publish SVG 1.1 second edition). Concerning the bindings of the element traversal specification, I have not seen a link to a zip file with bindings in them from the Recommendation. The traversal specification itself is under the W3C document license, including the annexes. If it really creates a problem, we are able to release the bindings in a separate folder or zip together with a different license without having to change the Recommendation. I think there are problems with having it under the document license (for example the “No right to create modifications or derivatives of W3C documents is granted pursuant to this license” part). Putting a ZIP file, including the interface licensed under the software license with the extra clause, somewhere in W3C datespace, and then linking to it from an erratum, looks like the best course of action. Then there is consistent licensing across the interfaces. It may still be worth considering requiring the software license plus Java package renaming clause be the recommended license as a policy, so that WGs don’t have to consider it themselves. (Would it even be worth creating a new version of http://www.w3.org/Consortium/Legal/copyright-software to include the clause?) Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
On Jan 15, 2009, at 7:24 AM, Bil Corry wrote: Maciej Stachowiak wrote on 1/15/2009 12:47 AM: So one thing to keep in mind is that any POST-based form would not be vulnerable to this kind of attack unless the victim site actually submits a form to an untrusted site. There is no way for a GET request to be redirected to a POST, and it seems to me the practice of Site A submitting a form to untrusted site B is likely to be quite rare and easily avoidable. Using XSS, an attacker could change the target of a login form to a MitM site, If the site has an XSS vulnerability, then there is no need to stage a CSRF attack using a man-in-the-middle server. The injected script could perform the equivalent of the CSRF attack directly (for example by altering form values and programatically submitting the form). Thus, I do not believe it makes sense to defend against this scenario, since by assumption the victim site is already owned. then redirect back to the original target, hiding the attack from the user. If we use Access Control Origin exclusively, then the Origin would be the original log-in page, not the attacker's MitM site (or NULL), so the attack would be invisible to the site too. The same would be true just by exploiting the site directly via the XSS vulnerability. Furthermore, HTML5 specifies that the XXX-Origin (or whatever it might get renamed to) header should not be sent for GET requests, the only kind of request where it would plausibly help anything. I disagree with the implementation within HTML5; I think it should be sent when the GET is going back to the same Origin, so a site can confirm that the request came from itself. I have other ideas about redirects, but that's another discussion. Well, the current HTML5 spec doesn't behave that way, so I think it is still the case that it provides practically no benefit. I don't think a redirect-tracking Origin on GET requests would have much benefit either, since in theory and by HTTP spec, GET-based forms should not have dangerous side effects. I realize that this is not true for some sites, but it would be easier for a thoughtful site to fix this by using POST than to do so by checking Origin on the server side. Thus, the difference in behavior of the CSRF-prevention Origin does not do any good, and so we may as well use just one Origin header. The Origin header (as defined in Access Control) will always be the page that made the initial request; redirects would be invisible. That in itself effectively neuters the CSRF protections. The only way to combine them isn't an option (per this list), so we now need two headers to address the specific requirements of each. The CSRF protections are only defeated in the GET case (where currently the CSRF-protection header is specified not to be sent), and in the case where the site has hostile content injected via XSS (in which case as far as I can tell it is already owned). CSRF protection remains effective in the non-XSS non-GET case, which it seems to me is arguably the most important case for protection. Regards, Maciej
Re: [access-control] Access-Control-Allow-Origin: * and ascii-origin in IE8
Hixie said the position I expressed was a little unclear, so I'd like to clarify briefly: 1) FACT: The HTML5 version of the CSRF-defense header (currently called 'XXX-Origin' as a temporary measure) is specified not to be sent for GET requests. 1.a) FACT: As a result, it does not provide any protection against CSRF attacks on GET-based forms. 1.b) OPINION: I think this is an OK choice and I do not propose changing it. It strikes a decent balance between security and privacy. 2) FACT: Hyperlinks or GET-based forms (which are commonly submitted cross-site) cannot redirect to POST-based forms. 2.a) OPINION: Specially marking Origin in the case of redirects is not necessary to secure a site's off-site links and GET-based forms against CSRF attacks on POST-based forms. 3) FACT: Cross-site form POSTs to untrusted sites are quite rare; and furthermore a man-in-the middle attacker redirecting such a request cannot change the body of the submission. 3.a) OPINION: Defending against CSRF in this rare case is not worth the cost of a second different Origin header, and can be done in any case by the site making such bodies readily distinguishable from its own form post bodies. 4) FACT: Sites vulnerable to XSS could be vulnerable to a man-in-the- middle CSRF as in point 3, but they are owned anyway. 4.a) OPINION: It's not worthwhile to defend XSS-vulnerable sites against CSRF, as no meaningful protection is provided. CONCLUSION: We should use a single Origin header with the name and semantics of the Access-Control Origin header for both its Access- Control purpose and for redirect defense. The differences in the HTML5 version are not worth the cost of a very similar but subtly different header. And if we ever find the attack in case 3 is more than theoretical, we could add a 'Redirected-Via' header to provide full information. Regards, Maciej
