date:20110104

On Mon, 3 Jan 2011, Glenn Maynard wrote:

 By the way, the WebSRT hit from Google 
 (http://www.whatwg.org/specs/web-apps/current-work/websrt.html) is 404.  
 I've had to read it out of the Google cache, since I'm not sure where it 
 went.

Oops. I thought I'd set up a redirect but I flubbed the syntax and forgot 
to check it. Fixed. Thanks.

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

Re: [whatwg] Timed tracks: feedback compendium

2011-01-04 Thread Alex Bishop


On 03/01/2011 15:57, Philip Jägenstedt wrote:

There was also some discussion about metadata. Language is sometimes
necessary for the font engine to pick the right glyph.


Could you elaborate on this? My assumption was that we'd just use CSS,
which doesn't rely on language for this.


It's not in any spec that I'm aware of, but some browsers (including
Opera) pick different glyphs depending on the language of the text,
which really helps when rendering CJK when you have several CJK fonts on
the system. Browsers will already know the language from track
srclang, so this would be for external players.


Firefox too. If you visit 
http://people.mozilla.org/~jdaggett/webfonts/serbianglyphs.html in 
Firefox 4, the text explicitly marked-up as being Serbian Cyrillic 
(using the lang=sr-Cyrl attribute) uses some different glyphs to the 
text with no language metadata.


Alex

--
Alex Bishop
alexbis...@gmail.com

Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property - Drawing model discussion

2011-01-04 Thread carol.szabo

Please see my in-line comments below:

From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of ext 
Robert O'Callahan
Sent: Monday, January 03, 2011 5:56 PM
To: Szabo Carol (Nokia-MS/Boston)
Cc: ch...@jumis.com; wha...@whatwg.org
Subject: Re: [whatwg] Fwd: RE: Inconsistent behaviour of 
globalCompositeOperation property

HTML5 - Canvas.

I have read this thread (from and of July 2010) and I happen to agree that the 
Safari/Chromium implementation is more intuitive, and likely less expensive to 
implement, therefore I offer these 2 proposals for changing the spec's Drawing 
model section to match what I perceive to be the preference of most people in 
that discussion.

Of note: According to the current Drawing model, an opaque shape's shadow would 
be erased as part of step 6 when drawn with source-in composite Mode if 
globalAlpha is 1, which is probably not the intended behavior.

Version 1:

4.8.11.1.13 Drawing model

When a shape or image is painted, user agents must follow these steps, in the 
order given (or act as if they do):

1. Render the shape or image onto an infinite transparent black bitmap, 
creating image M1, as described in the previous sections except that for the 
purpose of this step every pixel of the image will be considered to be fully 
opaque white and the current fillStyle will be considered to be solid fully 
opaque white and the strokeStyle will be considered fullyOpaque white as well

2. When shadows are drawn, render the shadow from image M1, using a fully 
opaque white shadow color as described in the shadows section, creating image 
M2.

3. Let C1 be a region obtained by intersecting the canvas's cliping region with 
the set of pixels in the canvas that correspond to pixels in M1 (by having the 
same coordinates) that are not fully transparent.

4. Let C2 be a region obtained by intersecting the canvas's cliping region with 
the set of pixels in the canvas that correspond to pixels in M2 (by having the 
same coordinates) that are not fully transparent.

5. Render the shape or image onto an infinite transparent black bitmap, 
creating image A, as described in the previous sections. For shapes, the 
current fill, stroke, and line styles must be honored, and the stroke must 
itself also be subjected to the current transformation matrix.

6. When shadows are drawn, render the shadow from image A, using the current 
shadow styles, creating image B.

7. When shadows are drawn, multiply the alpha component of every pixel in B by 
globalAlpha.

8. When shadows are drawn, composite B with the current canvas bitmap, cliping 
results to region C2 defined above, using the current composition operator.

9. Multiply the alpha component of every pixel in A by globalAlpha.

10. Composite A with the current canvas bitmap, cliping results to region C1 
defined above, using the current composition operator.

Making a binary fully-transparent/not-fully-transparent per-pixel decision to 
create regions C1 and C2 seems like it can't be right in the presence of 
antialiasing.

Suppose we have a path filled with black and operator copy. Any pixel on the 
edge of that path that gets any nonzero coverage value from antialiasing will 
end up solid black with this proposal. That's going to look very ugly. We'll 
want a solution where any canvas pixel which has a very small amount of 
coverage by the path will be mostly unchanged in the final result.

I do not understand why pixels touched by antialiasing are going to be solid 
black.
The way I understand antialiasing (and maybe I am wrong), pixels that are 
partly touched retained partly their old color and transparency and get parly 
the new color and transparency. More precisely the resulting transparency and 
color components an average of the color component being painted and the 
previous color component weighted by the coverage fraction of the pixel. Hence 
partially covered pixels are partially transparent, thus the background behind 
the canvas should shine through and the partially covered pixels won't be 
entirely black unless that background is black as well. I agree with you though 
that there are cases when inappropriately using globalCompositeOperation can 
yield ugly and perhaps surprising results, such as in the case you described if 
the canvas is completely red before the operation and it is put on a page that 
has green background, thus the shape will acquire an unexpected slightly green 
rim between black and red.
I still believe that this behavior as ugly as it may be in some cases, is still 
preferable to not being able to do shadows when using the copy operation (as 
results from the standard's current language), is more intuitive and less 
resource intensive (to me the less resource intensive is the most important 
part).

Version 2:

4.8.11.1.13 Drawing model

When a shape or image is painted, user agents must follow these steps, in the 
order given (or act as if they do):

Re: [whatwg] Device Element


On 1/4/11 5:48 AM, Diogo Resende wrote:

Flash is insecure because there's no security policies. It's similiar to
the firefox feature to read files: you read all or you read none. That's
not a good policy. Something similar to the geolocation would be better
(this specific site/app can access this specific device).


The problem with adding more capabilities like this in an ad-hoc way is 
that it involves user trust, and worse yet it involves trust in things 
the user can't audit and won't realize they're trusting.


For example, say www.foo.com requests access to the user's USB devices. 
 If the user allows the request, then they are trusting that:


1) The site is not malicious (this is the part the user probably
   thinks about when deciding to trust).
2) The site is loaded securely (entirely over https:).  If not,
   there's no guarantee you're talking to the right site.
