from:"Mike"

On Mon, May 11, 2015 at 9:19 AM, Jim Manico jim.man...@owasp.org wrote:

 The whole purpose of a sandbox is to limit what content inside of it can
 do. I want to limit where that sandbox can open windows with full
 cookie/script/etc access.


And you can do so by _not_ specifying the new flag I'm proposing. :)

Again `iframe sandbox`'s behavior would not change. The proposal would
add new behavior only for something like `iframe
sandbox=allow-unsandboxed-auxiliary allow-popup`.


 So essentially I want to say, You can show your ad, you cant run a script
 or access my main window.  Also, you can only open full-access windows back
 to the same domain that your ad came from.


If the ad comes from `advertising-is-awesome.net`, but is pointing users to
the excellent products at `products-are-nice.com`, how would your proposal
allow a click on the ad to navigate a user to the excellent products in an
unsandboxed window (e.g. one that has an origin)? I'd suggest that that's
an essential component. It's certainly essential to advertisers.


 Is that to extreme of an ask? I just dont like the idea that a sandboxed
 resource has full access to open any new window. It seems excessive and can
 exploit CSRF vulns in a way a full sandboxed iFrame as I'm describing could
 not.


I still don't understand the threat model you're proposing. That is, I
don't see sandboxing as a CSRF defense at all. Sandboxed frames can
navigate themselves to any origin right now, and load any origin in a
frame. If the `allow-popups` flag is set, it can open auxiliary windows. If
the `allow-forms` flag is set, it can POST to arbitrary origins.

-mike

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Mon, May 11, 2015 at 4:02 PM, Chris Coyier chriscoy...@gmail.com wrote:

 I'd think popups would be killed by default and allow-popups would allow
 them. Or if you need a new value, allow-obnoxious-things could work ;)


I would prefer to simply remove the functionality. :)

If we do decide that we need `alert()` and friends, I would suggest that
`allow-popups` is the wrong flag to use. The advertising use case I noted
at the top pretty much requires `window.open`/`target=_blank` to work
correctly. If those only work when `alert()` is enabled, then we wouldn't
solve the issue.


 Like navigator.geolocation (so we regex and strip it).


I think permissions for iframes in general are a separate question, but an
important one to deal with.


 The worst offender: linking to things that are .htpasswd protected and it
 pops up that authentication modal.


I wouldn't be terribly averse to dropping support for that inside a
sandbox. Especially a sandbox without `allow-same-origin`.

-mike

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Mon, May 11, 2015 at 4:12 PM, James M. Greene james.m.gre...@gmail.com
wrote:

 1. Block modal dialogs from inside sandboxed frames. That is:
 * `alert(...)` would return without popping up a dialog.
 * `confirm(...)` would return `false` without popping up a dialog.
 * `prompt(...)` would return `null` without popping up a dialog.
 * `print(...)` would return without popping up a dialog.


 I'm OK with that.  As a general rule, though, I would prefer that pretty
 much whatever gets blocked by default can be reenabled via additional new
 keywords (e.g. allow-modals).


Sure. It's not clear to me that there's a _good_ use of any of these
methods in an iframe, so I'd prefer to just remove the capability entirely,
but if there's a desire to retain the functionality, I'd certainly
implement something like `allow-modals` in Chrome.


 Although I understand the rational for blocking native plugins by default
 due to their inherent unmanaged nature, I still wish that they could be
 reenabled via a keyword as there are still realistic scenarios where you
 may want (e.g.) Flash enabled but still disallow/disable other features
 like popups, navigation, etc.


An issue with Flash (and other plugins) is that they generally bypass the
rest of the sandboxing flags. That is, enabling flash while disabling
`window.open` is somewhat ineffectual, as Flash can just pop a new window
with it's native code.

This is somewhat improved in Chrome, as PPAPI allows us a bit more access
to the ways in which Flash can poke at the system, but it doesn't improve
the (terrible) process model, etc. I think it would still be a bit too
dangerous to introduce an `allow-plugins` flag given the sandboxing state
in other browsers, but it's probably a conversation worth having.


 2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
 `sandbox` attribute, which, when present, would allow auxiliary browsing
 contexts created by `window.open` and `target=_blank` links to create
 clean browsing contexts, unaffected by the sandbox which spawned them.


 I'm OK with that, too.  I'm assuming that cascades, though, right?  In
 other words, if the top window does NOT use the
 allow-unsandboxed-auxiliary keyword on its child iframe, I'm assuming the
 child iframe cannot successfully use allow-unsandboxed-auxiliary on a
 child iframe of its own.


Yes, this is also how I imagined it working. I should have made that clear
in the proposal, but I think (hope!) this naturally falls out of the way
sandbox flags are propagated from frame to frame/window to window.

-mike

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Mon, May 11, 2015 at 7:24 PM, Ian Melven ian.mel...@gmail.com wrote:

 1) At one point i think showModalDialog was specified to be blocked unless
 allow-popups was set. (I can't find this in the current editor's draft of
 the spec).
 It seems to me that it would make sense to follow #1 in your proposal
 (blocking alert and friends) UNLESS allow-popups is specified perhaps ?
 Unless the advertising use case is such that they would want to specify
 allow-popups in most common cases, which negates any benefit of this
 restriction in practice


My understanding of the use case is that they want `allow-popups` in order
to allow navigation to a landing page via `target=_blank`, et al. They
don't want modal dialogs from that same window. Tying both behaviors to
`allow-popups` wouldn't solve their problem.


 2) this also sounds like allow-popups would be needed (since you shouldn't
 be allowed to open new auxiliary browsing context without it)


Correct. Both `allow-popups` and the new flag would need to be specified.


 and maybe is more consistent using 'allow-popups-unsandboxed' ?


Or `allow-unsandboxed-popups`. I don't really care how we spell it. :)

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

On Mon, May 11, 2015 at 11:59 PM, Justin Dolske dol...@mozilla.com wrote:

 On Mon, May 11, 2015 at 7:13 AM, Mike West mk...@google.com wrote:

  The worst offender: linking to things that are .htpasswd protected and
 it
  pops up that authentication modal.
 

 I wouldn't be terribly averse to dropping support for that inside a
 sandbox. Especially a sandbox without `allow-same-origin`.


 Firefox sorta does this by default, as of
 https://bugzilla.mozilla.org/show_bug.cgi?id=647010. At least it appears
 to for cross-origin iframes, which I would expect to be the normal case for
 ads?


Interesting! Thanks for the pointer to the bug. If Firefox is already going
this route, I don't see any reason Chrome shouldn't follow. It makes sense
to me, in any event.


 Also, along with blocking alert() et al from sandboxed iframes, it would
 be good to include the onbeforeunload dialog. It's a pretty common target
 for abuse. We've got a bug to disable it entirely in iframes (1131187), but
 no one is actively working on it.


Ah, yes. I forgot about `onbeforeunload`. I'd happily kill that inside a
sandbox as well. :)

-mike

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Two changes to iframe@sandbox

2015-05-10 Thread Mike West

On Mon, May 11, 2015 at 7:27 AM, Jim Manico jim.man...@owasp.org wrote:

  2. Allow sandboxed frames to spawn new windows without forcing the
 sandbox upon them.

 I think this needs to be restricted so sandboxed iFrames cannot spawn new
 windows back to the same domain - or better yet may only spawn windows to
 limited domain/domains driven by the initial ad request.


What risk do you see that mitigating? How would you expect it to behave
with regard to redirects or navigations? I guess I don't see the value in
adding these kinds of restrictions, and (especially given the target
audience, and their predilection for tons and tons of cross-origin
redirects) it seems like making it easier to sandbox the inlined frame
outweighs the desire to lock down the out-of-line auxiliary browsing
context.

Also, note that the proposal already makes the behavior opt-in via the
`allow-unsandboxed-auxiliary` keyword (it wouldn't change the behavior of
any existing sandboxed frame), and browsers generally throttle the creation
of popups in various ways (Chrome allows only one popup per user gesture,
for instance).

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[whatwg] Proposal: Two changes to iframe@sandbox

2015-05-10 Thread Mike West

(BCC: public-webapp...@w3.org)

Hello, wonderful whatwg@ folks!

I've talked with a few folks from Google's advertising teams who are
interested in using sandboxed iframes to mitigate the risks associated with
ads. They've flagged two things that they'd like to see happen in the
future:

1. Block usage of `alert()` (and its friends `confirm()`, `prompt()`, and
`print()` (and `showModalDialog()` for browsers that support it)).

2. Allow sandboxed frames to spawn new windows without forcing the sandbox
upon them. This would allow the advertisement itself to be sandboxed,
without forcing the same restrictive flags upon a landing page.

# Proposal

1. Block modal dialogs from inside sandboxed frames. That is:

* `alert(...)` would return without popping up a dialog.
* `confirm(...)` would return `false` without popping up a dialog.
* `prompt(...)` would return `null` without popping up a dialog.
* `print(...)` would return without popping up a dialog.

This was discussed briefly at
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014May/0002.html,
but I didn't find any follow-up (CCing folks from that thread). I've added
metrics to Chrome in https://codereview.chromium.org/1121053002, but it
will take a few weeks to get good data. Given the low usage of sandboxes in
general (~0.5% of page views, according to
https://www.chromestatus.com/metrics/feature/timeline/popularity/672), I
suspect we could fairly easily make this change.

2. Add a `allow-unsandboxed-auxiliary` keyword to those supported by the
`sandbox` attribute, which, when present, would allow auxiliary browsing
contexts created by `window.open` and `target=_blank` links to create
clean browsing contexts, unaffected by the sandbox which spawned them.

WDYT?

--
Mike West mk...@google.com, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

2014-10-17 Thread Mike West

On Thu, Oct 16, 2014 at 4:28 PM, Eduardo' Vela Nava e...@google.com
wrote:

 Well, it doesn't today. But maybe you mean in the future.


You're right, sorry. I was thinking of blob-based workers. Maybe we should
do the same for frames?


 But the point is that there are many ways to exfiltrate, these are just
 the first thing that comes to mind but others like input pattern also are
 an info leak, and I mean, these are just ideas coming up the top of my
 mind, the browser wasn't designed to solve this problem and it's dubious if
 it's really feasible to do so without reinventing a lot of things.


http://mikewest.github.io/credentialmanagement/writeonly/#input-behavior
outlines a few mechanisms, and potential resolutions. `pattern`, for
instance, is addressed by blocking input validation on the form field.

As you suggest, I'm sure there are more mechanisms. I don't think there are
infinite mechanisms, however, and I'm fairly certain that we could address
those that exist.




 I wasn't clear: the server still needs to accept a bare username/password
 pair, as it's not the case that users only log in a) using a password
 manager, b) on a machine that's syncing. As long as that's the case, I
 don't see how tying passwords to a cookie makes password theft less
 problematic.


 The user would just have to type the full password (including the extra
 cookie-random value that the password manager backed up). The caveat of
 course is that the user has to write this suffix somewhere, but that is
 what makes the password strong anyway.


I don't think asking users to remember a password and a random value is
tenable.


 And anyway, to be clear, this is just a discussion on an alternate design
 that has the same properties and is significantly easier to implement for
 both, authors and UAs, but it's by no means the only solution. My point is
 that there are probably simpler solutions that have similar security
 guarantees.


I'll reassert that this proposal is simpler for authors (11 character
opt-in) and users (no change) than the scheme you just outlined. It's more
complex for browser vendors, but that's fine and expected, as we're way
down at the bottom of the priority heap.

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

 a token that is converted
 to a password on an ongoing request by the network stack, but there is
 no way to confirm that the request is being made to the right
 destination and in good faith.


This is more of a problem for things like credit cards which are reused
everywhere than for credentials, which are not.

Like most other things in security, this proposal would make an attacker's
job harder, but certainly not impossible. It is not revolutionary in any
sense, but throws up some new roadblocks, and is _trivial_ for a website
author to implement. That last bit is important.


 The reason why I was previously skeptical of proposals of write-only
 fields is pretty much because the threat model is so complicated and
 the solutions are so fragile - but maybe I'm in the wrong on this.


I hope you are, as this is a problem I'd like to address.

-mike

[whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

Forking this out into a separate thread, as I think it deserves some
additional consideration.

On Thu, Oct 16, 2014 at 5:05 AM, Roger Hågensen resca...@emsai.net wrote:

 There is also legitimate needs for being able to edit the password field
 from a script.
 I have a custom login system (that is currently in public use) that takes
 the password, does a HMAC on it (plus a salt and some time limited
 info). This allows login in without having to send the password in the
 clear. It's not as secure as https but it's better than plaintext.


Sigbjørn Vik (CC'd) suggested something similar in a previous conversation.

I think it's probably reasonable for a password field to specify that some
sort of operation be done on its value before it's sent over the network.
It's not clear to me exactly what would be necessary in order to prevent
replay attacks, but it seems quite possible for the site to ask the browser
to salt and hash the value in some known way before passing it on:

If user agents offered some sort of well-understood set of operations that
could be performed on a password before sending it over the wire, they
could potentially avoid ever knowing the password, which might be nice
(though it would certainly require substantial rewrites on their backends).

As a hand-wavey strawman that I haven't thought too much about:

* Server stores credentials as `sha512(password + username)`.
* Server provides a nonce ('a') as part of a sign-in form, saves that nonce
for the given session, and points to the username field as a salt.
* The user agent injects a nonce ('b') into the sign-in form in some
well-known field, and fills the password field with `sha512(sha512(password
+ username) + a + b)`.

The server now has everything it needs to compute the same hash as the
client. If the hashes match, yay. Sign the user in.

There are certainly better ways to do this, perhaps even some that wouldn't
require really significant work on the server side to support.

Any limitations on form manipulations should be based on same origin
 limitations instead, such that only a javascript with the same origin as
 the html with the form can read/write/manipulate the form.


This is a very difficult problem, as evidenced by Chrome and Firefox's
struggles to allow extensions to bypass CSP. It's tough to keep track of
the origin of an action, especially when that action is the result of an
event handler or some other asynchronous action that no longer has a clear
call stack back to it's originator.

It's unlikely to be implemented. CSP locking down the sources of script is
the best we can offer, I think.

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Thu, Oct 16, 2014 at 1:31 AM, Eduardo' Vela Nava e...@google.com
wrote:

 Yea the keyup/down/press restrictions are definitely not useful, at least
 for password protection since the user has clearly no way to know if the
 field is safe or not.


I'd disagree that they're useless, but they're certainly not a robust
defense against an attacker reading information that you type into a form.


 The tainting is never gonna work reliably and consistently as Michal hinted
 (say, a blob: URL would run in the same origin but not be bound to CSP
 which could be used to exfiltrate the data).


The tainting problem is simplified by focusing on the part I care about:
autofill.


 The dependency on CSP also makes this a bit aspirational. I can agree that
 the login form could be CSP protected but the whole origin is not as
 likely. Specially for connect- and form-.


As noted in a previous response, I see these concerns as somewhat mitigated
by tagging the credential as writeonly in a way that would prevent autofill
into a read/write form.


 And even that might be insufficient (its a common practice to echo back
 typed passwords when the user doesn't answer a captcha or has it wrong, for
 example - a same-origin XHR will leak the password).


As I think you'd agree, those pages are already shooting themselves in the
foot. You're correct that this proposal doesn't solve their problems, but
that's not a unique disadvantage of the proposal. :)

There are other solutions that seem more likely to work to solve the
 problem of password managers (something like a synced channelId, for
 example, or even FIDO style solutions). This proposal seems to try to
 achieve a mixture of just replacing canary values at the network layer
 based on destination with an httpOnly-style model for user-supplied data.


1. Password managers aren't the problem. Especially when used to generate
even vaguely secure password, they make authentication on the web
significantly less insecure than it would otherwise be.

2. The various proposals on http://www.browserauth.net/ like channel-bound
cookies (which I think you're referring to above?) can solve cookie theft.
They don't solve password theft.


 If we have a password manager and are gonna ask authors to modify their
 site, we should just use it to transfer real credentials, not passwords..
 Passwords need to die anyway.


You ding CSP as a bit aspirational, and then propose killing passwords.
*cough* :)

As long as modify their site means type 11 characters into your site's
template and not rewrite your authentication stack from the ground up
using technologies you've never heard of, I think it's something we can
reasonably ask of authors. The central advantage of the writeonly proposal
is that it's a trivial drop-in change. It's certainly not the real
revolution in authentication that we desperately need on the web, but
that's a feature, not a bug. :)

-mike

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)

On Thu, Oct 16, 2014 at 11:43 AM, John Mellor joh...@google.com wrote:

 On 16 October 2014 08:52, Mike West mk...@google.com wrote:

 * Server stores credentials as `sha512(password + username)`.


 It might be better to require PBKDF2/bcrypt/scrypt.


Yeah, that certainly makes sense.

-mike

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela Nava e...@google.com
wrote:

 1. How are keyup/down/press restrictions useful for password protection?
 Actually they seem more useful for CSRF instead.

These events are some of the many ways in which the data being typed into a
particular field is exposed to script. If we're going to call the field
writeonly, we need to lock those down. That said, they only protect that
particular field: attackers can easily bypass this restriction by doing
more work (overlaying a new form, etc).

How are they useful for CSRF? I don't see the link.

 2. How is the tainting problem simplified by focusing on write only?

 Focusing on autofill means that we're moving the flag up to the
credential, so we can ensure that the browser only autofills into writeonly
form fields. To your specific example, it means we don't have to care about
blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in
iframes.

 3. How is tagging the credential as write-only help with the secure
 deployment of a site-wide CSP policy?

It doesn't. The two are completely unrelated.

My point was simply that if we tag a credential as writeonly, we wouldn't
fill it into a form that lacked the writeonly flag in a page that lacked
the writeonly CSP. Solving CSP deployment isn't a precondition of this
scheme.

 4. Why are sites that echo passwords in password fields shooting
 themselves in the foot?

 Echoing sensitive data in a place where an injected XHR can read it is a
general problem. This proposal doesn't make that worse.

 Imagine if the password manager, instead of just syncing passwords around
 also moved an httpOnly cookie. And whenever it detects the password going
 by it appends the httpOnly cookie.

 If the server detects such cookie in the request it concatenates it after
 the password and uses that as the auth credential.

 On the server, this only requires a one line change (adding he cookie at
 the end if present), on the client the APIs already exist.

 Same can be done with Channel ID with the further advantage that the OBC
 can't be copied. The advantage of the cookie approach is that it can be
 morphed and generated more easily.

Sounds like a great way of hardening sign-in. It's not clear to me how that
negates the problem of password theft, as I'd still need to be able to sign
in on my friend's computer when I accidentally spill coke on my laptop,
right?

 Also, as a point of reference we've redone authentication many more times
 in a lot less time with a lot less resources than deployed CSP across all
 of Google. So yes, it's easier.

That surprises me.

Still, I suspect both are significantly more work than adding an attribute
to a form field.

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Thu, Oct 16, 2014 at 12:16 PM, Eduardo' Vela Nava e...@google.com
wrote:

 On Thu, Oct 16, 2014 at 11:59 AM, Mike West mk...@google.com wrote:

 On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela Nava e...@google.com
 wrote:

 OK, so it's just being locked down out of a formality, but has no security
 purpose. Sure, so it's not useful for any security purposes.


Well, no. It doesn't solve the problem, but it introduces a hurdle. Making
an attacker do more work is good.

 2. How is the tainting problem simplified by focusing on write only?

  Focusing on autofill means that we're moving the flag up to the
 credential, so we can ensure that the browser only autofills into writeonly
 form fields. To your specific example, it means we don't have to care about
 blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in
 iframes.


 The blob: URL would simply steal the FormData from the other page (it's
 same origin), and submit it via XHR to another origin..


Ah, that's clever! However: blobs inherit the CSP of their parent frame, so
the same mitigations apply.

Moreover, if we're doing the network-stack replacement thing, and we know
details about the credential, then we can refuse to do the replacement in
the browser process if the destination doesn't match the details we have
stored for the credential, CSP or not.

 3. How is tagging the credential as write-only help with the secure
 deployment of a site-wide CSP policy?

 It doesn't. The two are completely unrelated.

 My point was simply that if we tag a credential as writeonly, we wouldn't
 fill it into a form that lacked the writeonly flag in a page that lacked
 the writeonly CSP. Solving CSP deployment isn't a precondition of this
 scheme.


 I see, so it wouldn't be sufficient to make a field writeonly, you would
 also need to declare that in the CSP.


Let me rephrase: if we tag a credential as writeonly, we wouldn't fill it
into a form field that wasn't writeonly. Form fields are tagged writeonly
either by virtue of an inlined attribute, or a CSP on the page.

Either individually signals to the browser that the site does not intend to
make programmatic use of the field's value. We wouldn't need both in order
to decide when to tag a credential as writeonly.


 The whole website would have to have connect-src policies stricly
 restricting the exfiltration of data from the domain. Is there any
 (relevant/important) website where locking down connect-src for the whole
 origin is possible or feasible? Or are we assuming every website has their
 login form in a unique origin? (Are you expecting to have per-page
 suborigins implemented before this is feasible?).

 4. Why are sites that echo passwords in password fields shooting
 themselves in the foot?

 Echoing sensitive data in a place where an injected XHR can read it is a
 general problem. This proposal doesn't make that worse.


 Sensitive data is echoed in places where XHRs can read all the time. Your
 email, your authentication credentials (OAuth, etc), your bank statements.
 This isn't a general problem.


It is a general problem, given the attack vector you're proposing: if I can
inject a same-origin XHR, I can read sensitive data. That includes
passwords, if the passwords are echo'd out in the page's contents. I'm
agreeing with you that writeonly doesn't solve this problem.

I'd suggest that sites themselves could solve it by echoing a nonce rather
than the original password, but that's obviously up to them and not
something we could spec.

 Sounds like a great way of hardening sign-in. It's not clear to me how
 that negates the problem of password theft, as I'd still need to be able to
 sign in on my friend's computer when I accidentally spill coke on my
 laptop, right?


 How is the password manager able to sync your password to your friend's
 computer?


I wasn't clear: the server still needs to accept a bare username/password
pair, as it's not the case that users only log in a) using a password
manager, b) on a machine that's syncing. As long as that's the case, I
don't see how tying passwords to a cookie makes password theft less
problematic.

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

Yes. Two things about service workers:

1. If you can spin up a service worker, the site is already very much in
trouble.

2. I have handwavey ideas about ensuring that the FormData object which
would be readable via the Request object in the service worker would retain
the opaque flag. The spec strawman hints at that, but I haven't done the
work to find all the places to monkey-patch.

-mike

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Oct 15, 2014 at 4:25 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 10/15/14, 10:15 AM, Mike West wrote:

 `FormData` objects created from forms including these writeonly elements
 would be opaque. You could use them to submit an XHR request, but you
 couldn't read the values directly from script.


 If you're at the point where you can run script on the page, can't you
 spin up a service worker that would capture the data in that XHR?

 -Boris

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

Good feedback, Michal. Thanks!

On Wed, Oct 15, 2014 at 4:41 PM, Michal Zalewski lcam...@coredump.cx
wrote:

  input writeonly type=password

 I think that one huge problem with this is that the attacker will have
 many other, indirect ways to get the value even if you protect direct
 access to the field. Two most obvious options include:


Note that there are two types of attacker I care about:

1. XSS. You've outlined some (of the probably many) ways to bypass the
kinds of protection I'd like to build here. Let's discuss below.

2. Renderer flaws. Currently, if someone can corrupt Chrome's renderer
process, she can request any and all passwords from the password store by
pretending to be various origins. If we can mark certain credentials as
writeonly, we know we never have to send them to the renderer, and that
any such requests could be ignored. This is similar to what (I hope) we're
doing with `httponly` cookies (though I haven't checked, it seems like an
obvious optimization).


 1) Change the action value for the form to point to evil.com, where
 evil.com is in attacker's control,


I hope that this is mitigated by the `form-action` CSP directive, which
allows the site to control the valid endpoints for form submission, and
`connect-src`, which allows the same for XHR, EventSource, WebSockets, etc.


 2) Change the action of the form to GET while keeping the same method,
 let it submit, and then examine location.search.


Good idea. One way of avoid this would be to lock all forms with writeonly
data and XHR with opaque FormData to the POST method. That's probably what
we'd like folks to be doing anyway in order to keep potentially interesting
information out of server logs and browser history.


 3) Change the action value of the form and the name of the password
 field so that the posted data is interpreted by the server as an
 attempt to, say, post a comment.


Again, mitigated (but by no means avoided) by path restrictions on the
`form-action` CSP directive.


 I worry that there's actually more, and that a lot of nasty taint
 tracking heuristics would be required to make it go away.


That's something I'd like to avoid, insofar as possible. I think it's
likely unavoidable to have some sort of opaque flag on request objects in
order to do the right thing with regard to ServiceWorkers, but since we
already track opaqueness for responses, I hope that's not an overly
burdensome taint to track.

-mike

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Wed, Oct 15, 2014 at 5:16 PM, Michal Zalewski lcam...@coredump.cx
wrote:

  Fair enough - although I worry that the likelihood of people using
  this in conjunction with tightly-scoped per-document CSP (versus the
  far more likely scenario of just having a minimal XSS-preventing
  site-wide or app-wide policy that will definitely not mitigate #3 and
  probably do nothing for #1) are pretty slim.

 In fact, the XSS-preventing part is probably a stretch. Facebook and
 Twitter are often mentioned as the two most significant customers for
 CSP, but both use unsafe-inline and unsafe-eval.


True. Because both have huge legacy systems built on inlining JavaScript.
That's an architectural change that is really truly difficult in aggregate.

The same is not the case for login forms. Or credit-card forms, for that
matter.

The only sites that wouldn't be able to implement something like this
without significant effort are those who do client-side encryption (well,
encryption) of the sensitive data before passing it on to the server.


 On top of that, note that #3 is not defeated by origin-scoped rules -
 you need to specify full paths.


You're correct. I mentioned that. :)

#3 also relies on the site having a comment form, or some other mechanism
of publicly reflecting POST data to the world without a CSRF. Lots of sites
have that sort of mechanism, sure, but I don't think that even a majority
of high-value sites do.

Honestly, if we're creating a mechanism that implies that a degree of
 protection is provided for password fields, we should either make it
 work on its own


Do you have suggestions for what on its own might look like?


 , *or* at the very minimum require a CSP with
 form-action specified, and otherwise warn or better yet, break fields
 flagged as writeonly.


Sure. Doing one or both is probably pretty reasonable. :)

-mike

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Wed, Oct 15, 2014 at 5:59 PM, Domenic Denicola 
dome...@domenicdenicola.com wrote:

 For the XSS attacker, couldn't they just use
 `theInput.removeAttribute(writeonly); alert(theInput.value);`?

 Or is this some kind of new un-removable attribute?


The strawman suggests setting a flag on the element, and doesn't suggest a
way of unsetting that flag. This is conceptually similar to iframe@sandbox's
effect on the document loaded into the frame.

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Wed, Oct 15, 2014 at 6:10 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:


 Nothing in-band will work, because the attacker can replace arbitrary
 amounts of the page if they're loaded as an in-page script.  It's
 gotta be *temporally* isolated - either something out-of-band like a
 response header, or something that has no effect by the time scripts
 run, like a meta that is only read during initial parsing.


Yes. Hence the CSP directive portion of the proposal.

The inline attribute is useful for the specific password manager case I'm
concentrating on, as it gives us a clear indication that the site doesn't
intend to do wacky manipulation of its credentials on the fly. We can use
this to determine how and when the password manager (or credit card
autofill, or whatever) ought to refuse to expose information to the
renderer.

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] Canonical Image and Color

2014-08-26 Thread Mike

