Technical Architecture Group Teleconference -- 01 Oct 2014

<wycats> On my way, running late

<wycats> Hiiii

<virginie> note that I have created some material to discuss here https://www.w3.org/Security/wiki/images/9/98/Web_Authentication_and_other_security_services.pptx

<dka_air> ok try https://purl-app.com/uhsh43uo

<dka> ok

<wycats> Man London traffic in the morning is bad news

<dka> trackbot, start meeting

<trackbot> Date: 01 October 2014

<Domenic> ScribeNick: Domenic

dka: we are about to send over some technical feedback on the EME spec
... one of the points of discussion yesterday was about how in some jurisdictions it's illegal to do security testing of DRM mechanisms
... wondering if we could have some kind of process lever, similar to the patent policy, to compell W3C members who are part of the EME group to agree not to sue companies or individuals doing this kind of security testing
... a good point of discussion between the TAG and the AB, as a new kind of policy-level thing

virginie: are you confident this is illegal?

Domenic: yes, anti-circumvention law in the DMCA in the US

twirl: actually that's very controversial. In theory if you prove you have no intent to violate copyright, you wouldn't be in trouble. But in practice it is used a lot.

<twirl> http://en.wikipedia.org/wiki/United_States_v._ElcomSoft_and_Sklyarov

twirl: if I were a security specialist I would be scared

dka: we thought this would be good to bring up because it's not a part of the technical feedback we want to give, but it is important feedback we want to give, if possible. We are not lawyers so we are not sure, but we wanted to bring it up.

<virginie> https://www.w3.org/Security/wiki/images/9/98/Web_Authentication_and_other_security_services.pptx

<virginie> https://www.w3.org/Security/wiki/IG/webcryptonext_workshop

virginie: (reviews slides)
... it was asked which features you would be willing to contribute to in the WG?
... (reviews wiki link)
... it was unclear where to put new topics as they were raised; this is a more general W3C issue

<virginie> http://lists.w3.org/Archives/Public/public-web-security/

virginie: there were lots of non-members involved in the discussion, so we decided to have the conversation on public-web-security

Domenic: does webcrypto not have a public mailing list?

virginie: it is readable to all, but not writable to all
... also we did not want to disturb the progress on finalizing webcrypto

Domenic: sounds good :)

virginie: the web security interest group does not have resources at the moment

(next slide, "Other topics")

<dka> Domenic: how much interest was there from implementers on new features for web crypto?

virginie: definitely Microsoft is interested in having credentials or sensitive information being stored in something that is external to the browser
... Mozilla already has an implementation to integrate with <secure> element, but they are not interested in standardizing it

<dka> https://wiki.mozilla.org/WebAPI/WebNFC#Fifth_iteration:_Secure_Element_.28Firefox_OS_v2.2.29

virginie: we could define a way to integrate with other secure (authentication) services, which could offer some of the stuff a <secure> element could offer, but we would want it to be as open as possible

<dka> cf http://www.w3.org/TR/nfc/

virginie: FIDO alliance is interested in secure tokens

Domenic: but they're not a browser vendor, right?

virginie: right
... unclear whether these next steps are a high priority in the browsers

Domenic: I am scared that you guys will do good work coming up with cool things and then it won't be implemented in browsers

<virginie> are you talking about http://mikewest.github.io/credentialmanagement/spec/

yes

(Domenic asked about interest within webcrypto about that proposal)

virginie: there is nothing too security-related here; we didn't have a chane to discuss it
... also unclear where it should go
... maybe webapps
... probably doesn't need cryptographers to review it
... maybe webappssec
... but once again no security concerns, it's basically about managing data

<wycats> adoption hacks 👍

Yves: webappssec would be a nice place to have this kind of work
... they could help review to avoid e.g. exposing credentials when you don't want to

<scribe> ScribeNick: wycats

Domenic: good job getting it over the finish line. I understand it was long and hard.
... and shipping everywhere is good

virginie: it's not done yet

Domenic: it's shipping!