3) The site has no script-injection vulnerabilities.
4) The site won't be hacked.
5) All the user's CAs are aboveboard and not cooperating with the ISP
   to fake sites (not a given in some countries!).

There are likely a few other things being trusted here that I'm not 
thinking of; I can guarantee that typical users won't think of #3-5 
above, and many won't think of #2 above.


I realize that _you_ trust #2-4 about your own web site.  But frankly, 
history says I shouldn't thus trust your site


Perhaps we need a stronger model where permission to access devices is 
granted not to an origin but to a particular script (with the hash of 
the script stored and permission denied on hash mismatch or something). 
 I don't know.  But granting blanket access to an entire origin seems 
questionable to me.


-Boris

Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property - Drawing model discussion

2011-01-04 Thread Robert O'Callahan

On Wed, Jan 5, 2011 at 8:12 AM, carol.sz...@nokia.com wrote:

  Please see my in-line comments below:

  --
 Version 1:

 4.8.11.1.13 Drawing model



 When a shape or image is painted, user agents must follow these steps, in
 the order given (or act as if they do):

 1. Render the shape or image onto an infinite transparent black bitmap,
 creating image M1, as described in the previous sections except that for the
 purpose of this step every pixel of the image will be considered to be fully
 opaque white and the current fillStyle will be considered to be solid fully
 opaque white and the strokeStyle will be considered fullyOpaque white as
 well

   2. When shadows are drawn, render the shadow from image M1, using a
 fully opaque white shadow color as described in the shadows section,
 creating image M2.

   3. Let C1 be a region obtained by intersecting the canvas's cliping
 region with the set of pixels in the canvas that correspond to pixels in M1
 (by having the same coordinates) that are not fully transparent.

 4. Let C2 be a region obtained by intersecting the canvas's cliping region
 with the set of pixels in the canvas that correspond to pixels in M2 (by
 having the same coordinates) that are not fully transparent.

   5. Render the shape or image onto an infinite transparent black bitmap,
 creating image A, as described in the previous sections. For shapes, the
 current fill, stroke, and line styles must be honored, and the stroke must
 itself also be subjected to the current transformation matrix.

 6. When shadows are drawn, render the shadow from image A, using the
 current shadow styles, creating image B.

 7. When shadows are drawn, multiply the alpha component of every pixel in
 B by globalAlpha.

 8. When shadows are drawn, composite B with the current canvas bitmap,
 cliping results to region C2 defined above, using the current composition
 operator.

 9. Multiply the alpha component of every pixel in A by globalAlpha.

 10. Composite A with the current canvas bitmap, cliping results to region
 C1 defined above, using the current composition operator.


 Making a binary fully-transparent/not-fully-transparent per-pixel decision
 to create regions C1 and C2 seems like it can't be right in the presence of
 antialiasing.

 Suppose we have a path filled with black and operator copy. Any pixel on
 the edge of that path that gets any nonzero coverage value from antialiasing
 will end up solid black with this proposal. That's going to look very ugly.
 We'll want a solution where any canvas pixel which has a very small amount
 of coverage by the path will be mostly unchanged in the final result.

  I do not understand why pixels touched by antialiasing are going to be
 solid black.

 Yes, I made a mistake. The actual result will be mostly-transparent black,
but that is equally unacceptable.

In step 1, every pixel which is very slightly covered by the path will be
filled with mostly-transparent white.
In step 3, all such pixels will be added to C1.
In step 5, those pixels will be set to mostly-transparent black in image A.
In step 10, for those pixels we'll composite mostly-transparent black onto
the canvas with operator copy, setting the canvas pixels to
mostly-transparent black.

The core problem is steps 3 and 4. Making a binary decision for each pixel
whether it's in or out of the shape simply can't work well  when
coverage-based antialiasing is being used.

If you generalize C1 and C2 to be alpha masks, or rephrase the approach so
that it permits such generalization, then this could work. But you have to
be careful about how you use partial alpha values in step 10.

The way I understand antialiasing (and maybe I am wrong), pixels that are
 partly touched retained partly their old color and transparency and get
 parly the new color and transparency. More precisely the resulting
 transparency and color components an average of the color component being
 painted and the previous color component weighted by the coverage fraction
 of the pixel. Hence partially covered pixels are partially transparent, thus
 the background behind the canvas should shine through and the partially
 covered pixels won't be entirely black unless that background is black as
 well.


That's right, but your proposal interacts with this process.

I agree with you though that there are cases when inappropriately using
 globalCompositeOperation can yield ugly and perhaps surprising results, such
 as in the case you described if the canvas is completely red before the
 operation and it is put on a page that has green background, thus the shape
 will acquire an unexpected slightly green rim between black and red.


Yes, it's easy to produce ugliness. With great power comes great
responsibility :-).



  Version 2:



 4.8.11.1.13 Drawing model



 When a shape or image is painted, user agents must follow these steps, in
 the order given (or act as if they do):

 1. Render the shape or image onto

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

2011-01-04 Thread Seth Brown

When you download and run a program you are placing the same level of
trust in a website (unless it the program is also distributed by an
additional trusted site and you can verify the one you have is the
same) as you would when allowing them to access one of your devices.

Therefore, device element access should require the same level of
confirmation as installing a downloaded program.

