Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Ryosuke Niwa 
On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:

> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak  wrote:
> On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:
> It is meant to be an encapsulation mechanism. Let me give a comparison. Many 
> JavaScript programmers choose to use closures as a way to store private data 
> for objects. That is an encapsulation mechanism. It is not, in itself, a hard 
> security mechanism. If the caller can hook your global environment, and for 
> example modify commonly used Object methods, then they may force a leak of 
> your data.
> 
> A closure is an iron-clad isolation mechanism for object ownership with 
> regards to the closing-over function object. There's absolutely no iteration 
> of the closed-over state of a function object; any such enumeration would be 
> a security hole (as with the old Mozilla object-as-param-to-eval bug). You 
> can't get the value of "foo" in this example except with the consent of the 
> returned function:
> 
> var maybeVendFoo = function() {
>   var foo = 1;
>   return function(willMaybeCall) {
> if (/* some test */) { willMaybeCall(foo); }
>   }
> };

But what if maybeVendFoo called some builtin functions like Math.abs on foo?  
e.g.

var maybeVendFoo = function () {
var foo = 1;
var bar = Math.abs(foo);
…
return function (willMaybeCall) {
if (/* some test */) {willMaybeCall(foo);
}
}

The caller of maybeVendFoo could easily override Math.abs and observe the value 
of foo:

var foo;
var realAbs = Math.abs;
Math.abs = function (val) { foo = val; return realAbs(val); }
maybeVendFoo();
Math.abs = realAbs;

This is exactly the kind of leakage we would have in Type 2 encapsulation 
Maciej has been talking about.

- R. Niwa

Re: Why can't we just use constructor instead of createdCallback?

2014-02-13 Thread Ryosuke Niwa 
We (Apple) support this proposal assuming that we can implement the proposed 
algorithm efficiently.

We would try to prototype it in WebKit in the coming months and will report 
implementation issues, including the feasibility of efficient implementation, 
if exists.

- R. Niwa

On Feb 13, 2014, at 6:50 PM, Jonas Sicking  wrote:

> Dimitri, I'd still love to hear feedback from you on the idea above.
> Seems like it could fix one of the design issues that a lot of people
> have reacted to.
> 
> / Jonas
> 
> On Wed, Jan 22, 2014 at 5:21 PM, Jonas Sicking  wrote:
>> On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky  wrote:
 One idea that came out of our discussion is was to add an additional step
 in the parser to call constructors on all "pending" elements before they're
 being constructed into the DOM tree.
>>> 
>>> Isn't that the bad thing we _don't_ want to do?  That is, invoke arbitrary
>>> page JS from the middle of the parsing algorithm?
>> 
>> The idea was to do something like this:
>> 
>> 1. While parsing, when you hit a custom element (with a constructor)
>> don't insert that element into its parent, nor insert any of its
>> children into the element.
>> 2. Put each such element into an array along with meta-info about what
>> parent and children it should have.
>> 3. Once you're done parsing as much as you want to parse (i.e. until
>> you hit a network boundary or feel the need to return to the event
>> loop), unwind enough of the calling stack until you feel comfortable
>> running content JS.
>> 4. Run the constructor for the first element in the array.
>> 5. After a constructor has been run, insert the element into its
>> parent, and insert its children into the element.
>> 6. Remove the element from the array and, unless the array is empty,
>> go back to step 4.
>> 
>> This is somewhat simplified. You also have to make sure not to insert
>> an elements into a parent where previous siblings are still pending to
>> be inserted.
>> 
>> The big question of course is if tracking the elements in the separate
>> array and inserting them after their constructor has run will be a
>> performance issue.
>> 
>> In Gecko it might be a bit of a problem since we can get O(n^2)
>> performance issues where n is the nesting depth of custom elements.
>> This is due to our recursive BindToTree notification which cause
>> problems when trees are constructed "bottom up"
>> 
>> But possibly this can be solved. And possibly other implementations
>> doesn't have the same problem. Or possibly they have worse problems.
>> 
>> But it wasn't immediately obvious to me that this wouldn't work.
>> 
>> / Jonas

Re: Why can't we just use constructor instead of createdCallback?

