WebDriver F2F TPAC 19 September 2016 -- 19 Sep 2016

RRSAgent: Good morning.

RRSAgent: Are you thick?

RRSAgent: Please draft the minutes.

RRSAgent: create the minutes

RRSAgent: please set these logs world-visible

RRSAgent: please draft the minutes

<scribe> Scribe: ato

<scribe> Scribe: Andreas Tolfsen

<scribe> ScribeNick: ato

<juangj> RRSAgent: please draft the minutes

<juangj> that didn’t work, none of you is present

RRSAgent: please draft the minutes

Sometimes hard to tell if RRSAgent does the bidding because of latency.

RRSAgent: please draft the minutes

MikeSmith: Morning coffee break 10-11, we need to pay respect to this.
... Make sure to break at 10:30.

AutomatedTester: We’ll start with introductions.
... I’m David Burns, editor and now chair. Work at Moizlla.

mkwst: I’m Mike West. Work on Chrome. Have not done work on WebDriver, but interested.

rbyers: Work on platform predictability. Just observing.

ToddRiefstack: Work on performance with Microsoft.

mikepie: Want to talk about extensions tomorrow.

JohnJansen: Work on the WebDriver implementation at Microsoft, Web Platform Tests, and a lot of stuff that’s not relevant.

juangj: Work with Google. Work on Google’s scalability of WebDriver internally.

paul: I’m interested in listening and wonder what’s happening in this space.

<scribe> [unknown observer introducing himself]

[another unknown observer introduction]

wilhelm_: My name is Wilhelm, former chair. Used to work with Opera. Now I’m running my own consultancy.

ato: I’m Andreas Tolfsen. I work for Mozilla. Used to be at Opera with wilhelm_.

jgraham: I work with geckodriver at Moizlla.

brrian: I work with Apple. On safaridriver.

sam_u: Hi, I work with Google.

simonstewart: I’m Simon Stewart. Creator of WebDriver, co-editor of the specification.

State of the Union

<juangj> https://www.w3.org/wiki/WebDriver/2016-TPAC-F2F

<AutomatedTester> https://www.w3.org/wiki/WebDriver/2016-TPAC-F2F

AutomatedTester: The last meeting was in Redmond, where for the first time we had Apple join us for a F2F.
... A number of items were discussed.
... Key item discussed was actions, where jgraham discussed how things were going to look.
... Since then we have had the first part of that landed in the spec, which is hte transposing of the matrix.
... Before it gets handed over to a dispatcher, where events are dispatched.
... The dispatch part is currently being reviewed.
... Is that correct?

jgraham: The pointers thing is still in review.

AutomatedTester: I didn’t land it because there might be some comments.
... Hopefully people have started reading that part, as that was really the last main item that we were going to try get landed before TPAC.
... A contentious item we’re going to discuss today are capabilities.
... From the specification PoV, we are down to the devil-in-the-detail kind of issues now.
... As for the test suite, since the last F2F there hasn’t really been much work on that.
... Because of things that have happened at Mozilla, we have been forced to focus more on our own implementation.
... That is the current state of the specification and the test suite.
... Am I missing anything?

JohnJansen: Should we discuss the test suite tomorrow maybe?

simonstewart, AutomatedTester: Yeha.

<MikeSmith> https://www.w3.org/2016/05/browser-testing-tools-charter.html

MikeSmith: Everybody should look at our current charter.
... There’s nothing interesting, apart from the end date.
... Ideally we would like to go to REC before end of March.
... Looks like that isn’t going to happen.

AutomatedTester: Should we make that the next agenda item?

ato: If we want to renew this we probably want to add Safari.

MikeSmith: Yes.

simonstewart: And Selenium, as an intermediary.

ato: Yes.

<Zakim> MikeSmith, you wanted to comment

JohnJansen: There’s a community/interest group meeting on Thursday.
... I thought the console API would be under this.
... Do I have the wrong impression?

jgraham: I don’t know what the point of having a WG for the WPT.
... We’re not aiming to produce specification text.

JohnJansen: I think that group could do with the direction of a group.
... To align browser vendors with the work going on there.
... No one has direct responsibility for it.
... It’s hard to know what the expectations are.
... It strikes me as something we might be able to improve.

