Re: [whatwg] Specs for window.atob() and window.btoa()

[Boris Zbarsky]

On 1/6/11 3:25 PM, Aryeh Gregor wrote:

Browsers disagreed about how to handle input to atob() that can't be
produced by btoa().  Firefox mostly throws exceptions, WebKit is
slightly more lenient, and Opera doesn't throw exceptions at all.
gsnedders told me Opera's behavior caused site compat problems, so I
went with Firefox's behavior, or about as close to Firefox's behavior
as I could determine without reading the source code.


For what it's worth, Firefox's behavior for atob (based on reading the 
source code, sorta) is the following (ignoring various exceptions on 
allocation failures and the like):


1)  If the input string contains any 16-bit units whose value is greater 
than 0xff, throw INVALID_CHARACTER_ERR.


2)  If the input string's length is greater than 0x / 3, throw a 
generic failure code (because otherwise a 32-bit computation of the 
output string length will overflow; this could probably be changed to 
use 64-bit arithmetic).


3)  If the length of the source string is 0 mod 4 and the string ends in 
either "=" or "==" then chop off the trailing equals signs from the 
string.  If after this step the length is 1 mod 4, throw 
INVALID_CHARACTER_ERR.


4)  If the string contains any characters other than those in 
[A-Za-z0-9+/] then throw INVALID_CHARACTER_ERR.


Step 2 is certainly missing from your spec (and as I said, may not be 
desirable); I haven't verified whether your regexp ends up enforcing 
exactly 3+4 above.



As far as I can tell by writing tests, there are only two cases where
Firefox's atob() doesn't throw an exception on input that can't have
come from btoa().  First, if there are trailing bits after decoding
that aren't all 0, Firefox discards them.  So for instance, atob("YQ")
and atob("YR") both return "a".  Second, it doesn't require trailing =
signs, so atob("YQ") works although btoa("a") is actually "YQ==".


Based on code inspection, that sounds right in terms of what the Firefox 
behavior is.


Note that it's not that uncommon to use atob on things that came from 
other base64-producing tools, not just from btoa.  Not sure whether that 
matters here.


-Boris

Re: [whatwg] security for scripts with elevated permissions

[Glenn Maynard]

On Thu, Jan 6, 2011 at 5:21 PM, Aryeh Gregor  wrote:
> An XSS attack can still get IP address, and thus usually rough
> location, so most of what I said still holds.

My IP address points to an area several towns wide.  IPs for mobile
devices (where geolocation is more often used) often tell next to
nothing.  Geolocation will give my location to a few meters--they're
not even in the same category.

I don't care about this enough to worry about it, but I understand why
some people do.

> Lots of people have written extensive explanations of why browsers do
> this.  Here's one I submitted as a comment to lwn.net a while back,
> maybe it will clear things up: http://lwn.net/Articles/413600/

I'm not sure I find that entirely convincing, though I understand the
logic.  In any case, I don't expect this to change for HTTP/HTTPS.
Maybe SPDY will improve this, if it ever gains wide use.

>> By the way, another real-world issue with SSL is that it's
>> considerably more computationally expensive: handling encrypted
>> requests takes much more CPU, especially for high-bandwidth servers.
>> Not every service can afford to buy extra or more powerful servers to
>> handle this.
>
> Apparently this isn't a real issue anymore in practice.  CPUs are fast
> enough that SSL is no big deal.  Google saw only a small load increase
> when it turned on HTTPS by default for all Gmail users:
> http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Without knowing the load characteristics of Gmail front-end servers,
I'm not too convinced.  I've seen significant load differences simply
between using sendfile and not on a server pushing around 150-300
mbit, and that's just one side-effect of SSL.

Regardless, I do think it's reasonable to require SSL for particularly
sensitive APIs.  If the costs of using it are annoying, that'll just
have to be lived with.  However much you trust a site, you don't want
to elevate its permissions to grant, say, broad local file access on
an unencrypted connection.  (Well, unless it's an intranet or
localhost service, of course.)

Whether SSL is *enough* for sensitive APIs like that--that, I think,
is the open question.

-- 
Glenn Maynard

Re: [whatwg] Drag-and-drop feedback

[Ian Hickson]

