Re: Adopting postMessage and MessageChannel from HTML5?
Hi All, On Jan 12, 2010, at 10:42 AM, ext Maciej Stachowiak wrote: On Jan 12, 2010, at 3:48 AM, Arthur Barstow wrote: Was that Advisory Committee Review process followed for any of the other specs we're working on that are not mentioned by name in the charter? I listed a number of them in my earlier email (Selectors 2.0, WebSimpleDB, DataCache, UMP). The Chairs and Team contacts discussed all of these and agreed they were covered by WebApps' current charter. In this case, it seems like we should follow the precedence used with the other specs that were split from HTML5 and moved to WebApps, thus this new spec would need to be added to WebApps Charter before WebApps can publish it. Anyway, I'll ask the Team for advice on the way forward and we should move this administrative thread to WebApps Member list. The decision is that WebApps may now publish a Working Group _Note_ for postMessage and MessageChannel but we may not publish a Working Draft until this item is formally added to our Charter. -Art Barstow
[widgets][vmmf] clarifications
Hi All, I have modified the VMMF draft at http://dev.w3.org/2006/waf/widgets-vmmf/ and merged the comments from Vodafone after reviewing them. I have the following questions that I would like to agree on (the VMMF text highlights the corresponding content): 1. Does the interactivity affect the value of disabled attribute of the instances of the HTMLInputElement in the document? (I assume yes) 2. Does the interactivity affect the :enabled and :disabled pseudo-classes? (I assume yes) 3. Since opacity property in CSS affects the rendered elements' tree, it seems we cannot use opacity on body element to make it transparent. What about defining new property (e.g. transparent: on | off) that would be applicable on body element only? Then the transparency would depend on the content and not on the view-mode, thus it would limit the necessity for additional values. For example, I would like to have the widget behave like fullscreen or mini, but the transparency could depend on the content. 4. Should we use the DOM0 objects in the spec? It seems to be clearer to the readers, but the objects / methods / attributes are not normatively documented. Thanks, 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 Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [UMP] Server opt-in
On Tue, Jan 12, 2010 at 5:34 PM, Adam Barth w...@adambarth.com wrote: On Tue, Jan 12, 2010 at 4:24 PM, Mark S. Miller erig...@google.com wrote: The most it can do is ignore such information. It is up to the client not to provide such information. It is the job of the standard to require the client not to provide it, and to inform server-side authors not to expect it. Right, but we're working in a threat model where ambient authority is confusing to servers can causes them to have vulnerabilities. If the server is smart enough to understand the dangers of ambient authority, then we don't need UMP. CORS would be sufficient. The client-side requires the UMP restrictions. When a client is about to send off a request, it doesn't yet know whether or not the server will ignore the client's ambient authority. To ensure that it must, the request delivered to the server contains no credentials. On the server-side, a resource implemented to the UMP security model doesn't expect requests to bear credentials, since clients are not expected to send them. There shouldn't be any code branches on the server-side that are conditional upon receiving credentials. Consequently, if a malicious client does send credentials, these have no impact on processing of the request. On Tue, Jan 12, 2010 at 4:56 PM, Tyler Close tyler.cl...@gmail.com wrote: UMP supports confidentiality where client and server desire confidentiality. My question, then, is how can a server enjoy the confidentiality benefits of UMP without paying the security costs of CORS? By neither issuing, nor accepting client credentials, so that clients can access the server's resources without being vulnerable to CSRF attacks that would break confidentiality. The confidentiality of a resource can be compromised by a CSRF vulnerability in a legitimate client. A server can avoid this loss of confidentiality by providing its clients a security model that is not vulnerable to CSRF. UMP provides this security model. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
[WARP] Extending access to local network resources
All, Back in December I volunteered (http://www.w3.org/2009/12/10-wam-minutes.html) to propose an alteration / supplement to WARP to permit widget access to resources on local networks with no managed DNS system. Such resources do not fit into the current WARP model of listing origins in the widget's configuration document unless those resources have IP addresses known in advance to the developer. There are a very large number of such networks in use worldwide: I believe that the vast majority of home networks and many wireless networks fall into this category. The BBC is specifically concerned that the lack of distinction between local network resources and Internet resources in the current WARP model could prevent widgets from being able to access network resources served from media devices on home networks. Anyway, the specific proposal I would like to make is for another special value of the origin attribute of the access element in the widget configuration document called link-local or similar, an associated special value in the access-request list and an associated processing rule that says that when the link-local value is specified, the user agent should grant access to network resources on the same subnet(s) as the user agent. I haven't gone into more technical detail in this email because I suspect that there will be sufficient disagreement with the general principles laid out above to generate a productive discussion. A few points, though: 1. I think that the definition of a subnet in IP versions 4 6 is sufficient to allow a meaningful definition of link-local. 2. Users are likely to want control over which specific networks a widget is granted access to, rather than just a blanket yes or no permission to access whatever local network(s) to which the host may be connected when the widget is running. I don't think that this is something that can or should be dealt with in the configuration of widgets. I believe that good user experiences can be constructed to give the user that control, but I won't go into detail unless somebody asks me to. 3. I would expect most *useful* widgets that can access local network resources to need some kind of ability to browse the local link for resources to access. Again, I think that's out of scope for a WARP alteration/supplement; it's the sort of thing people use mDNS + DNS-SD or UPNP's SSDP for, but those aren't web protocols, and Robin's threatened to drag me into the DAP WG if I start talking about device APIs. 4. Clearly the local network and the local link are not necessarily the same thing. I'm proposing a solution targeting the latter because (a) it actually has a useful definition and (b) I believe it to be sufficient for the use cases I care about. I look forward to your comments and criticisms - in particular I would like to understand the holes that Arve says are opened by making a distinction between local and remote IP addresses. S
[Bug 8758] New: Define DOMContentLoaded
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8758 Summary: Define DOMContentLoaded Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DOM3 Events AssignedTo: schep...@w3.org ReportedBy: ms2...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org HTML5 fires a DOMContentLoaded event. [1] It would probably be useful to define it in DOM3Events. [1] http://www.whatwg.org/html5/#stop-parsing -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [UMP] Server opt-in
On Thu, Jan 14, 2010 at 9:20 AM, Tyler Close tyler.cl...@gmail.com wrote: The confidentiality of a resource can be compromised by a CSRF vulnerability in a legitimate client. Can you define what you mean by CSRF? I think we must have different ideas about what the term means because I don't understand that sentence. For reference, here's a definition of CSRF that I wrote in 2008: In a cross-site request forgery (CSRF) attack, the attacker disrupts the integrity of the user’s session with a web site by injecting network requests via the user’s browser. --- http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf Here's how Wikipedia defines CSRF: Cross-site request forgery, also known as a one-click attack or session riding and abbreviated as CSRF (sea-surf[1]) or XSRF, is a type of malicious exploit of a website whereby unauthorized commands are transmitted from a user that the website trusts. --- http://en.wikipedia.org/wiki/Cross-site_request_forgery In particular, both of these definitions talk about integrity violations on the server. You seem to be talking about a confidentiality issues on the client. Adam
Re: File API: Blob and underlying file changes.
It seems that we feel that when a File object is sent via either Form or XHR, the latest underlying version should be used. When we get a slice via Blob.slice, we assume that the underlying file data is stable since then. So for uploader scenario, we need to cut a big file into multiple pieces. With current File API spec, we will have to do something like the following to make sure that all pieces are cut from a stable file. var file = myInputElement.files[0]; var blob = file.slice(0, file.size); var piece1 = blob.slice(0, 1000); var piece2 = blob.slice(1001, 1000); ... The above seems a bit ugly. If we want to make it clean, what Dmitry proposed above seems to be reasonable. But it would require non-trivial spec change. On Wed, Jan 13, 2010 at 11:28 AM, Dmitry Titov dim...@chromium.org wrote: Atomic read is obviously a nice thing - it would be hard to program against API that behaves as unpredictably as a single read operation that reads half of old content and half of new content. At the same note, it would be likely very hard to program against Blob objects if they could change underneath unpredictably. Imagine that we need to build an uploader that cuts a big file in multiple pieces and sends those pieces to the servers so they will be stitched together later. If during this operation the underlying file changes and this changes all the pieces that Blobs refer to (due to clamping and just silent change of content), all the slicing/stitching assumptions are invalid and it's hard to even notice since blobs are simply 'clamped' silently. Some degree of mess is possible then. Another use case could be a JPEG image processor that uses slice() to cut the headers from the image file and then uses info from the headers to cut further JFIF fields from the file (reading EXIF and populating local database of images for example). Changing the file in the middle of that is bad. It seems the typical use cases that will need Blob.slice() functionality form 'units of work' where Blob.slice() is used with likely assumption that underlying data is stable and does not change silently. Such a 'unit of work' should fail as a whole if underlying file changes. One way to achieve that is to reliably fail operations with 'derived' Blobs and even perhaps have a 'isValid' property on it. 'Derived' Blobs are those obtained via slice(), as opposite to 'original' Blobs that are also File. One disadvantage of this approach is that it implies that the same Blob has 2 possible behaviors - when it is obtained via Blob.slice() (or other methods) vs is a File. It all could be a bit cleaner if File did not derive from Blob, but instead had getAsBlob() method - then it would be possible to say that Blobs are always immutable but may become 'invalid' over time if underlying data changes. The FileReader can then be just a BlobReader and have cleaner semantics. If that was the case, then xhr.send(file) would capture the state of file at the moment of sending, while xhr.send(blob) would fail with exception if the blob is 'invalid' at the moment of send() operation. This would keep compatibility with current behavior and avoid duplicity of Blob behavior. Quite a change to the spec though... Dmitry On Wed, Jan 13, 2010 at 2:38 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Jan 12, 2010 at 5:28 PM, Chris Prince cpri...@google.com wrote: For the record, I'd like to make the read atomic, such that you can never get half a file before a change, and half after. But it likely depends on what OSs can enforce here. I think *enforcing* atomicity is difficult across all OSes. But implementations can get nearly the same effect by checking the file's last modification time at the start + end of the API call. If it has changed, the read operation can throw an exception. I'm talking about during the actual read. I.e. not related to the lifetime of the File object, just related to the time between the first 'progress' event, and the 'loadend' event. If the file changes during this time there is no way to fake atomicity since the partial file has already been returned. / Jonas
Re: [UMP] Server opt-in
On Thu, Jan 14, 2010 at 11:34 AM, Adam Barth w...@adambarth.com wrote: On Thu, Jan 14, 2010 at 9:20 AM, Tyler Close tyler.cl...@gmail.com wrote: The confidentiality of a resource can be compromised by a CSRF vulnerability in a legitimate client. Can you define what you mean by CSRF? I think we must have different ideas about what the term means because I don't understand that sentence. I should have said CSRF-like, by which I mean a Confused Deputy attack. I've been using the former term since some people find it easier to understand. For example, imagine a client using a third-party storage service. To copy data from one file to another, they do a GET on one URL for the source file, followed by a POST to another for the destination file. If the storage service is an attacker, it could tell the client the source file's URL is the URL for a resource the client can read, but the storage server cannot. The confidentiality of this resource is then compromised by a legitimate client that fell victim to a CSRF-like attack. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
