[CSSWG][SVGWG] Minutes Tokyo F2F 2013-06-05 Wed PM II: Zoom Media Queries, CSS XSS, Shapes Deps

These are the official CSSWG minutes. Unless you're correcting the minutes,
*Please respond by starting a new thread with an appropriate subject line.*

Zoom Media Queries
------------------

   Discussed SVG use case of including more details as user zooms in,
   e.g. on a map. While discussing how to solve this, it became clear
   that while people have some idea of how zooming is interpreted wrt
   Media Queries, the whole interaction of 'resolution' and resizing
   is vastly underdefined and needs work before we can sensibly add
   related new features.

CSS Security
------------

   Discussed possibilities of cross-site attacks via CSS. One case
   that krit brought up wrt importing shapes was dismissed as Not a Problem.
   Some others raised by roc & bz might need more thought and discussion.

Shapes Dependencies
-------------------

   Brief discussion of SVG proposals' dependencies on Shapes and how to
   deal with that.

====== Full minutes ======

min-zoom/max-zoom Media Queries
-------------------------------

   <dbaron> Topic: min-zoom/max-zoom media queries
   fantasai: Isn't the point of zoom to magnify things [without changing them]?
   heycam: Some people using mapping content using SVG
   heycam: want to do some kind of detail control
   heycam: Suggested this would be something to handle via Media Queries
   heycam: Situation is some iframes, several levels deep, want to know
           the zoom level of this map tile
   heycam: Came back with proposal where you have min-zoom/max-zoom, which
           is the resulting scale factor from natural size of the thing
   heycam: e.g. have SVG image shown at 50% of intrinsic size
   Bert, dbaron: resolution/device-pixel-ratio ?
   heycam: Does that tell you that inner view is drawn at 4px per 1px of
           outer view?
   dbaron: Wrt device pixels
   heycam: ... See if that's what they need
   fantasai: it tells you the resolution
   fantasai: in device pixels per 'px', or 'in', or whatever
   heycam: asks for clarifications
   dbaron: It should work. Whether actually works in current implementations,
           might be a different

   <dbaron> Need to clarify behavior of 'resolution' media queries under
            transforms, especially if transforms non-axis-aligned
   fantasai: I would say, no, transforms don't affect media queries
   <dbaron> ...but does viewBox?
   dbaron: But resizing due to change in viewbox would

   dbaron: I don't know that the spec is clearly enough defined to answer
           all these questions. Probably should be.
   dbaron: As an implementor, just went with "this is reasonable, sort of
           agrees with other browsers, good enough for this week".
           But probably need to sort out this mess.
   dbaron: e.g. how does browser zoom ui work, particularly desktop vs. mobile,
           which have different concepts of zoom
   heycam: so if 'resolution' doesn't account for intermediate transforms,
           how amenable would you be to having one that does?

   krit: Designers want to have different details depending on zoom level
   cabanier: what about animations?
   heycam: If what you want to do is to turn on some detailed element at
           some zoom level, and you're animating the size of the thing,
           I imagine that's what you'd want to happen
   heycam: So maybe I go back to talk about whether resolution should work
           or not
   glazou: David, you said that resolution, same thing
   glazou: I think dealing with resolution will be extremely tricky for
           some Web designer, and dealing with number for min-zoom /max-zoom,
           would be much easier
   heycam: Yeah, author would want to say "here's how content looks at
           default size; at twice magnification, looks like this"

   glazou: Wrt transforms scaling, ok, you can do that, but in simple case
           of normal web page where user just pinches, want to show control
           of whether it's zoomed in or not, don't think resolution provides
           a good solution
   glazou: You can't distinguish between iPad Retina and tablet with zooming
   dbaron: Mobile browser zoom doesn't affect media queries, whereas desktop
           does
   dbaron: I agree with everything you said, glazou, but I also want to
           avoid duplication.
   dbaron: Think we need to be clear on all these things before adding
           more to them

   fantasai: There are basically two types of scaling, graphical and logical.
   fantasai: Sometimes you're just wanting to magnify what exists. Certain
             types of UI zoom, and transforms, fall into this category
   fantasai: Other times actually changing parameters of layout
   fantasai: Need to be clear on which effects go in which category.
   glazou: Zooming by user is a user constraint; zooming by author is an
           author constraint
   glazou: First one makes sense for zoom, second for resolution

   SimonSapin: What I think you mean is, the ratio between the intrinsic
               size of an image and the used size of the image element
               in the outer document
   SimonSapin: This does not account for transforms

   dbaron: Might need another editor of MQ 4
   glazou: Florian is very busy right now, will have more time in a few months
   dbaron: Two big categories of changes that need to happen
   dbaron: We talked very briefly of doing syntax changes
   dbaron: To be closer to @supports
   dbaron: Other was adding queries to represent everything in media types,
           deprecating media types
   dbaron: But those are bigger things