That being said. Granting access to a particular script instead of an
entire site sounds like a reasonable security requirement to me. As
does using a hash to verify that the script you granted permission to
hasn't changed.

-Seth

Re: [whatwg] Timed tracks: feedback compendium

On Tue, Jan 4, 2011 at 4:24 AM, Philip Jägenstedt phil...@opera.com wrote:
 If you need an intermediary format while editing, you can just use any
 syntax you like and have the editor treat it specially.

If I'd need to write my own parser to write an editor for it, that's
one thing--but I hope I wouldn't need to create yet another ad hoc
caption format, mirroring the features of this one, just to work
around a lack of inline comments.

The cue text already vaguely resembles HTML.  What about !-- comments
--?  It's universally understood, and doesn't require any new escape
mechanisms.

-- 
Glenn Maynard

Re: [whatwg] Device Element

2011-01-04 Thread Bjartur Thorlacius

On 1/4/11, Diogo Resende drese...@thinkdigital.pt wrote:
 Flash is insecure because there's no security policies. It's similiar to
 the firefox feature to read files: you read all or you read none. That's
 not a good policy. Something similar to the geolocation would be better
 (this specific site/app can access this specific device).


File ACLs are usually implemented in kernels, not web browsers. I'll take
ACLs in userspace, but you can surely find a more appropriate place to
implement them.

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

On Tue, Jan 4, 2011 at 4:59 PM, Seth Brown lear...@gmail.com wrote:
 When you download and run a program you are placing the same level of
 trust in a website (unless it the program is also distributed by an
 additional trusted site and you can verify the one you have is the
 same) as you would when allowing them to access one of your devices.

 Therefore, device element access should require the same level of
 confirmation as installing a downloaded program.

 That being said. Granting access to a particular script instead of an
 entire site sounds like a reasonable security requirement to me. As
 does using a hash to verify that the script you granted permission to
 hasn't changed.

The issue of handling elevated permissions for scripts is a difficult
one, and I don't have a complete answer either, but re-confirming
every time the slightest change is made server-side is no solution.
Users aren't diffing scripts and verifying changes to see whether they
want to continue to grant permission.  Users aren't developers, and
most developers won't waste their time doing that, either (never mind
the issue of obfuscated Javascript code).

This would have exactly the same result as Vista's horrible UAC
mechanism: not only asking the user to confirm something he can't be
expected to understand, but asking in a constant, never-ending stream,
to the point where users either click yes without reading, or figure
out how to disable the prompt entirely (the worst end result possible,
if it causes a permissive default).

At some point, I do strongly believe that web apps should be able to
request elevated permission.  Many tasks that are still the domain of
native applications are stuck that way only because of security issues
like this, not because of any technical limitations of HTML or
Javascript.  This won't change without a reasonable security
mechanism--but asking the user every time a script changes is not an
answer.

-- 
Glenn Maynard

Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property - Drawing model discussion

2011-01-04 Thread carol.szabo

If Microsoft, Opera, and Mozilla all subscribed to the current version of the 
spec, it looks like WebKit is the only hold out.
In the discussions that I followed, I noticed no strong arguments, other then 
my own (concerning resource consumption, which Robert O'Callahan aparently 
rejected as invalid) in favor of changing the specification such that only 
covered pixels are affected by compositing.

Given the statements above I no longer think that changing the spec in this 
regard is a good thing, but I still believe that the disappearance of shadows 
for the source-in and copy modes and the strange result when shadows are drawn 
and the composite operation is source-out should be corrected. To do this I 
suggested the following in my previous e-mail, but I got no comments about my 
suggestion so I repeat it here (please excuse my insistence):

Replace steps 3 to 6 of the drawing model, with:

3. When shadows are 
drawnhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#when-shadows-are-drawn,
 composite B (source) with A (destination) using destination-over operation.

4. Multiply the alpha component of every pixel in A by 
globalAlphahttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-globalalpha.

5. Composite A within the clipping 
regionhttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#clipping-region
 over the current canvas bitmap using the current composition operator.

Please consider the proposal above.

Thanks to everyone for considering my thoughts,

Carol Szabo


From: rocalla...@gmail.com [mailto:rocalla...@gmail.com] On Behalf Of ext 
Robert O'Callahan
Sent: Tuesday, January 04, 2011 4:40 PM
To: Szabo Carol (Nokia-MS/Boston)
Cc: ch...@jumis.com; wha...@whatwg.org
Subject: Re: [whatwg] Fwd: RE: Inconsistent behaviour of 
globalCompositeOperation property - Drawing model discussion

On Wed, Jan 5, 2011 at 8:12 AM, 
carol.sz...@nokia.commailto:carol.sz...@nokia.com wrote:
Please see my in-line comments below:


Version 1:

4.8.11.1.13 Drawing model



When a shape or image is painted, user agents must follow these steps, in the 
order given (or act as if they do):

1. Render the shape or image onto an infinite transparent black bitmap, 
creating image M1, as described in the previous sections except that for the 
purpose of this step every pixel of the image will be considered to be fully 
opaque white and the current fillStyle will be considered to be solid fully 
opaque white and the strokeStyle will be considered fullyOpaque white as well

2. When shadows are drawn, render the shadow from image M1, using a fully 
opaque white shadow color as described in the shadows section, creating image 
M2.

3. Let C1 be a region obtained by intersecting the canvas's cliping region with 
the set of pixels in the canvas that correspond to pixels in M1 (by having the 
same coordinates) that are not fully transparent.

4. Let C2 be a region obtained by intersecting the canvas's cliping region with 
the set of pixels in the canvas that correspond to pixels in M2 (by having the 
same coordinates) that are not fully transparent.

