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

[Ryosuke Niwa]

On Jan 10, 2014, at 8:16 AM, Boris Zbarsky  wrote:

> On 1/10/14 11:10 AM, Erik Arvidsson wrote:
>> My hope was that it would be rare to override Symbol.create for Elements
>> so in most cases we would not need to call user code.
> 
> For spec purposes and parser implementation design purposes that doesn't 
> matter.  If user code can be called, the algorithms involved have to handle 
> user code being called at that point and potentially tearing the world down 
> (or apart, or just rearranging it in macabre ways like user code tends to 
> do)...
> 
>> After further discussing this with Dominic and others I've given up the
>> hope that an object instance cannot be reached before the constructor
>> has been called. This can happen due to navigating the DOM tree but also
>> be manually calling `MyCustomElement[Symbol.create]()`. At this point I
>> believe we should just resolve to best practice and that is to not use
>> @@create directly and do not navigate the DOM tree in your constructors.
> 
> Yeah, agreed.

An alternative idea we had was to “recursively” call constructors on the 
“unconstructed” elements in such situations.  So if the constructor of an 
element A tries to access to another unconstrcuted element B, then call B’s 
constructor at that point.

Either solution is better than not being able to use ES6 classes in my opinion.

- R. Niwa

[Bug 23487] Actually define going fullscreen

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23487

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Anne  ---
https://github.com/whatwg/fullscreen/commit/d2ebb7a9ecda445bbc184c578630bad792075300

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

[Bug 24232] The containing block of fixpos elements in the top layer shouldn't be the ICB

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24232

Anne  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Anne  ---
Thanks!

https://github.com/whatwg/fullscreen/commit/d77e0158a10a2e1904ade9eac6d03531437c3ef7

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

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

[Boris Zbarsky]

On 1/10/14 11:10 AM, Erik Arvidsson wrote:

My hope was that it would be rare to override Symbol.create for Elements
so in most cases we would not need to call user code.


For spec purposes and parser implementation design purposes that doesn't 
matter.  If user code can be called, the algorithms involved have to 
handle user code being called at that point and potentially tearing the 
world down (or apart, or just rearranging it in macabre ways like user 
code tends to do)...



After further discussing this with Dominic and others I've given up the
hope that an object instance cannot be reached before the constructor
has been called. This can happen due to navigating the DOM tree but also
be manually calling `MyCustomElement[Symbol.create]()`. At this point I
believe we should just resolve to best practice and that is to not use
@@create directly and do not navigate the DOM tree in your constructors.


Yeah, agreed.

-Boris

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

[Erik Arvidsson]

On Thu, Jan 9, 2014 at 10:57 PM, Ryosuke Niwa  wrote:

> > 1. The parser does not know that it needs to use MyElement.@@create to
> create the JS objects when it sees a .
>
> On the other hand, solving this seems to require running some author
> scripts at the element creation time, at some later time but before the
> node is inserted into the document.


My hope was that it would be rare to override Symbol.create for Elements so
in most cases we would not need to call user code.

After further discussing this with Dominic and others I've given up the
hope that an object instance cannot be reached before the constructor has
been called. This can happen due to navigating the DOM tree but also be
manually calling `MyCustomElement[Symbol.create]()`. At this point I
believe we should just resolve to best practice and that is to not use
@@create directly and do not navigate the DOM tree in your constructors.


-- 
erik

Re: [HTML imports]: Imports and Content Security Policy

[Frederik Braun]

On 10.01.2014 14:51, Nick Krempel wrote:
> To clarify: your example is supposed to be an attack on imported.com
> , not example.com  (we can
> assume the attacker has control over example.com )?
> 
> Nick
> 
> ​
Yes, imagine an XSS vulnerability on example.com. Using this to include
imported.com shouldn't mean that the CSP in place (which allows
imported.com) is suddenly allowing everything that is also mentioned in
the policy of imported.com.

Quite contrary: If you include imported.com *and* you want to restrict
the resources working on your page, example.com (which is what CSP
does), you have to explicitly whitelist everything that imported.com
brings, otherwise those features won't work.

