See also: IRC log
<mikepie> https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda
Florian: Any suggestion / addition / change to the agenda?
all: Going top down seems good.
kmag: I just think this is something we should do, and would like feedback.
andrey-rybka: I agree, but how does this relate to extensions?
kmag: Chrome APIs use callbacks, but they don't compose nicely. Promises are better.
mikepie: A goal of this group is compatibility with what's out there, so that's a source of tension.
kmag: 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.
kmag: 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.
kmag: In our promises based API, we also accept callbacks.
<scribe> ACTION: mikepie to check whether a promises based API is doable [recorded in https://github.com/browserext/browserext/issues/12]
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 step?
kmag: 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.
kmag: 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.
kmag: We have a database with JSON in it.
andrey-rybka: What does “no” mean in this MDN page?
kmag: It just means “not supported”.
AndersR: FF on android is all noes.
kmag: 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.
kmag: Can you work with our json database?
mikepie: Yes.
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.
mikepie: I got some feedback that that some people expect a dash between browser and ext, but I am fine that way.
kmag: I'm fine with this.
It seems more usual for a protocol not to have a dash.
mikepie: I'm fine with it, but others have used a dash, so some expect consistency.
Florian: No strong opinion either way.
<kmag> List of registered URI schemes: http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
kmag: I don't want to do this twice, whatever we pick, let's stick to it.
mikepie: So we keep it as it is.
kmag: Yes, every other protocol is dashless, except some vendor specific things, which this is not.
andrey-rybka: Makes sense.
Florian: So we keep it as previously resolved.
andrey-rybka: Dashes seem more appropriate for vendor prefixing.
kmag: aswan didn't have time to update the draft yet.
AndersR: Google has expressed non-interest in doing it on mobile, which makes it problematic given their market share.
kmag: 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
kmag: 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?
kmag: 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.
AndersR: I 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 them.
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 applications...
Erik: Nowadays browsers engines are getting embedded into things (CEF for instance), and for these use cases, native messaging is super important.
mikepie: Agreed.
Florian: If some other group wants to do it for the web platform 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 scenario.
Florian: Should we make a joint statement from browser ext and web payments to the TAG (and Web Platform WG?) 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 https://github.com/browserext/native-messaging/issues/6]
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.
kmag: Firefox uses signing 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.
<Erik> 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.
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.
Erik: This is also a lock-in problem.
Florian: We already have a bit of a draft, we just need to keep refining.
mikepie: The way we've done it, you can have extra keys, and they just get ignored (not break everything).
<mikepie> https://browserext.github.io/browserext/
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 good too.
andrey-rybka: I like all but 7.
mikepie: Not 7 or 8.
andrey-rybka: Add the X to 10?
Erik: 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 https://github.com/browserext/browserext.github.io/issues/12#issuecomment-249741948]
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.
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
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.
Florian: I think we should have a test suite
for browsers to test compatibility, based on what web platform and other w3c groups
do successfully.
Specifically, we want to emulate Web Platform Tests or if possible
actually become part of WPT.
kmag: Everything in one test
suite would be good for us.
... 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> Having an API way or extensions 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 harness.
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: Agreed.
kmag: Agreed.
Florian: So we'll keep going as a CG for now.
<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 tricky.
... 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: I 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?
kmag: Content injected by extension content script, 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
programmatic/runtime granting of permissions, so this listing of optional permissions 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 read-only 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 consistent
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?
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.
Florian: Mike, Andrey do you want to engage with aswan to help get the ball rolling
mikepie: yes
andrey-rybka: yes
andrey-rybka: When should we have the next meeting?
... In two weeks?
mikepie: On 5th (US)?
andrey-rybka: sure
Florian: works for me
... Ok, let's do that, same time as usual.