5. Render the shape or image onto an infinite transparent black bitmap, 
creating image A, as described in the previous sections. For shapes, the 
current fill, stroke, and line styles must be honored, and the stroke must 
itself also be subjected to the current transformation matrix.

6. When shadows are drawn, render the shadow from image A, using the current 
shadow styles, creating image B.

7. When shadows are drawn, multiply the alpha component of every pixel in B by 
globalAlpha.

8. When shadows are drawn, composite B with the current canvas bitmap, cliping 
results to region C2 defined above, using the current composition operator.

9. Multiply the alpha component of every pixel in A by globalAlpha.

10. Composite A with the current canvas bitmap, cliping results to region C1 
defined above, using the current composition operator.

Making a binary fully-transparent/not-fully-transparent per-pixel decision to 
create regions C1 and C2 seems like it can't be right in the presence of 
antialiasing.

Suppose we have a path filled with black and operator copy. Any pixel on the 
edge of that path that gets any nonzero coverage value from antialiasing will 
end up solid black with this proposal. That's going to look very ugly. We'll 
want a solution where any canvas pixel which has a very small amount of 
coverage by the path will be mostly unchanged in the final result.

I do not understand why pixels touched by antialiasing are going to be solid 
black.
Yes, I made a mistake. The actual result will be mostly-transparent black, but 
that is equally unacceptable.

In step 1, every pixel which is very slightly covered by the path will be 
filled with mostly-transparent white.
In step 3, all such pixels will

Re: [whatwg] Proposal for a tab visibility API

2011-01-04 Thread Alex Komoroske

Hi all,

Thanks again for your comments and feedback.  It's been a couple of weeks
since the last activity on this thread, and I wanted to take the opportunity
to do a very high-level summary of the discussion so far and put forward an
updated version of the proposal (which I've included at the end of this
e-mail).

My high-level summary:

Although there is *high *level agreement about the need for a similar type
of API, there are a number of concerns:

1) *Additional potential for abuse*.  My response to this was Although
there is some additional opportunity for abuse, I think that it is not
particularly large, possible to defend against if necessary, and outweighed
by the advantages such an API would provide to legitimate web developers.
 I'd be interested if those who originally raised this concern agree with
this assessment.
2) *Not the right tool for the use cases*.  Various other proposals,
including an ability to set a timer that only fires when a page is visible
or a way to semantically define what visibility specific types of content
require, have been proposed to address the provided use cases.  So far those
solutions are not concretely defined.
3) *Too specific about tab/window/visibility*.  I've attempted to update the
proposal (pasted below) to be more clear about the specific semantics and
how they might differ on different platforms.  I'd appreciate your comments.

*Updated API proposal*
*
*
document.visibility

A read-only property that returns a string, one of the values described in
the next section.  Developers can use the existence of this property to know
that they can rely on the rest of this API, too.

 Values returned by all conforming implementations
   * “visible” : the full-size page content is at least partially
visible on at least one screen.
   * “hidden” : the full-size page content is not visible to the
user at all.
 Additional values potentially returned by some implementations in some
cases
   * “prerender” : the page is currently being loaded off-screen and
might never be shown to the user.
   * “cache” : the page is currently “frozen” in a cache and not
displayed on screen (e.g. the back-forward cache).
   * “preview” : the page is currently visible only in a
lower-resolution thumbnail.


States in the second set are not guaranteed to be returned in all cases
where they might otherwise appear to apply--it is left to the discretion of
the implementation.

Additional return values may be added to this API in the future.

It is up to the implementation to interpret what these values mean in the
precise context of interface and platform.  As an example, a
current-generation desktop browser might interpret the values the following
way:
* “visible” : the tab is focused in its non-minimized window (regardless
of the focus state of the containing window).
* “hidden” : the tab is backgrounded within its window, or the
containing window is minimized.


document.isVisible

A simple convenience read-only property that returns a boolean. Returns true
if document.visibility’s current value is in the set of visibility states
considered to be visible.  In most implementations, only the “visible” state
is considered visible--although some implementations may consider other
values to be visible as well (for example, an implementation that makes
regular use of nearly-full-size thumbnail previews may consider “preview” to
be a visible state).

visibilitychange

A simple event, fired at the document object immediately after
document.visibility transitions between visibility states.  The event has a
property, fromState, that is set to the value of document.visibility just
before it was changed to the current value.  Note that visibility has
nothing to do with whether the document’s contents have fully loaded or not,
which implies that for any given visibility transition event, onload may or
may not have already fired.

On Mon, Dec 20, 2010 at 3:44 PM, Boris Zbarsky bzbar...@mit.edu wrote:

 On 12/20/10 5:16 PM, Alex Komoroske wrote:

 But I think overall the discussion about precisely what a tab means is
 not central to the core proposal.  Is that reasonable?


 Yep.

 -Boris

Re: [whatwg] Interaction between @multiple, @pattern and @list

On Fri, 1 Oct 2010, Jonas Sicking wrote:
 
 However, for input type=email multiple pattern=@company.com the 
 pattern is applied to the value as a whole, rather than to the 
 individual addresses. This seems less useful. It can be worked around 
 using more complex patterns, such as pattern=@company.com(, 
 @company.com)*. This works but is pretty clumsy. It also gets worse 
 for situations like pattern=.*@(company.com|parner.com)(, 
 .*@(company.com|partner.com))*.
 
 I suggest that when pattern and multiple are both applied on a control, 
 that the pattern is applied to each individual component of the value, 
 rather than the value as a whole.

Done.

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

Re: [whatwg] Suggestion for CSS-RESET property in CSS3 ((tag: css3, html5, css-reset, idea))

On Wed, 6 Oct 2010, Narendra Sisodiya wrote:
 
 I think, web developed should be done modular design approach.

