2009 Apr 23, 2:22Review of mime sniffing based XSS attacks with recommended protections for both web sites and browsers. Also, surprising to me since I rarely see it in this sort of a paper, thought and stats on the
compat. affects of their recommended changes for browsers. Very happy to see that in there!
web security ie browser xss sniff mime firefox chrome safari html html5 2009 Apr 23, 1:35"This e-mail is an attempt to give a relatively concise yet reasonably complete overview of non-Unicode character sets and encodings for 'Chinese characters', excluding those which are not supported
by at least one of the four browsers IE, Safari, Firefox and Opera (henceforth 'all browsers'), and tentatively avoiding technical details which are out of scope for HTML5 unless they are important
to gain a general understanding of the relevant issues."
html html5 iso-2022 charset encoding character unicode cjk 2009 Apr 7, 1:30I really dislike how IE deals with non-US-ASCII in URLs. I should write up a post on what exactly IE does with non-US-ASCII characters in URLs. "Just like IRIs the URL is mapped to a URI using UTF-8.
Except for the query component of the URL (the bit after the question mark). Here for legacy reasons the encoding of the document is used instead. Except if the encoding of the document is UTF-16, in
which case UTF-8 is used. Effectively, using non-ASCII characters in URLs in documents not encoded as UTF-8 or UTF-16 will give you surprising results, to say the least. Yay for browsers!"
http encoding html5 url uri unicode iri 2009 Apr 7, 12:14This makes plenty of sense, that a site should be able to check if a protocol handler exists for some URI scheme, but it'd be nice if this were some sort of declaritive fallback plan rather than
having to do it all with script. "The HTML5 standard function registerProtocolHandler() should probably remain void as in standard, but WhatWG could invent yet another boolean
protocolRegistered("area"), with the only argument (protocol name as string), to check whether a protocol is registered."
html5 registerProtocolHandler html script url uri scheme protocol 2009 Apr 7, 12:12HTML5's registerProtocolHandler seems to come from a cool FireFox 3 feature: "With web protocol handlers, the web application can register the specific protocol it wants to handle. Firefox will then
prompt the user to choose which of the registered applications (web or desktop) it should use to handle the action. Any protocol, real or imaginary, can be used - mailto: is only one example,
webcal:, tel: and fax: are others."
firefox uri scheme protocol mozilla html5 registerProtocolHandler 2009 Apr 7, 10:45HTML 5 allows websites to register themselves as handlers of particular URI schemes and particular content-types. I think this is great, but I'm surprised it doesn't support POSTing files to allow
for interactions with local content.
html5 url uri protocol reference html standard javascript webbrowser registerProtocolHandler 2009 Apr 7, 10:04Aggregation of feeds concerning HTML5 including Ian Hickson's, Planet Mozilla, Planet WebKit, the IE Blog, the WHATWG blog, etc etc.
w3c html5 html blog feed daily 2009 Apr 7, 9:02
I'm a big fan of the concept of registerProtocolHandler in HTML 5 and in FireFox 3, but not quite the implementation. From a high level, it allows web apps to register themselves as
handlers of an URL scheme so for (the canonical) example, GMail can register for the mailto URL scheme. I like the concept:
- Better integration of web apps with your system.
- Its easy for web apps to do.
- Links to URNs can now take the user to the sites the user prefers for the sort of thing identified by the URN. For example, if I have a physical address in HTML, instead of making that an http
link to Yahoo Maps, I can make the link a geo scheme URI and those who follow the link will get their preferred mapping site that
has registered for that scheme. Actually, looking at the geo scheme's RFC, maybe I'd rather use some other URN scheme to represent the physical location, but you get the point.
However, the way its currently spec'ed out I don't like the following:
- There's no way to know if you are the handler for a particular URL scheme which is an important question for web app URL protocol handler authors.
- There's no way to fallback to an http URL in the case that a particular URL scheme isn't registered. A suggested solution to testing the registration of a scheme is for browsers to provide an additional script method
to check if a scheme is registered. I don't like the idea of writing script that walks over all my page's links and rewrites them based on that method. I'd much rather see a declarative and
backwards compatible fallback mechanism, although I don't know what that would look like.
- There's no way to register for a namespace within the urn scheme URI, the info scheme URI, or the tag scheme URI. I want to register
info:lccn/... (Library of Congress Card Number identifiers) to LibraryThing or Amazon and I want to register urn:duri:... (dated URIs) to the Web Archive, among other things.
- Will this result in a proliferation of unregistered URL schemes with clashing namespaces? The ESW Wiki notes why this would be bad.
- And last, although this is nitpickier than the rest, I don't like the '%s' syntax used in the registration method. I'd much rather pass in an URL template, like the URL template used
in OpenSearch. If an URL template is used for matching rather than registering against a particular URL scheme, this could also allow for registering a namespace within a URN. For example
something along the lines of:
registerProtocolHandler("info:lccn/{lccnID}", "htttp://www.librarything.com/search_works.php?q={lccnID}", "LibraryThing LCCN")
url template registerprotocolhandler firefox technical url scheme protocol boring html5 uri urn 2009 Mar 23, 11:06The HTML5 spec tells us how it is in the real world for URLs: "This specification defines various algorithms for dealing with Web addresses intended for use by HTML user agents. For historical
reaons, in order to be compatible with existing Web content HTML user agents need to implement a number of processes not defined by the URI and IRI specifications [RFC3986], [RFC3987]."
html html5 url uri reference w3c 2009 Feb 3, 11:15"r2719 specifies that browsers should not allow scripts to set document.domain to anything on the Public Suffix List, such as "com" or "co.jp". Essential background reading on why this is dangerous:
Untraceable XSS Attacks. Most browsers already block this attack, e.g. Firefox since 3.0. [Background: Re: Setting document.domain]"
html5 tld publicsuffix dns security html internet web reference w3c 2008 Oct 24, 9:29"Standards Suck publishes video podcasts made by Anne van Kesteren, Marcos Caceres, and Lachlan Hunt about Web standards. We want to give the community an insight into standardization by critically
looking at what goes on behind the scenes at the W3C."
w3c blog video css html html5 xhtml web interview 2008 Oct 1, 1:08A weekly summary of the going-ons in the WHATWG usually on the topic of squabbles in HTML5 esp. what to do about the alt attribute in the img tag. Interesting stuff on charsets.
development software whatwg html5 html specification feed rss user-agent w3c 2008 Sep 29, 1:39Demos some of the working HTML5 features now available in recent builds of FireFox, IE8, Safari, and Opera. "Speaker: Ian Hickson. As the HTML5 effort reaches its first big milestone -- feature
completeness -- browsers are starting to implement it. It will be years before you can rely on HTML5 support when writing Web pages and applications, but you can start to experiment today to get a
feel of what the new standard offers. This talk will explore some of the most recent implementations of HTML5 features."
html5 ian-hickson html google video browser ie8 2008 Aug 20, 9:48Apple will or will not license the canvas tag? 'Apple Computer, Inc. ("Apple") believes it has intellectual property rights ("IP Rights") relative to WHATWG's Web Applications 1.0 Working Draft,
dated March 24, 2005, Section 10.1, entitled "Graphics: The bitmap canvas". At this time, Apple reserves all rights in its IP Rights and makes no representations as to Apple's willingness or
unwillingness to license these IP Rights. However, in the event that the Web Applications 1.0 Working Draft, dated March 24, 2005, becomes part of a formalized draft standard at W3C or IETF, for
example, Apple is prepared to address the disclosure/licensing rules of such organizations.'
apple patent html ip html5 canvas whatwg browser browser-war 2007 Apr 11, 10:27Summary of the various proposed replacements for HTML4.01.
article html internet xhtml xml html5 xhtml2 w3c chris-wilson
Some rights reserved