2014-02-13 Thread Jonas Sicking 
Dimitri, I'd still love to hear feedback from you on the idea above.
Seems like it could fix one of the design issues that a lot of people
have reacted to.

/ Jonas

On Wed, Jan 22, 2014 at 5:21 PM, Jonas Sicking  wrote:
> On Thu, Jan 9, 2014 at 9:27 PM, Boris Zbarsky  wrote:
>>> One idea that came out of our discussion is was to add an additional step
>>> in the parser to call constructors on all "pending" elements before they're
>>> being constructed into the DOM tree.
>>
>> Isn't that the bad thing we _don't_ want to do?  That is, invoke arbitrary
>> page JS from the middle of the parsing algorithm?
>
> The idea was to do something like this:
>
> 1. While parsing, when you hit a custom element (with a constructor)
> don't insert that element into its parent, nor insert any of its
> children into the element.
> 2. Put each such element into an array along with meta-info about what
> parent and children it should have.
> 3. Once you're done parsing as much as you want to parse (i.e. until
> you hit a network boundary or feel the need to return to the event
> loop), unwind enough of the calling stack until you feel comfortable
> running content JS.
> 4. Run the constructor for the first element in the array.
> 5. After a constructor has been run, insert the element into its
> parent, and insert its children into the element.
> 6. Remove the element from the array and, unless the array is empty,
> go back to step 4.
>
> This is somewhat simplified. You also have to make sure not to insert
> an elements into a parent where previous siblings are still pending to
> be inserted.
>
> The big question of course is if tracking the elements in the separate
> array and inserting them after their constructor has run will be a
> performance issue.
>
> In Gecko it might be a bit of a problem since we can get O(n^2)
> performance issues where n is the nesting depth of custom elements.
> This is due to our recursive BindToTree notification which cause
> problems when trees are constructed "bottom up"
>
> But possibly this can be solved. And possibly other implementations
> doesn't have the same problem. Or possibly they have worse problems.
>
> But it wasn't immediately obvious to me that this wouldn't work.
>
> / Jonas

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Maciej Stachowiak 

On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:

> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak  wrote:
> 
> On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:
> 
>> 
>> 
>> In discussion with Elliot and Erik, there appears to be an additional 
>> complication: any of the DOM manipulation methods that aren't locked down 
>> (marked non-configurable and filtered, ala caja) create avenues to get 
>> elements from the Shadow DOM and then inject styles. E.g., even with Arv's 
>> lockdown sketch: 
>> 
>>   https://gist.github.com/arv/8857167
>> 
>> You still have most of your work ahead of you. DocumentFragment provides 
>> tons of "ins", as will all incidentally composed APIs.
> 
> I'm not totally clear on what you're saying. I believe you're pointing out 
> that injecting hooks into the scripting environment a component runs in (such 
> as by replacing methods on global protototypes) can allow the shadow root to 
> be accessed even if no explicit access is given. I agree. This is not 
> addressed with simple forms of Type 2 encapsutation. It is a non-goal for 
> Type 2.
> 
> I'd like to understand what differentiates "simple forms of Type 2 
> encapsulation" from other potential forms that still meet the Type 2 
> criteria. Can you walk me through an example and show how they would be used 
> in a framework?

Type 4 encapsulation would also meet the Type 2 criteria, for example.