On Tue, 2 Nov 2010, Charles Pritchard wrote:
> On 11/1/2010 6:03 PM, Ian Hickson wrote:
> > On Thu, 26 Aug 2010, Charles Pritchard wrote:
> > > On 8/25/2010 2:02 PM, Ian Hickson wrote:
> > > > On Mon, 2 Aug 2010, Charles Pritchard wrote:
> > > > > >
> > > > > > [ UAs can use  to let the user enter remote 
> > > > > > URLs ]
> > > > > 
> > > > > When a user through selection, click+drag or manual entry of a 
> > > > > URL should the browser still submit an Origin request header? It 
> > > > > seems that CORS doesn't come into effect here -- but at the same 
> > > > > time, it'd be handy for logging purposes and added security.
> > > >
> > > > I don't think there'd be an origin, but that's rather up to the 
> > > > user agent. (In this case it's acting on behalf of the user, not 
> > > > the page, so I don't think it makes sense to give the page's 
> > > > origin.)
> > >
> > > Sounds like an implementer would not include a Referer header, 
> > > either.
> >
> > Possibly.
> 
> Is this something we want to leave undefined? As the  
> widget typically routes directly to OS-level file management, I don't 
> think there's a simple solution to bringing more control to the browser.

I don't really see anything wrong with leaving this undefined; it's just a 
user feature, not something the Web page can have any control over.


> > > Continuing on with tweaking URLs to work with with the File API:
> > > 
> > > Chrome has gone ahead with their setData proposal, enhancing the 
> > > event.dataTransfer object so that users may drag a file from within 
> > > the browser onto their desktop.
> > > 
> > > The extension uses setData with a key of DownloadURL and a value 
> > > including a mime type, file descriptor and URI.
> > > 
> > > I'd like this interface to work within ondrop; if 
> > > getData(DownloadURL) is set, then a FileList would be returned in 
> > > event.dataTransfer.files, much like it is when users drag files from 
> > > their desktop into the browser.
> > > 
> > > This would of course require Origin checks; whereas dragging onto 
> > > the desktop does not require an Origin check.
> >
> > I'm not quite sure I follow what you are proposing. However, in a 
> > future version of this API we should definitely add a "promise"-like 
> > feature that lets you specify drag data without having it already 
> > downloaded, so that when the user drops the data somewhere, the 
> > browser can then ask the JS for the data. I'm not sure using 
> > setData('DownloadURL') is a good way to do it; that just seems to add 
> > more hacks to an already pretty hacky API.
>
> The DataTransferItem proposal is heading in this direction. Currently, a 
> file collection ".files", works with the File API and XmlHttpRequest. 
> Drag+drop from the desktop returns file objects.
> 
> I'm proposing we explore methods to enable drag+drop from within the 
> browser to return file objects.
> 
> The FileSystem API is a resource: we can now build a file from within 
> standard APIs. Until that point, we could only use the BlobBuilder 
> semantics.
> 
> The proposal DataTransferItem.add(fileData) pretty much takes care of 
> the request (when used with a working/complete FileSystem API).
> 
> We still need a promise-like feature, as you've pointed out.

This all seems reasonable at a high level, but it's probably too early to 
start adding this kind of feature today. I've noted things along the lines 
of what you describe in the spec as possible "v2" material.


> On a side note -- I've been having a lot of issue with building blobs:

For blob issues, public-webapps is probably more appropriate as that is 
where the File API specs are being discussed.


On Tue, 2 Nov 2010, Daniel Cheng wrote:
> > On Tue, 9 Mar 2010, Daniel Cheng wrote:
> > >
> > > I think files have always been a special case and should continue to 
> > > be handled that way. I don't think there's any platform pasteboard 
> > > that supports multiple items of one non-file type, so it'd make the 
> > > most sense to make it a 1:1 mapping from types to data.
> >
> > Currently the new DataTransferItems API doesn't enforce the limit of 
> > one "string" item per type. Should it?
> 
> What happens if a page were to add multiple string items of "text/plain"?
> How would that translate if dragging to a native app? There's also some
> implementation concerns here--it'd be harder/require more memory to preserve
> multiple strings of the same type when dragging things within a page.
> (If/when Blob support is added, the same comments generally apply)

Ok, I've limited the API to only one "string" item per type.


On Tue, 16 Nov 2010, Charles Pritchard wrote:
> 
> How close are we to adding promises?

