IRC log of browserext on 2016-09-22

Timestamps are in UTC.

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