jgraham: Typically so far, the people in this room has had very specific WebDriver experience, which is not necessarily the same group of people you want giving input to WPT as a whole.
... It’s not clear from a human point of view that they are the same group.

JohnJansen: I agree. There’s an interesting Venn-diagram.

AutomatedTester: What you want, is a task force that WPT is actually maintained and driven forward?
... Historically, we have jgraham doing a lot of the harness work.
... And the infrastructure around that.
... And then the spec owners helping out.
... It would be good for specs to have actual tests.
... Things appear to be falling between the cracks.

jgraham: I have a feeling that this is a discussion for Thursday.

ato: It also feels like it’s a mistake to increase the charter of the group now before we publish.

jgraham: What are the success criteria?
... I’m thinking implementations.
... geckodriver is one implementation.

sam_u: We are making changes, but they are hidden behind a flag.

simonstewart: Selenium another.

(third)

JohnJansen: I don’t see why we can’t hit March.

jgraham: I think I disagree, as people implement the spec we will find things that people haven’t thought about.

[agreement]

MikeSmith: We don’t want to be in CR any longer we want to be.
... If we want to be the end of March, we need everything done by the end of February.
... We can always extend.
... But I always almost say no.
... So it’s hypocritical of me to call for it.

AutomatedTester: We have certain parts that are solid.

jgraham: In practice tests are written when implementations are written.
... People don’t generally write tests for the sake of writing tests.
... From our point of view, we haven’t written tests because we can’t run them in automation for build system issues.

[Mozilla discussion]

ato: I’m worried about the process of pushing fixes after REC.

rbyers: The activity can always continue on Github

MikeSmith: There isn’t a great process for that.

[discussion about process]

MikeSmith: For some organisations it’s important to always have a link to the spec text as it was when it was pushed to Rec.

<Zakim> MikeSmith, you wanted to comment about scheduling for transtion to CR and to Rec

rbyers: It’s always an option to hire a contractor to write tests.

sam_u: Yes, we have a lot of tests we could upstream

ato: But it’s not just as easy as upstreaming. It’s a lot of work to review tests against the spec, maybe you find bugs, you need to fix spec, iterate.

JohnJansen: I think we should keep the current date.

MikeSmith: We also need people to review those.
... With WPT the biggest frustration is review.
... It’s all volunteer work.

ato: At Mozilla we review W3C related changes equally to internal changes.
... Practically changes to WebDriver W3C bits, changes are being reviewed.

[talk about review process in WPT]

juangj: WebDriver 2

ato: Console API, extensions, meda, web bluetooth

MikeSmith: Evaluate manual tests in WPT and how we can automate them.
... It’s not just a software problem. we need to find out what things people have _not_ written tests for because they knew upfront they couldn’t automate.

<scribe> ACTION: rbyers and sam to investigate possibility of investing in the tests. [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action01]

RESOLUTION: We are keeping current deadline of pushing to REC in March.

https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/WebDriver/status

ato: ↑ geckodriver implementation status

JohnJansen: We wrote an app for matching annotations in specs to tests.
... We applied it to WebDriver because it’s a relatively contained spec.

mkwst: I would be interested in this.
... It’s not clear from a lot of the specs I’m working on that we’re testing the right things.

AutomatedTester: Break until 11.

RRSAgent: please draft the minutes

RRSAgent: When is midnight?

RRSAgent: You suck.

AutomatedTester: Is there anything people want to add to the agenda?

<AutomatedTester> https://www.w3.org/wiki/WebDriver/2016-TPAC-F2F

<jgraham> MikeSmith: Any idea what the problem with RSSAgent is?

<Ms2ger> RRSAgent: please draft the minutes

Full list of meetings from previous meetings: https://sny.no/bttmin

juangj: Security wrt. certs

sam_u: Send keys

AutomatedTester: Tomororw?

brrian: Yes

rbyers: Keyboard support in Blink people here. I can invite.

AutomatedTester: That sounds useful.

https://www.w3.org/2016/07/13-webdriver-minutes.html

<AutomatedTester> https://www.w3.org/2016/07/14-webdriver-minutes.html#ActionSummary

<MikeSmith> jgraham, no idea what the problem with RRSAgent might be