virginie: we have to decide whether to include auth in the WebCrypto charter
... we could use help to avoid creating thousands of working groups
... your advice would be helpful
... would you create a new auth WG?

Domenic: it really depends how people want to work
... for example the mega-web-apps WG seems to work fine
... other people may not

wycats: it probably depends on whether the exact same group of people in an existing WG is the same group that needs to work on another work item

dka: unless someone doesn't WANT to work on something, expanding the reach of an existing group seems better
... <thanks virginie>

<virginie> thanks for listening, will keep you informed about the next achievement of chartering discussion

Yesterday's event

dka: where should we tell people to engage if they're interested
... specifically engagement on our developer activities

mnot: perhaps we want a repo for meta-issues

wycats: opening issues about developer meetups on github is weird
... I think specifiction is the new mailing list

mnot: who runs specifiction? w3c?

dka: robin

dka: so specifiction
... I feel like it should be an issue on Github

Domenic: I like Github
... instead of having many mailing list, it seems Specifiction / Discourse's model is one big list
... Github is a place to talk about concrete issues

wycats: The way Ember uses Discourse is as a place for unstructured comments that can get routed to Github Issues

Domenic: this is different from the WHATWG's use of mailing list

wycats: it's good to have a sense of what goes on Github, Stack Overflow, etc.
... but if you just semi-automatically close issues on Discourse, people feel bad
... this was our experience in Ember

dka: it seems good to have a developer outreach component to our f2f meetups

wycats: it seems like the group of people who show up are from a closed circle

dka: it depends on the city

wycats: I think that JS users are our dominant audience

dka: last night about 1/2 the audience didn't identify as JS developers
... so what's the topic in Discourse?

Domenic: "standards / developer interfacing"

<dka> darobin ready to join us?

<darobin> sure!

<darobin> do I skype you?

<darobin> or webrtc something?

<mnot> http://w3ctag.github.io

URL

wycats: the optics of this are very bad

Domenic: please proceed Robin

darobin: there's a lot of ground to cover
... the core of the issue is whether the HTML specification can reference the URL specification normatively
... and in particular whether it's the WHATWG authored version or the W3C copy of it
... from a technical perspective I think we're ok
... the HTML spec is pretty modular
... but there are more complex social and political issues

dka: this is related to an effort to get the HTML5 spec published
... I had asked Philippe if the TAG could help
... I had a goal of trying to figure out where we go from here
... the initial feedback I had from Philippe is that we need a URL spec in W3C space
... so we talked about using the same approach as the DOM spc
... it's not a copy

wycats: in what important ways is it not a copy?

dka: it's a reprint
... but I didn't realize that WHATWG agreed to snapshots
... and that there was ongoing IPR efforts
... I don't think it was the right approach

wycats: in what way?

dka: because they were pointing to the CG W3C agreement
... and a stronger approach would be to use the W3C patent policy

wycats: it was not clear to me before that the normative reference requirements involve a policy that is as strict as the W3C

dka: moving on...
... we thought maybe there was a middle ground
... to make it explicit that the spec was a reprint
... but to get the stronger IPR from the Web Apps WG
... it feels like we almost got there

wycats: am I correct in understanding that the current state of the debate is about which CSS stylesheet is applied to the document?

dka: that would be very silly

wycats: I agree, that's why I phrased it that way ;)

darobin: there are several issues here
... 1) the core technical problems with URL
... it is far from perfect
... we have browsers that are not aligned with it
... how do we unify URLs in browsers with how they are used in other systems
... we probably can't solve it quickly
... 2) dka said that there was a controversy about what HTML needs to ship
... and this was framed as requiring a W3C spec

<darobin> http://www.w3.org/2013/09/normative-references

<Domenic> http://www.w3.org/community/w3process/track/issues/124

darobin: the current normative reference draft provides a set of considerations

timbl: indeed. I was misquoted.
... WHATWG specs can be referenced, but there are case-by-case considerations
... that are defined by the normative reference guidelines