Tab, You’re right if we take as given that: 1. FF and Chrome will finally fix 
the bug with handling different size attributes (hopefully they will) 
2.standard aspect ratio will be 1:1 (although maybe it can be different) 3.the 
layout of hi-res favicon will differ from a standard (16x16/32x32) favicon. 
Compare those: https://dl.dropboxusercontent.com/u/1830800/temp/icons.jpg
Generally seems like it could work. But on other hand the battle for high-res 
icons has been won by Apple’s Touch Icons. Almost sure that more websites have 
a touch icon than an icon with a size attribute exceeding 128px. Around 20% has 
an apple icon from top-1.
What do you think could be the fallback scenario (in case there is no proper 
icon)? Generated by browser?
In a case someone wanna see grabbed touch icons for top-1000 website: 
https://yadi.sk/d/CZgnIW6UZxpTg 
When I see it my sense of beauty says no to any API;)


Mike Tomshinsky
tomshin...@yandex-team.ru



On 26 авг. 2014 г., at 10:42, Tab Atkins Jr. jackalm...@gmail.com wrote:

 On Tue, Aug 26, 2014 at 4:21 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, Aug 25, 2014 at 8:59 PM, Mike tomshin...@yandex-team.ru wrote:
 2) There is already a couple of standards or quasi-standads:
- favicons (most promising seems to be the increasing of their size and 
 svg support)
- apple-touch-icon used by Apple and Android
- msapplication-TileImage used by MS
- Firefox OS icon (detached case)
- SpeedDial API by Opera (as an extension)
 
 There's also link rel=icon, which is the way to do this.
 
 Particularly when used with the sizes='' attribute, which lets you
 provide small favicons *and* large icons suitable for use in tiles
 like this.
 
 ~TJ

Re: [whatwg] Canonical Image and Color

2014-08-26 Thread Mike

Mathias, Anne
I really believe that the notification api is a related topic but can exist as 
a separate api used in page icon. I think it’s a good idea not to bind them 
together.

Mike Tomshinsky
tomshin...@yandex-team.ru



On 26 авг. 2014 г., at 10:50, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Aug 26, 2014 at 8:46 AM, Mathias Bynens mathi...@opera.com wrote:
 Sure, but what about the “notification counter” use case that Mike outlined?
 
 We should investigate that as a feature of the notifications API I
 think. Someone suggested that last week:
 https://github.com/whatwg/notifications/issues/23 I haven't really put
 much thought into how exactly we should go about it though, API-wise.
 
 
 -- 
 http://annevankesteren.nl/

Re: [whatwg] Various autocomplete= topics

2014-04-03 Thread Mike West

On Wed, Apr 2, 2014 at 10:56 PM, Ian Hickson i...@hixie.ch wrote:

  Also, consider the case of login forms without username fields. You see
  this sort of thing a lot these days, when sites remember who was last
  logged in:
 
  form
  labelPassword for hober: input type=password name=pw/label
  pNot hober? a href=...Click here to sign in/a.
  /form
 
  It's difficult for tools to manage the user's auth info for such pages.
  How can tools discover what the username is? The obvious solution, in a
  world with autocomplete=username, would be to add input type=hidden
  autocomplete=username name=username value=hober to the form.

 So far, autocomplete= hasn't applied to input type=hidden. This would
 be a bit weird, giving it a different meaning than usual (providing
 information to the UA, rather than getting information from the UA). I'm a
 bit skeptical of this kind of overloading.

 Not sure what the right solution is, though.


As Garrett noted, this is already a solution Google is using, though not
with explicit syntax, just taking advantage of existing heuristics. Paving
this (potential) cowpath isn't really that weird.

That said, an alternative might be to add a mechanism of associating
autocompletion metadata with the field in order to give the UA enough
context to fill it in. For example, if a password is being requested for a
known username, that username could be added as an new
autocomplete-username attribute (similar to the 'data-*' construct HTML
already supports):

input type=password autocomplete-username=hober

-mike

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: [whatwg] input type=number for year input

2014-02-18 Thread Mike Taylor


On 2/18/14, 17:17, Ian Hickson wrote:

On Tue, 18 Feb 2014, Jonathan Watt wrote:

The question is, should I change Mozilla's implementation to stop
displaying the internal value using grouping separators, or is it wrong
to use input type=number for year input. I'm erring on the former, but
I'd like to solicit others' thoughts on this matter.



My recommendation would be to just use comma separation for numbers
greater than .


Perhaps unrelated, but that would solve the 
type=number-for-tcp-ports-looks-kinda-weird problem: 
https://cloudup.com/cKEisWEkvjv


--
Mike Taylor
Web Compat, Mozilla

Re: [whatwg] input type=number for year input

2014-02-18 Thread Mike Taylor


On 2/18/14, 17:55, Mike Taylor wrote:

On 2/18/14, 17:17, Ian Hickson wrote:

On Tue, 18 Feb 2014, Jonathan Watt wrote:

The question is, should I change Mozilla's implementation to stop
displaying the internal value using grouping separators, or is it wrong
to use input type=number for year input. I'm erring on the former, but
I'd like to solicit others' thoughts on this matter.



My recommendation would be to just use comma separation for numbers
greater than .


Perhaps unrelated, but that would solve the
type=number-for-tcp-ports-looks-kinda-weird problem:
https://cloudup.com/cKEisWEkvjv


(for ports under , that is)

--
Mike Taylor
Web Compat, Mozilla

Re: [whatwg] Sandboxed IFrames and downloads.

2013-02-15 Thread Mike West

Ping. Is this a terrible idea? :)

--
Mike West mk...@google.com, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91


On Sat, Feb 2, 2013 at 7:11 PM, Mike West mk...@google.com wrote:

 It's currently possible to force a download by serving a file with a
 Content-Disposition: attachment; filename=... header. Notably, this
 mechanism can be used to download a file with minimal user interaction by
 including the resource to be downloaded in an IFrame. This holds even for
 sandboxed IFrames, as demonstrated by
 http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will
 download a file, fair warning).

 It seems consistent with the general thought behind the `sandbox`
 attribute that it should control downloads as well as the bits it already
 locks down. I'd propose adjusting the spec to include a sandboxed downloads
 flag, which, when present, would block all downloads from inside the frame
 (or, perhaps only require user confirmation?). This restriction could be
 lifted via an 'allow-downloads' keyword, if present in the sandbox
 attribute's token list.

 WDYT?

 --
 Mike West mk...@google.com, Developer Advocate
 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
 Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

[whatwg] Sandboxed IFrames and downloads.

2013-02-02 Thread Mike West

It's currently possible to force a download by serving a file with a
Content-Disposition: attachment; filename=... header. Notably, this
mechanism can be used to download a file with minimal user interaction by
including the resource to be downloaded in an IFrame. This holds even for
sandboxed IFrames, as demonstrated by
http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will download
a file, fair warning).

It seems consistent with the general thought behind the `sandbox` attribute
that it should control downloads as well as the bits it already locks down.
I'd propose adjusting the spec to include a sandboxed downloads flag,
which, when present, would block all downloads from inside the frame (or,
perhaps only require user confirmation?). This restriction could be lifted
via an 'allow-downloads' keyword, if present in the sandbox attribute's
token list.

WDYT?

--
Mike West mk...@google.com, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

[whatwg] `window.location.origin` in sandboxed IFrames.

2013-01-09 Thread Mike West

Hello!

In WebKit, loading 'iframe sandbox=allow-scripts
src=frame.html/iframe' with a framed document containing
'scriptalert(window.location.origin);/script' alerts the actual
origin of the document, which wasn't what I expected. I'm not sure
what's intended, but I expected that treating the framed document as
existing in a unique origin would have some effect on the string
output as it's location's origin.

Adam explained that WebKit currently treats the 'origin' attribute as
the origin of the document's location, not the origin of the
document[1]. This is generally benign, but surprised me in the
sandboxed case.

What should the expected behavior in this case be? Given the way that
MessageEvent sets the origin of a message from a sandboxed frame to
the string null, that seems like a reasonable option here as well.

WDYT?

[1]: https://bugs.webkit.org/show_bug.cgi?id=106488#c1

--
Mike West mk...@google.com, Developer Advocate
Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Re: [whatwg] events when navigating away before page load?

2012-12-14 Thread Mike Wilson

Thanks Ian, 

Ian Hickson wrote on 14 december 2012 19:22:
 On Fri, 14 Dec 2012, Mike Wilson wrote:
 
  What events are supposed to be fired when the browsing context 
  gets navigated away before the current page has finished 
  loading, ie before the load event has been fired?
 
 It's pretty complicated, but the short answer is beforeunload 
 and unload. DOMContentLoaded and load don't fire per spec, 
 though this is controversial (it's been suggested that the abort
 that happens during navigation should be equivalent to the abort 
 that happens when the user hits Stop; whether it is or not 
 changes whether or not we pretend that the page finished parsing 
 or not).

I added the beforeunload event in an updated fiddle:
http://jsfiddle.net/khwtB/

which resulted in:

  FF17  Chr23 IE9   spec
  - - - -
domload   y y n n
load  n n n n
beforeunload  y n y y
unload   y y n y

So yes, it seems there is a lack of agreement here :-)

Anyway, the finding that originally got me started on looking at
this was that I received an unload event without a preceeding
load event. Naively this seems logically wrong, but I appreciate
these are complicated matters so I'm content with the answer that
this probably shouldn't be expected in these kinds of cases.

Best regards
Mike

Re: [whatwg] events when navigating away before page load?

2012-12-14 Thread Mike Wilson

Ian Hickson wrote on 14 december 2012 21:11:
 
 As a general rule, the intent of the spec is that you 
 get a load when all your scripts (and other resources) 
 have loaded, and you get an unload when the page is 
 going away. Thus if the page goes away before the page 
 has finished loading, you just get an unload.

Yes, when I think about this a bit more it makes a lot of
sense. Initially I did expect a behaviour more like
abort/stop - skipping all outstanding i/o and fast-
forwarding to the firing of the load event(s). 
But as you say, as we are leaving the page anyway, there 
shouldn't be a big need to do page load initializations.
And a smart page can actually detect it's being rushed
through by looking for unload without load.

Note to self and to other page authors: make sure unload 
handlers don't break if related code in load handlers 
weren't executed.

 We additionally also suggest firing a load and so forth 
 when the user aborts the page, on the assumption that you 
 probably have all the scripts you need and are only 
 missing minor things like ads or analytics

Makes sense too - the user probably stopped the page
when it seemed complete enough to him, so he should get
event handlers and all other UI stuff set up that's
normally in load handlers.

I did a few more tests and found even more differences.
Chrome has different behaviour depending on if the 
navigation is initiated while parsing head or body,
and for the latter it fires the same events as Firefox
although in a different order:

FF17   Chr23  Chr23  IE9spec
nav head   nav head   nav body   nav head   nav head
or body  or bodyor body
-- -- -- -- --
beforeunld domloaddomloadbeforeunld beforeunld
domloadunload beforeunldunload
unloadunload

Interesting stuff indeed :-)

Best regards
Mike

Re: [whatwg] URL: URLQuery

2012-10-13 Thread Mike Dierken

Since a URL query string is not a strict map with only one value for a
key, would the get/set operations allow for an array as well as an
atomic value?


On Fri, Oct 12, 2012 at 3:02 PM, Glenn Maynard gl...@zewt.org wrote:

 The object paradigm is more natural for the common case:

 query.values[key] = value; // get()
 console.log(query.values[key]); // set()
 delete query.values[key]; // delete()
 query.getAll(key); // stays as-is

Re: [whatwg] [canvas] Proposal for supportsContext

2012-09-10 Thread Mike Taylor


On Mon, 10 Sep 2012 13:14:30 -0500, Dean Jackson d...@apple.com wrote:


To give a real world example, the popular tool Modernizr tests for the
availability of WebGL by attempting to create a WebGL context. This can  
happen

even on pages that have no intention of using WebGL - an author has just
inserted Modernizr into their page and is using it to test for another  
feature.
As I said, creating a context is not a free operation. In fact, on  
shipping

Safari (Mountain Lion) this causes us to switch to a more powerful GPU
on systems that have two graphics processors.

An alternative (for the WebGL case) would be to have the author test for  
the

presence of window.WebGLRenderingContext. However, this is not reliable.


This is actually what Modernizr does these days [1], but older versions  
did in fact create the context.


[1]  
https://github.com/Modernizr/Modernizr/blob/master/modernizr.js#L429-436


--
Mike Taylor
Opera Software

Re: [whatwg] Media queries, viewport dimensions, srcset and picture

2012-05-22 Thread Mike Gossmann

The patern thing is tangential. SRCSET using image dimensions instead of screen 
dimensions would work just as well, so would picture if it was set up to allow 
saying what the dimensions of each image are.

I would argue that this does address the pixel density issue though. It does it 
in the same way it handles em, rem, or percentage based designs: by ignoring 
all  that stuff and just picking the image that best fits the available 
hardware pixels. It's more future proof too, since you 200w 200h 2x image 
could also stand in as your 100w 100h 4x image, if/when something like that 
comes out,  without any updates needed.

Art direction is solved in a simialir way: don't provide any images that look 
bad, and don't size the img element to a size you don't have a picture for.

