[whatwg] [CSSWG][css-display-3] CR of CSS Display Level 3
The CSS WG has published a Candidate Recommendation and invites implementations of the CSS Display Module Level 3: https://www.w3.org/TR/css-display-3/ CSS Display describes how the CSS formatting box tree is generated from the document element tree and defines properties that control the types of boxes thus generated. New features since Level 2 include: * new two-keyword syntaxes for various display types * inline list-items * run-ins * 'display: contents' to replace an element with its contents The draft also features * A normative description of the CSS box generation model https://www.w3.org/TR/2018/CR-css-display-3-20180828/#intro * Definitions for blockification and inlinification https://www.w3.org/TR/2018/CR-css-display-3-20180828/#transformations * A glossary of key box model terms (largely extracted from CSS2.1) https://www.w3.org/TR/2018/CR-css-display-3-20180828/#glossary Significant changes since earlier drafts are listed at: https://www.w3.org/TR/2018/CR-css-display-3-20180828/#changes Disposition of comments: https://drafts.csswg.org/css-display-3/issues-wd-2017 Please review the draft, and send any comments to the www-style list, , prefixed with [css-display] (as I did on this message) or (preferably) file them in the GitHub repository at https://github.com/w3c/csswg-drafts/issues For the CSS WG, ~fantasai
Re: [whatwg] Security: emphasize that subdomain is not enough for user provided scriptable content
These domains are used specifically because they are reserved for that use - https://www.iana.org/domains/reserved If a non-reserved domain is used, it could be bought up by anyone and have its content changed to something not appropriate for linking from official spec documents. The note is technically correct, but perhaps it could be written differently to more clearly point out the necessity of a different TLD? On Tue, Aug 28, 2018 at 8:33 AM Mikko Rantalainen < mikko.rantalai...@peda.net> wrote: > The page > >https://html.spec.whatwg.org/dev/iframe-embed-object.html > > contains an example that has "usercontent.example.net" instead of e.g. > "video.example.com" used in the same chapter. It does have a warning > saying > > > It is important to use a separate domain so that if the attacker > > convinces the user to visit that page directly, the page doesn't run > > in the context of the site's origin, which would make the user > > vulnerable to any attack found in the page. > > but I think this should specifically mention that using a subdomain is > not enough because JavaScript can lift any domain restrictions if only > the subdomain is different. This difference may not be immediately > obvious to casual reader especially because both examples also have > different subdomains which is easier to notice. > > I'm not sure how wording should be put because technically > "example.com." is subdomain of "com." top level domain. And we have > stuff such as "co.uk.", which makes things even hairier. > > I guess that the spec would like to use .example.* domains in all the > examples but perhaps one could use something more explicit such as > > https://example-usercontent.com/... > > for this example in addition to being more explicit about subdomains in > the warning. That would prevent even casual reader from mixing > a.example.com and b.example-usercontent.com. > > -- > Mikko >
[whatwg] Security: emphasize that subdomain is not enough for user provided scriptable content
The page https://html.spec.whatwg.org/dev/iframe-embed-object.html contains an example that has "usercontent.example.net" instead of e.g. "video.example.com" used in the same chapter. It does have a warning saying It is important to use a separate domain so that if the attacker convinces the user to visit that page directly, the page doesn't run in the context of the site's origin, which would make the user vulnerable to any attack found in the page. but I think this should specifically mention that using a subdomain is not enough because JavaScript can lift any domain restrictions if only the subdomain is different. This difference may not be immediately obvious to casual reader especially because both examples also have different subdomains which is easier to notice. I'm not sure how wording should be put because technically "example.com." is subdomain of "com." top level domain. And we have stuff such as "co.uk.", which makes things even hairier. I guess that the spec would like to use .example.* domains in all the examples but perhaps one could use something more explicit such as https://example-usercontent.com/... for this example in addition to being more explicit about subdomains in the warning. That would prevent even casual reader from mixing a.example.com and b.example-usercontent.com. -- Mikko
