Re: Mutation events replacement
On Jun 4, 2009, at 21:43 , Jonas Sicking wrote: That's annoying. I'm guessing that creating an Attr node just for this purpose is overhead we can live without given that they're never used, but it would be cheap (and dead useful) to include at least the attribute's name (ns/ln pair). Yeah, I definitely don't want to fore Attr nodes to be created just for this. The reason for not supplying the ns/ln pair is that this way we can fire the callback just once even if multiple attributes were changed during a DOM operation. I think that this is a sweep-under-the-rug optimisation. For certain the dispatching will be faster, but the receiving end will have to iterate (and memorise) all attributes each time one is changed. Why not simply provide a list of ns/ln pairs? Presumably the implementation knows that at little extra cost. It's called with myNode. I actually got this wrong in the algorithm in my initial proposal. Here is a fixed version: Ok, cool with me. I don't feel strongly about it — but it seems that every time we do something that's generic to nodes people come back and ask for an elements only variant, because that's what they actually use. The only advantage I can see with this is that listeners that that only care about the element tree, would avoid getting notified when only non-element nodes were added or removed. The code in the listener would be exactly the same. So it's strictly a performance optimization. On the flip side, for something like the innerHTML setter, the UA will have to keep track of if the childlist used to contain any elements, and then check if the new childlist contains any element. I'm not convinced that this is worth it simply for a performance optimization. At least not in the initial revision of this API. Well if you care only about elements changing you might have to walk the subtree to check that it was something else changing. But I don't have a strong use case and I'm happy to start with something simpler and toss in an element variant later if people scream. Ah, yeah, we could fire it for changes to the target too. Well, if you're firing on PIs it could be useful :) Actually, target is readonly. Duh! Precisely because they're rare, I'm worried about bugs when all of a sudden they're triggered. I think that there's a distinction (in authors' minds) between content — which includes text — and the other stuff — like PIs and comments. I think we should mirror that understanding, as it's rather sensible. It'd be a shame if 99.99% of code had to start with if (node.nodeType == PROCESSING_INSTRUCTION_NODE || node.nodeType == COMMENT_NODE) return; and half of it forgot to. Note that the mutation event DOMCharacterDataModified fires on comment nodes too. Has it been a problem there? I always thought that was a bug :) The only way I can think of people using either mutation the mutation event, or this new API, is that once you get notified, you find the node you are interested in, and then get that nodes .textContent. This will work fine even the node being changed was a comment or PI. I could live with a note in the specification saying that authors should use .textContent as indeed it is the right protective thing to do. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
RE: [widgets] What does it mean to have an unavailable API
Hi Scott, If a Widget requires shared state and participant features (e.g. Google Wave), then we inject our reverse-AJAX JS, which triggers either polling, comet, or piggyback synching (depending on server configuration). So we wouldn't want to do this for every widget, especially when many of them are single-user/ single-state and don't need it. I can imagine other features implemented by Widget UAs that might have resource implications if not selectively applied using feature. I hope I understood your point correctly. This seems for me also to be an implementation detail. In general it is also possible that the feature is attached by requestFeature() in already some pre-initialized state. Resource constraints would suggest requestFeature() instead of feature, IMHO, since the features could be attached only when needed. To further optimize e.g. the memory management, we could have something like unloadFeature(). But this is out of scope for the security discussion. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcin Hanclik Sent: Thursday, June 04, 2009 5:19 PM To: Scott Wilson Cc: Jonas Sicking; Henri Sivonen; public-webapps Subject: RE: [widgets] What does it mean to have an unavailable API We inject JS into the head of the Widget HTML, including the Widget API object, before sending it to the client browser; it automatically initializes itself. As for me this is just one of the possible implementations and the spec should not mandate how the additional API is made available. The client browser term should be replaced by rendering engine in this context, IMHO. Browser is something bigger for me. As for your other comments, I have to grasp it deeper first. Thanks. Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Thursday, June 04, 2009 3:50 PM To: Marcin Hanclik Cc: Jonas Sicking; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API We inject JS into the head of the Widget HTML, including the Widget API object, before sending it to the client browser; it automatically initializes itself. If a Widget requires shared state and participant features (e.g. Google Wave), then we inject our reverse-AJAX JS, which triggers either polling, comet, or piggyback synching (depending on server configuration). So we wouldn't want to do this for every widget, especially when many of them are single-user/ single-state and don't need it. I can imagine other features implemented by Widget UAs that might have resource implications if not selectively applied using feature. For this reason alone the feature element gets a +1 from me :-) S On 4 Jun 2009, at 10:30, Marcin Hanclik wrote: Yes, one of the differences between feature and requestFeature() is the time when the actual API gets available. What is the automatic polling? Do you assume that the loaded feature is initialized by a kind of onLoad method? Thanks. Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: Thursday, June 04, 2009 10:58 AM To: Jonas Sicking Cc: Marcin Hanclik; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API Security is on UC; another is resource use. If the UA only needs to inject the modules needed by a Widget this can have a positive impact on downloading and processing Widgets. For example, if you have a lot of optional features, each of which is another 12k of injected JS... well, you get the idea. You don't want to have those downloaded every time if they aren't needed. Also, if any of those modules do automatic polling then you only want to load them for Widget instances that really do need to use them. S On 4 Jun 2009, at 08:25, Jonas Sicking wrote: On Wed, Jun 3, 2009 at 3:16 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Jonas, requestFeature() is mainly (still debated, though) for websites, i.e. online content where the feature is not present. feature is for packaged widgets only. Ah, so requestFeature() is a BONDI spec, not a widget spec? However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Calling requestFeature() does not mean that the security aspects are omitted. The check against the security policy happens when
New draft of Widgets: Access Requests Policy
Hi, a new ED of WARP is up, including the following changes based upon prior discussion: - a new, nicer name - better definitions - more fleshed ou requirements - more detailed policy - fixes to the element definition - fixes to the processing model - better acknowledgements Share and Enjoy at http://dev.w3.org/2006/waf/widgets-access/ -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Fwd: [widgets] PC LC#2 comment regarding icons
Marcos, All - I can't find a record of this email in the mail list archive. Begin forwarded message: From: Penukonda Venkat (EXT-PSD-MSW/Boston) ext- venkat.penuko...@nokia.com Date: June 2, 2009 11:59:34 AM EDT To: public-webapps@w3.org public-webapps@w3.org Cc: Barstow Art (Nokia-CIC/Boston) art.bars...@nokia.com Subject: [widgets] PC LC#2 comment regarding icons Hi, Please refer to the latest Widget PnC spec http://www.w3.org/TR/ 2009/WD-widgets-20090528/ As per Section 8.10, icon element is not localizable using xml:lang attribute. It can only be folder-based localizable. Section 9, Step-7, Item# 7A is referring to xml:lang of icon elements to determine the valid icon list. Above two sections are contradictory. Most probably the section 9.7 part need to be removed or corrected in the spec. Please let me know if you have any questions. -Thanks, -Venkat. === Venkat Penukonda Software QA Consultant Mobile: (978) 944-5879
Next DOM3 Events Telcon (Time and Day?)
Hi, Folks- I will be hosting a F2F at my house next week, but we will be reconvening the telcons week after next, probably on Wednesday, June 17 or Thursday, June 18. Either day works for me, but finding a good time for everyone might be challenging: we typically have attendees from Finland (Olli Pettay of Mozilla), from US West Coast (Travis Leithead and Jacob ??, of Microsoft), US East Coast (myself, and sometimes some government folks who are helping with testing), and now Sydney, Australia (Dan Danilatos, of Google Wave). [1] Olli says: For me the best days are Wednesday and Thursday, 10:00am-01:00am (EET). Monday and Tuesday evenings/nights are also possible. Travis says: Jacob and I are available for telecons 8-5 pm (perhaps a little later if needed). Pretty much any time on Wednesday or Thursday works for me (late afternoon is best). Looking at TimeAndDate [2], it looks like 21:00 UTC on Wednesday might work, if Dan is a morning person (otherwise it would be pretty cruel to him). The proposed agenda is (what else?) mutation events and a sane keyboard model. The telcon will last one hour. So, I would greatly appreciate keeping up the email dialog on mutation events (I will compile the use cases and requirements on the wiki, as they roll in). It may be that we don't solve mutation events for DOM3 Events, but put together another dedicated spec to address the use cases in another way, and caution people about the costs of mutation events. In addition, I'm hoping that we have a flowchart of keyboard event models by that time, for both IE (Travis and Jacob are working on this), and if possible, for WebKit. We have my rough draft of an idealized model [3], and Olli's more accurate Gecko model [4]. Dan, or anyone on your team, or anyone at all, could you work on a WebKit keyboard event model flowchart? When I get them all, I'll normalize them for easy comparison, and we can work to produce a unified model that works as widely as possible. If anyone wants to send in addition flowcharts for other implementations (including mobiles), that would also be welcome. I don't know that we'll be able to solve the IME issues, but if we can, we will. [1] http://www.timeanddate.com/worldclock/meetingtime.html?month=6day=17year=2009p2=43p3=101p4=234p5=240iv=0 [2] http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009month=6day=17hour=21min=0sec=0p1=43p2=101p3=234p4=240 [3] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/d3e-keyflow.svg [4] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/proposals/keyflow-gecko.svg Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)
[+www-tag] I have received several private responses to my post, but oddly, nothing public yet. In these responses, I have been asked most frequently about: On Wed, Jun 3, 2009 at 4:21 PM, Mark S. Miller erig...@google.com wrote: Why identify even same origin requests as cross-origin? Given that all cross-origin requests are identified as such, then even without the normal credentials, the mere absence of an origin header identifies the requestor as being from the same origin. This is in fact a form of credential. If the containing page does not consider the script in question to speak for it, then it shouldn't be allowed to implicitly claim (by the absence of an origin header) to be from the same origin. Since malicious machines, or malicious applications running on trusted machines, can sent messages that aren't self-identified as cross origin, why do I suggest that lack of an origin header (in the absence of other credentials) might lead a server into granting more access than it would for messages self-identified as Origin: null? For servers reachable from the open internet, such server behavior would indeed be nonsensical. However, many servers are behind corporate firewalls and not reachable from the open internet. The premise firewalls rely on, whether sensible or not, is that all software running behind that firewall that can send arbitrary network messages are not malicious. Under this assumptions, browsers behind the firewall are assumed not to be malicious themselves, but of course may be running malicious scripts associated only with origins outside the firewall. These can of course cause their browser to initiate network messages to severs within the firewall, but only messages identified with browser-imposed headers. For messages not identified as cross origin, a server can assume that either the initiating program is non-malicious (because it is associated with the server's behind-the-firewall origin) or that the initiating program will not receive the results of the request. Under these admittedly fragile (but common) assumptions, a server may indeed trust a message that doesn't identify itself as cross origin more than it trusts one that does. Thus, a non malicious script that doesn't wish the sanitized scripts it loads to speak for it should force all the messages they initiate to be identified as Origin: null. -- Cheers, --MarkM