<AutomatedTester> scribe: AutomatedTester

<ato> RRSAgent: please draft the minutes

capabilities

RRSAgent: draft minutes

jgraham: the best way to start is to document what the requirements are so we know where to compromise
... requirements should be written on the whiteboard (photo to follow)
... from the point of the browser we need to know the endpoint and the configuration items for that browser
... we have a requirement to support multiple UA details in a new session command
... we need to remove as much duplication from the capabilities as possible. E.g. don't have multiple 100mb Firefox addons base64 encoded

ato: are we going to discuss extension points?

simonstewart: yes, we do want to support it.
... there is no such thing as a routing request since a capabilities could route and might not be

jgraham: we can discuss this later
... from the point of view of the UA that should be sufficient. As far as possible we should get as much info as we can without starting the browser. We need to get there before initialising the resources where possible.
... have the ability to be transparent when moving between nodes. Should intermediaries be allowed to remove data?

simonstewart: we need to have something that is either widely used in Selenium or in the spec to main compatibility.

JohnJansen: capabilities from a browser vendor viewpoint, we have the way to get the UA we want on a specific platform or how do we get the UA we want with all the extensions

jgraham: capabilities is routing + configuration but we may need to keep it for compatibility

juangj: remove ambiguity in matching
... for ease of implementation

simonstewart: the ability to feature sniff so we can use mixins when checking what is returned
... we are basing the rest of this discussion on https://github.com/w3c/webdriver/pull/327

AutomatedTester: we need to discuss when items can be removed from the returned list

simonstewart: ease of implementation is missing from the list
... the original design was simple in that the validation was done in local end. The requiredCapabilities was thought of to move the validation from the local end to the remote end.
... we need to have validation on start up (resource allocation)
... Jleyba's PR https://github.com/w3c/webdriver/pull/327

jgraham: [drawing the JSON structure from the PR ^]

simonstewart: the idea is to iterate over firstMatch and merge to alwaysMatch and then start session and if you cant do it, you try the next firstMatch item
... the PR allows validation to happen in the end node, support multiple browser, minimise duplication, transparency, non ambiguous, ridiculuously easy to implement and feature sniffing

jgraham: I have a slightly alternate design based off jleyba's design. I put in the mailing list thread https://lists.w3.org/Archives/Public/public-browser-tools-testing/2016JulSep/0026.html
... [gives example of any browser on linux]
... My alternate scheme [draws on whiteboard] has "routing":{}

simonstewart: people would want to route on rotable

jgraham: is that a thing

sam_u: yes
... the other issue is anything can suddenly become a routing item

jgraham: well chromeOptions and firefoxOptions dont really have anything that allow for routing
... the next item is "capabilities":[{}, {}]
... its like jleyba's item except its just alwaysMatch and not iterating on firstMatch

simonstewart: practically speaking people add ALL THE THINGS when starting

jgraham: [discusses how looping matches in his proposal]

RRSAgent: draft minutes

MikeSmith,we dont appear to be getting drafted minutes but items are being logged

<MikeSmith> worst case, I have a complete local log of channel, and can generate minutes from it later

[discussion on matches vs alwaysMatch + firstMatch]

juangj: let me restate to make sure I understand: routing is a list of alwaysMatch from jleyba's and then move to next node and then do the capabilities/settings key and then do that as a group of if statements to make sure it is correct

jgraham: that is a good description. An intermediary node would only look at routing: and the end node would only look at capabilities:/settings:

JohnJansen: but browsers don't work that way

jgraham: [gives example]

ato: I think both of these proposals are a little too complicated.
... we have 3 items we need. Matrix switching, machine details, UA details

jgraham: I dont think we need to have all items as routing. E.g. browser profiles