wycats: the mailing list post said "However, based on my conversations with Consortium staff last week, the Director will NOT permit a Proposed Recommendation to include a normative reference to a WHATWG spec"
... and it would have been good to get clarification

timbl: it was hard to figure out how to reply
... for example marcos asked why W3C won't accept WHATWG as a peer org

Domenic: I would like that to get resolved

timbl: for example, when you look at the WHATWG charter, it says it's a closed WG by invitation only
... it's good to know the clear process
... the WHATWG advertises it as an invitation-only group

darobin: my personal analysis is that the way that HTML interfaces with the URL spec is sufficiently modular and orthogonal that it's ok to reference something we know is going to be updated
... Domenic and I worked hard on figuring out a way to do joint applications
... there are some issues right now but we can find agreement
... I thought the WHATWG did a friendly thing by handing over DOM parsing to W3C

<Domenic> domparsing.spec.whatwg.org redirects to https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html

dka: I think it's good to have HTML5 in the W3C

<darobin> and I heartily applaud that

<Domenic> as it was realized the W3C is doing a better job there

dka: enterprise IT consultants want to know that it's stable

timbl: people working in the government want to know if they should revise their procurement policy

dka: they find it important to know

wycats: nobody is waiting for HTML5 to ship in order to use features that are post-HTML4
... I think it is self-evidently absurd to claim anything of the sort

darobin: we're not going to get agreement
... I would like to get it to REC to free up resources

Domenic: a core issue is that it's a big web and many orgs doing many things
... it's unnecessarily combative

<Zakim> darobin, you wanted to try to process the three aspects of this separately and to close that rathole

wycats: the high order bit is whether people are implementing

timbl: let me tell you a story

<darobin> [timbl explains how W3C was the WHATWG before the WHATWG was cool]

<dka> Correction to what I said - I think it’s good to have w3c html5 go to Rec.

timbl: you said the high order bit is that it's where "cool things are happening"
... but what about closed membership?

<darobin> +1 to Domenic

Domenic: I think the WHATWG meets the criteria by any definition
... there is just a terminology issue

<dka> +1 as well, with explict respect to URL

dka: I think WHATWG meets the criteria 100%
... especially for URL

mnot: I have historically been circumspect about the WHATWG
... it would be ok if it was closed to browser vendors
... but with a clear governance model
... but if the lawyers at browser vendors are ok with the WHATWG, it seems fine

<mnot> http://tools.ietf.org/html/rfc2026#section-7.1

mnot: there is precedent for incorporating proprietary specifications

wycats: and proprietary standards are strictly worse than what the WHATWG is doing

mnot: I don't think the high bar is actually required

<darobin> Domenic: and if you look at the OpenStand principles, I think it is very clear that we [the WHATWG] actually adhere very strongly to those

obligatory http://imgs.xkcd.com/comics/standards.png

dka: what does the IETF think

mnot: we'll clean up whatever mess you guys make

<dka> :)

mnot: we are eagerly awaiting the results
... many IETF people think that this could be solved via a preprocessing step
... where "this" means the difference between the WHATWG spec and the the RFC
... there is a difference between URIs and URLs

Domenic and timbl: no

wycats: real-world cases need to worry about the browser's version of "URL"

timbl: keeping things as a preprocessor ("liberal" vs. "conservative" spec) is a good idea

<Yves> wycats, which browser version. The unparsed one or the parsed one? (or both)

Yves: the semantics of a URL defined in the platform

which includes both

wycats: 100% of web servers in the real world do some error correction

darobin: we had to write a special server for the platform test

mnot: the WHATWG can own URL

wycats: I like how the HTML5 parser works with "error states" + error correction

<darobin> http://galimatias.mola.io/

wycats: I think it's analogous to what Tim wants

<Domenic> there was also one in C

Domenic: can we normatively reference the WHATWG?

dka: the TAG seems to have consensus
... maybe we can scope to URL?

Domenic: we can try to make it precedent
... get rid of the bad blood

dka: the bad blood is there because there is a perception that that the WATWG actors have negative actions
... we have to end the fighting

