09:23:24 <RRSAgent> RRSAgent has joined #browserext
09:23:24 <RRSAgent> logging to http://www.w3.org/2016/09/22-browserext-irc
09:23:30 <Zakim> Zakim has joined #browserext
09:23:50 <Florian> Meeting: Browser Extension CG TPAC meeting
09:24:12 <Florian> Agenda: https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda
09:24:31 <Florian> Chair: Florian
09:24:51 <Florian> present+ Florian
09:25:02 <Florian> Florian Rivoal, Vivliostyle
09:41:10 <mikepie> mikepie has joined #browserext
09:42:21 <Florian> ScribeNick: Florian
09:42:21 <Erik2> Erik2 has joined #browserext
09:42:31 <mikepie> present+ mikepie
09:42:36 <mikepie> mikepie microsoft corp
09:42:39 <mikepie> https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda
09:42:46 <Erik> Erik has joined #browserext
09:42:57 <andrey-rybka> andrey-rybka has joined #browserext
09:42:57 <kmag2> present+ Kris Maglione, Mozilla
09:43:06 <AndersR> AndersR has joined #browserext
09:43:14 <andrey-rybka> Andrey Rybka - Bloomberg
09:43:18 <mikepie> resend https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda
09:43:32 <Erik> present+ Erik Anderson, Bloomberg
09:44:46 <Florian> TOPIC: Agenda
09:45:14 <Florian> Florian: Any suggestion / addition / change to the agenda?
09:45:29 <Florian> all: top down looks good
09:45:47 <Florian> Topic: Promises in async methods
09:46:10 <Florian> kmag2: I just think this is something we should do, and would like feedback
09:46:25 <Florian> andrey-rybka: I agree, but how does this relate to extensions
09:46:40 <Florian> kmag2: chrome APIs use callbacks, but they don't compose nicely
09:46:46 <Florian> kmag2: promises are better
09:47:08 <Florian> mikepie: A goal of this group is compat with what's out there, so that's a source of tention
09:47:40 <Florian> kmag2: I'd like to release a polyfill, which would bridge that gap.
09:50:05 <Florian> Florian: It would be good to be as close as possible to Chrome, but as that is a moving target, it may be difficult to have the spec really match that. So specifying what we think is best, and bridging the gap with a polyfill can make sense
09:51:24 <Florian> kmag2: Promises is something a lot of people want anyway, so that would also encourage people to develop this version of extensions, and use a polyfill to make that work on chrome
09:52:19 <Florian> mikepie: we only have 1 namespace in Edge (browser), so I can see with our engineering team to see if we can have two, one with promises, and one with callbacks to be chrome compatible, as Mozilla is doing
09:52:27 <Florian> mikepie: we'll look into it
09:52:43 <Florian> mikepie: We prefer to use promises, but we want to be careful about compat
09:52:56 <Florian> kmag2: in our promises based API, we also accept callbacks
09:54:27 <Florian> Action: mikepie to check whether a promises based API is doable
09:54:38 <Florian> Topic: Per-browser API support reporting
09:54:46 <Florian> https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/
09:54:52 <Florian> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserAction#Browser_compatibility
09:55:29 <Florian> mikepie: as we move forward with implementation, we've found examples of how browsers document what's supported across browsers
09:55:55 <Florian> mikepie: this tool compares IDL and implementations, and give you a visualization
09:56:00 <Florian> andrey-rybka: really nice
09:56:28 <Florian> mikepie: MDN also has this kind of information in a different format
09:56:44 <Florian> mikepie: what should be the next spec
09:57:00 <Florian> kmag2: on MDN, we would list everything that's on the spec, and list support, and also mention deviations from the spec
09:57:26 <Florian> mikepie: If we have webIDL, we can do that visual representation, and fold that in.
09:57:46 <Florian> kmag2: we have tools to extract doc from webIDL. I can talk to our people about that.
09:58:01 <Florian> mikepie: For MS, webIDL is the source for this
09:58:12 <Florian> kmag2: we have a database with json in it
09:58:41 <Florian> andrey-rybka: what does "no" mean in this MDN page?
09:58:52 <Florian> kmag2: just means not supported
09:59:15 <Florian> AndersR: FF on android is all noes
09:59:26 <Florian> kmag2: that's just the release version
10:00:16 <Florian> mikepie: I think we're going to do both approaches, we'll work with MDN and see if we can integrate. We'll reach out to other browser vendors as well
10:00:28 <Florian> kmag2: can you work with our json database
10:00:30 <Florian> mikepie: yes
10:00:51 <Florian> Topic: Confirm top object name (browser)
10:01:00 <Florian> http://browserext.github.io/minutes/2016-06-09.html
10:01:44 <Florian> mikepie: just wanted to make sure everyone had a say
10:02:01 <Florian> Florian: Shwetank pushed back a bit, but only a bit, and everyone else is in agreement
10:02:16 <Florian> Topic: Confirm protocol name proposed on 2016/06/09 ("browserext://")
10:02:41 <Florian> mikepie: I got some feedback that that some people expect a dash between browser and ext, but I am fine that way
10:02:47 <Florian> kmag2: I'm fine with this
10:03:23 <Florian> kmag2: it seems more usual for a protocol not to have a dash
10:03:41 <Florian> mikepie: fine with it, but others have used a dash, so some expect consistency
10:03:48 <Florian> Florian: No strong opinion either way
10:04:27 <kmag2> List of registered URI schemes: http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
10:05:11 <Florian> kmag2: don't want to do this twice, whatever we pick, let's stick to it
10:05:20 <Florian> mikepie: so we keep it as it is
10:05:31 <Florian> kmag2: yes, every other protocol is dashless
10:05:45 <Florian> kmag2: except some vendor specific things
10:05:51 <Florian> andrey-rybka: makes sense
10:06:11 <Florian> Florian: so we keep it as previously resolved
10:06:35 <Florian> andrey-rybka: dashes seem more appropriate for vendor prefixing
10:06:54 <Florian> Topic: Status and next steps for Native Messaging spec
10:07:20 <Florian> kmag2: aswan didn't have time to update the draft yet
10:07:52 <Florian> AndersR: Google has expressed non-interest, which makes it hard given their market share
10:08:13 <Florian> kmag2: we would like to implement something similar for android, based on web intents
10:08:29 <Florian> kmag2: we're basically starting from scratch there
10:08:51 <Florian> mikepie: we could meet about that, and and get as many browser vendors for this
10:09:02 <Florian> mikepie: we should make something that works for everybody
10:09:32 <Florian> kmag2: I would like the android API to be as similar as possible to the desktop one, except for how you register.
10:09:41 <Florian> andrey-rybka: How about ios?
10:10:01 <Florian> kmag2: iOS is more complicated, there's only one browser vendor, and everyone else embeds webview
10:10:19 <Florian> AndersR: have you talked to apple
10:10:37 <Florian> Florian: yes, but they don't comment publically on things they haven't done yet
10:11:13 <Florian> AndersR: talked to the TAG and web app sec, but they say they are not interested in native messaging because it is not the web
10:11:33 <Florian> AndersR: I think it is relevant, but they're not responsive
10:12:30 <Florian> AndersR: You can already start applications with intents, but then you cannot communicate with it.
10:12:57 <Florian> Erik: we already know that for payments it's not going to happen
10:13:16 <Florian> Erik: to get other vendors onboard, we need to get them engaged for payments
10:14:04 <Florian> AndersR: there's applepay for the web, which does some form of communication, sending data back and forth, which is what you'd want for this and other application...
10:15:04 <Florian> Erik: Nowadays browsers engines are getting embedded into things (CEF for instance), and for these use cases, native messaging is super important.
10:15:13 <Florian> mikepie: agree
10:16:35 <Florian> Florian: If some other group wants to do it for the webplatform in general, we should talk to them, but we're not the group to do it for the whole platform
10:17:06 <Florian> Erik: Payments can be the trojan horse, it needs this, and people care
10:17:40 <Florian> mikepie: we need to have a conversation with browser vendors, and a separate conversation focused on the payment senario
10:18:41 <Florian> Florian: should we make a joint statement from browser ext and web payments to the TAG (and webplatformwg?) about the importance of native messaging?
10:18:59 <Florian> Erik: payments absolutely needs it, there's no other way to pull it off.
10:19:57 <Florian> Action: Erik and Florian and Mike to work on a joint statement about the importance of native messaging
10:20:07 <Florian> Topic: Unique ID algorithm/scheme (e.g. browserext://<ID_GOES_HERE>)
10:20:31 <Florian> mikepie: there are different ways to generate that unique ID
10:20:44 <Florian> mikepie: the chrome store will do it for you when you submit an extension
10:20:55 <Florian> mikepie: also installation generates one if there wasn't one
10:21:03 <Florian> mikepie: how can we get that to work cross browser
10:21:28 <Florian> mikepie: do we need to come up with an algo?
10:21:50 <Florian> mikepie: the goal is to uniquely identify an extension, and we want to avoid spoofing
10:22:04 <Florian> mikepie: maybe we can let the author come up with it
10:22:14 <Florian> mikepie: but the browser enforces it, to avoid the spoofing
10:22:57 <Florian> mikepie: the browser could refuse to to install a second extension with the same id
10:23:12 <Florian> kmag2: FF uses signing
10:23:36 <Florian> kmag: but that doesn't work cross browser well
10:23:43 <Florian> andrey-rybka: is the FF approach unique?
10:23:52 <Florian> mikepie: no, Edge also. Opera probably as well
10:24:09 <Florian> mikepie: within the extension code, you don't have to hardcode it, you can get it at runtime
10:24:40 <Florian> kmag: in FF we generate a random id in every sessions, but that doesn't work well for permissions
10:25:12 <Florian> kmag: chrome supports native messaging, cross ext messaging, and from site to extension
10:25:18 <Florian> kmag: and they do all that based on the ID
10:25:28 <Florian> andrey-rybka: is that what you want to do as well
10:25:41 <Florian> mikepie: yes, but having different ids per browser breaks that
10:26:31 <Florian> mikepie: there's no way to do this without central registration
10:26:56 <Florian> Florian: maybe decentralized, but that's tricky
10:27:18 <Florian> mikepie: you need some kind of singing as well
10:27:26 <Erik2> Something to note about Web Payments. Any implementer of a Web Payment API also enters the fraud liability chain. The browser is NOT a secure environment for payments initiation. Implementers of a payment scheme need to do it in a cros browser way.
10:28:39 <Florian> Topic: Manifest format
10:29:11 <Florian> mikepie: we can have a look at the spec
10:29:28 <Florian> mikepie: there are a few things in there that aren't in any implementation today
10:29:45 <Florian> mikepie: we had some discussions at MS about required keys
10:30:04 <Florian> mikepie: people we supportive of that, to avoid being stuck with v1
10:30:33 <Florian> mikepie: the MS team though it could be called required capabilities instead of required keys
10:30:36 <Florian> andrey-rybka: sounds reasonable
10:31:01 <Florian> Florian: I think the mechanism is important, but I don't care about the name
10:31:21 <Florian> andrey-rybka: from a developer point of view, having standardized manifest is really important and makes things easier
10:31:34 <Florian> andrey-rybka: right now the portability isn't good
10:31:50 <Florian> Erik2: this is also a lock-in problem
10:32:13 <Florian> Florian: we already have a bit of a draft, we just need to keep refining
10:32:47 <Florian> mikepie: and the way we've done it, you can have extra keys, and they just get ignore (not break everything)
10:33:00 <mikepie> http://aka.ms/extw3c
10:34:12 <Florian> Topic: CG Logo
10:34:18 <Florian> https://github.com/browserext/browserext.github.io/issues/12
10:34:26 <Florian> https://mikepie1.github.io/browserext-1/LogoIdeas.png
10:35:23 <Florian> Florian: I like 10
10:35:25 <Florian> andrey-rybka: I like 9
10:35:37 <Florian> Florian: 9 is ok too
10:35:41 <Florian> andrey-rybka: I like all but 7
10:35:47 <Florian> mikepie: not 7 or 8
10:37:09 <Florian> andrey-rybka: add the X to 10?
10:37:36 <Florian> Erik2: I like 10, with EXT in there somehow
10:37:55 <Florian> mikepie: I'll do another round to try to fit the ext in there
10:38:16 <Florian> Action: mike to do a new iteration, centered around 10 or 9, with EXT or X somwhere in there
10:38:30 <Florian> Topic: Status of extended attribute "checkAnyPermissions"
10:38:57 <Florian> mikepie: bzbarsky is here
10:39:03 <Florian> kmag: yes, but crazy busy
10:39:14 <Florian> mikepie: maybe we can catch him during a break
10:39:36 <Florian> mikepie: I talked to Travis, also a contributor, he'd be happy to chat about this
10:39:46 <Florian> mikepie: There's also Yves
10:39:58 <Florian> mikepie: so we can reach to them today
10:40:35 <Florian> mikepie: I'll talk to Travis, kmag can you catch zbarsky
10:41:04 <Florian> mikepie: just to make sure they look for our email
10:41:33 <Florian> Topic: Testing with WebDriver
10:41:54 <Florian> mikepie: Had a good review with the browser testing and tools group
10:42:05 <Florian> mikepie: we discussed the extensions to test the extensions
10:42:12 <Florian> mikepie: the feedback was positive
10:42:20 <Florian> mikepie: they expect others to do similar extensions
10:42:43 <Florian> mikepie: but as our proposal is strictly additive, they think we should host it ourselves rather than add it to their spec
10:43:04 <Florian> mikepie: I can do that and include it in the browserext spec, section 2.7
10:43:10 <Florian> mikepie:  I can just include that there
10:43:48 <Florian> Florian: Sounds good. Later on we can split into a new spec if this stabilizes at a different speed
10:43:58 <Florian> Florian: but this is a good initial host for it at least
10:45:28 <Florian> kmag: we can host most of it here, but some parts of the mother spec do need changes, so we will need to keep talking to them
10:45:43 <Florian> AndersR: Can you test the API without using an actual extension
10:45:59 <Florian> mikepie: In Edge, you would need an extension to be loaded for these APIS to be available
10:46:32 <Florian> andrey-rybka: if you're doing this server side, you may not have a browser
10:46:45 <Florian> mikepie: there are several use cases:
10:46:57 <Florian> mikepie: extension authors want to test their extensions
10:47:09 <Florian> mikepie: site authors may want to test compat with popular extensions
10:47:44 <Florian> mikepie: also, browser vendors testing the extensions API themselves
10:48:20 <Florian> mikepie: one more use case is for this group to test for compliance
10:48:59 <andrey-rybka> Florian: I think we should have a test suite for browsers to test compatability
10:49:27 <andrey-rybka> Florian: based on what csswg and other w3c groups do successfully
10:49:53 <andrey-rybka> Florian: specally we want to emulate Web Platform Tests
10:50:03 <Florian> Florian: emulate, of if possible actually become part of WPT
10:50:22 <Florian> kmag: everything in one test suite would be good for us
10:50:55 <Florian> kmag: [explains how mozilla does its tests]
10:51:40 <Florian> kmag: our API works by generating extensions on the fly based on JSON, and communicating with the test driver
10:52:28 <Florian> andrey-rybka: does this run headless
10:52:31 <Florian> kmag: this is complicated
10:52:44 <Florian> kmag: mostly we run in VMs or on bare hardware
10:52:50 <Florian> andrey-rybka: it is very heavy
10:52:55 <Florian> kmag: yes, but necessary
10:52:59 <Florian> andrey-rybka: are you sure?
10:53:11 <Florian> kmag: we have tests that don't use UI, but there are things you cannot test that way
10:53:34 <Florian> andrey-rybka: I have a selenium grid, but that's horribly slow
10:53:58 <Florian> kmag: it's fine to look at something for messaging similar to the chrome test API
10:54:09 <Florian> s/kmag/mikepie/
10:55:12 <mikepie> mikepie: Having an API way or exensions to interop/signal with test harness is good, but we should also support other ways to interop with extensions, since commercial extensions won't signal the harnes
11:05:59 <Florian> Topic: Next steps for this CG. Should we form a WG?
11:06:30 <Florian> Florian: I think at some point we should transition the work into a WG, but I don't want to kill the momentum with administrative work
11:06:58 <Florian> mikepie: I would also like to expand a bit more the work we do on the testing and implementation side before we make that jump
11:07:02 <Florian> andrey-rybka: agree
11:07:04 <Florian> kmag: agree
11:07:14 <Florian> Florian: So we'll keep going as a CG for now
11:07:23 <Florian> Topic: spec review
11:07:41 <mikepie> http://aka.ms/extw3c
11:07:42 <andrey-rybka> https://browserext.github.io/browserext/
11:09:14 <Florian> mikepie: I have some editorial work to do, but no need to discuss that
11:09:46 <Florian> mikepie: I added 3 use cases, do you feel they are appropriate
11:10:44 <Florian> Florian: the 3rd one seems privacy sensitive, but feels in scope
11:11:01 <Florian> mikepie: yes, but at the same time it is not part of the APIs we have specified so far
11:11:17 <Florian> kmag: cookies feel like they belong here, bookmarks is more trikcy
11:11:27 <Florian> kmag: for messaging, we need to resolve the id issue
11:11:50 <Florian> andrey-rybka: should we talk about native messaging?
11:11:55 <Florian> kmag: it is in a separate spec
11:13:30 <Florian> Florian: section 2.1.1 needs to say what happens when you try some of the non allowed things
11:13:44 <Florian> kmag: we should define this in terms of the default CSP spec, which does say all these things
11:13:49 <Florian> andrey-rybka: agree
11:14:16 <Florian> kmag: I think we need a separate section to deal with content scripts and how they interact with CSP
11:14:29 <Florian> kmag: in chrome they can inject content to violate CSP
11:14:35 <Florian> andrey-rybka: how does that happen?
11:16:38 <kmag2> Content injected by extension content scriptw, such as scripts or images, which would violate the page's CSP are accepted by Chrome. The exception is things like event listener attributes (onmousedown="..."), which are not evaluated while the extension context is on the stack, and are still subject to CSP.
11:16:48 <Florian> AndersR: I do not understand the 4th bullet in 2.1.1
11:17:26 <Florian> mikepie: there's sandboxing, and content scripts cannot call functions into the page
11:17:45 <Florian> mikepie: so if I want to modify a onclick
11:18:23 <Florian> mikepie: [...]
11:19:00 <Florian> mikepie: I'll get back to this later when I have a better way to explain.
11:19:41 <Florian> kmag: I think that should be a separate section
11:20:02 <Florian> andrey-rybka: shall we go section by section, or issue by issue?
11:20:08 <Florian> mikepie: let's go with issues
11:20:38 <Florian> mikepie: we currently don't talk in the spec about programatic/runtime granting of permissions
11:20:53 <Florian> mikepie: so this listing of optional persmissions is kind of of odd here
11:21:10 <Florian> kmag: we should remove it for now
11:21:23 <Florian> Florian: this is something we can add back later without compat issue, right
11:21:25 <Florian> kmag: right
11:21:44 <Florian> RESOLUTION: drop optional permissions from the spec
11:22:09 <Florian> andrey-rybka: should there be a readonly attribute EventListener onClicked?
11:22:15 <Florian> kmag: I don't understand the question
11:22:27 <Florian> mikepie: I'll follow up
11:22:50 <Florian> andrey-rybka: what about issue 5?
11:24:07 <Florian> mikepie: we should be consistant about how we name the types and the parameters
11:24:27 <Florian> mikepie: I'm going to switch everything to use details
11:24:47 <Florian> RESOLUTION: Change all the naming to use details
11:25:14 <Florian> andrey-rybka: should we prefix all names with Browser or BrowserExt etc
11:25:25 <Florian> mikepie: currently this is inconsistent
11:25:42 <Florian> kmag: yes, we need to prefix things, WebIDL stuff shares a namespace
11:26:05 <Florian> mikepie: should we do BrowserExtBrowserFoo, or just BrowserExtFoo?
11:26:16 <Florian> kmag: shorter is fine
11:26:57 <Florian> RESOLUTION: prefix all with BrowserExt and the object name
11:27:38 <Florian> mikepie:  do we need the extension object?
11:27:53 <Florian> kmag: I think we should keep it but note that it is deprecated
11:28:46 <Florian> kmag: it is still necessary for a few things, but we shouldn't be adding to it
11:29:02 <Florian> kmag: things that are already in runtime shouldn't be duplicated there
11:29:22 <Florian> kmag: I don't think you need getbackground page
11:29:34 <Florian> mikepie: not sure
11:30:36 <Florian> Florian: can we decide on the high level principle and just let the editor deal with it?
11:31:22 <Florian> kmag: I think these are already in runtime, they don't need them
11:32:07 <Florian> RESOLUTION: drop the extension object, reintroduce later if needed
11:33:52 <Florian> mikepie: Issue 11 is a work item for me to go fix the types appropriately
11:35:00 <Florian> Topic: Native messaging
11:35:17 <Florian> Florian: Mike, Andrey do you want to engage with aswan to help get the ball rolling
11:35:21 <Florian> mikepie: yes
11:35:23 <Florian> andrey-rybka: yes
11:35:53 <Florian> RRSAgent, make log public
11:36:12 <Florian> andrey-rybka: when should we have the next meeting?
11:36:16 <Florian> andrey-rybka: two weeks?
11:36:55 <Florian> mikepie: On 5th (US)?
11:37:01 <Florian> andrey-rybka: sure
11:37:24 <Florian> Florian: works for me
11:37:45 <Florian> Florian: Ok, let's do that, same time as usual.
11:38:25 <Florian> RRSAgent, make log public
11:38:29 <Florian> RRSAgent, draft minutes
11:38:29 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/22-browserext-minutes.html Florian
11:38:50 <Florian> RRSAgent, bye
11:38:50 <RRSAgent> I see 3 open action items saved in http://www.w3.org/2016/09/22-browserext-actions.rdf :
11:38:50 <RRSAgent> ACTION: mikepie to check whether a promises based API is doable [1]
11:38:50 <RRSAgent>   recorded in http://www.w3.org/2016/09/22-browserext-irc#T09-54-27
11:38:50 <RRSAgent> ACTION: Erik and Florian and Mike to work on a joint statement about the importance of native messaging [2]
11:38:50 <RRSAgent>   recorded in http://www.w3.org/2016/09/22-browserext-irc#T10-19-57
11:38:50 <RRSAgent> ACTION: mike to do a new iteration, centered around 10 or 9, with EXT or X somwhere in there [3]
11:38:50 <RRSAgent>   recorded in http://www.w3.org/2016/09/22-browserext-irc#T10-38-16