- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 5 Mar 2017 11:00:12 -0500
- To: public-houdini@w3.org
- Cc: www-style@w3.org
=================================================
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