wycats: it's not doing anybody (the WHATWG included) any favors

dka and Domenic: confirm

timbl: things have changed in 25 years
... we knew we were forking the IETF

<dka> correction “also because there is a perception that the whatwg actors have ..."

<dka> key word “also” - there has been lots of negativity on both “sides” of this topic

<dka> tim: [suggests something needs to happen for w3c to consider whatwg to be a “first class standards” body]

<dka> [discussion now on what that would be]

<dka> My pereception is that it is a first class standards body.

<darobin> timbl: maybe we could look through the openstand principles and see if we would want to add things, to define how we should interact with any group

I think it's very destructive to say that a standard that is interoperably implemented is "not a standard"

<dka> Tim is talking about a specific thing when he mentions OpenStand: http://open-stand.org

<darobin> more specifically http://open-stand.org/about-us/principles/

<dka> Indeed.

<timbl> TLDR “I was a pretty respectful teenager”

TLDR "When I was a boy, children had respect for their elders" :P

wycats: is strict patent policy actually a requirement for normative references?

Domenic: points out that non-REC docs don't have patent commitments

darobin: it would be awesome if the W3C would help the WHATWG with patent commitments
... for example, an experimental attempt to get patent commitments through the process

<dka> +1

Domenic: via the CG FSA form

dka: telefonica is prepared to make a commitment through that mechanism

<dka> confirmed

Domenic: helping the WHATWG getting a better patent process in place is a good longer-term work item
... it seems like a new process would be helpful

<dka> https://pad.w3ctag.org/p/resolutions-1oct2014

<dka> A proposed resolution here: https://pad.w3ctag.org/p/resolutions-1oct2014 - please help me wordsmith this so that we can have lunch.

<darobin> [I just want to go on the record as strongly supporting the idea that we as a community need to do a much better job at flagging what's implemented and what's a proposal]

<Domenic> +1

wycats: if the W3C is pointing at a WHATWG spec that is interoperably implemented, it can sure it will not change

<dka> http://www.w3.org/2013/09/normative-references

<timbl> wycats, IPR in OpenStand is not very strong but is there — Affirming standards organizations have defined procedures to develop specifications that can be implemented under fair terms. Given market diversity, fair terms may vary from royalty-free to fair, reasonable, and non-discriminatory terms (FRAND).

<dka> resolution: With regard to normative references from w3c documents, we agree that the whatwg adheres to open standards principles and that in principle there is no barrier to w3c documents refeferencing whatwg documents normatively. In the specific case of URL being rerefenced from HTML5, we recommend that the W3C HTML5 spec should reference the whatwg URL specification and that between W3C and WHATWG we should continue to resolve any remaining technical and editorial

<dka> issues in the spec.

<dka> resolution: we are heartened that the WHATWG has made moves towards having a stronger IPR policy. We propose to issue a call for patent commitments via the WHATCG's FSA patent commitment form: http://blog.whatwg.org/make-patent-commitments

<dka> hm...

<dka> This is the raw IRC log: http://www.w3.org/2014/10/01-tagmem-irc

Modularization / future of specifiction...

darobin: I was hoping to have a prototype implementation of the ideas
... I'm behind schedule
... The feedback from the EWS was very positive
... TLDR modularize HTML to make it easier to contribute to
... put everything on Github
... use Specifiction for broad feedback
... specific feedback on Github
... There was a general discussion about the "CSS Problem" aka millions of standards
... Another thing that came up was that there's quite a bit of interest
... people want to submit proposals
... also we want to standardize on bikeshed

wycats: I talked about feature flags once features are being actively implemented so you can build a "canary" version of the spec vs. a "release" build
... as a way to enable a more "living standard" approach with more stability marking

<Yves> stability markings... and implementation reports linked as well? (ala caniuse with a finer grain)

wycats: Yves: yes, you would be able to attach implementation reports to a feature name

dka: it seems like there's a lot of synergistic work going on

darobin: we should all be paying attention to what each other are doing