I think it's probably a little early given that no implementation has yet 
implemented the DataTransforItems object (as far as I know).


> > > * I am worried about the effectAllowed attribute. Needless to say 
> > > that the number of value is exponencially proportional to the number 
> > > 

Re: [whatwg] Consecutive hyphen-minus characters in comments/in ACE-strings of IDNs

[Ian Hickson]

On Thu, 6 Jan 2011, Glenn Maynard wrote:
> On Thu, Jan 6, 2011 at 8:10 PM, Ian Hickson  wrote:
> >  * Helping authors not write HTML markup that might be hard to convert to
> >   XML, and helping authors avoid nesting comments accidentally, by
> >   flagging "--" sequences in comments
> >
> >  * Getting out of the way of authors who want to put "--" sequences in
> >   comments, e.g. because they use "--" as a long dash (as I do all the
> >   time!), or because they want to comment out punycoded URLs.
> >
> > Currently the spec assumes the former is more important. Personally, I
> > think the latter is rather more useful, but then I use "--" as long
> > dashes all the time! When this was last studied, the weight of argument
> > was on the stricter "disallow --" side of things, presumably.
> 
> I do this, too, and disallowing this in comments would be very annoying.
> 
> This is probably a novice question since it seems too obvious, but 
> rather than disallowing "--", why not disallow the entire comment 
> opening token, "

Re: [whatwg] Consecutive hyphen-minus characters in comments/in ACE-strings of IDNs

[Glenn Maynard]

On Thu, Jan 6, 2011 at 8:10 PM, Ian Hickson  wrote:
>  * Helping authors not write HTML markup that might be hard to convert to
>   XML, and helping authors avoid nesting comments accidentally, by
>   flagging "--" sequences in comments
>
>  * Getting out of the way of authors who want to put "--" sequences in
>   comments, e.g. because they use "--" as a long dash (as I do all the
>   time!), or because they want to comment out punycoded URLs.
>
> Currently the spec assumes the former is more important. Personally, I
> think the latter is rather more useful, but then I use "--" as long
> dashes all the time! When this was last studied, the weight of argument
> was on the stricter "disallow --" side of things, presumably.

I do this, too, and disallowing this in comments would be very annoying.

This is probably a novice question since it seems too obvious, but
rather than disallowing "--", why not disallow the entire comment
opening token, "

Re: [whatwg] Consecutive hyphen-minus characters in comments/in ACE-strings of IDNs

[Ian Hickson]

On Tue, 2 Nov 2010, Martin Janecke wrote:
>
> In 10.1.6 Comments the current HTML spec 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#comments
>  
> says:
> 
> > Following this sequence, the comment may have text, with the additional
> > restriction that the text must not [...] contain two consecutive U+002D
> > HYPHEN-MINUS characters (--) [...]
> 
> Section 5 of RFC 3490 http://tools.ietf.org/html/rfc3490#section-5 
> defines the ACE-prefix in Internationalized Domain Names to be "xn--", 
> i.e. always containing two consecutive hyphen-minus characters.
> 
> This leads to the odd situation that correctly ASCII-compatible encoded 
> IDNs cannot be used in HTML comments. For example, the wide-spread habit 
> of commenting out parts of HTML code in web pages fails when the code 
> contains those otherwise valid URLs. This really happens in practice 
> when working with IDNs (my personal experience) and I assume this 
> incompatibility will cause a growing number of pages to be invalid in 
> future, as the number of used IDNs grows, which will happen for sure, as 
> ICANN has approved internationalized top level domain names this year.
> 
> Can the problems be prevented? E.g. by making "xn--" and "XN--" valid in 
> comments?
> 
> May it even be justified to make "--" valid in comments again? As I 
> understand 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-May/006337.html 
> and following replies, "--" used to be valid earlier in the spec and was 
> then changed to make HTML more compatible with SGML, although HTML(5) is 
> explicitly not SGML anymore. Making "--" valid won't affect any 
> previously valid or invalid HTML page in any negative way, will it?

The main reason, IIRC, that we have disallowed "--" in comments in 
text/html is that they are disallowed in XML, and to help authors catch 
cases where they are commenting out comments.