The difference is that with "simple" Type 2 you do not attempt to protect 
against a pre-poisoned scripting environment. I would be satisfied with Type 4 
(if it's usable) but it is much harder to spec as you need it to give rigorous 
security guarantees.

>  
>> This is fraught.
> 
> Calling something fraught is not an argument.
> 
> Good news! I provided an argument in the following sentence to help 
> contextualize my conclusion and, I had hoped, lead you to understand why I'd 
> said that.

Your argument seems to be based on an incorrect premise.

>  
>> To get real ocap-style denial of access to the shadow DOM, we likely need to 
>> intercept and check all DOM accesses. Is the system still usable at this 
>> point? It's difficult to know. In either case, a system like caja *can* 
>> exist without explicit supportwhich raises the question: what's the 
>> goal? Is "Type 2" defined by real denial of access? Or is the request for a 
>> fig-leaf (perception of security)?
> 
> Type 2 is not meant to be a security mechanism.
> 
> I'd like to see an example of Type 2 isolation before I agree to that.
>  
> It is meant to be an encapsulation mechanism. Let me give a comparison. Many 
> JavaScript programmers choose to use closures as a way to store private data 
> for objects. That is an encapsulation mechanism. It is not, in itself, a hard 
> security mechanism. If the caller can hook your global environment, and for 
> example modify commonly used Object methods, then they may force a leak of 
> your data.
> 
> A closure is an iron-clad isolation mechanism for object ownership with 
> regards to the closing-over function object. There's absolutely no iteration 
> of the closed-over state of a function object; any such enumeration would be 
> a security hole (as with the old Mozilla object-as-param-to-eval bug). You 
> can't get the value of "foo" in this example except with the consent of the 
> returned function:
> 
> var maybeVendFoo = function() {
>   var foo = 1;
>   return function(willMaybeCall) {
> if (/* some test */) { willMaybeCall(foo); }
>   }
> };
> 
> Leakage via other methods can be locked down by the first code to run in an 
> environment (caja does this, and nothing prevents it from doing this for SD 
> as it can pre-process/filter scripts that might try to access internals).

Caja is effective for protecting a page from code it embeds, since the page can 
have a guarantee that its code is the first to run. But it cannot be used to 
protect embedded code from a page, so for example a JS library cannot guarantee 
that objects it holds only in closure variables will not leak to the 
surrounding page. This is exactly analogous to shadow DOM leakage via DOM 
methods.

> 
> Getting to closure-strength encapsulation means neutering all potential 
> DOM/CSS access. Maybe I'm dense, but that seems stronger than the "simple 
> form of Type 2".

That seems like a false conclusion to me given the above.

> 
> If you're making the case that it might be helpful to folks trying to 
> implement Type 4 if the platform gave them a way to neuter access without so 
> much pre-processing/runtime-filtering, I could take that as an analog with 
> marking things non-configurable in ES. But it seems you think there's an 
> interim point that developers will use directly. I don't understand that and 
> would like to.

I don't believe Type 4 can be implemented on top of Type 1 with a 
pre-processing/runtime-filtering strategy. It would require additions to the 
platform. Filtering cannot create a two-way distrust boundary, only

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Tab Atkins Jr. 
On Thu, Feb 13, 2014 at 4:07 PM, Charles McCathie Nevile
 wrote:
> On Thu, 13 Feb 2014 19:09:33 +0100, Tab Atkins Jr. 
> wrote:
>> On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren 
>>> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell 
 Until we can agree on this, Type 2 feels like an attractive nuisance
 and, onreflection, one that I think we should punt to compilers like

 caja in the interim. If toolkits need it, I'd like to understand those
 use-cases from experience.
>>>
>>> I think Maciej explains fairly well in
>>> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
>>> why it's good to have. Also, Type 2 can be used for built-in elements,
>>> which I thought was one of the things we are trying to solve here.
>>
>> Stay after class and write 100 times on the board: "Type 2 is not a
>> security boundary".
>
> This is not appropriate on this email list.

Sorry, it was meant to be a playful response to Anne, and as I know
him personally and consider him a friend, I assumed he'd take it in
kind.  (Based on his reaction in IRC, I think he did.)

~TJ

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Charles McCathie Nevile 

Tab,

On Thu, 13 Feb 2014 19:09:33 +0100, Tab Atkins Jr.   
wrote:



On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren 

On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell 
Until we can agree on this, Type 2 feels like an attractive nuisance  
and, onreflection, one that I think we should punt to compilers like

caja in the interim. If toolkits need it, I'd like to understand those
use-cases from experience.


I think Maciej explains fairly well in
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
why it's good to have. Also, Type 2 can be used for built-in elements,
which I thought was one of the things we are trying to solve here.


Stay after class and write 100 times on the board: "Type 2 is not a
security boundary".


This is not appropriate on this email list.

cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Alex Russell 
On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak  wrote:

>
> On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:
>
>
>
> In discussion with Elliot and Erik, there appears to be an additional
> complication: any of the DOM manipulation methods that aren't locked down
> (marked non-configurable and filtered, ala caja) create avenues to get
> elements from the Shadow DOM and then inject styles. E.g., even with Arv's
> lockdown sketch:
>
>   https://gist.github.com/arv/8857167
>
> You still have most of your work ahead of you. DocumentFragment provides
> tons of "ins", as will all incidentally composed APIs.
>
>
> I'm not totally clear on what you're saying. I believe you're pointing out
> that injecting hooks into the scripting environment a component runs in
> (such as by replacing methods on global protototypes) can allow the shadow
> root to be accessed even if no explicit access is given. I agree. This is
> not addressed with simple forms of Type 2 encapsutation. It is a non-goal
> for Type 2.
>

I'd like to understand what differentiates "simple forms of Type 2
encapsulation" from other potential forms that still meet the Type 2
criteria. Can you walk me through an example and show how they would be
used in a framework?


>  This is fraught.
>
>
> Calling something fraught is not an argument.
>

Good news! I provided an argument in the following sentence to help
contextualize my conclusion and, I had hoped, lead you to understand why
I'd said that.


> To get real ocap-style denial of access to the shadow DOM, we likely need
> to intercept and check all DOM accesses. Is the system still usable at this
> point? It's difficult to know. In either case, a system like caja *can*
> exist without explicit supportwhich raises the question: what's the
> goal? Is "Type 2" defined by real denial of access? Or is the request for a
> fig-leaf (perception of security)?
>
>
> Type 2 is not meant to be a security mechanism.
>

I'd like to see an example of Type 2 isolation before I agree to that.


> It is meant to be an encapsulation mechanism. Let me give a comparison.
> Many JavaScript programmers choose to use closures as a way to store
> private data for objects. That is an encapsulation mechanism. It is not, in
> itself, a hard security mechanism. If the caller can hook your global
> environment, and for example modify commonly used Object methods, then they
> may force a leak of your data.
>

A closure is an iron-clad isolation mechanism for object ownership with
regards to the closing-over function object. There's absolutely no
iteration of the closed-over state of a function object; any such
enumeration would be a security hole (as with the old Mozilla
object-as-param-to-eval bug). You can't get the value of "foo" in this
example except with the consent of the returned function:

var maybeVendFoo = function() {
  var foo = 1;
  return function(willMaybeCall) {
if (/* some test */) { willMaybeCall(foo); }
  }
};

Leakage via other methods can be locked down by the first code to run in an
environment (caja does this, and nothing prevents it from doing this for SD
as it can pre-process/filter scripts that might try to access internals).

Getting to closure-strength encapsulation means neutering all potential
DOM/CSS access. Maybe I'm dense, but that seems stronger than the "simple
form of Type 2".

If you're making the case that it might be helpful to folks trying to
implement Type 4 if the platform gave them a way to neuter access without
so much pre-processing/runtime-filtering, I could take that as an analog
with marking things non-configurable in ES. But it seems you think there's
an interim point that developers will use directly. I don't understand that
and would like to.

But that does not mean using closers for data hiding is a "fig-leaf" or
> "attractive nuisance".
>

Agreed, but only because they're stronger than you imply by analogy. What
I'm arguing is that if closures are the right analogy for some variant of
Shadow DOM then they'd need to get MUCH stronger  (Type 4) to meet that
charge.


> It's simply taking access to internals out of the toolset of common and
> convenient things, thereby reducing the chance of a caller inadvertently
> coming to depend on implementation details. ES6 private symbols serve a
> similar role.
>

Sadly, private symbols don't look likely to make an appearance in ES6.


> The proposal is merely to provide the same level of protection for the
> shadow DOM.
>
>
> This is the struggle I have with Type 2. I can get my mind around Type 4
> and want it very badly. So badly, in fact, that I bore most people I talk
> to with the idea of creating primitives that explain x-origin iframes (some
> sort of "renderer worker", how are the graphics contexts allocated and
> protected? what does it mean to navigate? what sorts of constraints can we
> put on data-propagation approaches for flowed layouts that can keep us out
> of security hell?).
>
>
> (1) The form of Type 1 encapsu

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Bjoern Hoehrmann 
* Maciej Stachowiak wrote:
>Type 2 is not meant to be a security mechanism. It is meant to be an 
>encapsulation mechanism. Let me give a comparison. Many JavaScript 
>programmers choose to use closures as a way to store private data for 
>objects. That is an encapsulation mechanism. It is not, in itself, a 
>hard security mechanism. If the caller can hook your global environment, 
>and for example modify commonly used Object methods, then they may force 
>a leak of your data. But that does not mean using closers for data 
>hiding is a "fig-leaf" or "attractive nuisance". It's simply taking 
>access to internals out of the toolset of common and convenient things, 
>thereby reducing the chance of a caller inadvertently coming to depend 
>on implementation details.

An analogy for the above would be a programming environment where your
access to a private data member via `example.private_member` is denied
but you can still use the runtime environment's reflection API to get
to it. In a sense, marking a data member private then is just hard-to-
miss documentation of the API contract. I think that is sensible, but
it is also quite far away from your description of "Type 2"

  Encapsulation against deliberate access - no API is provided which
  lets code outside the component poke at the shadow DOM. Only internals
that the component chooses to expose are exposed."

since the reflection API is being provided in my analogous example, and
it leaves out mention of "common" and "convenient" which are central to
your description above. I can easily agree that "use classes maybe?" is
an insufficient answer to requests for this kinder, gentler version of
"Type 2".
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

[Bug 24349] [imports]: Import documents should always be in no-quirks mode

2014-02-13 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349

Morrita Hajime  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Morrita Hajime  ---
(In reply to Anne from comment #3)
> That's not the right fix. You're pointing to a document that defines
> behavior for when a Document is set to quirks mode. You're not actually
> preventing a document from being set to quirks mode. You need a particular
> HTML parser invocation and everything else is not needed.

OK, so here is another attempt:
https://github.com/w3c/webcomponents/commit/38326f265eecee0c9455e7884a2504796fb5b819

As the spec already has aparser invocation, I added a tweak there.
I wonder this hits the reasonable extension point of the parser though.
Feedback and reopen welcome!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[webcomponents]: Web Components in 2014

2014-02-13 Thread Dimitri Glazkov 
Hello public-webapps!

As promised, here's the "plans and expectations" summary for the Web
Components spec umbrella. Apologies for taking so long.

== Web Components Explainer ==

Current Editor: domin...@google.com
Status: Non-normative document

The explainer is continually updated to reflect the progress of all specs.
Since this document just keeps tracking the overall state, it will see
ongoing work throughout 2014.

== Custom Elements ==

Current Editor: dglaz...@chromium.org
Status: Last Call Draft

The custom elements spec is in LC. The expectation is that it will pass LC
at some point this year and enter CR.

Current state: The spec is stable, most work will evolve existing abilities
and refactor out primitives.

Polyfills and native implementations:

* Polymer (http://www.polymer-project.org/) maintains a polyfill (
https://github.com/polymer/CustomElements)
* An implementation based on the current spec is shipping in Chrome 33 Beta
* Implementation in Mozilla is progressing (
https://bugzilla.mozilla.org/show_bug.cgi?id=856140)

What's happening/up next:

1) Adding ES6 support. I started reading
https://people.mozilla.org/~jorendorff/es6-draft.html and plan to begin
with sprinkling non-normative comments over the spec, then grow them into
normative prose as the official ES6 spec emerges. Related bugs:
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24018
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24019
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24020

2) Adding an explicit registry API. This will likely be a separate spec,
which takes the "registry" concept from the spec and exposes it as its own
primitive:
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578

3) Defining HTML elements as custom elements. This will likely involve
splitting element/callback queue machinery into its own primitive as well
and adding more callbacks.
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24570
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24577
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24603
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24655

4) Adding a WebIDL attribute to mark places where callbacks are invoked:
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24579

