[Houdini] Minutes Seattle F2F 2017-01-10 Part II: Worklets

=================================================
   These are the official Houdini Task Force
     minutes. Unless you're correcting the
      minutes, please respond by starting
 a new thread with an appropriate subject line.
=================================================


Worklets
--------

  - RESOLVED: If paint script runs too long as determined by UA, UA
              may terminate script and produce an invalid image.
  - RESOLVED: Switch to using "omit" for CORS attribute. Add the
              options bag at the end of import for the credentials
              setting.
  - A few github issues about security were brought up which lead to
      a larger conversation around if these worklets should only be
      available in a secure context (HTTPS or local)
      - The argument in favor was that it would bring developers
          closer to the agreed-upon goal of a secure web.
      - The argument against was that this would increase
          fragmentation and therefore confusion for beginning devs
          and that the CSS WG wasn't the proper place to push toward
          a secure web.
      - The group will raise this with TAG and get their
          recommendation.
  - There was support for adding loading worklets declaratively to
      this version of the spec.

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Seattle-F2F-Jan-10-2017

Scribe: fantasai

Worklets
========

  iank: Haven't updated since TPAC
  iank: Basically a bunch of feedback I need to incorporate from
        Anne.
  [iank goes over issue 319]

Long Running Scripts
--------------------

  iank: Discuss in this particular issue
        (https://github.com/w3c/css-houdini-drafts/issues/236) is
        feedback from bz.
  iank: If something runs for too long, e.g. while(True) loop.
  iank: Can add to spec that it could produce an invalid image and
        log an error to the console?
  iank: Does that seem fine with people?
  slightlyoff: I support giving UAs leeway here.
  Rossen: I'm in favor of error-handling.
  Proposal: If paint runs too long as determined by UA, UA may
            terminate script and produce an invalid image.
  Rossen: Would be good to have an explicit and definitive error
          handling for properties etc. For paint don't care what you
          paint
  Rossen: But in the middle of cascade, good to have something
          coherent between implementations so they don't get one
          value due to error in one and a different in other impl
  TabAtkins: Images have good handling: produce an invalid image.
  TabAtkins: For anything that doesn't have better behavior, get
             invalid-at-computed-value-time behavior that variables
             have.
  Proposal: If paint script runs too long as determined by UA, UA
            may terminate script and produce an invalid image.

  RESOLVED: If paint script runs too long as determined by UA, UA
            may terminate script and produce an invalid image.

  fremy: Layout?
  iank: Have to decide what invalid layout means. Can talk about
        that during layout topic :)