The question, I guess, is which of the following do we think is more 
important:

 * Helping authors not write HTML markup that might be hard to convert to 
   XML, and helping authors avoid nesting comments accidentally, by 
   flagging "--" sequences in comments

 * Getting out of the way of authors who want to put "--" sequences in 
   comments, e.g. because they use "--" as a long dash (as I do all the 
   time!), or because they want to comment out punycoded URLs.

Currently the spec assumes the former is more important. Personally, I 
think the latter is rather more useful, but then I use "--" as long 
dashes all the time! When this was last studied, the weight of argument 
was on the stricter "disallow --" side of things, presumably.

I'm open to changing this back; does anyone else have an opinion on this?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] without keyboard editing

[Ian Hickson]

On Mon, 1 Nov 2010, TAMURA, Kent wrote:
>
> A team in Google tried to use  for a product, and 
> they decided not to use it. What they needed was a control to select an 
> integer from a specific integer range such as 1 - 16. The number type 
> control in Opera and WebKit allow a user to input out-of-range value 
> even if the control has min=1 and max=16 attributes. It's not a good UI 
> and the reason why they doesn't use type=number.
> 
> They need a number control which
>  - doesn't allow any keyboard / cut&paste operations and
>   So, a text field part is read-only, but the spin-buttons work.
>  - always has a valid value.
>   "required" by default, and sanitization algorithm may be different.
> 
> I'm not sure how to solve this issue.  Introducing new content attribute 
> or another number type?

That's a very odd set of requirements. Can you tell us more about the use 
case? (Are there any controls in native OSes that operate that way?)


On Mon, 1 Nov 2010, Jonas Sicking wrote:
> 
> Do you really want to disallow keyboard editing, or do you just want to 
> disallow entering an out-of-range number? The latter should be prevented 
> by a proper implementation of . If that is not the 
> case in webkit or opera then I suggest you file bugs on those 
> implementations.

Browsers are allowed to let authors enter out-of-range numbers; indeed one 
can imagine situations where the default value might be out of range (e.g. 
a form saying "your previous choice is no longer valid, select a new 
value" when some business logic constraints change). However, the UA is 
indeed required to make sure the value is always numeric (or the empty 
string).


> If you really want to disallow editing then maybe what you want is 
> . If not then I'm wondering how common that type of 
> input widget you are requesting is. It might not be common enough that 
> it really warrants direct support in HTML. You can always use javascript 
> to build such a widget, ideally in combination with .

Indeed, without knowing more of the use case it's hard to say one way or 
the other.



On Tue, 2 Nov 2010, Aryeh Gregor wrote:
> 
> If the user enters a value of 100 in , then
> it seems perverse to tell them "The maximum allowed value is 50" so
> they have to go back and fix it.  It makes more sense to just
> automatically clamp it to 50.

Either behaviour is allowed. That's mostly a quality-of-implementation 
issue.


> The spec is trying to say as little as possible about UI here, so that 
> browsers can experiment.  A browser where "Suffering from an 
> underflow"/"overflow"/"step mismatch" never occurred would be 
> conforming.  So I don't think we need implementations to concur at this 
> point -- they should be trying stuff out and seeing what works in 
> practice.  If they converge on particular conventions like this, then 
> the conventions can be added to the spec at that point.

Indeed.


On Sun, 7 Nov 2010, Aryeh Gregor wrote:
> On Thu, Nov 4, 2010 at 8:55 PM, Boris Zbarsky  wrote:
> > 
> > Not firing the input event would likely break scripts too...

I don't see how it could break scripts at this stage, since it's still 
very early days.


> The input event is not guaranteed to be fired on every keystroke anyway 
> [...]

The 'input' event only fires when the underlying /value/ changes, per 
spec, so if the UA isn't updating the underlying /value/ for out-of-range 
inputs, then the event doesn't fire.


On Sun, 7 Nov 2010, ddailey wrote:
> 
> [...] The problem is vaguely related to a question of mathematics: while 
> an ordinary base n writing system allows the expression of any number, 
> n, using log (n) digits, some systems that are equally efficient have 
> the added benefit (?) that individual numbers may be expressed in more 
> than one way. Ordinary bases have exactly one expression per number and 
> all numbers are expressible. Some systems might easily express certain 
> numbers using log (log (n)) digits, but might not be able to express all 
> numbers. (for example, the expression "2^(2^n)" expresses the n digit 
> number (base 2) that it represents , using only log (log (n)) digits ). 
> Is there a system of expression more efficient that ordinary base n for 
> writing all numbers? Suppose there is a writing system S that encodes 
> all numbers, n, expressible in S, using at most log(log(n)) digits. If 
> such a system is not possible then there must be a smallest number Q 
> that is not expressible within that system. Let us express that number 
> using the symbol "Q" which takes one digit.
> 
> If we had a control which allowed the entry of any large integer more 
> quickly than through a numeric keypad, then would this not be a good 
> widget? Likewise, the question of optimizing the "color picker" 
> interface so that a human can choose "precisely" (modulo psy) a 
> predetermined color (in RGB, HSV, or CIELAB space) in the least amount 
> of time, has not, I would claim, yet been optimized. I think the optimal 

Re: [whatwg] PageTransitionEvent persisted data type

[Ian Hickson]

On Thu, 28 Oct 2010, Andrew Oakley wrote:
>
> Is there any reason that the PageTransitionEvent persisted attribute 
> (and corresponding argument to initPageTransitionEvent) is of type any 
> rather than boolean?

Copypasta. Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] whatwg Digest, Vol 82, Issue 10