This is more or less what XBL is intended to do:

   
http://dev.w3.org/cvsweb/~checkout~/2006/xbl2/Overview.html?content-type=text/html;%20charset=utf-8

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

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

2011-01-04 Thread Seth Brown

I couldn't agree more that we should avoid turning this into vista's UAC.

Maybe developers could make changes infrequent enough that users
wouldn't be bothered very often? They could encapsulate the device
access logic into one .js file that shouldn't be regularly changed.

Another option is to set default security to list changes to scripts
with device access in the device access preferences pane. Allow a
higher security setting that would send alert popups to notify
changes.

You could also use a third party CA like entity to verify your scripts
(this option would naturally have to develop over time).

-Seth


On Tue, Jan 4, 2011 at 5:20 PM, Glenn Maynard gl...@zewt.org wrote:
 On Tue, Jan 4, 2011 at 4:59 PM, Seth Brown lear...@gmail.com wrote:
 When you download and run a program you are placing the same level of
 trust in a website (unless it the program is also distributed by an
 additional trusted site and you can verify the one you have is the
 same) as you would when allowing them to access one of your devices.

 Therefore, device element access should require the same level of
 confirmation as installing a downloaded program.

 That being said. Granting access to a particular script instead of an
 entire site sounds like a reasonable security requirement to me. As
 does using a hash to verify that the script you granted permission to
 hasn't changed.

 The issue of handling elevated permissions for scripts is a difficult
 one, and I don't have a complete answer either, but re-confirming
 every time the slightest change is made server-side is no solution.
 Users aren't diffing scripts and verifying changes to see whether they
 want to continue to grant permission.  Users aren't developers, and
 most developers won't waste their time doing that, either (never mind
 the issue of obfuscated Javascript code).

 This would have exactly the same result as Vista's horrible UAC
 mechanism: not only asking the user to confirm something he can't be
 expected to understand, but asking in a constant, never-ending stream,
 to the point where users either click yes without reading, or figure
 out how to disable the prompt entirely (the worst end result possible,
 if it causes a permissive default).

 At some point, I do strongly believe that web apps should be able to
 request elevated permission.  Many tasks that are still the domain of
 native applications are stuck that way only because of security issues
 like this, not because of any technical limitations of HTML or
 Javascript.  This won't change without a reasonable security
 mechanism--but asking the user every time a script changes is not an
 answer.

 --
 Glenn Maynard

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

On Tue, Jan 4, 2011 at 7:07 PM, Seth Brown lear...@gmail.com wrote:
 I couldn't agree more that we should avoid turning this into vista's UAC.

 Maybe developers could make changes infrequent enough that users
 wouldn't be bothered very often? They could encapsulate the device
 access logic into one .js file that shouldn't be regularly changed.

Please don't restrict my ability to update my software with an
annoyingly-designed security system.  Whether I believe that rapid
updates or slow, well-tested updates are a better model for my web
app, I shouldn't be forced into one or the other because of a security
model that annoys the user every time I change something.

And: it still doesn't help.  Asking a user whether changes to a
Javascript file are okay is meaningless.  Regular users don't know
Javascript; there's no way they can know whether to accept a change or
not.  No general security model can be built around requiring the user
to understand the technical issues behind the security.

-- 
Glenn Maynard

Re: [whatwg] textarea newline format - raw value vs. transformed value and setSelectionRange

On Sun, 10 Oct 2010, Michael A. Puls II wrote:

Consider the following [simplified]:

!DOCTYPE html
title/title
script
window.addEventListener(DOMContentLoaded, function() {
var ta = document.getElementsByTagName(textarea)[0];
ta.value = ta.value.replace(/\r|\n/g, encodeURIComponent);
}, false);
/script
textarea rows=3Line 1
Line 2
Line 3/textarea

The behavior between Firefox 4 latest trunk and Opera 10.70 latest
snapshot is different because they're using different newline formats.

The correct behaviour is that the element's value becomes
Line 1%0ALine 2%0ALine 3

See step 1 at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#attr-textarea-wrap-hard-state.

That says that the 'value' getter returns the raw value + newlines normalized
to \r\n.

No, it says that the submission value has that transformation applied. The
'.value' getter returns the _raw_ value, which doesn't have U+000Ds added
by the user agent (they can only be there if the script added them).

I always thought that meant that the raw value (what was parsed into the
DOM)

The raw value is what the user edits.

contained newlines normalized to \r\n too for textareas and that a
browser with an HTML5 parser like Firefox would automatically show
newlines normalized to \r\n without even having a conversion done
(internally) for the 'value' getter.

No, the HTML parser strips U+000D characters (\r).

I'm also not sure step 1 applies to the 'value' setter. I can't tell for
sure. It looks like not, but not sure.

It doesn't apply to .value at all, only to the 'value' concept, which is a
concept used in form submission and constraint validation.

Also, I'm not sure if setSelectionRange() should operate on the raw
value, or the transformed value in step 1.

Raw value, because textarea is defined as an element that represents a
multiline plain text edit control for the element's raw value.

Opera's not using an HTML5 parser yet, so I can't check what it might
do, but could this be clarified?

It's not clear to me what isn't clear. :-) Could you elaborate on what the
spec says that led you to your interpretation?

In
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#preprocessing-the-input-stream

it says:

U+000D CARRIAGE RETURN (CR) characters and U+000A LINE FEED (LF)
characters are treated specially. Any CR characters that are followed by
LF characters must be removed, and any CR characters not followed by LF
characters must be converted to LF characters. Thus, newlines in HTML
DOMs are represented by LF characters, and there are never any CR
characters in the input to the tokenization stage.

Does that mean that the raw value of the parsed textarea should only
ever have '\n' for newlines (unless the 'value' setter is used in JS to
introduce '\r' characters)?

Yes.