my closing slide from my talk yesterday: http://note.io/1rGZOo3

dka: so what's the plan?

darobin: some tooling and then some experimental work on pulling out a few initial things

Domenic: it seems weird to have the W3C do the modularity work
... given that it originates with the WHATWG

darobin: it's more of a proof of concept
... some of the work will be on new features

plinss: is this like the CSS model (for new work only)

darobin: we'll start that way
... but it's important to know what's been superseded

<Domenic> Domenic: be clear this is proof of concept so as not to confuse developers, other standards people, etc.

<Domenic> darobin: sounds good

wycats: this isn't intended to be hostile, so let's make sure that we don't come off that way by accident

Domenic: I liked the way you described the different venues for feedback

<slightlyoff> morning all.

<dka_> hi alex!

<dka_> we are about to start in on extensible web report card brainstorming

<dka_> can you join?

<slightlyoff> yep

<dka_> domenic will be live-editing an etherpad and we hope to transfer this over to a github repo before the end of the day

<Domenic> https://pad.w3ctag.org/p/ew_report_card

<slightlyoff> and you still can't participte in serializing something that submits a file

<slightlyoff> do y'all have a camera on? I can't see London

<slightlyoff> no worries

<slightlyoff> isn't there work on ambient light sensors?

<slightlyoff> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/AAtN0xjI9Gc

<slightlyoff> brb, coffee

<slightlyoff> back,s orry

<slightlyoff> so I'm not 100% sold that ASM.js plays well with others; its default model makes FFI hard from JS and doesn't exactly have a mapping to DOM

<slightlyoff> it's good, and enabling, but I'm not sure it's "there"

<slightlyoff> minor quibbles

<slightlyoff> on it

<Domenic> wycats: see slightlyoff's take above ^

slightlyoff: 👍

<Domenic> wycats: move to is disruptive in class?

I am concerned

because I am unsure if FFI ever can be optimal

what do you mean by mapping to DOM?

I agree that these are good things to research

<Domenic> it seems like it could be as optimal as the C++ DOM <-> JS mappings that exist

sure

<Domenic> you should be able to get s/C++ DOM/asm.js

dherman: what do you know about this?

could in theory be more optimal

since you could imagine stronger inlining

but I don't know

<dherman> we've talked about ways to improve the FFI

<dherman> I agree it's an area that needs research

<dherman> it's better than its competitors at FFI ;)

lolol

<slightlyoff> "better than competitors at FFI" -- I want that shirt

<slightlyoff> "ASM.js -- it's not SWIG"

<slightlyoff> brb

<slightlyoff> agree that the event loop is something we can call out

<slightlyoff> also, coordination with other threads

<slightlyoff> e.g., render thread

<slightlyoff> audio thread

<slightlyoff> etc.

sniffing is not exposed

would be a trivial API

window.sniff(blob) :P

window.👃(blob)

<slightlyoff> back, sorry

welcome back

<slightlyoff> what is this URL?

<slightlyoff> can someone paste it here?

<scribe> unknown

<Domenic> http://w3ctag.github.io/extensible-web-report-card/ but wanted it auto-generated from markdown so that's not good...

<slightlyoff> thanks

<twirl> looks ok to me

<twirl> except fonts

<slightlyoff> so a question

<slightlyoff> the Scrolling section says "scrolling is a fundamentally native capability", but I don't think this is true

<slightlyoff> input handling is

<slightlyoff> scrolling is what a system does in response to input handling

<slightlyoff> disconnected = \

<slightlyoff> will get coffee = )

<Domenic> wycats ^

hello

<Yves> disconnected as well, needs to drop soon anyway

<slightlyoff> so I'm pretty sure that the bit that isn't being currently standardized for push is the low-level protoocol set (e.g., GCM)

what I mean is that what happens when the user moves his finger is always intermediated by the system

and trying to reinvent that in JS is insane

and basically impossible to do reliably

finger/mouse/etc

<slightlyoff> that doesn't make sense to me

then I'm being unclear