Using the image dimensions instead of the screen dimensions also solves the 
desktop first vs mobile first dilemma. Syndication becomes easier (or are 
your breakpoints the same as readability's?), updating the design becomes 
easier (no editing every image in every post because a breakpoint changed) and 
really simplifies use cases like the following:

You're making a grid of thumbnails. At it's largest size, it's three images 
across. It stays this way until the images are 2/3 their size, at which point 
it changes to 2 columns at the original size. When the images hit half their 
original size, it switches to one column, full size. So one image is created at 
the three most likely sizes (1/1, 1/2, 1/3) and then srcset is used to make 
sure the

--
Mike Gossmann



Mathew Marquis m...@matmarquis.com wrote:

On May 22, 2012, at 5:43 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, May 22, 2012 at 10:21 AM, Markus Ernst derer...@gmx.ch wrote:
 I am somehow surprised that there are no reactions to this proposal. To me
 as a humble author it looks like it would address the main issue of both
 picture and @srcset, as it leaves the MQ to CSS, and thus separates design
 from content.
 
 1. It does not address the pixel density use case. 2. A pattern-based
 approach was actually mentioned in Ian Hickson's email when he
 announced the srcset attribute.
 

We’re apt to see the element used in one of two ways: 

* Serving a size-appropriate image source in a flexible layout, wherein the 
size of the images will be controlled by CSS—typically, `max-width: 100%`. 
Using a pixel density MQ will serve a larger image within this constraint. 
Inherent size is not a concern with this case—which is fortunate, as this will 
likely require sources with varying dimensions, per the “art direction” case.

* Serving a static-dimension asset at varying resolutions, a la Apple.com. To 
always rely on the intrinsic size of another source is to negate the art 
direction use case — however, we could simply add optional `width` and 
`height` attributes to `picture`, constraining the higher res image to a 
specified set of dimensions. This leaves control in the authors’ hands in a 
simple, predictable way without negating either use case.

I can’t speak to this personally, but Kornel has mentioned that using said 
attributes instead of relying on a calculated inherent width will avoid 
reflows. It should likely be an option in either case.

 
 -- 
 Anne — Opera Software
 http://annevankesteren.nl/
 http://www.opera.com/

Re: [whatwg] Media queries, viewport dimensions, srcset and picture

2012-05-21 Thread Mike Gossmann

I think variables for more than width and height might actually be a bit 
redundant, since all the other variables are just copying over values from src, 
which are known values when the tag is being created, that won't change on 
their own. A developer could just type them a second time and be done with it. 
This doesn't prevent the width and height variables from being used as part of 
a folder structure or filename either. Trying to use a something like 
{filename} could also cause problems if you want to use 
src=img/blog/anImage_200x300.jpg as your fallback, unless the variable can 
strip the sizes out on it's own.

--
Mike Gossmann

[whatwg] Media queries, viewport dimensions, srcset and picture

2012-05-20 Thread Mike Gossmann

When all the picture vs srcset started showing up on twitter, I was initially 
behind picture. I'm sure you all know the arguments for it, and I liked those 
arguments. Today though, I was reading an article about the two, and there was 
a misunderstanding about how srcset was working in the comments, and it made me 
realize that something closer to srcset would be ideal.

The big thing I realized is that as a developer, I do not want to write more 
media queries - or anything that works at all like them - into image elements. 
It's redundant. There's a good chance there's already a bunch of CSS in place 
controlling the shape and size of the image element itself, why should I have 
to write a bunch more, somewhere else, to control the src of the image too?

Why can't it work so that in the html I say here's an image, there's a version 
of it at 150x150, and a version at 48x48, and then in the CSS I say that the 
image is 25% of the width of the article it's in, which works out to 100px 
wide, and then the browser can just decide that the 150x150 would be best, and 
scale it down. If I change the CSS, I don't have to change the html too, the 
images I provided are still only available at those sizes. With image/picture 
sources set by viewport dimensions, even something as simple as adding more 
padding around articles on a site could involve going through all the HTML and 
adjusting the breakpoints in the tags. This way layout, units, and screen dpi, 
don't matter when writing the HTML,

I've seen people get confused and think srcset work this way, instead of by 
viewport size (unless I'm the confused one), and if they were right then srcset 
would work well for this. It would be even nicer if there was something even 
more CMS friendly, like:

img src=/img/people.jpg sizes=100x200 300x250 900x300 
pattern=/tools/resizer.php?img=people.jpgamp;width={w}amp;height={h} alt=A 
picture of some people.

So src would be the fallback, then sizes would say which dimensions are 
available, in a fairly common format, using spaces to separate options like 
class does. pattern (probably a bad name) would be a template for the URL the 
browser can request the image from, replacing {w} and {h} with the requested 
dimensions. There wouldn't need to be a token for the dpi/resoultion/whatever, 
the browser could just request an image twice or three times or whatever the 
size. There's no point in having sizes=100x100@1 100x100@2 200x200@1 when you 
can just have sizes=100x100 200x200

This gives the designer/developer full control over the shape and size of the 
image element (through CSS), while still allowing the browser to make decisions 
based on bandwidth and whatnot.

--
Mike Gossmann | m...@c572.ca | http://gossmati.ca

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

2012-05-16 Thread Mike Taylor

On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox  
m...@matthewwilcox.com wrote:


What's the actual WHATWG proscribed format for conducting conversations  
in email

format?


See http://wiki.whatwg.org/wiki/FAQ#Should_I_top-post_or_reply_inline.3F

--
Mike Taylor
Opera Software

Re: [whatwg] RWD Heaven: if browsers reported device capabilities in a request header

2012-02-07 Thread Mike Taylor

On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox  
m...@matthewwilcox.com wrote:



, will cause their users to get more broken pages (which is what happens
in many cases with browser sniffing right now), will lock new devices  
out
of the market (which is what happens with new UA strings right now).   
And

hence that the proposal is bad for the web in various ways.


I'm not sure what your grounds are for thinking this. Would it not be
sensible for the server to have to serve some default if the headers  
aren't

there anyway, the assumption must be that the device can't send these
headers. In what circumstances might this cause breakages? And how could  
it
possibly lock out any devices? This is a progressive-enhancement type  
tech,
not a if you don't have the ability to notify the server you can't get  
any

info type tech. Surely?


Progressive-enhancement type tech gets abused as well. Take the video  
element, with its lovely source elements for codecs and fallback content  
for non-supporting UAs. No hacks necessary. Then throw laziness and  
javascript at it and you've got a mess.


An example, visit http://www.maerskfleet.com/ with an empty UA string (or  
use Opera). In a browser that should be able to support video, you'll  
get a JS error and the page is blank. Even after including Modernizr and  
using HTML5 which is designed to gracefully degrade for older UAs,  
developers do the same old UA sniffing trick:  
https://gist.github.com/1761168


I would love to believe that all developers would use this proposal for  
good, as it were. Experience leads me to believe it will be just another  
technique sniffed and served to the regular suspects.


--
Mike Taylor
Opera Software

Re: [whatwg] Cut and paste (and related) events' futures

2012-01-26 Thread Mike Taylor


Hi Chris,

On Thu, 26 Jan 2012 20:27:41 -0600, Chris O'Brien  
accou...@prettycode.org wrote:



In all the last-released versions of the major browsers (except Opera),
there's support for cut-and-paste events like onpaste on input
type=text... and textarea elements.

Is there any plan to put these events into the standard? Isn't that a  
basic
tenent of WHATWG--if the real-world vendor implementations are in  
consensus
yet don't reflect the standard, change (or add to) the standard to  
reflect

the de facto market standard, so long as any modifications are backwards
compatible?


You're probably looking for this:  
http://dev.w3.org/2006/webapi/clipops/clipops.html. A search for  
clipboard data API in the archives might bring up some interesting  
discussion as well.


Cheers,

--
Mike Taylor
Opera Software

[whatwg] HTML5 named entity Gt; and Lt;

2011-12-14 Thread Mike Samuel

The table in section 12.5 (
http://www.whatwg.org/specs/web-apps/current-work/multipage/named-character-references.html
) says
 GT;U+0003E
 Gt;U+0226B≫
 gt;U+0003E
 GT U+0003E
 gt U+0003E

which I believe means that GT;, gt;,GT, and gt all encode
 but Gt; encodes U+226B MUCH GREATER-THAN.

http://svn.whatwg.org/webapps/entities-unicode.inc includes these but
the entities-legacy.inc does not.

Similarly

 Lt;U+0226A≪

This is a potential source of confusion for naive HTML entity decoders
fall-back to case-insensitive matching when there is no mapping for a
given entity name.

MathML already has other succinct mappings for U+226A (ll;) and
U+226B (gg;).  Could HTML5 avoid confusion by deprecating Lt; and
Gt; in favor of ll; and gg; or remove them entirely?

http://www.google.com/codesearch#search/q=amp;Gt;%20file:.html$%20case:yestype=cs
shows four files using Gt;, 2 of which treat it as synonymous with gt;.

Re: [whatwg] Signed XHTML

2011-10-31 Thread Mike Hanson

On Oct 31, 2011, at 3:53 AM, Mikko Rantalainen wrote:

 2011-10-27 14:29 EEST: Henri Sivonen:
 On Thu, Oct 20, 2011 at 9:57 PM, Martin Boßlet
 martin.boss...@googlemail.com wrote:
 Are there plans in this direction? Would functionality like this have a
 chance to be considered for the standard?
 
 The chances are extremely slim.
 
 XML signatures depend on XML canonicalization which is notoriously
 difficult to implement correctly and suffers from interop problems
 because unmatched sets of bugs in the canonicalization phase make
 signature verification fail. I think browser vendors would be
 reasonable if they resisted making XML signatures of canonicalization
 part of the platform.
 
 Moreover, most of the Web is HTML, so enthusiasm for XHTML-only
 features is likely very low these days.
 
 I agree. If a method for signature would be introduced, it should be on
 HTTP-level instead. For example, the server (or client) could pass an
 extra header (e.g. Content-Signature) where value would be the signature
 of the content with some extra info about the keyalgorithm used for
 signature.

And, for the record, S/MIME already defines the application/pkcs7-signature 
MIME type for signed message-bodies (see RFC 5751 for the latest).

Support for S/MIME response processing in browsers is thin-to-nonexistent, but 
business-to-business exchange of S/MIME signed bodies over HTTP has been around 
for many years.  It at least has the benefit of not requiring canonicalization, 
since the signature algortithm is defined to run over the serialized bytes of 
the message.

The main reason to push for signatures in the body of a message would be 
because there was desire to sign a sub-region of the document, or to support 
multiple or partially-trusted signers; the use cases for that are quite 
rarified at this point.

-mh

Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list

2011-10-28 Thread Mike Taylor

On Fri, Oct 28, 2011 at 11:52 AM, Philip Jägenstedt phil...@opera.comwrote:

 On Fri, 28 Oct 2011 12:58:01 +0200, David Håsäther hasat...@gmail.com
 wrote:

  It would be more useful if the DOMTokenList methods (contains, add,
 remove, toggle) would take a space separated list of tokens. This is
 the behavior most DOM libraries have when dealing with class names.

 So, when setting two classes, instead of

  ele.classList.add(hey);
  ele.classList.add(ho);

 you could do

ele.classList.add(hey ho);

 Currently, the latter results in an INVALID_CHARACTER_ERR.

 The behavior of all methods should be obvious I guess.


 +1, but what should toggle return?

  toggle(a) returns true if a was added, which is equivalent to
 !contains(a) on the initial string or contains(a) on the final string.
 For toggle(a b), !contains(a b) on the initial string may not be the
 same as contains(a b) on the final string, so which should it be? Put
 simpler, should it return true if any token is added or if all tokens are
 added?


I would prefer if it returned the DOMTokenList, to enable chaining like:

   foo.toggle('bar baz').remove('bat');

Same for the rest of the DOMTokenList methods, as well.

   foo.add('bar').remove('baz');

See also https://github.com/jquery/standards/issues/13 for relevant
discussion.

Re: [whatwg] script element onerror event

2011-05-29 Thread Mike Wilson

Hi John,

This event is actually already speced, see #14 fire a simple event 
named error at the element in:
http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script
(and the onerror attribute is valid for all elements)

Best regards
Mike Wilson 

John J. Barton wrote:
 To allow optional JavaScript download, some widely used JavaScript 
 libraries, such as jQuery and requireJS, use script elements added to 
 the document dynamically by JavaScript. (Of course this 
 feature is also 
 used by applications directly as well).   For normal deployment this 
 approach works well in practice. At development time however, 
 or in the 
 presence of network or server problems, the approach gives poor error 
 recovery information. Fundamentally the problem is that the insertion 
 mechanism has no error return path.
 
 The script element does support one event, 'onload' which fires after 
 the script has finished loading. I suggest the addition of one new 
 event, 'onerror', which fires in every other case. For examples, a 
 network error (4XX, 5XX) or JavaScript parse error would 
 trigger onerror 
 but not onload.  On the other hand, a runtime error for the 
 outer-function of the script element would trigger onload (I 
 guess), but 
 the developer can handle this with try/catch.
 
 Very long load times would still have poor error recovery 
 information, 
 but developers could implement UI to signal loading... once 
 they know 
 they will get some update event eventually.
 
 jjb

Re: [whatwg] script element onerror event

2011-05-29 Thread Mike Wilson

John J. Barton wrote:

Step 14 is unclear or incomplete however:
 If the src
http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src
attribute's value is the empty string or if it could not be resolved,...

Does this mean the error handler will be called in the case of 4XX, 5XX, and
syntax errors?

If you follow the algorithm a bit further down you have this in step 15.2:

If the load resulted in an error (for example a DNS error, or an HTTP 404
error)
Executing the script block must just consist of firing a simple event named
error at the element.

Best regards
Mike

Re: [whatwg] script element onerror event

2011-05-29 Thread Mike Wilson

Mike Wilson wrote:

John J. Barton wrote:

Step 14 is unclear or incomplete however:
 If the src
http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src
attribute's value is the empty string or if it could not be resolved,...

Does this mean the error handler will be called in the case of 4XX, 5XX, and
syntax errors?

If you follow the algorithm a bit further down you have this in step 15.2:

If the load resulted in an error (for example a DNS error, or an HTTP 404
error)
Executing the script block must just consist of firing a simple event named
error at the element. 

Oops, this section isn't step 15.2, it's below it. 
Here's the link:
http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block
 
Best regards
Mike

Re: [whatwg] window.cipher HTML crypto API draft spec

2011-05-23 Thread Mike Hanson

The Need for Web Security API paper is a good intro - we'll be discussing it 
in the W3C Identity workshop tomorrow.  I'll make sure this thread makes it 
into the requirements discussion.

In talking with a couple people about it today, it became clear that there at 
least two, maybe three (or more), layers to a browser-level crypto API.

The first level is math: fast, correct, FIPS 140-audited implementations of 
common crypto algorithms.  Parser implementations might go in this bucket as 
well.

The second is authority-granting: allowing web content to access keying 
material that resides outside of the content's usual purview, typically for 
integrity-protecting or authenticating purposes.  This could be as simple as 
key material held outside of the content's access, or as complex as a hardware 
security module.  PKCS11 will come up at some point in this conversation.  
Perhaps hardware randomness is in this bin.

The third sort-of domain, is in level-crossing: think of providing access to 
SSL/TLS keys from content, as in RFC 5705.  There are probably 
authority-granting cases here that I haven't thought of.  This may not be a 
useful distinction.

I suspect that it will be useful to lightly separate the math conversation 
from the authority conversation - they are both interesting but they probably 
involve different people and different concerns.

-Mike


On May 23, 2011, at 9:05 PM, Jonas Sicking wrote:

 On Mon, May 23, 2011 at 8:14 PM, =JeffH jeff.hod...@kingsmountain.com wrote:
 David Dahl replied..
 
 Simon Heckmann si...@simonheckmann.de asked..
 
 Why does it only handle asymmetric encryption? Something to
 encrypt/decrypt data with e.g. AES would be nice as well!
 
 I do need to add a symmetric encryption API as well, my current focus has
 been on the exchange of message between web users, but that is only one
 facet of the results of this effort. I should look at the big picture a
 bit
 and think about what that API should look like.
 
 Various folks have been thinking about the need to leverage platform crypto
 functions (rather than implementing crypto in JS libraries) via a
 standardized API for browser-side web app code such that a
 swath of use cases is addressed, here's a couple examples of such position
 statements..
 
  The Need for a Web Security API
  http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_28.pdf
 
  Wanted: Native JS Encryption
  http://robert.accettura.com/blog/2011/03/03/wanted-native-js-encryption/
  https://mail.mozilla.org/pipermail/es-discuss/2011-March/013144.html
 
 Some have noted that there ought to be a very high level API built on top of
 such a substrate that web app developers could use for their more common use
 cases. Keyczar is one example of such an API http://www.keyczar.org/, and
 cryptlib is another
 http://www.cryptlib.com/security-software/programming-code-examples.
 
 Couldn't this high level API be the API that David is proposing? Or
 are these threads calling for something even higher level?
 
 Adam Barth replied..
 
 David Dahl said..
 
 Yes, that is the case, I am using NSS. I imagine other browser vendors
 would also use NSS to implement this.
 
 It's very unlikely that Microsoft will use NSS to implement this API in
 IE.
 
 Agreed.  We nominally need an API that can be implemented by interfacing
 with NSS and CAPI (Microsoft Cryptography API) (arguably as well as OpenSSL,
 GPG, OpenPGP, etc).
 
 The API David is proposing is looking generic enough to me that it
 should be no problem implementing in libraries other than NSS. Do you
 see any reason it wouldn't be?
 
 As a separate question, is anyone here familiar enough with keygen to
 know if the proposed API could replace keygen?
 
 / Jonas

Re: [whatwg] Giving the body tag a new meaning.

2011-03-01 Thread Mike Taylor


On 3/1/11 1:54 PM, usuario wrote:

According to the spec:
The body element represents the body of a document (as opposed to the
document’s metadata).

I think definition is a bit ambiguous.


Why not propose a better definition then?

Re: [whatwg] Cryptographically strong random numbers

2011-02-14 Thread Mike Shaver

On Fri, Feb 11, 2011 at 1:36 PM, Adam Barth w...@adambarth.com wrote:
 Regardless, the ability does not exist in JavaScriptCore.  If you'd
 like to contribute a patch that makes it possible, I'm sure it would
 be warmly received.

That is surprising to me. Isn't it necessary in order to implement
window.forms.formname and other dynamically-reflected properties?

Mike

Re: [whatwg] navigation shouldn't abort if canceled

2011-02-03 Thread Mike Wilson

Boris Zbarsky wrote:
 On 2/2/11 3:22 PM, Michael Nordman wrote:
  That does sound like a bug? I'd be curious to know what the 
  reasoning was for the existing sequence of steps.
 
  From what I can tell, current browser behavior.

As I wrote in my initial post, my observation was actually
that this is contrary to current browser behaviour.
But I may be misinterpreting the consequences of the algorithm
as stated. Here's my test scenario in pseudo code:

1) load a page that has a beforeunload handler
2) the page has an img/link css/external script that is slow to
   load
