See also: IRC log
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
Florian: Any suggestion / addition / change to the agenda?
all: top down looks good
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]
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
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
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
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]
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.
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
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]
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
... 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
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
<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
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.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/kmag/mikepie/ Found ScribeNick: Florian Inferring Scribes: Florian Present: Florian mikepie Kris_Maglione Mozilla Erik_Anderson Bloomberg Agenda: https://github.com/browserext/browserext.github.io/wiki/2016-TPAC-Agenda Got date from IRC log name: 22 Sep 2016 Guessing minutes URL: http://www.w3.org/2016/09/22-browserext-minutes.html People with action items: erik florian mike mikepie WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]