Browser Extension CG TPAC meeting -- 22 Sep 2016

Florian Rivoal, Vivliostyle

<scribe> ScribeNick: Florian

<mikepie> mikepie microsoft corp

<mikepie> https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda

<andrey-rybka> Andrey Rybka - Bloomberg

<mikepie> resend https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda

Agenda

Florian: Any suggestion / addition / change to the agenda?

all: top down looks good

Promises in async methods

kmag2: I just think this is something we should do, and would like feedback

andrey-rybka: I agree, but how does this relate to extensions

kmag2: chrome APIs use callbacks, but they don't compose nicely
... promises are better

mikepie: A goal of this group is compat with what's out there, so that's a source of tention

kmag2: I'd like to release a polyfill, which would bridge that gap.

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

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

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
... we'll look into it
... We prefer to use promises, but we want to be careful about compat

kmag2: in our promises based API, we also accept callbacks

<scribe> ACTION: mikepie to check whether a promises based API is doable [recorded in http://www.w3.org/2016/09/22-browserext-minutes.html#action01]

Per-browser API support reporting

https://developer.microsoft.com/en-us/microsoft-edge/platform/catalog/

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/browserAction#Browser_compatibility

mikepie: as we move forward with implementation, we've found examples of how browsers document what's supported across browsers
... this tool compares IDL and implementations, and give you a visualization

andrey-rybka: really nice

mikepie: MDN also has this kind of information in a different format
... what should be the next spec

kmag2: on MDN, we would list everything that's on the spec, and list support, and also mention deviations from the spec

mikepie: If we have webIDL, we can do that visual representation, and fold that in.

kmag2: we have tools to extract doc from webIDL. I can talk to our people about that.

mikepie: For MS, webIDL is the source for this

kmag2: we have a database with json in it

andrey-rybka: what does "no" mean in this MDN page?

kmag2: just means not supported

AndersR: FF on android is all noes

kmag2: that's just the release version

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

kmag2: can you work with our json database

mikepie: yes

Confirm top object name (browser)

http://browserext.github.io/minutes/2016-06-09.html

mikepie: just wanted to make sure everyone had a say

Florian: Shwetank pushed back a bit, but only a bit, and everyone else is in agreement

Confirm protocol name proposed on 2016/06/09 ("browserext://")

mikepie: I got some feedback that that some people expect a dash between browser and ext, but I am fine that way

kmag2: I'm fine with this
... it seems more usual for a protocol not to have a dash

mikepie: fine with it, but others have used a dash, so some expect consistency

Florian: No strong opinion either way

<kmag2> List of registered URI schemes: http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

kmag2: don't want to do this twice, whatever we pick, let's stick to it

mikepie: so we keep it as it is

kmag2: yes, every other protocol is dashless
... except some vendor specific things

andrey-rybka: makes sense

Florian: so we keep it as previously resolved

andrey-rybka: dashes seem more appropriate for vendor prefixing

Status and next steps for Native Messaging spec

kmag2: aswan didn't have time to update the draft yet

AndersR: Google has expressed non-interest, which makes it hard given their market share

kmag2: we would like to implement something similar for android, based on web intents
... we're basically starting from scratch there

mikepie: we could meet about that, and and get as many browser vendors for this
... we should make something that works for everybody

kmag2: I would like the android API to be as similar as possible to the desktop one, except for how you register.

andrey-rybka: How about ios?

kmag2: iOS is more complicated, there's only one browser vendor, and everyone else embeds webview

AndersR: have you talked to apple

Florian: yes, but they don't comment publically on things they haven't done yet

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
... I think it is relevant, but they're not responsive
... You can already start applications with intents, but then you cannot communicate with it.

Erik: we already know that for payments it's not going to happen
... to get other vendors onboard, we need to get them engaged for payments

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...

Erik: Nowadays browsers engines are getting embedded into things (CEF for instance), and for these use cases, native messaging is super important.

mikepie: agree

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

Erik: Payments can be the trojan horse, it needs this, and people care

mikepie: we need to have a conversation with browser vendors, and a separate conversation focused on the payment senario

Florian: should we make a joint statement from browser ext and web payments to the TAG (and webplatformwg?) about the importance of native messaging?

Erik: payments absolutely needs it, there's no other way to pull it off.

<scribe> ACTION: Erik and Florian and Mike to work on a joint statement about the importance of native messaging [recorded in http://www.w3.org/2016/09/22-browserext-minutes.html#action02]

Unique ID algorithm/scheme (e.g. browserext://<ID_GOES_HERE>)

mikepie: there are different ways to generate that unique ID
... the chrome store will do it for you when you submit an extension
... also installation generates one if there wasn't one
... how can we get that to work cross browser
... do we need to come up with an algo?
... the goal is to uniquely identify an extension, and we want to avoid spoofing
... maybe we can let the author come up with it
... but the browser enforces it, to avoid the spoofing
... the browser could refuse to to install a second extension with the same id

kmag2: FF uses signing

kmag: but that doesn't work cross browser well

andrey-rybka: is the FF approach unique?

mikepie: no, Edge also. Opera probably as well
... within the extension code, you don't have to hardcode it, you can get it at runtime

kmag: in FF we generate a random id in every sessions, but that doesn't work well for permissions
... chrome supports native messaging, cross ext messaging, and from site to extension
... and they do all that based on the ID

andrey-rybka: is that what you want to do as well

mikepie: yes, but having different ids per browser breaks that
... there's no way to do this without central registration

Florian: maybe decentralized, but that's tricky

mikepie: you need some kind of singing as well

<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.

Manifest format

mikepie: we can have a look at the spec
... there are a few things in there that aren't in any implementation today
... we had some discussions at MS about required keys
... people we supportive of that, to avoid being stuck with v1
... the MS team though it could be called required capabilities instead of required keys

andrey-rybka: sounds reasonable

Florian: I think the mechanism is important, but I don't care about the name

andrey-rybka: from a developer point of view, having standardized manifest is really important and makes things easier
... right now the portability isn't good

Erik2: this is also a lock-in problem

Florian: we already have a bit of a draft, we just need to keep refining

mikepie: and the way we've done it, you can have extra keys, and they just get ignore (not break everything)

<mikepie> http://aka.ms/extw3c

CG Logo

https://github.com/browserext/browserext.github.io/issues/12

https://mikepie1.github.io/browserext-1/LogoIdeas.png

Florian: I like 10

andrey-rybka: I like 9

Florian: 9 is ok too

andrey-rybka: I like all but 7

mikepie: not 7 or 8

andrey-rybka: add the X to 10?

Erik2: I like 10, with EXT in there somehow

mikepie: I'll do another round to try to fit the ext in there

<scribe> ACTION: mike to do a new iteration, centered around 10 or 9, with EXT or X somwhere in there [recorded in http://www.w3.org/2016/09/22-browserext-minutes.html#action03]

Status of extended attribute "checkAnyPermissions"

mikepie: bzbarsky is here

kmag: yes, but crazy busy

mikepie: maybe we can catch him during a break
... I talked to Travis, also a contributor, he'd be happy to chat about this
... There's also Yves
... so we can reach to them today
... I'll talk to Travis, kmag can you catch zbarsky
... just to make sure they look for our email

Testing with WebDriver

mikepie: Had a good review with the browser testing and tools group
... we discussed the extensions to test the extensions
... the feedback was positive
... they expect others to do similar extensions
... but as our proposal is strictly additive, they think we should host it ourselves rather than add it to their spec
... I can do that and include it in the browserext spec, section 2.7
... I can just include that there

Florian: Sounds good. Later on we can split into a new spec if this stabilizes at a different speed
... but this is a good initial host for it at least

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

AndersR: Can you test the API without using an actual extension

mikepie: In Edge, you would need an extension to be loaded for these APIS to be available

andrey-rybka: if you're doing this server side, you may not have a browser

mikepie: there are several use cases:
... extension authors want to test their extensions
... site authors may want to test compat with popular extensions
... also, browser vendors testing the extensions API themselves
... one more use case is for this group to test for compliance

<andrey-rybka> Florian: I think we should have a test suite for browsers to test compatability

<andrey-rybka> Florian: based on what csswg and other w3c groups do successfully

<andrey-rybka> Florian: specally we want to emulate Web Platform Tests

Florian: emulate, of if possible actually become part of WPT

kmag: everything in one test suite would be good for us
... [explains how mozilla does its tests]
... our API works by generating extensions on the fly based on JSON, and communicating with the test driver

andrey-rybka: does this run headless

kmag: this is complicated
... mostly we run in VMs or on bare hardware

andrey-rybka: it is very heavy

kmag: yes, but necessary

andrey-rybka: are you sure?

kmag: we have tests that don't use UI, but there are things you cannot test that way

andrey-rybka: I have a selenium grid, but that's horribly slow

mikepie: it's fine to look at something for messaging similar to the chrome test API

<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

Next steps for this CG. Should we form a WG?

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

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

andrey-rybka: agree

kmag: agree

Florian: So we'll keep going as a CG for now

spec review

<mikepie> http://aka.ms/extw3c

<andrey-rybka> https://browserext.github.io/browserext/

mikepie: I have some editorial work to do, but no need to discuss that
... I added 3 use cases, do you feel they are appropriate

Florian: the 3rd one seems privacy sensitive, but feels in scope

mikepie: yes, but at the same time it is not part of the APIs we have specified so far

kmag: cookies feel like they belong here, bookmarks is more trikcy
... for messaging, we need to resolve the id issue

andrey-rybka: should we talk about native messaging?

kmag: it is in a separate spec

Florian: section 2.1.1 needs to say what happens when you try some of the non allowed things

kmag: we should define this in terms of the default CSP spec, which does say all these things

andrey-rybka: agree

kmag: I think we need a separate section to deal with content scripts and how they interact with CSP
... in chrome they can inject content to violate CSP

andrey-rybka: how does that happen?

<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.

AndersR: I do not understand the 4th bullet in 2.1.1

mikepie: there's sandboxing, and content scripts cannot call functions into the page
... so if I want to modify a onclick
... [...]
... I'll get back to this later when I have a better way to explain.

kmag: I think that should be a separate section

andrey-rybka: shall we go section by section, or issue by issue?

mikepie: let's go with issues
... we currently don't talk in the spec about programatic/runtime granting of permissions
... so this listing of optional persmissions is kind of of odd here

kmag: we should remove it for now

Florian: this is something we can add back later without compat issue, right

kmag: right

RESOLUTION: drop optional permissions from the spec

andrey-rybka: should there be a readonly attribute EventListener onClicked?

kmag: I don't understand the question

mikepie: I'll follow up

andrey-rybka: what about issue 5?

mikepie: we should be consistant about how we name the types and the parameters
... I'm going to switch everything to use details

RESOLUTION: Change all the naming to use details

andrey-rybka: should we prefix all names with Browser or BrowserExt etc

mikepie: currently this is inconsistent

kmag: yes, we need to prefix things, WebIDL stuff shares a namespace

mikepie: should we do BrowserExtBrowserFoo, or just BrowserExtFoo?

kmag: shorter is fine

RESOLUTION: prefix all with BrowserExt and the object name

mikepie: do we need the extension object?

kmag: I think we should keep it but note that it is deprecated
... it is still necessary for a few things, but we shouldn't be adding to it
... things that are already in runtime shouldn't be duplicated there
... I don't think you need getbackground page

mikepie: not sure

Florian: can we decide on the high level principle and just let the editor deal with it?

kmag: I think these are already in runtime, they don't need them

RESOLUTION: drop the extension object, reintroduce later if needed

mikepie: Issue 11 is a work item for me to go fix the types appropriately

Native messaging

Florian: Mike, Andrey do you want to engage with aswan to help get the ball rolling

mikepie: yes

andrey-rybka: yes
... when should we have the next meeting?
... two weeks?

mikepie: On 5th (US)?

andrey-rybka: sure

Florian: works for me
... Ok, let's do that, same time as usual.

- DRAFT -

Browser Extension CG TPAC meeting

22 Sep 2016

Attendees

Contents