3) navigate away from the page before the resource in (2) has
   completed loading
4) answer stay on page on the beforeunload prompt

According to 
http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documen
ts
I would expect the resource in (2) to stop loading at (3), as
a result of aborting the document in the navigation
algorithm's step 9.

But this is not what I am seeing in Firefox 3.6 or even IE6
(I tested a number of other browsers too but don't have the
exact versions handy).
The external resources all complete loading, with load events 
and all.

Did I miss something?

Best regards
Mike Wilson

Re: [whatwg] navigation shouldn't abort if canceled

2011-02-03 Thread Mike Wilson

Boris Zbarsky wrote:
  As I wrote in my initial post, my observation was actually
  that this is contrary to current browser behaviour.
 
 Ah, I see.
 
 So in Gecko, at least, beforeunload fires before the document 
 is aborted.

Right, that matches my findings in other browsers as well.

So can we then say that 
http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documen
ts
probably needs updating?
Is the fix as simple as moving step 9 to the position between
current step 11 and 12? (directly after beforeunload)

Best regards
Mike

Re: [whatwg] navigation shouldn't abort if canceled

2011-02-01 Thread Mike Wilson

No comments so far on this issue so I'll describe it a bit more.
Consequences of the current text are that resource fetches are
canceled for a document when navigating away from it, even if
the user then chooses to cancel the navigation at a 
beforeunload prompt and returns to the document.

Best regards
Mike Wilson

Mike Wilson wrote on December 26, 2010:
 http://www.whatwg.org/specs/web-apps/current-work/#navigating-
 across-documents
 (as of December 26, 2010)
 | When a browsing context is navigated to a new resource, the 
 | user agent must run the following steps:
 ...
 | 9.  Abort the active document of the browsing context.
 ...
 | 11. Prompt to unload the Document object. If the user refused 
 | to allow the document to be unloaded, then these steps 
 | must be aborted.
 
 Might this be a bug? (It seems more consistent with other
 parts of the html5 spec, and with browsers, to do the abort 
 after the user has allowed the document to unload.)
 
 Best regards
 Mike Wilson

Re: [whatwg] WebWorkers and images

2011-01-14 Thread Mike Wilson

Boris Zbarsky wrote:
 It would be interesting to have an API that allows passing
 an imagedata object (not a copy) to a worker.  Such an API 
 would have to make the data disappear on the caller's side.
 That could be implemented reasonably efficiently using 
 shared memory (either directly with threads or using shared 
 memory segments with processes).

FWIW, there's some interesting discussion on handing over 
data in message passing in this Google TechTalk:
http://www.youtube.com/watch?v=37NaHRE0Sqw
although this is about a Java framework.
(some data structure pictures at 27:57 and forward)

Best regards
Mike Wilson

Re: [whatwg] link onLoad event

2011-01-14 Thread Mike Wilson

Diogo Resende wrote:
 I see already information on the latest draft about a load 
 and error event, I think this is it. I was hoping some 
 browser vendors would implement it sooner :)

Yes, ironically link.onload works in IE6, but not in current
stable versions of Firefox, Safari or Chrome :-P

Best regards
Mike Wilson

[whatwg] navigation shouldn't abort if canceled

2010-12-26 Thread Mike Wilson

http://www.whatwg.org/specs/web-apps/current-work/#navigating-across-documen
ts
(as of December 26, 2010)
| When a browsing context is navigated to a new resource, the 
| user agent must run the following steps:
...
| 9.  Abort the active document of the browsing context.
...
| 11. Prompt to unload the Document object. If the user refused 
| to allow the document to be unloaded, then these steps 
| must be aborted.

Might this be a bug? (It seems more consistent with other
parts of the html5 spec, and with browsers, to do the abort 
after the user has allowed the document to unload.)

Best regards
Mike Wilson

Re: [whatwg] Proposal: add attributes etags last-modified to link element.

2010-09-20 Thread Mike Belshe

On Sun, Sep 19, 2010 at 11:25 PM, Julian Reschke julian.resc...@gmx.dewrote:

 On 20.09.2010 02:37, Aryeh Gregor wrote:

 ...

 Sure it would.  You can currently only save an HTTP request if a
 future Expires header (or equivalent) can be sent.  A lot of the time,
 the resource might change at any moment, so you can't send such a
 header.  The client has to check every time, and get a 204, even if
 the resource changes very rarely.  If you could indicate in the HTML
 source that you know the resource hasn't changed, you could save a lot
 of round-trips on a page that links to many resources.

  ...

 Resources that should be cached (stylesheets, images) but change at
 unexpected times are indeed a problem.

 A well understood approach is to push some kind of version indicator into
 the URI (such as query parameter).


LINK, in general, allows a server to indicate to a client that it will need
a particular resource earlier than the client otherwise would have
discovered it.  Today, the LINK header doesn't assist with understanding
existing cache control mechanics, so if the browser does have the resource
in cache but it needs validation, you didn't accomplish what you had hoped
with the LINK header - the client is still going to make a costly
round-trip.  For savvy content authers, they could, as you suggest, simply
modify the content to work with this case.  This effectively restricts the
full benefit of LINK to the subset of resources which are static and have
long-lived expiry.  That would leave LINK less useful to large swaths of the
internet where they do leverage if-modified-since and etags.

Rather than ask this question about the LINK header attributes, you could
instead aim your question at HTTP - why does HTTP bother with
if-modified-since?But the answer is moot - that decision was made long
ago.

Given that the web *does* use these basic cache control mechanisms, why
*wouldn't* you want the LINK header to be capable of using them too?  :-)
 This proposal is actually just making LINK more like the rest of HTTP.

Mike








 Best regards, Julian

Re: [whatwg] Proposal: add attributes etags last-modified to link element.

2010-09-20 Thread Mike Belshe

2010/9/20 Julian Reschke julian.resc...@gmx.de

 On 20.09.2010 17:26, Mike Belshe wrote:

 ...

 LINK, in general, allows a server to indicate to a client that it will
 need a particular resource earlier than the client otherwise would have
 discovered it.  Today, the LINK header doesn't assist with understanding

  ...

 Sorry?

 That may be a use case that *could* be implemented using LINK, but it's
 certainly *not* the general use case.

 For instance, it doesn't seem to be true for any of the currently used link
 relations in wide use, such as icon or stylesheet (there's no later
 discovery at all).

 Or are you referring to using the Link *header* in addition to an
 equivalent HTML LINK?


Yes, I'm talking about the HTTP header.Sorry for the confusion.




  existing cache control mechanics, so if the browser does have the
 resource in cache but it needs validation, you didn't accomplish what
 you had hoped with the LINK header - the client is still going to make a
 costly round-trip.  For savvy content authers, they could, as you
 suggest, simply modify the content to work with this case.  This
 effectively restricts the full benefit of LINK to the subset of
 resources which are static and have long-lived expiry.  That would leave
 LINK less useful to large swaths of the internet where they do leverage
 if-modified-since and etags.


 Link relations cover many other use cases than those that you seem to be
 considering.

 For resources that change infrequently but at unexpected times, it's
 already possible to get what you want by varying the URI when the resource
 changes (such as putting a timestamp or a revision number into a query
 parameter).


Yeah, I'm thinking of servers that can learn and auto-generate these
headers.  I think you're thinking of content authors plunking this into
their HTML.

The vast majority of HTML is served without consideration of this type of
detail.  And as the web grows, the content author shouldn't be tied up
thinking about them.  The servers can do it better anyway.








  Rather than ask this question about the LINK header attributes, you
 could instead aim your question at HTTP - why does HTTP bother with
 if-modified-since?But the answer is moot - that decision was made
 long ago.


 Not sure what you're referring to. If-Modified-Since predates ETags (as far
 as I recall).


  Given that the web *does* use these basic cache control mechanisms, why
 *wouldn't* you want the LINK header to be capable of using them too?
  :-)  This proposal is actually just making LINK more like the rest of
 HTTP.


 My main concern is that if we put etags into *HTML* links, we're leaking
 protocol-level information into markup. I think it would be good if we could
 avoid that, and so far I haven't seen any use case that doesn't work
 without.


I don't see anyone realistically doing that either.

I'd be perfectly happy to split these out of the HTML-link to the HTTP-link.
 Maybe its time they be split up.

Mike



 Best regards, Julian

Re: [whatwg] Canvas API: What should happen if non-finite floats are used

2010-09-08 Thread Mike Shaver