Re: [HTML imports]: Imports and Content Security Policy

[Nick Krempel]

On 10 January 2014 14:08, Frederik Braun  wrote:

> Yes, imagine an XSS vulnerability on example.com. Using this to include
> imported.com shouldn't mean that the CSP in place (which allows
> imported.com) is suddenly allowing everything that is also mentioned in
> the policy of imported.com.
>
Sorry I don't follow. In your example, you said the CSP of imported.com was
'self' only.

Re: [HTML imports]: Imports and Content Security Policy

[Nick Krempel]

To clarify: your example is supposed to be an attack on imported.com, not
example.com (we can assume the attacker has control over example.com)?

Nick

​

Re: [HTML imports]: Imports and Content Security Policy

[Hajime Morrita]

On Fri, Jan 10, 2014 at 5:30 PM, Frederik Braun  wrote:

> On 10.01.2014 03:52, Hajime Morrita wrote:
> > Hi Frederik,
> > Thanks for bringing it up!
> >
> > As you pointed out, CSP of imported documents essentially extends the
> > set of allowed domains. I thought I was useful for component authors to
> > specify their own domains, like one of their own CDN.
>
> Well the loss of convenience is indeed unfortunate.
> >
> > I'm not sure how it is threatening because components won't have any
> > sensitive state in it
> > because HTML Imports doesn't have any isolation mechanism after all. It
> > however might be an optimistic view.
> >
>
> I'm not concerned about state, but it shouldn't be allowed to bypass a
> CSP (which is stated in a header, after all) by a simple content
> injection that triggers an HTML Import (XSS is very prevalent and the
> main reason we're pushing for CSP is to prevent XSS :))
>
> > Being conservative, it could be better to apply master document's CSP to
> > whole import tree
> > and ignore CSPs on imports. It is less flexible and page authors need to
> > list all domains for
> > possibly imported resources, but this flat model looks what Web is
> > relying today.
> >
> Yes, just to re-emphasize: I think this is the way to go.
>

Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24268

Although we might come up with better idea,
I agree that we should start from safer option.


> > I'd appreciate any feedback and/or suggestions here. It seems there is
> > some progress on CSP side.
> > It would be great if there is some new mechanism to handle CSP of
> > subresources.
> > Things like ES6 modules might get benefit from it as well.
>
>
>


-- 
morrita

[Bug 24268] New: [imports]: imported documents should obey CSP on master document.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24268

Bug ID: 24268
   Summary: [imports]: imported documents should obey CSP on
master document.
   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

See discussion on:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0036.html

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

Re: [HTML imports]: Imports and Content Security Policy

[Frederik Braun]

On 10.01.2014 03:52, Hajime Morrita wrote:
> Hi Frederik,
> Thanks for bringing it up!
> 
> As you pointed out, CSP of imported documents essentially extends the
> set of allowed domains. I thought I was useful for component authors to
> specify their own domains, like one of their own CDN.

Well the loss of convenience is indeed unfortunate.
> 
> I'm not sure how it is threatening because components won't have any
> sensitive state in it
> because HTML Imports doesn't have any isolation mechanism after all. It
> however might be an optimistic view.
> 

I'm not concerned about state, but it shouldn't be allowed to bypass a
CSP (which is stated in a header, after all) by a simple content
injection that triggers an HTML Import (XSS is very prevalent and the
main reason we're pushing for CSP is to prevent XSS :))

> Being conservative, it could be better to apply master document's CSP to
> whole import tree
> and ignore CSPs on imports. It is less flexible and page authors need to
> list all domains for
> possibly imported resources, but this flat model looks what Web is
> relying today.
> 
Yes, just to re-emphasize: I think this is the way to go.

> I'd appreciate any feedback and/or suggestions here. It seems there is
> some progress on CSP side.
> It would be great if there is some new mechanism to handle CSP of
> subresources.
> Things like ES6 modules might get benefit from it as well.