CSS Security
------------

   <krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html#the-clip-path
   krit: Security question wrt basic shape
   krit: Can use CSS shapes to define a clipping area
   krit: Here's an image, can define a clip path on it.
   krit: Can also be animated
   krit: Quite easy to apply this clip path
   krit: Problem is the following
   krit: Usually you have clip-path inline in your style sheet
   krit: Can also cross-reference path from a different domain
   krit: Suppose, e.g. style sheet on mybank.com
   krit: evil.com tries to reference it
   krit: question is, can any private data come from this style sheet
   krit: E.g. can evaluate the shape with pointer events
   krit: If you clip to circle, outside that doesn't contribute to clipping area
   krit: Suppose one domain uses clip path to show password or something
   krit: If you clip anything with this letter here, then the areas outside
         it don't contribute to hit testing
   krit: So could scan the clipping path and reingineer what the clip-path
         could look like

   dbaron: I think anyone using clip-path to use confidential data is doing
           it wrong.
   dbaron: If that's the attack, I'm not that worried about it!
   dbaron: I would be more worried about an attack that involved treating
           other data as pieces of a CSS style sheet
   dbaron: e.g. send someone an email message with some CSS in the subject
   dbaron: And then closing equivalent to that in another message
   dbaron: Could retrieve all the subjects in between by requesting a
           particular URL from Yahoo.
   dbaron: That I'd be worried about
   dbaron: But this I'm not worried about
   glazou: I'm not that worried...

   Alan asks about some other shape image thing
   krit: Very weird case. Only one I could come up with as an issue
   heycam: What if you had a style sheet that just had content property,
           did hit testing on content
   krit: That would be a bigger security issue.
   fantasai: Putting sensitive data in a style sheet's content property
             also makes no sense at all.
   heycam discusses other properties exposing things in the same way
   ...
   <heycam> My point is if you can show that you can already get some
            information by testing an element styled by a style sheet
            from another domain -- e.g. the content property -- then
            it's fine to have shapes in clip-path, since it's not opening
            the hole any further.

   krit: If we agree this is a security problem, then our options are to
         remove [...]
   dbaron: I think we pretty much agree that it's not a security problem
           we want to fix.
   <dbaron> (unless there's a worse case that we haven't heard yet)
   dbaron: We could put a note in the spec, that authors shouldn't put
           sensitive info in clip-path
   Alan, dino: Don't think this is an issue
   Bert: Position div for each pixel of your password
   <dbaron> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0012.html
   dino: I don't know why we're even discussing this.
   Bert: Good to discuss, but I think we can conclude that this is a weird
         case we don't need to worry about
   RESOLVED: We don't care, unless bz can come up with something more convincing

   <dbaron> So I think Boris's concerns in that thread are actually somewhat
            different from that contrived bank case.
   <dbaron> maybe more like http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0008.html
   dbaron: Involves using clip-path on attacker site over <iframe> to
           victimize site.
   dbaron: That's more concerning.
   dbaron: But not useful to discuss here.
   dino: How is it more of a problem than overflow?
   dbaron: Not different.
   <dbaron> message from roc: http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html
   krit: Boris is referencing a mail of roc. The problem that roc's describing
         has to do with feDisplacementMap that is based on pixel displacement
         by color value. In combination with the current defintion of
         'pointer-events', it can influence hit testing in a way that
         it can be used to reveal privacy data.
   dbaron: The attack I described wasn't what bz described
   <dbaron> ... since bz was describing something that would be fixed by
            rejecting clip-path for cross-origin non-CORS style sheets
   <dbaron> which the attack of a site that controls a site's cross-origin
            style sheet and can simultaneously frame it isn't fixed by
   dbaron: This is stuff that needs to be thought about longer. We should
           be fine, I think.

   heycam: been awhile since roc's message. should someone look at that?

CSS Shapes & co
---------------

   tav: Things we would most need from Exclusions and Shapes have been
        removed from latest drafts
   tav: shape-inside
   tav: And using SVG paths and shapes
   Alan: My plan for that is to have that in next level of CSS Shapes
   Alan: I'm trying to constrain first level of spec to stuff that is most
         immediately useful to CSS at the moment
   Alan: I don't think there's an issue with having your SVG work depend
         on Shapes level 2 instead of Shapes level 1
   glazou: Problem is referencing a non-normative document
   glazou: Discussion in AC forum, W3C suggested references can only be
           W3C RECs. Document referencing WD can't go to REC
   plh: But can go to PR. Just can't go to REC.
   fantasai: I don't think this will be an issue.
   plh: For the record, Robin Berjon started a thread on chairs list wrt
        dependencies
   Alan: Noted, haven't created L2 document yet
   Alan: question of whether to make L2 doc to park these things in
   TabAtkins: Make sense. Just put <details class=obsolete> and note things
   TabAtkins: Maybe I'll rename the class

Received on Friday, 28 June 2013 01:29:33 UTC