On Wed, Sep 8, 2010 at 10:33 AM, Oliver Hunt oli...@apple.com wrote:
 In a lot of cases all you want to do is ignore NaN and Infinite values, 
 otherwise you basically have to prepend every call to canvas with NaN and 
 Infinity checks if you're computing values unless you can absolutely 
 guarantee your values won't have gone nuts at any point in the computation -- 
 otherwise you're going to get reports that occasionally your content breaks 
 but with no repro case (typical users will not be seeing error messages, it 
 just doesn't work).

Does this mean that you're expecting that the ignored calls didn't
matter?  Surely having parts of the drawing be missing will often be
noticed by users as well!

Mike

Re: [whatwg] Volume and Mute feedback on video

2010-08-20 Thread Mike Wilcox

On Aug 20, 2010, at 2:57 PM, Ian Hickson wrote:
 On Thu, 10 Jun 2010, Ashley Sheridan wrote:
 
 Or you could just raise the volume of the audio track itself. I think 
 being able to raise the volume like this (beyond 100% of what it is) 
 with script just makes it something more likely to be abused (think how 
 the TV adverts always seem twice as loud as the programs they surround) 
 and so will end up getting blocked more often.
 
 Yeah.

I highly disagree with limiting functionality from the standpoint that someone 
could do something that annoys us. Greater than 100% volume has a very solid 
use case. Setting a property to 1.5 is much easier than re-encoding a video.

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net

Re: [whatwg] Fullscreen feedback

2010-08-20 Thread Mike Wilcox

On Aug 20, 2010, at 3:24 PM, Ian Hickson wrote:
 By CSSOM, I mean a separate specification, specifically one from the 
 family of specifications that Anne is working on
 ...though my understanding is that Anne doesn't have the bandwidth to take 
 this on right now (this may be less of a problem if Robert's proposal can 
 just be taken wholesale, though).

RE: Fullscreen - I would be happy if the warning text was removed:
User agents should not provide a public API to cause videos to be shown 
full-screen.

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net

Re: [whatwg] Proposal: Add HTMLElement.innerText

innerText is one of those things IE got right, just like innerHTML. Let's 
please consider making that a standard instead of removing it. Also, please 
don't make the mistake of thinking it is the same thing as textContent. Think 
of textContent as pre-formatted text, and innerText as plain text. IE even 
correctly handles a span with display:block; and adds a line break.


Michael, good try, but I've been down that road; it's pretty hard to do. You 
left in the script text, spaces were missing, and there were no line breaks. 
You'd almost need an HTML parser. Take a list of tags like these: 
p span span em strong p script ul li span li span

You need to know where there are line breaks, or spaces, or neither. And that's 
without considering all the other block or HTML5 elements, or tables, etc. 
However, it's still not as easy as testing for whether the node is a block (or 
list-item, etc), because you then need to know if it is a block compared to the 
next and previous nodes; else a span in a p will get line breaks.

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net



On Aug 15, 2010, at 7:41 AM, Michael A. Puls II wrote:

 On Sat, 14 Aug 2010 20:03:30 -0400, Mike Wilcox m...@mikewilcox.net wrote:
 
 Wow, I was just thinking of proposing this myself a few days ago.
 
 In addition to Adam's comments, there is no standard, stable way of 
 *getting* the text from a series of nodes. textContent returns everything, 
 including tabs, white space, and even script content.
 
 Well, you can do stuff like this:
 
 --
 (function() {
function trim(s) {
return s.replace(/^\s\s*/, '').replace(/\s\s*$/, '');
}
function setInnerText(v) {
this.textContent = v;
}
function getInnerText() {
var iter = this.ownerDocument.createNodeIterator(this,
NodeFilter.SHOW_TEXT, null, null);
var ret = ;
var first = true;
for (var node; (node = iter.nextNode()); ) {
var fixed = trim(node.nodeValue.replace(/\r|\n|\t/g, ));
if (fixed.length  0) {
if (!first) {
ret +=  ;
}
ret += fixed;
first = false;
}
}
return ret;
}
HTMLElement.prototype.__defineGetter__('myInnerText', getInnerText);
HTMLElement.prototype.__defineSetter__('myInnerText', setInnerText);
 })();
 --
 
 and adjust how you handle spaces and build the string etc. as you see fit. 
 Then, it's just alert(el.myInnerText).
 
 NodeIterator's standard. __defineGetter/Setter__ is de-facto standard (and 
 you have Object.defineProperty as standard for those that support it). How 
 newlines and tabs and spaces are stripped/normalized just isn't standardized 
 in this case. But that might different depending on the application.
 
 Or, just run a regex on textContent.
 
 -- 
 Michael

Re: [whatwg] Proposal: Add HTMLElement.innerText

On Aug 15, 2010, at 6:26 PM, Jonas Sicking wrote:

 On Sun, Aug 15, 2010 at 11:17 AM, Mike Wilcox m...@mikewilcox.net wrote:
 innerText is one of those things IE got right, just like innerHTML. Let's 
 please consider making that a standard instead of removing it. Also, please 
 don't make the mistake of thinking it is the same thing as textContent. 
 Think of textContent as pre-formatted text, and innerText as plain text. IE 
 even correctly handles a span with display:block; and adds a line break.
 
 Whoa! That was new information to me. Does webkit also take CSS
 information into account?

Yes

 What happens with elements that have
 white-space:pre?

It maintains the formatting.

 What about display:none?

Does not show.

Safari and IE look to handle everything consistently.

 
 Is this really a feature that has interoperability?

Between what?

Mike

Re: [whatwg] Proposal: Add HTMLElement.innerText

On Aug 15, 2010, at 7:29 PM, Robert O'Callahan wrote:

 What about lists? Alt text in img?

It handles lists and the line breaks, but it doesn't indent.

Image attributes are ignored.

Mike

Re: [whatwg] Proposal: Add HTMLElement.innerText

On Aug 15, 2010, at 7:53 PM, Robert O'Callahan wrote:
 
 Tables?

TDs are inline and TRs act as line breaks.

 Is there any documentation for how the serialization works?

I'm just running the tests as you guys request them. I'm not sure if or how 
well this feature is spec'd out.

Mike

Re: [whatwg] Proposal: Add HTMLElement.innerText

2010-08-14 Thread Mike Wilcox

Wow, I was just thinking of proposing this myself a few days ago.

In addition to Adam's comments, there is no standard, stable way of *getting* 
the text from a series of nodes. textContent returns everything, including 
tabs, white space, and even script content.

BTW, I haven't checked, but I read that Opera's innerText implementation is 
essentially an alias of textContent.

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net



On Aug 14, 2010, at 5:39 PM, Adam Barth wrote:

 == Use Case ==
 
 It's common that a web page has a string of untrusted characters
 (e.g., received via cross-site XMLHttpRequest or postMessage) that it
 wishes to display to the user.  The page wants to display the string
 using a simple, secure API.
 
 == Workarounds ==
 
 Currently, the path of least resistance is to assign the string to
 HTMLElement.innerHTML.  However, that is insecure because the
 untrusted string can execute script via that API.
 
 It's possible to display the string securely using the following pattern:
 
 elmt.appendChild(document.createTextNode(untrusted_string));
 
 However, that pattern is more cumbersome than elmt.innerHTML =
 untrusted_string, so developers end up writing insecure code.
 
 == Proposal ==
 
 We should expose a property on HTMLElement similar to innerHTML called
 innerText.  When assigning a string to innerText, the string is placed
 in a text node (and is not parsed as HTML).
 
 == Deployment ==
 
 HTMLElement.innerText appears to be deployed in Internet Explorer,
 Chrome, Safari, and Opera.  However, the API is missing from Firefox
 and the HTML5 spec.  (Note the existing implementations of the API
 seem to do some work around newline normalization, which we should
 consider when adding the API to the specification.)
 
 Kind regards,
 Adam

Re: [whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)

2010-08-12 Thread Mike Wilcox

I'm perplexed at the resistance. We've tried telling our clients not to use 
IE6, IE8 is much faster. But inevitably, we have to make it work.

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net



On Aug 11, 2010, at 8:29 PM, Boris Zbarsky wrote:

 On 8/11/10 9:17 PM, Garrett Smith wrote:
 On 8/11/10, Boris Zbarskybzbar...@mit.edu  wrote:
 On 8/11/10 11:48 AM, Boris Zbarsky wrote:
 javascript:var start = new Date(); function f(n) { for (var k =
 n.firstChild; k; k = n.nextSibling) f(k); } f(document); alert(new
 Date() - start)
 
 Er, that had a typo.  The correct script is:
 
 javascript:var start = new Date(); function f(n) { for (var k =
 n.firstChild; k; k = k.nextSibling) f(k); } f(document); alert(new
 Date() - start);
 
 
 My result is 1012
 
 In what browser?  Firefox 3.6?  (And presumably on reasonably slow hardware, 
 if so.)
 
 If so, really do try 4.0 beta.  It's a good bit faster.
 
 It's also highly contrived example. When you start doing any DOM
 manipluation, particularly appending or removing nodes, you're going
 to notice a lot larger times.
 
 Well, sure, but you also won't be walking the entire DOM in JS like this.  
 The HTML5 spec scripts sure don't, last I checked.
 
 Now the numbers are slightly larger; on the order of 230ms to 350ms.
 Barely above human lag-perception.  This is on a several-years-old
 laptop as hardware.
 
 How do figure that's barely above human lag perception?
 
 The commonly accepted figure for when things start to feel laggy in UI terms 
 is 200ms.  If someone clicks and nothing happens for more than 200ms then 
 they perceive the response as slow.  Otherwise they generally perceive it as 
 pretty much instant.
 
 -Boris

Re: [whatwg] select element should have a required attribute

2010-08-10 Thread Mike Wilcox

This seems like the ideal situation to use a placeholder attribute:

select required=true placeholder=Select an item...
option value=Foo Foo /option
option value=Bar Bar /option
option value= None /option
/select 

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net

Re: [whatwg] HTML resource packages

2010-08-10 Thread Mike Belshe

On Mon, Aug 9, 2010 at 1:40 PM, Justin Lebar justin.le...@gmail.com wrote:

  Can you provide the content of the page which you used in your
 whitepaper?
  (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820)

 I'll post this to the bug when I get home tonight.  But your comments
 are astute -- the page I used is a pretty bad benchmark for a variety
 of reasons.  It sounds like you probably could hack up a much better
 one.

 a) Looks like pages were loaded exactly once, as per your notes?  How
  hard is it to run the tests long enough to get to a 95% confidence
 interval?

 Since I was running on a simulated network with no random parameters
 (e.g. no packet loss), there was very little variance in load time
 across runs.


I suspect you are right.  Still, it's good due diligence - especially for a
whitepaper :-)  The good news is that if it really is consistent, then it
should be easy...




 d) What did you do about subdomains in the test?  I assume your test
  loaded from one subdomain?

 That's correct.

  I'm betting time-to-paint goes through the roof with resource bundles:-)

 It does right now because we don't support incremental extraction,
 which is why I didn't bother measuring time-to-paint.  The hope is
 that with incremental extraction, we won't take too much of a hit.


Well, here is the crux then.

What should browsers optimize for?  Should we take performance features
which optimize for PLT or time-to-first-paint or something else?  I have
spent a *ton* of time trying to answer this question (as have many others),
and this is just a tough one to answer.

For now, I believe the Chrome/WebKit teams are in agreement that sacrificing
time-to-first render to decrease PLT is a bad idea.  I'm not sure what the
firefox philosophy here is?

One thing we can do to better evaluate features is to simply always measure
both metrics.  If both metrics get better, then it is a clear win.  But
without recording both metrics, we just don't really know how to evaluate if
a feature is good or bad.

Sorry to send you through more work - I am not trying to nix your feature
:-(  I think it is great you are taking the time to study all of this.

Mike







 -Justin

 On Mon, Aug 9, 2010 at 1:30 PM, Mike Belshe m...@belshe.com wrote:
  Justin -
  Can you provide the content of the page which you used in your
 whitepaper?
  (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820)
  I have a few concerns about the benchmark:
 a) Looks like pages were loaded exactly once, as per your notes?  How
  hard is it to run the tests long enough to get to a 95% confidence
 interval?
 b) As you note in the report, slow start will kill you.  I've verified
  this so many times it makes me sick.  If you try more combinations, I
  believe you'll see this.
 c) The 1.3MB of subresources in a single bundle seems unrealistic to
 me.
   On one hand you say that its similar to CNN, but note that CNN has
  JS/CSS/images, not just thumbnails like your test.  Further, note that
 CNN
  pulls these resources from multiple domains; combining them into one
 domain
  may work, but certainly makes the test content very different from CNN.
  So
  the claim that it is somehow representative seems incorrect.   For more
  accurate data on what websites look like,
  see http://code.google.com/speed/articles/web-metrics.html
 d) What did you do about subdomains in the test?  I assume your test
  loaded from one subdomain?
 e) There is more to a browser than page-load-time.
  Time-to-first-paint
  is critical as well.  For instance, in WebKit and Chrome, we have
 specific
  heuristics which optimize for time-to-render instead of total page load.
   CNN is always cited as a bad page, but it's really not - it just has a
  lot of content, both below and above the fold.  When the user can
 interact
  with the page successfully, the user is happy.  In other words, I know I
 can
  make webkit's PLT much faster by removing a couple of throttles.  But I
 also
  know that doing so worsens the user experience by delaying the time to
 first
  paint.  So - is it possible to measure both times?  I'm betting
  time-to-paint goes through the roof with resource bundles:-)
  If you provide the content, I'll try to run some tests.  It will take a
 few
  days.
  Mike
 
  On Mon, Aug 9, 2010 at 9:52 AM, Justin Lebar justin.le...@gmail.com
 wrote:
 
  On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor 
  simetrical+...@gmail.comsimetrical%2b...@gmail.com
 
  wrote:
   If UAs can assume that files with the same path
   are the same regardless of whether they came from a resource package
   or which, and they have all but a couple of the files cached, they
   could request those directly instead of from the resource package,
   even if a resource package is specified.
 
  These kinds of heuristics are far beyond the scope of resource
  packages as we're planning to implement them.  Again, I think this
  type of behavior

Re: [whatwg] Feedback on the Mozilla FullScreen API proposal

2010-08-06 Thread Mike Wilcox

Kudos to Mozilla (and Robert?). This is awesome. It does appear that you plan 
to allow fullscreen without the use of a user-trigggered event such as a 
button-click like Flash does. Not only would I like to launch my app in 
fullscreen to play a game, I may want to allow my advertisers to launch 
fullscreen videos for a premium fee. I think this is a good thing. It's 
important to keep restriction versatile so that both the user and developer are 
in control. As opposed to too much security completely killing the feature and 
force developers to continue to rely upon Flash.


First a small thing. The format of the CSS style:
:full-screen
:full-screen-root-with-target
I don't see why fullscreen should be hyphenated. Even the title of the page 
uses it as one word.


I don't understand the use of requestFullScreenWithKeys(). Why would I ever use 
a more restrictive method? How about just fullscreen() - and it toggles? And 
security is handled through element attributes?


I assume the entire reason for security is for third party apps (video) and 
advertisements (have I missed an actor?). It seems to me that I would want to 
prevent a third party from calling fullscreen. The spec makes it look like its 
up to the developer on whether to use the security or not. Did I read it wrong? 
The spec focuses a lot on iframes. It's fine to restrict functionality in an 
iframe, but a majority of third party apps and advertisements don't happen in 
an iframe, they are written to the page, often with document.write – and they 
often write their own iframe. The iframe restriction will work for scenarios 
such as an HTML5 Video embed, but not for ads.