<slightlyoff> the reason we can't do it reliably is that we haven't been given events

<slightlyoff> at least not until recently

deny

we have the events

the user moved his finger

<slightlyoff> no, we don't

how fast should the content move in the viewport?

<slightlyoff> I know from an engine perspective that we weren't giving them to you

<slightlyoff> up to the program.

how do you know if the user meant to scroll or click?

it's actually NOT up to the program

<slightlyoff> sure it is

you do NOT want to do that

absolutely not

<slightlyoff> I *MIGHT* want to do that

you might

it is good to be able to

<slightlyoff> and when I do, the system damned well better let me

but in most cases you want the system to decide things like momentum, what happens when you get to the top, etc.

because they are OS-wide policies

and you would like consistency with the OS

trying to reverse engineer the OS policy *per device* and write JS libraries is crazy

people do it and it's horrible

they end up just applying the iOS policy to android

etc.

and when iOS tweaks the global policy, you're stuck with an old algorithm

<slightlyoff> sorry...was getting coffee

<slightlyoff> so you get to decide: do you want to empower developers or not?

you would like a way to delegate to the native policy but still understand what is happening so you can put things on the moving element

deny

layering bro

<slightlyoff> if the answer is yes, then we must accept that there will be both high and low level

there is always an intermediate layer

<slightlyoff> and not deny developers the low-level power just because there is high-level interaction

which does the native functionality with hooks

that is the hardest part of web dev

<slightlyoff> I think you're used to having your SDK fused into the platform

it's where "rebuilding the stack" happens the most

<slightlyoff> in a really unhelpful way

disagree

people want the ability to have consistency with the native SDK on the web

<slightlyoff> look at "pull to refresh" as a gesture

not always

but sometimes

<slightlyoff> it didn't come from iOS

<slightlyoff> or android

<slightlyoff> it came from programs having the freedom and power to do the Right Thing (TM) becaues they had low-level, synchronous access to events

not originally

you're misunderstanding me but I don't know why

I absolutely want people to have access to the low level

absolutely 100%

<slightlyoff> great, then we agree

but I think you can assume that once you've done that you're "done"

or once you've done that plus the high level you're "done"

and I'm saying there's a specific interaction that is the hard part

that we do very poorly

which is the interaction between content and native display/interactions

<slightlyoff> thinking specifically about scrolling, it's hard

<slightlyoff> so there's a threaded scrolling system in most impls

<slightlyoff> where a texture is sent to a separate thread to move in order to prevent main-thread jank

<slightlyoff> (this is slow, BTW, but less janky)

<slightlyoff> "native" apps don't do this

<slightlyoff> they just implement scrolling in direct response in their input handling thread

<slightlyoff> and now we're in a place with beforescroll that we can hint the system to say "no, I want to behave like a real boy and do my scrolling on the main thread"

<slightlyoff> "don't context switch me, bro"

<slightlyoff> this is both potentially quite a bit faster/more-responsive and more like what "regular" programs can do

<slightlyoff> but it means taking over the control

<slightlyoff> by _switching model_

<slightlyoff> the alternative is to expose the off-thread scroll behavior and...I dunno...invent a "scroll worker"?

<slightlyoff> but that's not actually something anyone wants

<slightlyoff> and we frequently have this issue where control means switching systems or models

<slightlyoff> e.g., JS and __proto__

<slightlyoff> you go slow path for using it

<slightlyoff> it's the price of control

<slightlyoff> there seems to me to be something fundamental in the idea that you'll have 2 systems and, as much as everyone hates it, it's unavoidable

I agree

<slightlyoff> I think dherman makes this point frequently and better than I can

I think this point of interaction is the key thing that triggers stack rebuilding

so if you don't want people to have to rebuild stacks

you need to contend with it

<slightlyoff> yeah

<slightlyoff> and there needs to be general advice to implementers in the form of "get over it"

similar things happen with form elements

you have to choose between "black box" and "I'll do it myself"

<slightlyoff> yep yep

<dherman> what'd I do?

<slightlyoff> hah