If so, does that mean that setSelectionRange() should operate on the
raw, internal value (that just has '\n' for newlines in it normally),
but the 'value' getter still returns the transformed value with newlines
normalized to \r\n?

The value getting doesn't return the transformed value. See the definition
of the value getting for details.

I see
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#dom-textarea/input-setselectionrange,

but it doesn't mention this.

I've clarified the spec to indicate that setSelectionRange() and company
operate on the raw value.

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

Re: [whatwg] Proposal for a tab visibility API

2011-01-04 Thread Alex Komoroske

On Tue, Jan 4, 2011 at 3:50 PM, Glenn Maynard gl...@zewt.org wrote:


 The earlier condition that I think you mentioned seemed reasonable:
 never say the page is hidden when it's not, eg. no false positives.
 It's more harmful to tell a visible page that it's invisible, than to
 tell an invisible page that it's visible:

  * “visible” : the full-size page content may be at least partially
 visible on at least one screen.
  * “hidden” : the full-size page content is not visible to the user at all.

 This gives implementations some latitude to decide whether a condition
 should be treated as hidden, and doesn't require figuring out
 precisely whether a window is visible in every case.

 Great point, Glenn.  I agree completely.

--Alex

Re: [whatwg] Device element

2011-01-04 Thread Seth Brown

That was the point of what I said in the previous message. The default
security level wouldn't prompt users every time a script changes. But
for users who are interested and do understand what's going on--they
have the option of checking to see if a script has changed and can do
some more verification.

On Tue, Jan 4, 2011 at 7:15 PM, Glenn Maynard gl...@zewt.org wrote:
 And: it still doesn't help.  Asking a user whether changes to a
 Javascript file are okay is meaningless.  Regular users don't know
 Javascript; there's no way they can know whether to accept a change or
 not.  No general security model can be built around requiring the user
 to understand the technical issues behind the security.

Re: [whatwg] link.sizes and [PutForwards=value]

On Thu, 14 Oct 2010, Olli Pettay wrote:
 
 may I wonder why on earth any new API, like
 link.sizes uses PutForwards?
 IMHO, PutForwards should be limited to the
 awkward DOM0 APIs like window.location.

On Fri, 15 Oct 2010, Anne van Kesteren wrote:
 
 What's wrong with PutForwards?

On Fri, 15 Oct 2010, Olli Pettay wrote:

 It makes getters and setters work in a very different way.
 Inconsistency in APIs isn't a good thing.

I don't understand how they work in a different way?

The idea is to make the attribute appear to work like a DOMString for most 
purposes, but to allow methods to be invoked on it. (All the attributes 
that have [PutForwards] set also have a stringifier on their object's 
interface.)

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

Re: [whatwg] textarea newline format - raw value vs. transformed value and setSelectionRange

2011-01-04 Thread Michael A. Puls II

On Tue, 04 Jan 2011 19:38:17 -0500, Ian Hickson i...@hixie.ch wrote:

On Sun, 10 Oct 2010, Michael A. Puls II wrote:

Consider the following [simplified]:

The behavior between Firefox 4 latest trunk and Opera 10.70 latest
snapshot is different because they're using different newline formats.

The correct behaviour is that the element's value becomes
Line 1%0ALine 2%0ALine 3

O.K.

See step 1 at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#attr-textarea-wrap-hard-state.

That says that the 'value' getter returns the raw value + newlines
normalized

to \r\n.

No, it says that the submission value has that transformation applied.
The

'.value' getter returns the _raw_ value, which doesn't have U+000Ds added
by the user agent (they can only be there if the script added them).

O.K.

I always thought that meant that the raw value (what was parsed into the
DOM)

The raw value is what the user edits.

O.K.

No, the HTML parser strips U+000D characters (\r).

O.K.

I'm also not sure step 1 applies to the 'value' setter. I can't tell for
sure. It looks like not, but not sure.

It doesn't apply to .value at all, only to the 'value' concept, which is
a

concept used in form submission and constraint validation.

O.K.

Also, I'm not sure if setSelectionRange() should operate on the raw
value, or the transformed value in step 1.

Raw value, because textarea is defined as an element that represents a
multiline plain text edit control for the element's raw value.

O.K.

Opera's not using an HTML5 parser yet, so I can't check what it might
do, but could this be clarified?

It's not clear to me what isn't clear. :-) Could you elaborate on what
the

spec says that led you to your interpretation?

At some point, I got the idea that all browsers were going to make the
.value setter/getter normalize newlines so that it matched the newline
format that's submitted. Opera does this.

I don't remember how I got the idea for sure, but I think I suggested this
a while ago and just thought you agreed and put it in the spec. I guess it
just slipped by me that you were not talking about the value getter/setter.

So, Opera is just completely wrong with its behavior and even when it gets
an HTML5 parser, the value and textContent getters/setters and the user
input handling will have to be fixed to not normalize newlines to \r\n.
Then, Opera will match Firefox I think. Although, last time I checked, I
think webkit's .value getter/setter normalizations everything to just \n,
which would be wrong too as no normalize should be done.

So, I understand now. If everyone else understands too, no need to clarify
anything here.

But, what happens when pressing ENTER in a textarea? Should it always
create a \n in the raw value? What if you paste content that has Line
1\r\nLine 2 in an empty textarea area? Will the raw value contain Line
1\nLine 2 then?

Just want to make sure.

In
http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#preprocessing-the-input-stream
it says:

Does that mean that the raw value of the parsed textarea should only
ever have '\n' for newlines (unless the 'value' setter is used in JS to
introduce '\r' characters)?

Yes.

O.K.

The value getting doesn't return the transformed value. See the
definition

of the value getting for details.

O.K.

I see
http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#dom-textarea/input-setselectionrange,
but it doesn't mention this.

I've clarified the spec to indicate that setSelectionRange() and company
operate on the raw value.