import() setup is inefficient
-----------------------------

  iank: This issue (https://github.com/w3c/css-houdini-drafts/issues/229)
        is talking about when a UA creates a workletGlobalScope,
        want to load exactly the same scripts as the last time
        loaded workletGlobal Scope.
  iank: For a lot of this stuff need to sit down with Domenic and
        make sure it's all good.

consider "omit" for the CORS setting?
-------------------------------------

  iank: This (https://github.com/w3c/css-houdini-drafts/issues/128)
        is credentials for scripts.
  iank: Currently we use the anonymous credentials.
  iank: Says we should use omit by default, then add an option to
        how workers does it if you want something different.
  TabAtkins: I suggest we defer to Domenic.
  <zcorpan> https://fetch.spec.whatwg.org/#concept-request-credentials-mode

  fremy: Omit same origin or input.
  <fremy> (meant to say I didnt see anonymous in the spec, and
          wondered whatbit meant vs omit)

  zcorpan: Anonymous is a value of the HTML attribute, the
           cross-origin attribute
  zcorpan: I don't think you can set it for workers.
  zcorpan: The link element has a cross-origin
  zcorpan: but then the fetch spec has a different API.
  iank: So I think we should do what Domenic says here, default to
        omit, and then at a later stage if needed can add an option

  RESOLVED: Switch to using "omit" for CORS attribute. Add the
            options bag at the end of import for the credentials
            setting.

  <zcorpan> https://html.spec.whatwg.org/#workeroptions
  <zcorpan> dictionary WorkletOptions { RequestCredentials
            credentials = "omit"; };

Worklets & Security
-------------------

  Rossen: A couple issue linked form spec,
          https://github.com/w3c/css-houdini-drafts/issues/92 and
          https://github.com/w3c/css-houdini-drafts/issues/47
  Rossen: 47 has to do with security considerations for worklets
  Rossen: You committed to have something in a week definitely, back
          in Dec 2015
  Rossen: #92, is it editorial or need to do more digging?
  iank: Need to do more digging.
  iank: I think we'll just copy whatever workers do in this regard.

  iank: One issue is should worklets be available to non-secure
        contexts?
  zcorpan: Secure context is https or localhost or something like
           that.
  zcorpan: In general I think new features should be available only
           in secure contexts, esp if a new way to run scripts.
  iank: Would the CSSWG commit to adding new features only to secure
        contexts?
  slightlyoff: I've argued strongly for secure contexts.
  slightlyoff: This is a new feature
  slightlyoff: There's no golden policy wrt all new features
  slightlyoff: But relatively straightforward to make the case here.
  slightlyoff: It's strictly additive, separable, and can
               feature-detected.
  slightlyoff: So I think there's an opportunism that we can apply
               here.
  slightlyoff: If the goal is fewer new features in non-secure
               contexts, this might be a good target.

  Rossen: Question - do you have examples where you want to use in a
          non-secure context?
  iank: If someone hasn't switched to https yet.
  plinss: I think you have to think about what can be done with a
          malicious paint worklet loaded from a third-party site.
  esprehn: Slicing up rendering space by secure context is really
           weird.
  esprehn: Are we going to not allow grid on non-secure sites?
  esprehn: CSS is getting color functions, is that going to be HTTPS?
  TabAtkins: You're not running arbitrary code.

  dbaron: The one other thing there is that I think in many cases we
          can restrict things to secure contexts at for example the
          IDL level.
  dbaron: Once you have a secure-context-only attribute to IDL, it's
          very easy to flip that for a new property or interface.
  dbaron: We might at some point do that for other things in CSS,
          but we can do this reasonably effectively without adding
          too many mechanisms to the platform
  smfr: Mechanisms aren't important. What's important is, only
        reason to restrict to secure context if it adds a new
        security concern. E.g. geolocation makes sense to restrict.
  smfr: I don't think we should make arbitrary splits in the
        platform that authors have to work with.
  * fantasai agrees with smfr
  dbaron: You can have very sensitive data in traditional things
          like form submission.
  dbaron: Limiting things to secure contexts is that if you limit
          features to secure contexts, it will push more of the Web
          to https.
  slightlyoff: We've had significant success over past year or two
               in moving a large fraction of the web to secure
               contexts. Part of that has been browser UI so that
               users actually understand underlying state.
  slightlyoff: But also by encouraging developers by new features
               being only available in secure context.
  slightlyoff: TAG finding about securing the Web, our goal is to
               make Web a trustworthy medium, which it is not in
               large part today.
  zcorpan: There's also point that whenever we add a new capability
           or new feature, the security implications are not yet
           known until there is security research and it's used on
           the Web.
  zcorpan: So we don't know yet if this will introduce new security
           problems.
  zcorpan: So makes more sense to restrict it now.

  fremy: Paint API or worklets in general?
  fremy: Paint API is just canvas, we already shipped that.
  zcorpan: worklets in general.
  iank: Do we then limit registerProperty to secure contexts?
  esprehn: What's the complexity here? Do we now have to parse
           paint() as invalid in CSS? Do we now have to put secure
           checks all over the CSS parser.
  TabAtkins: It'll parse as invalid cuz the name isn't available.
  fremy: You cannot use a fallback.
  fremy, esprehn: It's not the same as the paint() function itself
                  being invalid.
  fremy: Can't feature-detect it.
  zcorpan: Just use a secure context.
  fremy: What if you create a new framework?
  fremy: @supports can't detect this case.
  plinss: I don't know if we want a media query for secure context
          or not.
  plinss: Detect if feature is available.
  dbaron: Agree with Elliott that if custom paint isn't available
          then paint() parses as invalid.

  TabAtkins: What's the scenario here where you need to fall back?
  dbaron: The case of writing code that is meant to be used by other
          people in ways that you can't predict.

  fantasai: I also support smfr that if we split the platform in
            random way will confuse developers even more and will
            not be helpful
  fantasai: so if there is a reason for the to be secured, good, but
            if it is for the sake of it will be weird.
  fantasai: Especially for new coders, who are just beginning to
            learn HTML & CSS.
  dbaron: I think that position is out of date with the way the
          industry thinks about security. HTTPS needs to become the
          default for new Web hosting.
  esprehn: If we want to make *everything* secure-only, including
           all new CSS features like Grid, then I guess that's
           consistent.
  slightlyoff:  [missed]
  esprehn: I think it's very weird that when you're on a non-secure
           context, a random half of the Web platform suddenly
           disappears.
  TabAtkins: It's easy to get things to bog down, but can argue on
             large chunks of new things to hidden vs not.
  ...
  esprehn: It feels like the Android API. You set it to a particular
           number, and a random set of the API disappears. Very
           frustrating for developers.
  slightlyoff: This allows versioning, that's good.
  esprehn: OpenJail also works like this, and everyone is abandoning
           it for Vulcan.
  <dino> I assume esprehn meant OpenGL. I'm not sure there are many
         devices with shipping Vulkan support.

  fantasai: I'd like to point out that there are no authors in this
            room atm.
  smfr: Local dev could be difficult.
  TabAtkins: localhost is secure.
  esprehn: I think anything .localhost also counts.
  smfr: File urls?
  TabAtkins: Dunno.

  esprehn: If we ship it secure here, can always ship it non-secure
           later.
  Rossen: If we go with secure only first, a lot easier to relax
          than to try and make it secure-only later.

  Rossen: Not sure this is the most appropriate vehicle to make this
          decision.
  <dino> +1 to Rossen. It isn't a choice for this WG.
  plinss: This train has left the station a long time ago.
  slightlyoff: Did it for service workers?
  fremy: But they do expose new information.
  slightlyoff: [cites appcache]
  slightlyoff: We should have always put serviceworkers and ? behind
               secure.
  slightlyoff: Used new API to do that.
  smfr: In a new API space that's reasonable, but this is just
        canvas.
  plinss: Look at what ISPs do to inject content into websites.
  smfr: Agree that's an issue, but don't think using piecemeal bits
        of CSS to push that.
  plinss: But this introduces script.
  fremy: They already have script.
  plinss: But this puts it somewhere else.
  plinss: Shouldn't be arguing whether we should be secure, but
          arguing whether we have to be insecure.

  <dino> please don't use CSS features to push https upgrades.
  <fantasai> +1
  <dino> pushing for https is great. but it isn't a decision to be
         made on a feature by feature basis in a styling working
         group
  <dino> you can make that choice in your browser if you feel
         compelled
  <dino> It's cool that some other (much closer to the network) new
         APIs require https. But this is CSS. What are we protecting
         here?
  <dino> If a page is served over http, someone injecting custom
         paint overrides is only one of my many problems.
  * fantasai reads out dino's comments

  slightlyoff: Very surreal to have Apple arguing against privacy
               and security. Extraordinary.
  smfr: We're happy to limit features that we know are
        security-sensitive, like camera and geolocation.
  smfr: In this case fragmenting the author experience is worse than
        the issues we know with custom paint and worklets.
  smfr: If there's a provable privacy issue with this feature, but
        otherwise we think the damage to the Web is greater by
        fragmenting it.
  <fantasai> +1
  slightlyoff: Argument that this would help transition to https?
  smfr: I don't think it would.
  smfr: I think if we want to accelerate to https, this isn't the
        way to do this.
  smfr: Improving browser UI is better.
  slightlyoff: We have a team dedicated to this issue, and having a
               carrot for developers is a major plus.
  slightlyoff: Lowering price of certificates through better CAs
               also helps.

  esprehn: This is a different case.
  esprehn: Service workers doesn't have an alternative.
  esprehn: This has one, it's use tons of divs.
  esprehn: My concern is that this will drive library authors to
           build huge libraries that use custom paint path where it
           exists and tons of divs/other workarounds where it isn't
           *forever*
  <dbaron> Elliott's point about libraries is concerning.

  philipwalton: We said many times that Houdini is geared at
                framework authors.
  philipwalton: They're writing for third party.
  philipwalton: Important to consider that Houdini authors might not
                choose to use features, because not available to
                everybody.
  philipwalton: In opposition to serviceworkers, which is intended
                for direct use.
  slightlyoff: serviceworkers is mainly used for push notification
               libraries
  slightlyoff: had same debate.
  slightlyoff: Unwillingness to limit the potential audience for the
               feature, and difficulty for devs
  slightlyoff: in handling two paths.
  slightlyoff: We haven't seen ppl by and large making appcahce part
               part of their tools.
  slightlyoff: Have seen ?
  slightlyoff: As soon as tools and platform assume it, and ppl are
               on https, when TOS is easy and assumed.
  slightlyoff: We're rolling out insecure-http-ui
  slightlyoff: If you have a web page that loads over HTTP, will be
               marked as insecure in the browser, in 2017
  slightlyoff: We should expect that insecure contexts will go away
  <esprehn> "Insecure by default http UI"
  <esprehn> As in all pages over http (not https) will have a scary
            red warning
  <gregwhitworth> slightlyoff: yes they are on https

  Scribe: nainar

  fantasai: It makes a difference for professional sites, but there
            are other parts of the web who are learning/doing their
            own thing - those people are not going to be on HTTP2 -
            they don't care if browser is secure.
  fantasai: They aren't keeping up with latest tech/ library hotness.
  fantasai: They are going to have keep up with fragmentation.
  slightlyoff: Those devs are experiencing that web has all the APIs
               - they are already hitting discontinuity.
  slightlyoff: There is a large gap that they have to know about.
  fantasai: These people are not really trying to do stuff like
            geolocation, I don't have a strong opinion for this.

  Scribe: fantasai

  fremy: Houdini is to fill gaps, if we say you can fill gaps but
         not everywhere, then you have a problem.
  slightlyoff: You always have that because there are old browsers
               that exist.

  Rossen: Let's bring topic to closure
  Rossen: We can try to make a resolution, we have 3 members of TAG
          in here.
  Rossen: Can gage their feedback on the resolution, or we can table
          issue and move on cuz doesn't seem like we are ready to
          make a decision one way or another.
  Rossen: iank has a few more examples to support the topic.
  Rossen: Also I'm afraid this will provoke more discussion.

  Rossen: As you're doing demos, please make an argument one way or
          other an stick to it? :)
  iank: Just wanna show pretty demos.
  [iank shows off ripple effect]
  <surma> (here are the two demos:
https://github.com/GoogleChrome/houdini-samples/tree/master/paint-worklet)
  iank: Because we don't have properties and values hooked up
        correctly, using background-image.
  iank: We're getting typed OM image here, then using canvas
        drawImage command.

  Rossen: I suggest we add this as a TAG topic.
  Rossen: Doesn't seem like we'll object to TAG's recommendation.
  Rossen: Anything else on this?
  iank: I probably need to head out to NY to work with Domenic.

Loading worklets declaratively
------------------------------

  Rossen: Issue about loading worklets declaratively.
  iank: Wanted to do this in a later draft.
  fantasai: Is there some complication to doing it now?
  Rossen: I think declarative part has been constant feedback from
          developers.
  Rossen: If at least we acknowledge and have a section in the spec,
          that would be helpful.
  fantasai: Sometimes a declarative feature is complicated to
            define, but if that's not the case here then just go
            ahead and define it, will be helpful to developers.
  iank: Proposal here is <link href="paint.js" rel="paint-worker"/>
  iank: If there's no objection to that, could add it.
  fantasai: Does this belong in markup or style?
  fremy: It increases load time to put it in CSS file.
  fantasai: Yeah, but in some cases you want to encapsulate style in
            the stylesheet files.
  iank: I'd need help for that, defining the syntax.
  fantasai: Something like what's proposed in the issue seems fine.
            Maybe use a space, e.g. @import <keyword> <url>.;
  Rossen: How much implementation do you think you already have with
          this?
  iank: Quite a lot?
  iank: Main thing remaining is loading script as a module, team in
        Tokyo adding that this month.

<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
 <tr>
        <td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
  <td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
  </td>
 </tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>

Received on Sunday, 5 March 2017 16:32:17 UTC