juangj: [gives an example on how routing would work on the alwaysMatch/firstMatch

jgraham: settings: would only have the UA items. Routing would direct you to the right machine

juangj: routing gets you to the machine that has what you need and then settings checks the UA is correct or returns NoSessionCreatedError

simonstewart: jgraham's proposal means local end needs to understand the topology of the network.

jgraham: I don't understand why anything needs to know the topology

simonstewart: this feels like it's going to be difficult for localend people to understand
... current implementations know how to look capabilities: key

AUtomatedTester: no one is currently using the current spec requiredCapabilities key. I went and spoke to browserstack/testingbot/saucelabs and google to understand their use

simonstewart: this is great! this simplifies things

ato: it is easy to retrofit the PR to the current implementations for a form of backwards compatibility
... it is more difficult for local end implementors (Selenium Project) for the 2nd proposal
... What would we do to existing implementations

simonstewart: we would put requiredCapabilities into alwaysMatch and firstMatch into desiredCapabilities

juangj: browser profiles can still be duplicated

AutomatedTester: we could always use something like jgraham's either idea of a browser: {}

simonstewart: or we can have a way of store this profile on a server somewhere and a value pointing to it

ato: we dont get many profile users

jgraham: not sure, it was a big request in GeckoDriver

ato: people are more interested in setting prefs or extensions

jgraham: well in the 100mb profile case, the extension is 99mb

ato: with Firefox 47 we had to add extension end point to allow people to install addons later on

simonstewart: [describes historic Firefox XPI disklayout]

ato: Mozilla is now copying what chromeOptions is doing to simplify things

JohnJansen: but not in the spec?

ato: yes, this is Mozilla specific
... where would chromeOptions/FirefoxOptions go?

simonstewart: in alwaysMatch

ato: what happens if you send {alwaysMatch: someRandomKey:""}

simonstewart: NoSessionCreatedError is returned since it should fully do all the keys within that

[discussion about adding random items as the top level key]

[e.g. access tokens for networks]

ato: we should have a note for how a local end _may_ write this

RESOLUTION: Move forward with jleyba's PR

<scribe> ACTION: Note/Example on how this would be used [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action02]

<ato> Example of example: http://w3c.github.io/webdriver/webdriver-spec.html#capabilities

<ato> Example 5

<scribe> ACTION: DBURNS clean up jleyba's PR and get landed and then iterate as issues come up [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action03]

Automated: CAn things be removed when we return capabilities?

simonstewart: no, we need backwards/forwards compatibility

RRSAgent: draft minutes

<simonstewart> +present

RRSAgent: draft minutes

<juangj> ArrrrrArrrrSAgent

Returned capabilities

<ato> brrian: We are ready to begin again.

<brrian> ato: I'll be back in 10 mins or so, don't wait

simonstewart: there are 2 possible options on the table
... 1) take the capaibilities that are matched and return what has been met and extra UA supported capabilities

ato: So only the matched capabilities?

simonstewart: yes, this allows people to sniff what is returned and then use mixins
... historically we used capabilities to check what is returned and feature sniff before moving on
... given the new newSession details discussed earlier now has the validation on the remote end and we just returned matched
... in the spec we have a handful of things with capabilities in the commands (acceptsSslCerts)

jgraham: we dont want to return large amounts of data, e.g. large profile

simonstewart: we MUST return anything that has a capability name that is currently in the specification

jgraham: should we return we have done it or the value that was set
... e.g. browserName == true or browserName == Edge

simonstewart: browserName == Edge

ato: are we going to predefine a list ?

simonstewart: we want a canonical list and then have the ability to extend it

ato: do we use vendor prefixing?

simonstewart: just pick a string
... what would people prefer?

jgraham: the first option and vendors can change it if they need to. Ideally not to return 100mb profile base64 string

[discussion of current spec text]

ato: if you want to be nice to your user you can send back what the issue is but it does say we to send back a string
... from the practical point of view, for WPT we just check type of the errror not the string

simonstewart: there are multiple ways to fail on startup and this will be the end node talking to the browser (the shim probably)

RESOLUTION: returned object from new session should be capaibilities that are matched and return what has been met and UA capabilities (browser/platform/ssl) and the vendor can decide what is returned