Thanks

--
Michael

Re: [whatwg] Pressure API?

On Wed, 20 Oct 2010, Jens M�ller wrote:
 
 now that device orientation, geolocation, camera etc. have been spec'ed: 
 Is there any intent to provide an API for pressure sensors?
 
 This might well be the next hip feature in smartphones ...
 
 Oh, and while we are at it: Humidity probably belongs to the same group.

I haven't added these features to the spec for now, since the use cases 
for it aren't that compelling and so it's probably best to wait a while 
longer, allowing browser vendors to implement more of the stuff we have 
already added.


On Wed, 20 Oct 2010, Rich Tibbett wrote:
 
 Could this be modeled as an extension [1] to the System Info API [2]?
 
 This spec is still at the working draft phase. Perhaps renaming it to 
 'Generic Sensors API' and removing a whole bunch of the sensors included 
 in there at the moment would be appropriate.
 
 Getting and monitoring pressure and humidity within that framework would 
 work.
 
 [1] http://www.w3.org/TR/system-info-api/#extensibility
 [2] http://www.w3.org/TR/system-info-api

That doesn't really look like a Web spec... it doesn't really address 
privacy and security concerns (it just says browsers must not retrieve 
or update system information to Web sites without the express permission 
of the user, which doesn't really give much of a chance for there to be 
a good user interface for this), and it's massively over-engineered for 
what it is (the API surface is bigger than canvas!).

It looks more like something one would use in walled-garden environments.


On Wed, 20 Oct 2010, Henri Sivonen wrote:
 
 Are there other use cases apart from guessing the altitude? It figuring 
 out the device altitude is the use case, shouldn't the API expose the 
 altitude and allow the altitude to be computed by the browser or by the 
 operating system from a pressure sensor, from GPS or both?

Indeed.


On Wed, 20 Oct 2010, Marshall Eubanks wrote:
 
 Having worked in meteorology, I can tell you that, if every cell phone 
 had a barometer attached, that data could and would be used to improve 
 micro-forecasts over densely populated regions. It should be possible 
 to track storm fronts and the like to the 100 meter level - imagine an 
 app that gave you a 1 minute warning on the need for an umbrella.
 
 I am not going to pass any judgement on how hip this would be, but those 
 are the uses I can see.

I think we're some way away from having many users run background Web apps 
on their mobile devices for this kind of thing! However, in the future 
this may become more realistic and that would be a good time to spec this.

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

Re: [whatwg] Browser inconsistencies in rendering optgroup and option

On Wed, 20 Oct 2010, Boris Zbarsky wrote:

 Consider the following testcase (XHTML, but an equivalent DOM can be
 constructed in HTML, of course).
 
 !DOCTYPE html
 html xmlns=http://www.w3.org/1999/xhtml;
   body
 aaa
 optgroup
   bbb
 /optgroup
 ccc
 option
   ddd
 /option
 eee
   /body
 /html
 
 I observe the following behaviors:
 
 1)  Gecko makes optgroup and option blocks (and applies some
 bold/italic/font-size styles to the optgroup, at least).
 2)  Presto renders the text in the optgroup (which it treats as an
 inline) but doesn't render the option at all.
 3)  Webkit renders neither the optgroup nor the option
 4)  Trident (IE8/9) renders like Gecko as far as styling the optgroup,
 except it makes the optgroup and option inlines, not blocks.
 
 I have a hard time believing any of this matters for interop, but

I think the IE behaviour is closest to what the spec says, technically, 
though that's mostly because the spec doesn't say much of anything about 
option and optgroup rendering and so they just fall back to their 
defaults. (The spec doesn't even suggest different default font styles, 
leaving that up to the default select binding.)

We can change the spec here if there's a reason to do so, but as you say, 
I'd be surprised if there were interop needs here, so the simplest 
behaviour (nothing special) seems the best.

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

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


On 1/4/11 6:15 PM, Glenn Maynard wrote:

 No general security model can be built around requiring the user
to understand the technical issues behind the security.


Agreed.

At the same time no general security model should be build around 
requiring users to make decisions based on no information.


So in brief, asking the user is just a bad security model...

Note that you keep comparing websites to desktop software, but desktop 
software typically doesn't change out from under the user (possibly in 
ways the original software developer didn't intend).  The desktop apps 
that do update themselves have a lot of checks on the process precisely 
to avoid issues like MITM injection of trojaned updates and whatnot.  So 
in practice, they have a setup where you make a trust decision once, and 
then the code that you already trusted verifies signatures on every 
change to itself.


Perhaps we need infrastructure like that for websites; I'm not quite 
sure how to make it work, though, since the code that the user trusted 
once is not known to still be ok, unlike the desktop app case.


-Boris

Re: [whatwg] Browser inconsistencies in rendering optgroup and option


On 1/4/11 7:47 PM, Ian Hickson wrote:

1)  Gecko makes optgroup and option blocks (and applies some
 bold/italic/font-size styles to the optgroup, at least).
2)  Presto renders the text in theoptgroup  (which it treats as an
 inline) but doesn't render theoption  at all.
3)  Webkit renders neither theoptgroup  nor theoption
4)  Trident (IE8/9) renders like Gecko as far as styling the optgroup,
 except it makes the optgroup and option inlines, not blocks.

I have a hard time believing any of this matters for interop, but


I think the IE behaviour is closest to what the spec says, technically,
though that's mostly because the spec doesn't say much of anything about
option  andoptgroup  rendering and so they just fall back to their
defaults. (The spec doesn't even suggest different default font styles,
leaving that up to the defaultselect  binding.)

We can change the spec here if there's a reason to do so, but as you say,
I'd be surprised if there were interop needs here, so the simplest
behaviour (nothing special) seems the best.