Here are some suggested constants. The actual spelling or exact usage is not 
relevant, I'm addressing functionality (I agree with Anne on constants in JS). 
I'm looking at these suggestions mostly from the POV of a web developer, not a 
user nor user agent.

The first, simple use case I'm looking to solve is to block your ads from using 
fullscreen. I don't see a way to do that in the spec. I recommend the above 
options are properties of the document.body:
body allowFullscreen=blocked

Note however, that I recommend that allowFullscreen=block be the default, so 
ads can't start launching fullscreen in existing, unmaintained pages.


The second simple scenario is to use fullscreen but you don't need to worry 
about ads:
body allowFullscreen=allow


The third scenario gets more tricky, and is why I am suggesting using the 
properties as node attributes. Think about the NY Times wanting to allow 
fullscreen to read the article but block ads (or certain ads) from fullscreen:
body allowFullscreen=blocked
article allowFullscreen=allow
aside allowFullscreen=blocked

The suggestion is that fullscreen permissions are on the element level and are 
inherited. Further, they should be only writable in HTML markup, and read-only 
in JavaScript so permissions cannot be dynamically changed.

A potential problem is a rouge third party script scanning the page to find the 
article element allows fullscreen; and it writes content to it and launches it. 
The solution could be that allowFullscreen is NOT readable by JavaScript – it 
can only discover permissions by the attempt to go fullscreen.  

A modification to this would be a write-once apiKey that is private:

head
scrpt
document.setFullscreenApiKey(mysecret); // set only once, subsequent 
calls ignored, cannot be read
onClick = function(){
requestFullScreen(mysecret); 
}
/scrpt
body allowFullscreen=password

I think this idea is clever, but I may be over thinking it. 
allowFullscreen=userIntiated,mouseOnly is probably all that is needed in this 
case (and perhaps most cases).


Of course, nothing is 100% secure, and since this is the list that said DRM is 
impossible, I'm really advocating that we don't try for 100% safety and cripple 
the feature. 


Mike Wilcox
http://clubajax.org
m...@mikewilcox.net



On Aug 5, 2010, at 5:17 PM, Simon Fraser wrote:

 This is feedback on the Mozilla FullScreen API proposal here:
 https://wiki.mozilla.org/index.php?title=Gecko:FullScreenAPI

Re: [whatwg] Feedback on the Mozilla FullScreen API proposal

2010-08-06 Thread Mike Wilcox


On Aug 5, 2010, at 9:24 PM, Robert O'Callahan wrote:
 
 It's probably worth having such an event, but there will be times when 
 neither fullscreendenied or fullscreenchanged are fired. I hope authors don't 
 write apps that break in such cases.

We definitely need some sort of event to indicate if fullscreen was successful 
or not – not so that our apps don't break, but so we can notify the user of 
failed functionality. Even a status property is insufficient as it will force 
us to use a setInterval which seems hacky. And preferably, it would be good to 
know the reason for the denial:

onFullscreenDenied = function(status){
if(status==blocked by browser){
alert(You need to change your browser's settings to use 
fullscreen mode.);
}else if(status==blocked by page){
disableMyFullScreenButton();
alert(Sorry, fullscreen is not available.);
}
}


Regarding fullscreen elements: I appreciate the initiative, but I wonder if 
it's necessary to allow fullscreen at the element level? I think Simon is 
already pointing out potential gotchas. What exactly is the difference between 
a fullscreen-element and a fullscreen-page that has an element in absolutely 
position, top z-index, at 100% width and height? As a developer, after entering 
fullscreen I could possibly do a fancy transition of the element to take up 
100%. I have to assume this is what the UA would be doing in the background 
anyway in order to keep the proper x/y coordinates.


Mike Wilcox

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

2010-07-30 Thread Mike Shaver

On Fri, Jul 30, 2010 at 12:43 AM, Oliver Hunt oli...@apple.com wrote:
 The various html collections aren't fixed length, they're not assignable, so 
 they can't used interchangeably with arrays at the best of times.

Array generics work on arrays that aren't fixed-length, perhaps
obviously, and I believe they're still valid over arrays which have
had their indexed properties configured to be unwritable as well.  As
your later example shows, they can be used interchangeably with arrays
at exactly the best of times: when wanting to apply a non-mutating
extra to one!

We've got the array statics in Firefox (Array.forEach, etc.) and it's
made the make-collections-be-arrays cries from those working on
front-end JS subside dramatically.  I think they would probably solve
the problem quite effectively, and not require us to be on the lookout
for naming collisions between future Array.prototype and
HTMLCollection fields.

Mike

Re: [whatwg] Please disallow javascript: URLs in browser address bars

2010-07-22 Thread Mike Shaver

On Thu, Jul 22, 2010 at 4:48 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 These days, though, all major browsers have javascript consoles which
 you can bring up and paste that into.

That doesn't typically apply to content tabs or windows, though.

I have a couple of questions:

What is the proposed change to which specification, exactly?  URL-bar
behaviour, especially input permission, seem out of scope for the
specs that the WHATWG is working on.  Would a UA that asked for the
user's permission the first time a bookmarklet is used (like some
prompt the first time a given helper app or URL scheme is used) be
compliant?

What should the URL bar say when the user clicks a javascript: link
which produces content?  a href=javascript:5;five!/a

Mike

Re: [whatwg] Please disallow javascript: URLs in browser address bars

2010-07-22 Thread Mike Shaver

On Thu, Jul 22, 2010 at 5:32 PM, Luke Hutchison luke.hu...@mit.edu wrote:
 On Thu, Jul 22, 2010 at 5:03 PM, Mike Shaver mike.sha...@gmail.com wrote:
 What is the proposed change to which specification, exactly?  URL-bar
 behaviour, especially input permission, seem out of scope for the
 specs that the WHATWG is working on.

 Is there a better venue to discuss this then?  (It seems like even if
 UI issues are out of the scope of what WHATWG is working on, all the
 right people are signed up to this list...)

I'm not sure of a better venue off-hand.  I don't think that there's
anyone from Microsoft participating in this list, though, and I expect
that a lot of the users affected by the Facebook viruses are using
their browser.

 Would a UA that asked for the
 user's permission the first time a bookmarklet is used (like some
 prompt the first time a given helper app or URL scheme is used) be
 compliant?

 You mean like Windows User Account Control? ;)

No, I mean like the prompts for geolocation, popup windows, first-use
helper applications, first-use URL protocols, and similar.  But my
question is more about what you propose to disallow, and why you
choose disable as the requirement.

 It's not unreasonable to guess that the number of people
 inconvenienced by the easy exploitability of the current behavior
 numbers in the millions, given that Facebook has 500M users and these
 viruses continue to spread like wildfire.  The number inconvenienced
 by having these URLs disabled by default (and re-enableable via a
 developer option the first time they hit this limitation)

That is only helpful against the specific case of direct paste in the
URL bar, though, and bookmarklets aren't just a developer-only
feature.  They're widely used by URL-shortening services, blogging and
micro-blogging services, and Amazon's universal wish list.

 Given the success of these exploits so far, it is also reasonable to
 suggest that the sophistication of attack will only increase with
 time.

Yes, which I think is why so many of us are suggesting that making the
social engineer say drag this link to your bookmark bar, and use it
when you Really Like something! is not going to be much of a
mitigation.

It's not that I don't believe it's a problem, to be clear; it's that I
don't think you're proposing a meaningful solution to it!

Mike

Re: [whatwg] video application/octet-stream

On Wed, Jul 21, 2010 at 9:10 AM, Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net wrote:
 (clients try to guess based on
 incorrect information and you end up with stupid switches).

Could you be more specific about the incorrect information?  My
understanding, from this thread and elsewhere, is that video formats
are reliably sniffable, and furthermore that the appropriate MIME type
for ogg-with-VP8 vs ogg-with-theora isn't clear (or possibly even
extant).  It seems like reliance on MIME type will result in more of
the guessing-and-stupid-switches than sniffing.

Mike

Re: [whatwg] video application/octet-stream

On Wed, Jul 21, 2010 at 9:43 AM, Nils Dagsson Moskopp
nils-dagsson-mosk...@dieweltistgarnichtso.net wrote:
 Mike Shaver mike.sha...@gmail.com schrieb am Wed, 21 Jul 2010
 09:15:18 -0400:
 and furthermore that the appropriate MIME type
 for ogg-with-VP8 vs ogg-with-theora isn't clear (or possibly even
 extant).

 According to RFC4281 http://www.rfc-editor.org/rfc/rfc4281.txt,there
 is an optional codecs parameter for container file formats.

Does that work in practice?  How can one configure, f.e., Apache to
send the right type for foo.ogv ?

Dave Singer is on this list, and is one of the authors of that RFC, so
perhaps he can tell us: has the codecs parameter from RFC4281 worked
in practice for Apple?  Could you describe where it's used, and how
it's typically configured?

 It seems like reliance on MIME type will result in more of
 the guessing-and-stupid-switches than sniffing.

 Because they still might be wrong?

From what I can see of how they are used on the web today, MIME types
are less precise than the determination made by sniffing within the
container, yes.

Mike

Re: [whatwg] video application/octet-stream

On Wed, Jul 21, 2010 at 9:46 AM, Chris Double chris.dou...@double.co.nz wrote:
 How much data are you willing to sniff to find out if the Ogg file
 contains Theora and/or Vorbis? You have to read the header packets
 contained within the Ogg file to get this.

A few kilobytes certainly seems reasonable -- I don't think we can
actually do anything with the video until we've made that
determination, so I'm actually quite sure what's being asked.  Can you
describe a scenario where Firefox would have a reliable MIME type, but
isn't retrieving the first chunk of the video anyway?  Do browsers use
HEAD to check for video compatibility today?

Mike

Re: [whatwg] video application/octet-stream

On Wed, Jul 21, 2010 at 9:51 AM, Philip Jägenstedt phil...@opera.com wrote:
 On Wed, 21 Jul 2010 15:15:18 +0200, Mike Shaver mike.sha...@gmail.com
 wrote:
 Could you be more specific about the incorrect information?  My
 understanding, from this thread and elsewhere, is that video formats
 are reliably sniffable, and furthermore that the appropriate MIME type
 for ogg-with-VP8 vs ogg-with-theora isn't clear (or possibly even
 extant).  It seems like reliance on MIME type will result in more of
 the guessing-and-stupid-switches than sniffing.

 The MIME type for both of those would be video/ogg. It wouldn't be hard or
 very error-prone to use only the MIME type, Firefox already does that. It's
 also not very hard to rely on sniffing, which all the other browsers do,
 although Opera still checks the MIME type first.

Indeed, so it seems that sniffing is always required, unless we expect
reliable use of the codecs parameter to become widespread.  (I
confess that I do not expect this, even if this group and the W3C
exhort authors to do so.)

 * Configuring the MIME type is an extra step that seemingly many authors
 don't know that they need. That it is easy to configure doesn't really help.

It may or may not be easy to configure the MIME type correctly, if we
are to include codec details.

 * Ignoring the MIME type will lead to more videos served as text/plain,
 which will render as huge amounts of garbage text in current browsers if
 opened directly (i.e. in a top-level browsing context).

Ignoring the MIME type *and* not sniffing those cases, you mean?

Mike

Re: [whatwg] video application/octet-stream

On Wed, Jul 21, 2010 at 10:04 AM, Philip Jägenstedt phil...@opera.com wrote:
 Right, sniffing is currently only done in the context of video, at least
 in Opera. The problem could be fixed by adding more sniffing, certainly.

A warning that you're about to open a 5MB text document might be
humane anyway. :-)

Mike

Re: [whatwg] video application/octet-stream

On Wed, Jul 21, 2010 at 10:07 AM, Chris Double
chris.dou...@double.co.nz wrote:
 When content sniffing are we ignoring the mime type served by the
 server and always sniffing? If so then incorrectly configured servers
 can result in more downloaded data due to having to read the data
 looking for a valid video. For example:

 video
  source src='foo.ogg'
  source src='foo.mkv'
 /video

 If the web browser doesn't support Ogg but does support matroska, and
 the server sends the video/ogg content type,  the browser can stop and
 go to the next source after downloading very little data.

 If the web browser is expected to ignore the mime type and content
 sniff it must see if 'foo.ogg' is a matroska file. According to the
 matroska spec arbitary ASCII data can be placed before the EBML
 identifier. This means reading a possible large amount of data (even
 the entire file) before being able to say that it's not a matroska
 file.