[Aryeh Gregor]

On Wed, Jan 5, 2011 at 7:47 PM, Glenn Maynard  wrote:
> Javascript injection is a harder problem, for example: it isn't
> prevented by SSL, can persist without maintenance (unlike an MITM
> attack), can be introduced untracably and without any special network
> access (you don't need to "get in the middle"), and so in practice are
> much more common than MITM attacks.

An XSS attack can still get IP address, and thus usually rough
location, so most of what I said still holds.

> It's bothered me for a long time that browsers treat self-signed
> certificates as *less* secure than plaintext, which is nonsense.

Lots of people have written extensive explanations of why browsers do
this.  Here's one I submitted as a comment to lwn.net a while back,
maybe it will clear things up: http://lwn.net/Articles/413600/

> By the way, another real-world issue with SSL is that it's
> considerably more computationally expensive: handling encrypted
> requests takes much more CPU, especially for high-bandwidth servers.
> Not every service can afford to buy extra or more powerful servers to
> handle this.

Apparently this isn't a real issue anymore in practice.  CPUs are fast
enough that SSL is no big deal.  Google saw only a small load increase
when it turned on HTTPS by default for all Gmail users:
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

On Thu, Jan 6, 2011 at 12:21 AM, Boris Zbarsky  wrote:
> How do you revoke it?  Once someone knows where you are, they know it. You
> can't make them stop knowing it.

In the context of an attacker who has some particular notion of who
you are and wants to connect that to your location, yes.  But is this
likely to be a common threat?  It's all very well to consider worst
cases, but the default convenience/security tradeoff has to be
calculated according to the typical case, not the worst case.  Typical
users are the ones who determine market share, and if the web platform
refuses to add features that would benefit the typical user because
they would hurt atypical users, typical users will choose other
platforms.

The web platform is so intrinsically convenient that it can remain
competitive with conventional applications while erring far on the
side of security in convenience/security tradeoffs.  But comparably
convenient platforms like Flash or mobile app stores will gain more
users if the web trades away too much convenience by comparison.
Ideally we should try to accommodate all users' security needs without
sacrificing convenience, but in cases where that's not possible,
atypical users will inevitably have to reconfigure their browsers.

Of course, maybe I'm just missing the cases where a reasonably typical
user (not, e.g., the target of malicious governments, or stalkers who
happen to be hackers) would be attacked in a fashion where anyone
would be interested in learning their location once and remembering
it.

> http://www.technologyreview.com/web/26981/page1/ might be worth reading.

Users who use Tor for their web browsing are decidedly atypical, and
can be expected to remain so given the inherent performance penalty it
imposes.

Re: [whatwg] Allow Headings As Children of

[Ian Hickson]

On Wed, 27 Oct 2010, Hugh Guiney wrote:
>
> I am authoring a video portfolio page using Kroc Camen's Video For 
> Everybody code  for 
> each piece. In this code he includes a download section for users who 
> may be unable to play the video live on the site, e.g. because they lack 
> both HTML5 (or the proper browser codecs) and Flash support. As this 
> hopefully won't be a problem for most users, I would prefer not to 
> distract them with this information unless they decide they need it, and 
> therefore have chosen to mark it up with .
> 
> However, I feel this "Download" portion is also important enough to be 
> its own subsection, as it is distinct from the surrounding content and 
> may be useful to navigate to as part of the document outline. The 
> obvious way to accomplish this would be for instance:
> 
> 
> Download
> 
> MP4
> OGG
> ...
> 
> 
> 
> but this is invalid via the current spec which only allows  to 
> contain phrasing content. I could give it its own heading outside of 
> , but this would be redundant as I would have to do duplicate 
> the heading text in both  and , and it makes the expansion 
> action area ambiguous. A mouse user might encounter the collapsed menu 
> and not know whether to click on the heading or the summary to expand 
> it—or even just consider it the author's error, or a glitch.
> 
> Even if I were to use different text for each element, I find few things 
> to be appropriate in this context that are not similarly redundant. 
> "Download" for the heading and "Video Format Options" for the summary? 
> The fact that the list is of format options would be reasonably apparent 
> by the link text for each item indicating "MP4", "OGG", etc.
> 
> My proposal to address this would be to allow heading content under 
> —or, conversely, to allow  to be used as a descendant 
> of  rather than just the first child, such that you could wrap 
> headings around it, as phrasing content is already allowed under 
> . But, the latter changes structure and therefore parsing 
> whereas the former is simply a validation change.

I would recommend just doing:

   
Download

 ...

   

...and not worrying about the Download bit ending up in the document 
outline. In practice, if the  in question is close to the  
element, it would be pretty straight forward for users to find the 
download links without having to look for a "downloads" section in the 
document outline.

Putting an  inside a  wouldn't acutally put the  
into the document's outline, because  elements are sectioning 
roots, which means they don't contribute to the document outline.

The reason we don't allow elements like  in the summary is that the 
summary is intended to be a single line in the rendering, and so allowing 
elements that are intentionally separate "blocks" sends the wrong message. 
It would also be rather weird to have what is intended to be a disclosure 
widget be its own "section" in the document outline.

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Specification of window.find()

[Ian Hickson]

On Wed, 27 Oct 2010, benjamin.poul...@nokia.com wrote:
> 
> I would like to suggest a change for the main HTML 5 specification: 
> http://www.whatwg.org/specs/web-apps/current-work/
> 
> The problem I have is with the Window object specification 
> (http://www.whatwg.org/specs/web-apps/current-work/#the-window-object ).
> It does not mention the method find() which can be found on most engines 
> (e.g.: https://developer.mozilla.org/en/DOM/window.find ).

It looks like IE doesn't implement this, so it's probably not strictly 
required for compat with the Web.

What are the use cases for this feature?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] onLoad event

[Ian Hickson]

On Wed, 27 Oct 2010, Diogo Resende wrote:
> 
> Is there a way to know that a  has been loaded (and processed)? 
> I'm more interested in CSS links than others but the process should be 
> the same. In my opinion it's a better way of loading stylesheets than 
> downloading using XmlHttpRequest and then creating the 

[whatwg] Specs for window.atob() and window.btoa()

[Aryeh Gregor]

I've written a provisional spec for window.atob() and window.btoa():

http://aryeh.name/spec/base64.html

These are functions supported by all browsers except IE, which do
base64 encoding and decoding.  I also wrote a fairly complete test
suite, at:

http://dvcs.w3.org/hg/html/raw-file/tip/tests/submission/AryehGregor/base64.html

Suggestions for improvements to either the spec or tests are
appreciated.  Some notes:

Browsers disagreed about how to handle input to atob() that can't be
produced by btoa().  Firefox mostly throws exceptions, WebKit is
slightly more lenient, and Opera doesn't throw exceptions at all.
gsnedders told me Opera's behavior caused site compat problems, so I
went with Firefox's behavior, or about as close to Firefox's behavior
as I could determine without reading the source code.  I recorded this
line of reasoning in a source code comment for posterity.

As far as I can tell by writing tests, there are only two cases where
Firefox's atob() doesn't throw an exception on input that can't have
come from btoa().  First, if there are trailing bits after decoding
that aren't all 0, Firefox discards them.  So for instance, atob("YQ")
and atob("YR") both return "a".  Second, it doesn't require trailing =
signs, so atob("YQ") works although btoa("a") is actually "YQ==".  The
latter seems reasonable to keep, but if we dropped the former, I could
get rid of the explicit algorithm and defer to the RFC for decoding
too, making the whole spec much simpler.  In that case, the invariant
btoa(atob(s)) == s would always hold after padding s with an = or two
if necessary, so determining whether a particular case should throw an
exception would be easy, but checking correctness by source-code
inspection would be harder.  What do implementers feel about this?

I used a regex to decide whether browsers should throw an exception
for atob() because it's simpler to spec and test, but it's probably
more annoying to implement.  If implementers would prefer I instead
say at which points in the algorithm to throw an exception, let me
know.  (This is moot if the algorithm can be thrown out entirely.)

[whatwg] Please rename this thread (Was: Re: whatwg Digest, Vol 82, Issue 10)

[Simon Fraser]

Please don't start or continue threads without a useful subject line.

Simon

Re: [whatwg] Make "f...@bar.com, " a valid email address list

[Ian Hickson]

On Thu, 6 Jan 2011, Mounir Lamouri wrote:
> > On Fri, 22 Oct 2010, Anne van Kesteren wrote:
> >> I think it would be better to simply omit that trailing comma. Which 
> >> should be allowed. If the specification currently does not allow that 
> >> (somehow) it would be a bug and is just something that needs 
> >> clarification.
> > 
> > Indeed. Also fixed.
> 
> I don't see where/how this has been fixed. To me, it's clear that 
> "f...@bar.com, b...@bar.com" will now be represented as 
> "f...@bar.com,b...@bar.com" in the DOM but not "f...@bar.com, b...@bar.com," 
> (which will be "f...@bar.com,b...@bar.com,"). In addition, this value 
> seems to still be invalid.
> 
> Can you point out the section/line that handle this case?

It was fixed by completely decoupling the /value/ from what the user 
edits. The user now edits /values/ (plural), and the user agent then 
"exports" the user's edits to the /value/. (Apologies for the similarity 
in the names of these concepts; it's difficult to come up with unique yet 
still understandable names that aren't too verbose.)

This is defined in the part of the spec starting with "When the multiple 
attribute is specified on the element".

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Make "f...@bar.com, " a valid email address list

[Mounir Lamouri]

On 01/06/2011 12:40 AM, Ian Hickson wrote:
> 
> This thread led me to realise there were a number of problems in the spec 
> with the multiple="" attribute as applied to type=email, including a poor 
> definition of how list="" applies, a poor definition of how selectedOption 
> applies, an incoherent expectation that the selection API should apply to 
> type=email at all (which doesn't work since the UI is supposed to be 
> IDN-based but the output and the API isn't), and various complication 
> regarding how values are to be checked, depite the recent fixes in that 
> area. I revamped how it was specced and hopefully it makes more sense now.
> 
> On Thu, 21 Oct 2010, Mounir Lamouri wrote:
>>
>> For the moment, a valid email address list is a set of comma-separated 
>> tokens where each tokens are a valid email address so in the case of 
>> "f...@bar.com, ", "f...@bar.com" is a valid email address but not "".
>>
>> Unfortunately, as soon as you want to put a UI on top of that, values 
>> will always be appended by ", ".
> 
> I've changed the spec so that it decouples the underlying DOM and 
> submission value from the UI, so that's no longer an issue.

> On Fri, 22 Oct 2010, Anne van Kesteren wrote:
>> I think it would be better to simply omit that trailing comma. Which 
>> should be allowed. If the specification currently does not allow that 
>> (somehow) it would be a bug and is just something that needs 
>> clarification.
> 
> Indeed. Also fixed.

I don't see where/how this has been fixed. To me, it's clear that
"f...@bar.com,   b...@bar.com" will now be represented as
"f...@bar.com,b...@bar.com" in the DOM but not "f...@bar.com,
b...@bar.com," (which will be "f...@bar.com,b...@bar.com,"). In addition,
this value seems to still be invalid.

Can you point out the section/line that handle this case?

Thanks,
--
Mounir

Re: [whatwg] whatwg Digest, Vol 82, Issue 10

[timeless]

On Thu, Jan 6, 2011 at 1:54 AM, Aryeh Gregor  wrote:
> * If your cert expires or you misconfigure the site something else
> goes wrong, all your users get scary error messages.

This isn't limited to SNI. I saw one server which had its certificate
expire at the end of Dec 30, 2010 (i.e. it was expired the morning of
the last day of last year). Renewing certificates is scheduled
maintenance which needs to be done and *planned for* anyway.

I'm kinda surprised that servers and CAs don't have better support for
reminding admins of this stuff.

I know for mozilla.org, nagios is responsible for warning admins.

The odd thing (to me) is that CAs make money selling certs, so one
would expect them to want to sell the renewed cert and get that new
booking by selling the new cert say 3-6 months before the old one
expires. And thus they're actually being customer oriented, providing
a useful service (possibly telling the customer about expired certs
they issued which are still running...).

Re: [whatwg] whatwg Digest, Vol 82, Issue 10

[timeless]

On Thu, Jan 6, 2011 at 1:54 AM, Aryeh Gregor  wrote:
> * You can typically only serve one domain per IP address, unless you
> can set up SNI (do all browsers support that yet?).

[1] Browsers with support for TLS server name indication:
* Internet Explorer 7 (Vista or higher, not XP) or later
* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
* Opera Mobile at least version 10.1 beta on Android
* Google Chrome (Vista or higher. XP on Chrome 6 or newer. OS X 10.5.7
or higher on Chrome 5.0.342.1 or newer)
* Safari 2.1 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)
* MobileSafari in Apple iOS 4.0 or later
* Windows Phone 7
* Maemo

So, basically the unsupported bits for SNI are:
iOS3 and below running Safari
 -- iiuc [2], iPod Touch [3] first generation (purchased roughly
before September 9, 2008) + original iPhone [4] are the only two which
can't run iOS4 (purchased roughly before July 11, 2008)
OS X 10.5.5 [5] and below running Safari
 -- iiuc [6][7], PowerPC G4 computers with CPU speed < 867 MHz can't
run 10.5 ootb, these were obsoleted around August 13, 2002
XP [8] running IE 7-
 -- Users should upgrade to IE8 which is supported [9] (or any other browser)

For other "desktop" configurations (including the unsupported ones
listed above), users can use Firefox/Opera. For mobile configurations,
users can use SkyFire/Opera Mobile.

The coverage for SNI is thus, in fact, quite good.

I can't speak for Symbian, but assuming I'm reading [10] correctly,
Symbian 1 would not have SNI as there's a request against 417 [11] to
add it. Sybmian 2 [12] offers WebKit 525 [10] which should be new
enough to include SNI (as that's roughly what's in Safari 3 which
includes it). This doesn't cover many older models but Opera/SkyFire
should be available for most.

Similarly per [10], BlackBerry 6 [13] which is WebKit 534 should have
SNI. This of course doesn't cover many models, but Opera should be
available for most.

Probably worth doing is a study of SNI failure behavior. My experience
w/ mobile browsers and mobile users is that the warnings are ignored
anyway (especially on Symbian where you're constantly bombarded with
stupid dialogs and quickly learn to  through them),
which means that your users are probably used to the problem. But once
they get to your SNI page, you can include a note to mobile users of
browsers which don't have SNI explaining that if they want a more
secure experience they should switch to 
(the browsers are free, so the only cost to you is a quick test and
the only cost to the user is the download cost for a better browser).

[1] http://en.wikipedia.org/wiki/Server_Name_Indication
[2] 
http://en.wikipedia.org/wiki/IOS_version_history#4.x:_Fourth_major_release_of_the_OS
[3] http://en.wikipedia.org/wiki/IPod_Touch#Models
[4] http://en.wikipedia.org/wiki/IPhone#Models
[5] http://en.wikipedia.org/wiki/Mac_OS_X_v10.5#Release_history
[6] http://en.wikipedia.org/wiki/Mac_OS_X_v10.5#Usage_on_unsupported_hardware
[7] http://en.wikipedia.org/wiki/Power_Mac_G4#Four-slot_models
[8] http://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle
[9] http://en.wikipedia.org/wiki/Internet_Explorer_8#OS_requirement
[10] http://www.quirksmode.org/webkit.html
[11] https://lists.webkit.org/pipermail/webkit-unassigned/2006-June/011657.html
[12] http://en.wikipedia.org/wiki/Symbian#Version_history
[13] http://en.wikipedia.org/wiki/BlackBerry_OS#Current_versions