Well, the reason Gecko styles optgroup and option as blocks is because 
it uses CSS layout for the innards of the dropdown in the case of 
comboboxes and for the list in the case of listboxes.  And you really 
don't want all your options on one line.  ;)


So we need to either specify that or define some non-CSS thing about how 
dropdowns and listboxes are actually rendered (esp. because websites 
very much depend on the details of it!).


I would clearly prefer that the behavior be defined in terms of CSS; UAs 
that under the hood want to ignore the styles and just do something 
magic can still do that, of course.


-Boris

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

On Tue, Jan 4, 2011 at 10:53 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 Note that you keep comparing websites to desktop software, but desktop
 software typically doesn't change out from under the user (possibly in ways
 the original software developer didn't intend).  The desktop apps that do
 update themselves have a lot of checks on the process precisely to avoid
 issues like MITM injection of trojaned updates and whatnot.  So in practice,
 they have a setup where you make a trust decision once, and then the code
 that you already trusted verifies signatures on every change to itself.

HTTPS already prevents MITM attacks and most others; the major attack
vector they don't prevent is a compromised server.

I thnik the main difference is that the private keys needed to sign
with HTTPS are normally located on the server delivering the scripts,
whereas signed updates can keep their private keys offline.  That's
not a model web apps can mimic: all ways to execute scripts, in both
Javascript files and inline in HTML, would need to be signed, which is
impossible with templated HTML.

 Perhaps we need infrastructure like that for websites; I'm not quite sure
 how to make it work, though, since the code that the user trusted once is
 not known to still be ok, unlike the desktop app case.

You don't really know that an installer you download from a server is
valid, either.  Most of the time--for most users and most
software--you have to take it on faith that the file on the server
hasn't been compromised.  But, yes, you only have to do that once with
auto-updating systems, not on every update.

-- 
Glenn Maynard

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


On 1/4/11 10:51 PM, Glenn Maynard wrote:

On Tue, Jan 4, 2011 at 10:53 PM, Boris Zbarskybzbar...@mit.edu  wrote:

Note that you keep comparing websites to desktop software, but desktop
software typically doesn't change out from under the user (possibly in ways
the original software developer didn't intend).  The desktop apps that do
update themselves have a lot of checks on the process precisely to avoid
issues like MITM injection of trojaned updates and whatnot.  So in practice,
they have a setup where you make a trust decision once, and then the code
that you already trusted verifies signatures on every change to itself.


HTTPS already prevents MITM attacks and most others


I've yet to see someone suggest restricting the asking UI to https sites 
(though I think it's something that obviously needs to happen).  As far 
as I can tell, things like browser geolocation prompts are not thus 
restricted at the moment.



the major attack vector they don't prevent is a compromised server.


Or various kinds of cross-site script injection (which you may or may 
not consider as a compromised server).



I thnik the main difference is that the private keys needed to sign
with HTTPS are normally located on the server delivering the scripts,
whereas signed updates can keep their private keys offline.


Or fetch them over https from a server they trust sufficiently (e.g. 
because it's very locked down in terms of what it allows in the way of 
access and what it serves up), actually; I believe at least some update 
mechanisms do just that.



That's not a model web apps can mimic: all ways to execute scripts, in both
Javascript files and inline in HTML, would need to be signed, which is
impossible with templated HTML.


Agreed, but that seems like a problem for actual security here.


You don't really know that an installer you download from a server is
valid, either.  Most of the time--for most users and most
software--you have to take it on faith that the file on the server
hasn't been compromised.


That really depends.  Publishing checksums is not all that uncommon. 
The point is that at least the remote possibility of due diligence on 
the user's part exists here.  So far, for web sites, it doesn't.



But, yes, you only have to do that once with auto-updating systems, not on 
every update.


Indeed.

-Boris

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

On Wed, Jan 5, 2011 at 12:10 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 HTTPS already prevents MITM attacks and most others

 I've yet to see someone suggest restricting the asking UI to https sites
 (though I think it's something that obviously needs to happen).  As far as I
 can tell, things like browser geolocation prompts are not thus restricted at
 the moment.

Well, there are at least two broad classes of elevated privileges:
things which are clearly useful to web pages but are disallowed or
limited because they're too easily misused, and things with more
serious security implications.  Fullscreening, mouse capturing,
stopping the context menu, bypassing local storage quotas, etc. are in
the former category.  Unrestricted file and network access (accepting
network connections for direct peer-to-peer connections, UDP) is in
the latter category.

Stricter requirements like SSL makes more sense for the latter case.
I'd put geolocation squarely in the first, lesser group.

Unblocking the lesser case is probably much easier, to allow elevating
a site to permit those things which are useful, and which are at worst
a nuisance if a script is hijacked.

 the major attack vector they don't prevent is a compromised server.

 Or various kinds of cross-site script injection (which you may or may not
 consider as a compromised server).

I suppose this is analogous to buffer overflows in native code.

-- 
Glenn Maynard

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


On 1/5/11 12:29 AM, Glenn Maynard wrote:

Stricter requirements like SSL makes more sense for the latter case.
I'd put geolocation squarely in the first, lesser group.


I wouldn't.  Just because a user trusts some particular entity to know 
exactly where they are, doesn't mean they trust their stalker with that 
information.  I picked geolocation specifically, because that involves 
an irrevocable surrender of personal information, not just annoyance 
like disabling the context menu.



Or various kinds of cross-site script injection (which you may or may not
consider as a compromised server).


I suppose this is analogous to buffer overflows in native code.


As opposed to a virus infection (which would be similar to a compromised 
server), say?  Yes, that seems like a good analogy.  One difference is 
that buffer overflows are primarily a problem insofar as you don't 
control your input.  With a website, you never control your input: 
anyone can point the user to any url on your site.  Even urls you didn't 
think of existing.


-Boris

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