[whatwg] AppCache
Dear Group and Readers, i guess it´s best to add a small chapter. With a paragraph for the CACHE MANIFEST NOMASTER token and a clause to accept the URL in the NETWORK section. The reason was, that i could cache Joomla! so far, that i can load css, scripts, images from disk and the rest from the network. Joomla! has a lot of files, and the loading time is big. Not caching the master solves this almost. _ The other thing is, to change not the original too much and to let it almost as it is, is to write _a new chapter for the cache object holder_. The list holding the urls and pointers to the cache files. Here i can arrange the data fields needed and the interface additions for iterating and modifying the array. This makes web application caches more programmable, considering existing apps, and giving much more possibilities to use the cache. E.g. generated content which can be cached easily. When reading the original i think about it seeing it complete and ask myself for the sense of changing it, it´s ok without caching a Joomla! or Wordpress, just for writing cool applications from scratch, but on the other side i think programmers will soon make use of the new features. The only thing, because so many tutorials would have to be written new, leave the functionality it has, like it is. Adding a chapter for the cache object holder, letting the fields and attribute functions and events appear, seems to be a possibilty to write it. Adding the whitelisting the master topic into the original is the only change which should really be made. For that some other clauses may obsolete, but it wouldn´t change the world...:-)) the current applications, browsers or tutorials. In the other subsection for the array, there are the informations for the browser programmers, how to style the cache array and some new functions for javascript. With friendly regards Edward Gerhold
Re: [whatwg] microformats, microdata, and custom data attributes
Justin Karneges wrote: Given that it is meant primarily as a data exchange protocol, explicit is better, so I'm preferring Microdata instead of Microformats here. The strength of the Microformats community is in helping to define the vocabulary, that's a different issue from the format you'll use to represent it. Rob
Re: [whatwg] Cache Manifest: why have FALLBACK?
Ilkka Huotari wrote: Benefits: Making things simpler, easier for the programmer to understand. Faster to learn, less bugs, better code? My initial thought is that including offline resources in a section entitled NETWORK will lead to more confusion among developers rather than less. Rob
Re: [whatwg] Cache Manifest: why have FALLBACK?
My initial thought is that including offline resources in a section entitled NETWORK will lead to more confusion among developers rather than less. Well, the FALLBACK section is intended to access to network too, isn't that right? I mean the resources in it are supposed to be fetched from the network (with the fallback resource). The section name (FALLBACK) doesn't reflect that though, it doesn't particularly reflect the fact that it is going to access the network. So, from this point too, I think it would make sense to combine them? Of course the section name NETWORK doesn't reflect the fact that there might be an offline resource, but I don't think it would be a huge problem? It would be backwards compatible which would be a nice point. Also, other benefits could include that a simpler (shorter) spec could perhaps make its further development/evolution easier. I'm a new developer with HTML5 so these are my experiences from the past few months, and can be off sometimes. But I thought I should share them anyway. Regards, Ilkka
[whatwg] Disallowing dots in the protocol argument of registerProtocolHandler()
Good afternoon, When playing with registerProtocolHandler() last week, I noticed that the following constructs are possible: navigator.registerProtocolHandler(mail.google.com, http://evilsite.tld/%s;, Google Mail); navigator.registerProtocolHandler(192.168.1.1, http://evilsite.tld/%s;, D-Link Wireless Router); According to the URI spec[1], both mail.google.com and 192.168.1.1 are valid URL schemes: Scheme names consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus (+), period (.), or hyphen (-). After running the lines of script above, typing any of the following URLs will lead the user to evilsite.tld: mail.google.com:80/mail/ 192.168.1.1:80 The use of confusing URLs to trick the user into visiting a malicious site is nothing new. The difference this time is that the URLs above would trick even me, and I'm not particularly prone to phishing. Using this technique to trick users would require an attacker to bypass two obstacles: * To permanently add mail.google.com as a scheme pointing to evilsite.tld, user approval in two separate dialogs is required in both Firefox and my internal Opera build. * If the user's web browser keeps the address field visible at all times, the user may notice that they are redirected to evilsite.tld once the URL has been interpreted by the browser. Despite this, we would prefer to err on the side of caution here. Our experience with other warning dialogs indicate that users don't necessarily read or understand what they approve, and phishing schemes with far cruder URLs (paypal.com.evilsite.com) succeed surprisingly often. To save ourselves (and our users) from possible future headaches, we have decided to disallow the use of dots in the protocol argument of registerProtocolHandler(). Of the IANA-registered URL schemes[2], only the following contain dots: iris.beep iris.xpc iris.xpcs iris.lws soap.beep soap.beeps xmlrpc.beep xmlrpc.beep z39.50r z39.50s I don't see any clear use cases for overriding any of the above in a web browser. Opera will still interpret URLs in accordance with the URI spec, but registerProtocolHandler() may only override the subset of URL schemes containing alphanumeric characters, + and -. I suggest the same restriction is added to the HTML specification. A proof of concept of the issue described in this email can be found here: http://people.opera.com/wilhelmja/registerprotocolhandler/ [1]: http://www.ietf.org/rfc/rfc3986.txt [2]: http://www.iana.org/assignments/uri-schemes.html -- Wilhelm Joys Andersen Core, Opera Software
[whatwg] Addition of a setExtend(in DOMString extend) method to the CanvasGradient interface
The extend mode of canvas gradients isn't under user control as it is in SVG. I'd like to propose adding a setExtend(in DOMString extend) method to the CanvasGradient interface[1], where the method would accept the arguments none, repeat, reflect and pad. These would be defined similarly to the values that the 'spreadMethod' attribute on SVG gradients accepts[2]. Jonathan [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasgradient [2] http://www.w3.org/TR/SVG11/pservers.html#LinearGradientElementSpreadMethodAttribute
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On Tue, 12 Apr 2011, Lachlan Hunt wrote: We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. [...] We'd like to know if we've missed any important schemes that must be blocked, and we think it might be useful if the spec listed most of those, except for the vendor specific schemes, which should probably be left up to each vendor to worry about. I haven't updated the spec yet, but it strikes me that maybe what we should do instead is have a whitelist of protocols we definitely want to allow (e.g. mailto:), and define a common prefix for protocols that are used with this feature, in a similar way to how with XHR we've added Sec-* as a list of headers _not_ to support. So e.g. we could whitelist any protocol starting with web+ and then register that as a common extension point for people inventing protocols for use with this feature, so that people writing OS-native apps would know that if they used a protocol with that prefix it's something that any web site could try to take over. I'd be curious about people's opinions on that matter. (If we did this, the whitelist may have to be updated occasionally to add new protocols that people invented that we think are fine to be overridden, but that are not web+-prefixed.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On Tue, Apr 19, 2011 at 10:33 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 12 Apr 2011, Lachlan Hunt wrote: We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. [...] We'd like to know if we've missed any important schemes that must be blocked, and we think it might be useful if the spec listed most of those, except for the vendor specific schemes, which should probably be left up to each vendor to worry about. I haven't updated the spec yet, but it strikes me that maybe what we should do instead is have a whitelist of protocols we definitely want to allow (e.g. mailto:), and define a common prefix for protocols that are used with this feature, in a similar way to how with XHR we've added Sec-* as a list of headers _not_ to support. So e.g. we could whitelist any protocol starting with web+ and then register that as a common extension point for people inventing protocols for use with this feature, so that people writing OS-native apps would know that if they used a protocol with that prefix it's something that any web site could try to take over. I'd be curious about people's opinions on that matter. (If we did this, the whitelist may have to be updated occasionally to add new protocols that people invented that we think are fine to be overridden, but that are not web+-prefixed.) This seems like the right approach. Even if we blacklist correctly now, needing to remember to blacklist each new protocol is too risky. A whitelist somewhat limits the potential for people using registerProtocolHandler in unexpected useful ways, but it still meets the primary use cases. Ojan
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On 2011-04-19 19:33, Ian Hickson wrote: On Tue, 12 Apr 2011, Lachlan Hunt wrote: We are investigating registerProtocolHandler and have been discussing the need for a blacklist of protocols to forbid. [...] We'd like to know if we've missed any important schemes that must be blocked, and we think it might be useful if the spec listed most of those, except for the vendor specific schemes, which should probably be left up to each vendor to worry about. I haven't updated the spec yet, but it strikes me that maybe what we should do instead is have a whitelist of protocols we definitely want to allow (e.g. mailto:), and define a common prefix for protocols that are used with this feature, in a similar way to how with XHR we've added Sec-* as a list of headers _not_ to support. Other protocols we should probably also whitelist: irc, sms, smsto, tel. I'm also curious how we could handle ISBN URNs, like: urn:isbn:0-395-36341-1 That would be useful to have a web service that could look up the ISBN and direct users to information about the book, or to an online store. As currently specified, services have to register a handler for urn, even if they only handle ISBN URNs. The other alternative would be to mint a new web+isbn scheme, which seems suboptimal. So e.g. we could whitelist any protocol starting with web+ and then register that as a common extension point for people inventing protocols for use with this feature, so that people writing OS-native apps would know that if they used a protocol with that prefix it's something that any web site could try to take over. That seems reasonable. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On Tue, Apr 19, 2011 at 11:11 AM, Lachlan Hunt lachlan.h...@lachy.id.au wrote: I'm also curious how we could handle ISBN URNs, like: urn:isbn:0-395-36341-1 That would be useful to have a web service that could look up the ISBN and direct users to information about the book, or to an online store. As currently specified, services have to register a handler for urn, even if they only handle ISBN URNs. The other alternative would be to mint a new web+isbn scheme, which seems suboptimal. Presumably we can specifically whitelist urn:isbn as a scheme to support (and adjust the algorithm sufficiently to make this do what's intended)? Are there other nested urn: schemes that we could expose? If so, we could just make the whole class of urn:* protocols available. So e.g. we could whitelist any protocol starting with web+ and then register that as a common extension point for people inventing protocols for use with this feature, so that people writing OS-native apps would know that if they used a protocol with that prefix it's something that any web site could try to take over. Sounds good. ~TJ
Re: [whatwg] Blacklist for regsiterProtocolHandler()
On 2011-04-19 20:29, Tab Atkins Jr. wrote: On Tue, Apr 19, 2011 at 11:11 AM, Lachlan Huntlachlan.h...@lachy.id.au wrote: I'm also curious how we could handle ISBN URNs, like: urn:isbn:0-395-36341-1 That would be useful to have a web service that could look up the ISBN and direct users to information about the book, or to an online store. As currently specified, services have to register a handler for urn, even if they only handle ISBN URNs. The other alternative would be to mint a new web+isbn scheme, which seems suboptimal. Presumably we can specifically whitelist urn:isbn as a scheme to support (and adjust the algorithm sufficiently to make this do what's intended)? Are there other nested urn: schemes that we could expose? If so, we could just make the whole class of urn:* protocols available. http://en.wikipedia.org/wiki/Uniform_Resource_Name#Examples http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[whatwg] Cache
Dear Group and Readers, writing a subsection Whitelisting the master entry, 6.6.3.4 would allow me to remove any The master file is always cached-like clauses, i think i´ve read before. The browser programmers will have followed these steps and so originally the master file had always been cached. Logically if you think about it. The other subsection on a higher level is The application cache lists, a chapter _about the container_ keeping the media. I dunno if there is one list, or three lists, for each section one, or what is read by the browser programmers, when they wrote the cache. For that, i think i have to pull out another ace. I am gonna look at the browser source codes, to see, what kind of structures they used for the application cache entries and lists. There i´ll learn, how they connected the javascript commands to the class operations in the c++ code. I think i´ll start with chrome, because i have a recent copy of chromiums sources. With the knowledge from that side, i should could create a good explanation of what to add to the containers and how to connect the new operations for the javascript api. The add to remove, iterator functions and the cool new events which allow to code plugins changing the cache contents. The stuff i´ve written about. That makes sense, a container section, or? I won´t change the existing thing in any way, but extend the programmed container with the function. Like in my first mail, but in this form in the specification document. I think the lists for the cache are explained, but how the browsers implemented it, i have to look after. The new chapter would exactly speak about the container and how the media is dynamically managed by the web application. There are attributes (let ...) and functions (step by step). I still am not shure if i will renumber the last sections or whatever. Sorry for my lameness to take a few more days. Until then With friendly regards Edward Gerhold
Re: [whatwg] microformats, microdata, and custom data attributes
On Tuesday 19 April 2011 03:27:30 Rob Crowther wrote: Justin Karneges wrote: Given that it is meant primarily as a data exchange protocol, explicit is better, so I'm preferring Microdata instead of Microformats here. The strength of the Microformats community is in helping to define the vocabulary, that's a different issue from the format you'll use to represent it. Ah, I simply assumed these were two competing approaches. Does this mean Microdata has no community behind it to work on vocabulary? In any case, I think the Person object defined by data-vocabulary.org should work for my purposes. But, if I feel the need to invent something new, I can propose it to the Microformats community first if that's the right process. I am quite new to these communities. Thanks, Justin
Re: [whatwg] microformats, microdata, and custom data attributes
On Tue, Apr 19, 2011 at 2:24 PM, Justin Karneges jus...@affinix.com wrote: On Tuesday 19 April 2011 03:27:30 Rob Crowther wrote: Justin Karneges wrote: Given that it is meant primarily as a data exchange protocol, explicit is better, so I'm preferring Microdata instead of Microformats here. The strength of the Microformats community is in helping to define the vocabulary, that's a different issue from the format you'll use to represent it. Ah, I simply assumed these were two competing approaches. Does this mean Microdata has no community behind it to work on vocabulary? Microdata is a syntax for encoding vocabularies into an HTML page, similar to how class/rel can be a syntax for encoding vocabularies. The vocabularies themselves can be defined largely ignorant of the encoding syntax, as long as the vocab's underlying data-structure ends up being more-or-less tree-based (vocabularies defined for RDF are officially graph-based, but in practice can usually be treated as tree-based). In any case, I think the Person object defined by data-vocabulary.org should work for my purposes. But, if I feel the need to invent something new, I can propose it to the Microformats community first if that's the right process. I am quite new to these communities. Sounds acceptable. The Microformats community is friendly and open, as far as I've experienced. Have fun! ~TJ
Re: [whatwg] Cache Manifest: why have FALLBACK?
I'm trying to figure out if there is any other difference between NETWORK and FALLBACK sections than FALLBACK section having the fallback resource. (I hope I'm not bothering people with my questions, but I also hope that these questions could help somebody else.) So... is there any other difference between them? I did some testing in Chrome and Firefox and while the behavior was not actually identical between those browsers, it seemed that there isn't any other crucial difference between the sections. Ilkka