Assuming that such a browser were to exist, and that such content were
to exist (an Ogg file that did not contain any characters outside of
0x20-0x7F in the first few kilobytes), and that it were to be a
problem for that browser's users, I would probably suggest that the
developers of said browser implement basic Ogg support (enough to say
this is Ogg, so we don't support it), and go back to solving more
pressing problems!

Mike

Re: [whatwg] video application/octet-stream

On Wed, Jul 21, 2010 at 10:24 AM, Chris Double
chris.dou...@double.co.nz wrote:
 On Thu, Jul 22, 2010 at 2:15 AM, Mike Shaver mike.sha...@gmail.com wrote:
 ...I would probably suggest that the
 developers of said browser implement basic Ogg support (enough to say
 this is Ogg, so we don't support it), and go back to solving more
 pressing problems!

 Or the developers of said browser could obey the mime type that the
 server sent,

My understanding is that this isn't working out so well for us.

Mike

Re: [whatwg] Canvas stroke alignment

2010-07-19 Thread Mike Wilcox

Wow, that would be so enormously useful. You make a shape, add a shape inside 
of it that is 100x100, add a stroke, get the width and it's 101. This error 
cascades, and shifts your items around on redraw. The math workaround is not 
easy.

FWIW, Photoshop uses position for this option (I don't believe Flash supports 
this).
I don't think the CSS3 box-sizing:border-box helps.

Does voting count? +1!


Mike Wilcox
http://clubajax.org
m...@mikewilcox.net



On Jul 19, 2010, at 10:08 AM, Nick wrote:

 Canvas would benefit from a way to set stroke alignment. With the only 
 available alignment being center, which is not very useful, custom paths have 
 to be drawn to mimic inside and outside stroke alignment. That workaround may 
 give unwanted transparency on pixels between a path and its stroke path once 
 a path goes diagonal or curves.
 
 Having Canvas take care of stroke alignment (center, inside and outside) by 
 adding something like strokeAlign can fix these transparency problems and 
 makes adding strokes a lot easier and more useful.
 
 --
 Nick Stakenburg

Re: [whatwg] Article: Growing pains afflict HTML5 standardization

2010-07-12 Thread Mike Wilcox

On Jul 12, 2010, at 2:30 AM, Julian Reschke wrote:
 Google: 
 http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.comcharset=%28detect+automatically%29doctype=Inlinegroup=0
  - 35 errors

That's a little different. Google purposely uses unstandardized, incorrect HTML 
in ways that still render in a browser in order to make it more difficult for 
screen scrapers. They also break it in a different way every week.

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net

Re: [whatwg] Article: Growing pains afflict HTML5 standardization

2010-07-12 Thread Mike Wilcox

On Jul 12, 2010, at 7:58 AM, Julian Reschke wrote:

On 12.07.2010 14:44, Mike Wilcox wrote:
On Jul 12, 2010, at 2:30 AM, Julian Reschke wrote:
Google:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.comcharset=%28detect+automatically%29doctype=Inlinegroup=0
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.comcharset=%28detect+automatically%29doctype=Inlinegroup=0
- 35 errors

That's a little different. Google purposely uses unstandardized,
incorrect HTML in ways that still render in a browser in order to make
it more difficult for screen scrapers. They also break it in a
different way every week.

How exactly is it different?

Do you think that what Google does somehow is better?

Just asking.

Not better... on purpose. Proactive sabotage if you will.

As far as I can tell, it just shows that content providers continue to send
whatever happens to work, thus are not concerned at all about validity (note:
there's a permathread about this as well -- why disallow things that are
known the work reliably...).

I agree, and some pages I've seen and used makes my head want to burst. Clients
will tell me Don't give us code that slows down our page! and I look at their
code and I think Really?

In defense of CNET, I looked at the source code and it's not the worst markup
I've seen. I looked at the validation errors again, and a vast amount of them
are caused by ad services and social network plugins.

That's still a problem (also one to burst my head), but a different problem.

Mike

Re: [whatwg] Article: Growing pains afflict HTML5 standardization

2010-07-12 Thread Mike Wilcox

On Jul 12, 2010, at 8:39 AM, Nils Dagsson Moskopp wrote:

That's a little different. Google purposely uses unstandardized,
incorrect HTML in ways that still render in a browser in order to
make it more difficult for screen scrapers. They also break it in a
different way every week.

Assuming this is true (which I find difficult to believe), wouldn't a
screen scraper based on the HTML5 parsing algorithm defeat this
purpose ?

Honestly, I don't know. But W3 defaulted to an HTML5 validator:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.google.com%2Fsearch%3Fsource%3Dig%26hl%3Den%26rlz%3D%26%3D%26q%3Dhtml5%26aq%3Df%26aqi%3D%26aql%3D%26oq%3D%26gs_rfai%3Dcharset=%28detect+automatically%29doctype=Inlinegroup=0

On Jul 12, 2010, at 7:55 AM, Julian Reschke wrote:

Any evidence for this? And how do you know the reason for CNET isn't the same?

VERY unconvinced.

Such skepticism! I really didn't expect that I said anything controversial. We
all know Google is a black box, and I don't, nor have I ever worked for them,
so I can't testify that what I say is a fact...

Google does not publish a full API for their search results in spite of the
fact that they publish most everything else. That's because their search
results / API is their golden egg – they can't give that away. And they need to
protect it. I've tried scraping results with YQL and it failed. I made other
attempts that had more success only to find they did not work a week later.

Studying the validation results more closely however does not back up my
original statement – the markup does look as I described, but the things I
expected to break the validator are not what I expected. The things I had in
mind was for the most part unclosed tags, which I didn't know validated. I knew
they were allowed, but thought the validator would complain.

Besides the protecting of their API, Google also will scratch and claw to save
every byte. They are the gold standard of a high performance website. While
this may or may not explain the things that don't validate, what it does say is
that nothing coming from google.com is accidental.

Mike

Re: [whatwg] More YouTube response

2010-07-05 Thread Mike Wilcox

It's the iPhone and especially the iPad which has really pushed the adoption of 
HTML5 video. And afaik, you can't install WebM on them. To me (and my company) 
that's where the issue lies.

Mike Wilcox
http://clubajax.org
m...@mikewilcox.net



On Jul 5, 2010, at 3:46 PM, Shane Fagan wrote:

 Internet Explorer 9 will not support VP8 unless the user manually
 installs the codec.  This puts it at the same level of support as
 Safari has for Theora, as far as I know.  So even if we assume every
 user upgraded to the latest alphas of the browser they used, H.264 is
 supported by about 65% of users' browsers, and VP8 by about 40%.  Of
 course, in reality, less than half of users' browsers support video
 at all right now, and given IE uptake rates, that's only going to
 change slowly.
 
 For windows maybe there should be a .exe/.msi with the entire package of
 VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install but
 adoption isnt really our issue thats Microsoft's issue if WebM takes
 off. I dont foresee it being any harder than Adobe Flash to install for
 the regular user so websites could just direct users to the download if
 they dont have it already.
 
 Oh and IE is dropping in use according to the media over the past 3
 months ever since the browser selection screen came so its becoming less
 of an issue in time. 
 
 --fagan

Re: [whatwg] Allowing in attribute values

One advantage is almost the same as your footnote: JavaScript source is
permitted in the values of many attributes, and can certainly contain the 
operator.

On Jun 25, 2010 12:34 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu
wrote:
 On 06/25/2010 11:50 AM, Boris Zbarsky wrote:
 It seems like what you want here is for browsers to parse as they do
 now, but a particular subset of browser-accepted syntax to be enshrined
 so that when defining your restrictions over content you control you can
 just say follow the spec instead of follow the spec and don't put ''
 in attribute values, right?

 That's more or less how I feel. The spec places requirements on how user
 agents, data mining tools, and conformance checkers must handle
 non-conforming input, but there are many other things in the world that
 process HTML. In other applications, it may be acceptable to have
 undefined behavior on non-conforming input, like in ISO C.

 HTML5 has a very clear specification of conformance, and a validator is
 widely available. If I build a tool that guarantees correct behavior only
 on conforming inputs, then users can easily check their documents for
 conformance before using my tool. If my tool has additional restrictions,
 then I need to write my own validator, and answer a lot of questions.

 I was inspired to suggest this restriction after using mod_layout for
 Apache, which inserts a banner at the top of a page. It works by doing a
 wildcard search for body*. There are a number of obvious ways to
 break this [1]; one of them is by having  in an attribute value. I'm
 sure there are many thousands of such programs around the world.

 It sounds like most experts here would prefer to allow  in attribute
 values in conforming documents, and that's fine. I don't fully understand
 the advantage, but I won't argue against consensus.

 --Ben

 [1] A javascript line like widthbodywidth  heightbodyheight would
 also break it, as would an appropriately constructed comment. It might be
 possible to construct a regexp for this that functions correctly on all
 conformant HTML5 documents. Such a regexp would be considerably simpler
 if  were disallowed in attribute values.

Re: [whatwg] input type=location proposals

On Thu, Jun 24, 2010 at 5:55 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:
 I think it's quite a fringe case. What about things that are more used:

 type=number - a browser could aid input with some sort of spinner
 type=price - a browser could use the locale to select a monetary format, or 
 at least display the amount in the locale format specified by the document 
 itself

I think that most users are able to input a number or price without
much difficulty.  Asking a user to input their latitude and longitude
is a great way to bounce them entirely, since none of them are going
to have any idea how to find it out.

Mike

Re: [whatwg] Technical Parity with W3C HTML Spec

On Fri, Jun 25, 2010 at 9:11 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 The WHATWG has a steering council made up of browser developers.
 Officially, they can override Ian's decisions or make him step down as
 editor.  They've never had to exercise this power yet, though.

Could you elaborate on this?  That *anyone* can override Ian's
decisions or make him step down as editor is news to me, and I suspect
that the organization I represent is counted among the developers you
list.  Who is on the steering council of browser developers?  How does
one appeal a decision to them, and how do they determine what to do
(unanimity, majority vote, rotating single-person veto, five-card
draw)?

Mike

Re: [whatwg] Technical Parity with W3C HTML Spec

On Fri, Jun 25, 2010 at 1:51 PM, Ian Hickson i...@hixie.ch wrote:
 I value technical merit even higher than convergence.

How is technical merit assessed?  Removing Theora from the
specification, for example, seems like it was for political rather
than technical reasons, if I understand how you use the terms.  How
can one learn of the technical motivations of decisions such as the
change to require ImageData for Canvas, or participate in their
evaluation prior to them gaining the incumbent's advantage of being
present in the specification text?

Mike

Re: [whatwg] input type=location proposals

On Fri, Jun 25, 2010 at 2:45 PM, Ashley Sheridan
a...@ashleysheridan.co.uk wrote:

 On Fri, 2010-06-25 at 17:09 -0400, Aryeh Gregor wrote:
  type=number has been in the spec for years.

 Do you have a link to this to verify?

http://dev.w3.org/html5/markup/input.number.html is the fourth hit for
type=number in Google for me, but your search engine results results
may vary.

It's also under the input element, type values, number part of the
WHATWG's HTML5 draft, a document with which you may have some
familiarity.

Mike

Re: [whatwg] Technical Parity with W3C HTML Spec

On Fri, Jun 25, 2010 at 3:00 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Bottom of the charter: http://www.whatwg.org/charter

 I believe the decision process is knife fight to first blood.

Editors should reflect the consensus opinion of the working group
when writing their specifications, but it is the document editor's
responsibility to break deadlocks when the working group cannot come
to an agreement on an issue doesn't sound like the working group can
override anything, and only goes as far as should.

It turns out that two of the Members are in the same building as me,
though, so I'll go see what they think the model is.  I think they may
be surprised to discover that they could have overridden Ian on
anything!

Mike

Re: [whatwg] Technical Parity with W3C HTML Spec

On Fri, Jun 25, 2010 at 3:07 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 How
 can one learn of the technical motivations of decisions such as the
 change to require ImageData for Canvas,

 On the WHATWG wiki a Rationale page is being assembled by a volunteer
 (don't know their name, but they go by 'variable' in #whatwg) to
 document the reasoning behind various decisions that come up in
 questions.  Beyond that, mailing-list diving.

In the case of the ImageData change, I can't find any proposal made to
the list prior to the spec being altered, but I will dive anew.

 There can
 sometimes be a significant delay between something being proposed and
 this happening, though, so within that timespan things can be
 discussed without the incumbent advantage you talk about.

That only works if changes are proposed via the mailing list, and it
relies on meaningful delay.  If my recollection of the original
additions of SQL databases and web workers is correct, there was very
little such delay, certainly relative to the scale of content.

Are you describing how you think the WHATWG has committed to work, how
it does work, or how you think it should work?

Mike

Re: [whatwg] Technical Parity with W3C HTML Spec

On Fri, Jun 25, 2010 at 3:09 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 I wasn't precise in my language - don't read too much into my exact wording.

No, certainly; I'm much more interested in the spirit here than the
wording, since it doesn't match my experience or understanding.  I'll
take on my education burden myself, though!

Mike

Re: [whatwg] Technical Parity with W3C HTML Spec

On Fri, Jun 25, 2010 at 3:30 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
 I'm pretty sure they won't be.  Any significant implementer has always
 had veto power over the spec.

I fear that simply refusing to implement is indeed the WHATWG's
equivalent of how Tab described FO-threats in the W3C environment: a
much more efficient way to influence the direction of the document
than sharing technical reasoning during the design of a capability.

 For example, Mozilla vetoed Web
 Databases, and Apple vetoed Theora requirements, by just saying they
 wouldn't implement them.

Web Databases was removed from the specification before we were even
certain within Mozilla that we wouldn't implement them, so I don't
think that's quite right.  It's true that we don't think it's a good
technology direction for the web, and that we didn't believe it
belonged in HTML5 proper, but I don't think that's quite the same
thing.  (To the extent that Mozilla has unanimity on such things in
the first place.)

 Ian has always made it clear that he'll spec
 whatever the implementers are happy with.

That is not my recollection of what happened with offline, for what
it's worth. Mozilla and Google had a relatively small set of
deviations between approaches (ours developed on the whatwg list and
Google's developed behind closed doors prior to the Gears
announcement) and Ian specified an entirely different model, over the
objections of both Mozilla and Google.  I welcome corrections to the
timeline and details here, but apparently the behaviour that we
*should* have exhibited was simply refusing to implement, rather than
changing late in our development cycle to the new specification that
Ian constructed, for which there was no implementation or deployment
experience.

Is that really how we want the group to operate?  It seems to reward
silent refusal with greater influence than transparent reasoning.  We
saw similarly (IMO) offensive behaviour when IBM voted against the ES5
specification at ECMA General Assembly, simply because their pet
feature hadn't been included (though there was ample technical
justification for its omission, both in closed-door membership
meetings and in the public list).  Happily, in that case it simply
made IBM look manipulative and petty, and didn't prevent the
specification from reaching ratification.

If I were to be in charge of an organization building a platform that
competed with the web, I would certainly consider it worth my time to
implement a browser and then refuse to implement pieces of the
specification that competed with my line of business.  Certainly if I
were running an organization that made a browser and had a line of
business threatened by a piece of the specification, it would be very
clear how to mitigate that threat, since no specifics need be provided
in support of a refusal veto.

Mike

Re: [whatwg] Technical Parity with W3C HTML Spec