Re: [Fwd: Offline data synchronization API]
On Jun 21, 2008, at 12:13 AM, Nikunj Mehta wrote: Hi Art, Here's a paper that describes the use cases and requirements about AtomDB. It does not include API details, although if you find this interesting, we can proceed to that next. I look forward to reading comments and getting feedback from the community I would appreciate a summary of what AtomDB provides that is not covered by the offline features of HTML5. If there is indeed interesting new functionality, I would like to understand how it can work in concert with HTML5 features such as the application cache. Would AtomDB be a competing technology or a complementary technology? Regards, Maciej Thanks, Nikunj Arthur Barstow wrote: Nikunj - perhaps it would be helpful if you provided some additional information/pointers regarding AtomDB e.g. use cases and requirements, the architectural model, API, comparison/gaps versus related functions in HTML5, etc. -Regards, Art Barstow On Jun 11, 2008, at 5:11 PM, ext Nikunj Mehta wrote: We are familiar with the offline persistence capabilities of HTML5 and their support in browser implementations. Oracle's AtomDB and related specification are about transparent, read-write caches that are auto-synchronized using Atom publishing protocol. I hope this makes clear the intent of my original email. Regards, Nikunj Maciej Stachowiak wrote: On Jun 11, 2008, at 1:47 PM, Nikunj Mehta wrote: Hi Art, Charles, We have developed a technology, called AtomDB, at Oracle for transparent, local access to Web application resources when not connected to a network. This is one of the most frequently requested features on our mobile applications, which until now has required a non-Web application solution. Oracle is interested in developing Web applications for mobile and non- mobile environments that are resilient to network unreliability. In the process of developing AtomDB, Oracle has analyzed various challenges in off line data access. We realize that the Webapps WG is interested in this area and Oracle is willing to contribute resources to advance specifications that improve application robustness to network conditions. We have a specification that we could share with the WebApps WG, if there is interest. I look forward to what the working group has to say on this. HTML5 includes mechanisms for offline applications and offline data. The application cache is implemented in the Firefox 3 Release Candidate and the Safari 4 Developer Preview: http://www.w3.org/html/wg/html5/#offline Database storage is in Safari 3.1 and newer: http://www.w3.org/html/wg/html5/#sql Google Gears also has features similar to both of these and I believe those features are planned to converge with the standard. Regards, Maciej Going far without the bars.pdf
Re: IRC logging
* Lachlan Hunt wrote: There is currently no way to disable logging, as the need has never arisen in any of the other channels. We can note it as a feature request and it might get implemented one day. Contrary to what you suggest this has already been requested by several parties. There is of course never a need for that, since discussions you don't want to have logged are simply taken offline where neither channel participants nor log readers have access to them. Unfortunately no, but so far it's the best we've got available to us. It's always possible to fill in any gaps from other's personal IRC logs; it's quite simple for Krijn to insert them if someone sends them to him. Many would regard this as serious breach of protocol, unless the people whose conversations have been logged in the logger bot's absence approve of that explicitly for the occasion for various reasons; unreasonable as that may seem. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
* Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
* Anne van Kesteren wrote: Yeah, I'd very much prefer the Progress Events specification to handle this so that not all other specifications using the Progress Events specification need to do so. I agree that a protocol agnostic design would be good, but that indeed doesn't preclude saying what should happen in the HTTP case. Then you should probably file a separate issue on this. It seems to me though that saying much beyond that this is implementation-defined would be misleading to authors, e.g., they might hardcode progress values in their application and get very different values from the implementation, breaking their application. This could happen e.g. if the user is behind a proxy that rewrites the content in some way, or if there are errors in the transmission (the browser may have attempted to pipeline several in- dependent requests and has to retry them later due to a buggy server). If not specified in elaborate detail, the specification should of course highlight very explicitly that authors should not rely on the accuracy of the numbers in any way. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Opting in to cookies - proposal
* Jonas Sicking wrote: First off, as before, when I talk about cookies in this mail I really mean cookies + digest auth headers + any other headers that carry the users credentials to a site. I don't quite see why you would mix these. Is there anywhere where I can read up on the use cases for an extra feature to enable the transmission of cookies if not included by default? Especially for users credentials in cookies it is difficult to imagine real world applications that would depend on or at least greatly benefit from such a feature. By use case I mean elaborate descriptions of how a user would use the system as a whole to accomplish some well-defined and meaningful goal. I am particularily interested in the user interface research relative to this, for example, how the user is involved in the decision whether the cookies are sent, and when they should be sent but are not (because the user is not logged in at all with the other application, or the session has expired). It would seem that one way or the other, the embedding site would have to ask the user to login into the embedded site and stay logged in while it attempts to do whatever it is supposed to do. Training users to do that would of course lead to social engineering attacks (Please make sure you are logged into your account iframe/, then exploit some vul- nerability on the site, say a session riding one unrelated to AC). So I am wondering what I am missing here. Similarily, if this is just for some value-added services, it would be very interesting to see the usability research on how users react when, say, their customizations on some site suddenly no longer leak into the embedding application (which of course depends on whether, say, they had to consent before the browser would send the cookies to the embedded site, in that case they would have at least a clue where the error may come from). So in general I am rather doubtful that an option to send cookies along, be that with the Cookie or some alternate cookie header, is the best way to address whatever problem is supposed to be solved by this (not that I have seen a list, sufficiently detailed to propose alternate solutions, of those so far; if they are available I'd appreciate a pointer). By the time implementations of this are widely available, developers will have alternate technologies at their disposal to implement whatever cookie- dependant services they want. So since the idea here is to keep the attack surface managable, it seems the best course of action would be to not add this feature in the first place, unless and until we have detailed information on why applications cannot do without it sent here to the list and subjected it to public scrutiny. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Origin (was: Re: XHR LC Draft Feedback)
* Adam Barth wrote: We suggest that user agents attach an Origin header to POST requests. This balances the security benefits of easy CSRF protection with the privacy costs. If user agents attached this header, sites could protect themselves from CSRF by (2) undertaking state-modify actions only in response to POST requests and (2) implementing the below web application firewall rule (e.g., ModSecurity rule): Isn't that balance a little bit odd? You can virtually eliminate the privacy concerns simply by saying no more than This request has been initiated from a site different from the one mentioned in the Host header, say, `Pragma: cross-site`, without losing much flexibility. The scan for pragma contains 'cross-site' is also easier to set up. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: ISSUE-5 (Unexpanded Entities): Wording for the Treatment of Unexpanded Entity References and Entity Replacement Markup [Element Traversal]
* Web Applications Working Group Issue Tracker wrote: Simon Pieters suggests wording similar to HTML5, in http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0191.html. That is not a technically valid solution (and that particular wording does not, in fact, apply to the core node traversal interfaces, if you implement, say, .nextSibling as if entities had been expanded, entities have in fact been expanded). Anne's proposed solution is not valid either, except when applied to DOM Core, rescinding EntityReference nodes alltogether, as the issue is about how to implement this interface if you do have EntityReference nodes in the tree (or want your code to work whether or not you do). By the way, I would strongly recommend to use Subject header values no longer than ~50-60 bytes as longer ones trigger serious bugs in many mail clients, and would also strongly recommend to wrap lines in the body after ~70 characters. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: Origin (was: Re: XHR LC Draft Feedback)
* Collin Jackson wrote: The advantage of the Origin header is that it provides sites with functionality that can't already be emulated with XMLHttpRequest: it allows them to distinguish trusted (sub)domains from completely untrusted domains. The stated goal was to balance easy protection against session riding attacks without compromising privacy too much. Allowing session riding via some sites but not others is something that cannot be done securely today without major effort as whatever information is used to tell good requests apart from bad requests may either be absent or faked. That'll remain so until any browser that does not set the header can be blocked. I would hope that at that point, other means of cross site and document communication are more attractive to developers than what is currently not affected by same-origin restrictions, and hope that new ways of by- passing the same-origin restrictions will not rely on the Origin header alone, so I don't think there is any real advantage. Perhaps I'm missing something? I'm ignoring that the AC draft now also has a header named Origin as that is a more recent development. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