[discussion around what is returned

jgraham: we need to have text in the spec for what capabilities is returned

simonstewart: [repeats resolution to check that is what people want]

jgraham: but do we really want to return proxy: ?

simonstewart: we can look at some of them where we return large things and just return a boolean to say it was done or not
... do we return everything or just what we matched?
... we can say we are using the profile and just the names of the extensions instead of the extension

RESOLUTION: returned object from new session should be the full list of known capabilities with defined serialisation

<simonstewart> Suggested resolution: return “all capabilities matched for the session”, “every capability name given in the spec”, and “a custom subset (which may be All The Things) that the browser supports”

RESOLUTION: return “all capabilities matched for the session”, “every capability name given in the spec”, and “a custom subset (which may be All The Things) that the browser supports”

RRSAgent: draft minutes

RESOLUTION: return object with 2 keys, session_id: ".." capabilities:“all capabilities matched for the session”, “every capability name given in the spec”, and “a custom subset (which may be All The Things) that the browser supports”

<scribe> ACTION: to mention somewhere, over the rainbow, keys injected by intermediary nodes must be namespaced with a vendor prefix [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action04]

<ato> 🌈

<MikeSmith> w00t

<ato> MikeSmith: ++

JohnJansen: what about capabilities that the browsers can do that the developers have no idea about

simonstewart: we used to have a endpoint that used to do that GET /session_id

jgraham: from a local end, are they wanting to support arbitary things?

ato: I cant imagine that people would do that

AutomatedTester: PHPDriver from facebook required people know the transport mechanisms

jgraham: this feels like this is just, you need more documentation

JohnJansen: knowing there is a MS Capabilities end point I can see what is able of doing it without having to look up docs

jgraham: feels like, writing more docs is better than adding a new end point

juangj: why not put this in a /status endpoint

<juangj> (ftr, that was half in jest)

ato: we wont be removing capabilities

AutomatedTester: but we are adding new items

jgraham: if you are using it in an exploratory way there might be vendor specific items
... we could return a link to documentation
... but just returning the keys and no clue of what the values can be in there could be weak sauce
... people still need to then go read the docs

simonstewart: this does sound like docs
... but there is another argument of asking what returning capabilities are available

<ato> “Probably someone is going to have a counter example involving intermediary notes”

ato: what is the granularity? top level?

jgraham: yes, just the top level

sam_u: this could be useful as a service exploring

simonstewart: OSS Selenium grid has a web page and people want to explore those capabilities

jgraham: intermediary nodes can't return this info so it breaks the transparency concept we wanted and discussed earlier

Todd: when I worked in cloud services, it was possible to return meta data from the service
... It might be good to make sure we have documentation

jgraham: I am happy for it to return a full set

JohnJansen: I dont understand why I was against returning the full capabilities

RESOLUTION: return an object with 2 keys, session_id: "...", capabilities: { full list of known capabilities with defined serialisation}

RRSAgent: draft minutes

<ato> AutomatedTester: http://vignette3.wikia.nocookie.net/uncyclopedia/images/0/04/Khrushchev_Banging.jpg/revision/latest?cb=20080805101523

Unsigned Self Signed Certification

<juangj> http://i.imgur.com/CKWJ5wh.gif

simonstewart: things to discuss, capability name and default value

brrian: the default should be no/false as this causes a lot of insecure systems

simonstewart: [discusses the 3 audiences of WebDriver specification]

ato: currently OSS FirefoxDriver defaults to no, chrome defaults to yes and IE doesnt support it

<simonstewart> PageLoadingTest.testShouldBeAbleToAccessPagesWithAnInsecureSslCertificate

jgraham: one question that needs answer, what are vendors allowed

AutomatedTester: Mozilla infosec would like security in depth
... Mozilla would also, if possible, to have a browser notification to say that we have WebDriver running

jgraham: what happens if the person can't launch a session but can hijack a session that is running

simonstewart: if you security conscious you would have code to default it off

brrian: I havent spoken to our infosec

<jimevans_> I, for one, have no issues with a vendor putting up a visible indicator that the browser is being driven by WebDriver.

brrian: it will be really hard to have this in safari because of it's current architecture

JohnJansen: how do you switch it on?

juangj: you do [following steps]

<juangj> [literally clicking one menu option in Safari]

ato: should we have a note about a visual display

all: yes

<jimevans> I also like the safari implementation (manual activation, "pane of glass" over automated sessions.

<juangj> agreed with jim, the orange address bar and break-glass mechanisms are really nice

<scribe> ACTION: add prose to "show a visual display that automation is currently running" to the specification [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action05]

ato: if Apple can't default to true we should have everyone default to false

jgraham: we would need to make this a SHOULD then (which is terrible)

<ato> FTR, what I said was that this discussion is _pending_ on what Apple’s sec team comes back with.

ato: this discussion is _pending_ on what Apple’s sec team comes back with.

JohnJansen: we have ways of working out security threats and security in depth is a good thing but they would let it go

ato: I dont have an opinion either way but I have an opinion on the input type

jgraham: we can do what we want but if the local ends are going to do the opposite then it doesnt matter

ato: what do want, leave it off by default in the spec?

simonstewart: in the spec it should be off
... in the GET and people access bad HTTPS we return a message (InsecureSSLError)

jgraham: in Edge, can you check that you got an self-signed cert?

JohnJansen: not sure

jgraham: so for navigation we need to check

ato: we need to make the page loading part of the spec more generic and unsigned certs should be handled there

jgraham: how does the page load strategy work in Selenium?

simonstewart: on everything, not just Go

<scribe> ACTION: Make Page load strategy more generic [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action06]

<scribe> ACTION: add error code for when we invoke page loading strategy and we hit a self-signed certificate [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action07]

ato: should we also have the user prompt handler return this error too?

simonstewart: yes, we need it in the processing model

ato: I dont think it should be there, we have setTimeouts that we dont want affect

<scribe> ACTION: to add insecure page check where it makes sense [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action08]

<scribe> ACTION: to investigate user prompt handling and insecure page detection to the processing model [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action09]

<ato> moving*

simonstewart: so acceptSslCert: False is the default

brrian: do we want to be acceptInsecureSSLCerts as a key?

<brrian> acceptInsecureSSLCerts

RESOLUTION: change acceptSslCert to acceptInsecureCerts
... change the wording to be SHOULD when processing the acceptInsecureCerts

sam_u: should Chrome be backwards compat?

jgraham: that's your choice

Safe listing domains

ato: previously we discussed instead of a boolean, which is too course, should we be a list?

simonstewart: safe listing is a good idea

jgraham: can Gecko do that?

ato: yes

sam_u: in Chrome this is going to be really hard to do it

JohnJansen: and same with us

ato: do we want to do this or keep the boolean?

simonstewart: we need to a feature for a future spec to allow us to do this

<scribe> ACTION: add a bug that allows safe listing of domains for V2 [recorded in http://www.w3.org/2016/09/19-webdriver-minutes.html#action10]

RRSAgent: draft minutes

Open Bugs https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20860&hide_resolved=1

<juangj> same

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24121

<simonstewart> Level 2 is https://www.w3.org/Bugs/Public/show_bug.cgi?id=24121

<simonstewart> MikeSmith,I don’t suppose anyone has an HDMI to HDMI cable we could borrow? Or a Mac DVI to VGA converter?

<MikeSmith> simonstewart, ask at reception

<MikeSmith> will ask myself as well

<lukeis> RRSAgent: draft minutes

<ato> “I had a dream about what to do after minimising the browser window last night”

<simonstewart> https://github.com/jnicklas/capybara/pull/1744#issuecomment-244200356

<brrian> lukeis: we had a lightning triage session

<ato> lukeis: Lisbon is quite good fun.

<ato> lukeis: It’s a fairly civilised place to hold a conference, although I must admit the conference venue is very W3C-esque which implies terrible catering.

<juangj> not that conveneint to leave the conference center for lunch

<juangj> working as intended

<juangj> didn’t want to forget to resume logging tomorrow

<kmag2> Does anyone have a rough idea of when extension automation will be discussed today? I don't want to take up space in the room longer than necessary.

<ato> RRSAgent: silence

<ato> Meeting: WebDriver F2F TPAC 20 September 2016

<ato> Chair: AutomatedTester

<ato> Agenda: https://www.w3.org/wiki/WebDriver/2016-TPAC-F2F

<ato> RRSAgent: please draft the minutes

- DRAFT -

WebDriver F2F TPAC 19 September 2016

19 Sep 2016

Attendees

Contents

State of the Union

capabilities

Returned capabilities

Unsigned Self Signed Certification

Safe listing domains

Open Bugs https://www.w3.org/Bugs/Public/showdependencytree.cgi?id=20860&hide_resolved=1

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output