5) Continuing spec maintenance. Related bugs:
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24043
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24087
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24176
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24178
* https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314

Testing status and plan:

A test suite is in active development:
* https://github.com/w3c/web-platform-tests/pull/464
* https://github.com/w3c/web-platform-tests/pull/469
* https://github.com/w3c/web-platform-tests/pull/578
* https://github.com/w3c/web-platform-tests/pull/609

== Shadow DOM ==

Status: Working Draft
Current Editor: hay...@google.com

The Shadow DOM spec is a Working Draft. We’re preparing next working draft
which reflects the feedback.

Current state: after a refactoring, the spec had settled down, maintenance
and evolution in progress. Also, there's now a sister spec in CSS WG:
http://dev.w3.org/csswg/shadow-styling/

Polyfills and native implementations:
* Polymer (http://www.polymer-project.org/) maintains a polyfill (
https://github.com/polymer/ShadowDOM)
* An implementation based on the editor’s draft is shipping in Chrome
Canary behind a flag.
* Implementation in Mozilla is progressing (
https://bugzilla.mozilla.org/show_bug.cgi?id=811542)

What's happening/up next:
* Come up with an isolation primitive (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16509)
* Specify the "hidden" mode (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144).
* Work on underlying primitives? (projection, etc.)
* Imperative Content distribution API (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429)
* Better event-stopping logic (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247)
* DOM-based vs. Box-based Selection. This on the radar, but will likely not
fit into this year.

Testing status and plan:

A test suite in W3C repository (
https://github.com/w3c/web-platform-tests/tree/master/shadow-dom). We are
maintaining the repository and continually updating the tests to reflect
the latest spec.

== HTML Imports ==

Status: First Public Working Draft
Current Editor: morr...@chromium.org

Current state: Active development, with high rate of change.

The HTML imports published first public WD last year. Since then, we’ve
receiving feedback from implementers and polyfill users. We’re preparing
next working draft which reflects all of the feedback.

Polyfills and native implementations:
* As custom elements and Shadow DOM, Polymer maintains a polyfill (
https://github.com/polymer/HTMLImports).
* An implementation reflecting current spec and some filed bugs are shipped
in Chrome behind a flag.

What's happening/up next:
* Asynchronous loading (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24

[Bug 24658] New: [imports]: The fetch readiness shouldn't block fetching.

2014-02-13 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24658

Bug ID: 24658
   Summary: [imports]: The fetch readiness shouldn't block
fetching.
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: morr...@google.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 20683

Spawned from Bug 24564.

Blocking fetch kills concurrency.
Instead, the readiness criteria should block only script execution.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Maciej Stachowiak 

On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:

> 
> 
> In discussion with Elliot and Erik, there appears to be an additional 
> complication: any of the DOM manipulation methods that aren't locked down 
> (marked non-configurable and filtered, ala caja) create avenues to get 
> elements from the Shadow DOM and then inject styles. E.g., even with Arv's 
> lockdown sketch: 
> 
>   https://gist.github.com/arv/8857167
> 
> You still have most of your work ahead of you. DocumentFragment provides tons 
> of "ins", as will all incidentally composed APIs.

I'm not totally clear on what you're saying. I believe you're pointing out that 
injecting hooks into the scripting environment a component runs in (such as by 
replacing methods on global protototypes) can allow the shadow root to be 
accessed even if no explicit access is given. I agree. This is not addressed 
with simple forms of Type 2 encapsutation. It is a non-goal for Type 2.

> 
> This is fraught.

Calling something fraught is not an argument.

> To get real ocap-style denial of access to the shadow DOM, we likely need to 
> intercept and check all DOM accesses. Is the system still usable at this 
> point? It's difficult to know. In either case, a system like caja *can* exist 
> without explicit supportwhich raises the question: what's the goal? Is 
> "Type 2" defined by real denial of access? Or is the request for a fig-leaf 
> (perception of security)?

Type 2 is not meant to be a security mechanism. It is meant to be an 
encapsulation mechanism. Let me give a comparison. Many JavaScript programmers 
choose to use closures as a way to store private data for objects. That is an 
encapsulation mechanism. It is not, in itself, a hard security mechanism. If 
the caller can hook your global environment, and for example modify commonly 
used Object methods, then they may force a leak of your data. But that does not 
mean using closers for data hiding is a "fig-leaf" or "attractive nuisance". 
It's simply taking access to internals out of the toolset of common and 
convenient things, thereby reducing the chance of a caller inadvertently coming 
to depend on implementation details. ES6 private symbols serve a similar role. 
The proposal is merely to provide the same level of protection for the shadow 
DOM.

> 
> This is the struggle I have with Type 2. I can get my mind around Type 4 and 
> want it very badly. So badly, in fact, that I bore most people I talk to with 
> the idea of creating primitives that explain x-origin iframes (some sort of 
> "renderer worker", how are the graphics contexts allocated and protected? 
> what does it mean to navigate? what sorts of constraints can we put on 
> data-propagation approaches for flowed layouts that can keep us out of 
> security hell?).

(1) The form of Type 1 encapsulation offered by current Shadow DOM specs cannot 
explain *any* built-in element that has a compound structure. Because built-in 
elements do not expose their Shadow DOM. It would be nearly impossible to do 
that and code them safely. If you want explanatory power for built-ins, Type 1 
is not sufficient.

(2) Enabling iframes to be implemented as a custom element would be hard, and 
goes beyond the bare minimum of Type 4 requirements. That said, as far as I can 
tell there is no need whatsoever to expose the details of how graphics contexts 
are allocated to enable this. Why would you think that? As I understand it, 
iframes are primarily about providing a security boundary with some tiny 
narrowly scoped holes, not about management of graphics resources. You would 
not use canvas-level primitives to implement iframes. 

> What I don't understand is what daylight there can be, in practice, between 
> Type 2 and Type 4-by-other-means. Either we lean on convention (using class 
> names for styling) and see how it goes, potentially extracting something like 
> the previously-proposed "::part()" system, or we go down the caja-style 
> rabbit hole and try to lock down _all_ the things, and not just from 
> incidental access.
> 
> Where would you have us draw this line?

I would draw the line between simple, obvious explicit mechanisms whose 
intended common use amounts to free-form access to the Shadow DOM, and 
mechanisms that indirectly allow this access by injecting traps into the global 
environment. Providing a clean global environment is not a goal for Type 2. Nor 
is a secure membrane for method calls.

> 
> Until we can agree on this, Type 2 feels like an attractive nuisance

I think you are only calling it an "attractive nuisance" because you did not 
understand what it is meant to provide, and instead believe it is a broken 
version of a different feature. It is not. I have tried to explain. I hope my 
explanation was informative.

> and, on reflection, one that I think we should punt to compilers like caja in 
> the interim. If toolkits need it, I'd like to understand those use-cases from 
> experience.

Caja cannot solve the Type 2

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Bjoern Hoehrmann 
* Anne van Kesteren wrote:
>On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell  wrote:
>> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
>> reflection, one that I think we should punt to compilers like caja in the
>> interim. If toolkits need it, I'd like to understand those use-cases from
>> experience.
>
>I think Maciej explains fairly well in
>http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
>why it's good to have. Also, Type 2 can be used for built-in elements,
>which I thought was one of the things we are trying to solve here.

The desire to retrofit built-ins into cross-browser component technology
has not been very helpful to deliver component technology into the hands
of authors.

I also note that "Encapsulation against deliberate access" would make it
quite difficult to automate components for testing and other purposes;
in many cases you would be unable to make a reduced test case that shows
some defect in a third party component that others can load in their web
browser without difficulty; and automation tools would need a privileged
API to break the encapsulation.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Alex Russell 
On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren  wrote:

> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell 
> wrote:
> > Until we can agree on this, Type 2 feels like an attractive nuisance
> and, on
> > reflection, one that I think we should punt to compilers like caja in the
> > interim. If toolkits need it, I'd like to understand those use-cases from
> > experience.
>
> I think Maciej explains fairly well in
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
> why it's good to have. Also, Type 2 can be used for built-in elements,
> which I thought was one of the things we are trying to solve here.


I encourage you to go through the exercise that arv has.

What does it mean, in practice, to *really* defend against "deliberate
access" (Maciej's Type 2). If you were to try to implement a built-in using
what, in your mind, is Type 2, would it work? Would you really be able to
hang privileged user access off that implementation?

Any time I consider the question, it leads me to want to lock down all
routes to access outside some (unspecified, and I fear unspecifiable until
we get *much* stronger primitives) relationship between a script execution
context and some subset of the DOM. This is painful because DOM makes
transport across "worlds" so trivial. Iframes, built-in-controls and caja
have all done this, but they do it by going for Type 4.

There is no spoon. Type 2 is a mirage.

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Tab Atkins Jr. 
On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren  wrote:
> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell  wrote:
>> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
>> reflection, one that I think we should punt to compilers like caja in the
>> interim. If toolkits need it, I'd like to understand those use-cases from
>> experience.
>
> I think Maciej explains fairly well in
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
> why it's good to have. Also, Type 2 can be used for built-in elements,
> which I thought was one of the things we are trying to solve here.

Stay after class and write 100 times on the board: "Type 2 is not a
security boundary".

~TJ

[Bug 24655] New: [Custom]: Consider turning processing stack + queues into its own primitive

2014-02-13 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24655

Bug ID: 24655
   Summary: [Custom]: Consider turning processing stack + queues
into its own primitive
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: dglaz...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14968

A sort of write barrier UAs can arbitrarily erect to protect integrity of their
DOM operations. Maybe even something that authors can use eventually?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Boris Zbarsky 

On 2/13/14 5:35 AM, Anne van Kesteren wrote:

Also, Type 2 can be used for built-in elements


Built-in elements need Type 4.

-Boris

[testing] Using labels to get a list of all open PRs for WebApps' test suites

2014-02-13 Thread Arthur Barstow 

[ Bcc public-webapps-testuite ]

Thanks to Dom and Tobie, [w-p-t] PRs are automatically tagged with WG 
identifiers (pattern is wg- f.ex. "wg-webapps"). This means 
there is an easy way to get a list of the open PRs for WebApp's tests:




I noticed some of WebApps' PRs are relatively old (~12 months) so if you 
are a Test Facilitator, please review your PRs and address them 
accordingly. (Perhaps some of the older CORS PRs are no longer 
useful/applicable?)


-Thanks, AB

[w-p-t] 

 Original Message 
Subject:Update to auto-labeling of pull requests on GH
Resent-Date:Thu, 13 Feb 2014 10:37:22 +
Resent-From:
Date:   Thu, 13 Feb 2014 11:36:53 +0100
From:   ext Tobie Langel 
To: 



Hi folks,

Just a quick update to let you know I've pulled and deployed some 
changes from Dom which now automatically tags pull requests with their 
related working group(s).


I ran the script against pre-existing pull requests but have run into 
issues in doing so, so I'm not sure whether I caught all of them or not. 
If you bump into a pull request which is missing the correct tags, 
please add them manually. Thanks.


In any case, this allows you to watch all open pull requests against a 
particular WG like so:


https://github.com/w3c/web-platform-tests/issues?labels=wg-webappsec

Of course, if you want to dig deeper, you can still get all PR for a 
particular spec by using it's shortname:


https://github.com/w3c/web-platform-tests/issues?labels=cors

Hope this helps.

--tobie

[Bug 13913] Attributes don't have an order

2014-02-13 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13913

Bug 13913 depends on bug 13912, which changed state.

Bug 13912 Summary: What order are attributes in?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=13912

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |DUPLICATE

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

2014-02-13 Thread Anne van Kesteren 
On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell  wrote:
> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
> reflection, one that I think we should punt to compilers like caja in the
> interim. If toolkits need it, I'd like to understand those use-cases from
> experience.

I think Maciej explains fairly well in
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
why it's good to have. Also, Type 2 can be used for built-in elements,
which I thought was one of the things we are trying to solve here.


-- 
http://annevankesteren.nl/

[Bug 24349] [imports]: Import documents should always be in no-quirks mode

2014-02-13 Thread bugzilla 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24349

Anne  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #3 from Anne  ---
That's not the right fix. You're pointing to a document that defines behavior
for when a Document is set to quirks mode. You're not actually preventing a
document from being set to quirks mode. You need a particular HTML parser
invocation and everything else is not needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.