Re: Draft Charter Available for Comments [via Browser Extension Community Group]

On 2015-10-26 15:06, Florian Rivoal wrote:
>> On 26 Oct 2015, at 00:51, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
>>
>> On 2015-10-25 15:59, W3C Community Development Team wrote:
>>> Hello World!
>>>
>>> Draft charter is available for comments:
>>> http://browserext.github.io/charter/
>>>
>>> Please provide comments / feedback via Github issues
>>>
>>> Any feedback is welcome and please join in the group if you feel this is a
>>> problem worth solving.
>> Basing this work on Chrome extensions is a good idea.
>> There are a couple of things to consider though:
>>
>> 1. The AppStore. Maybe the only realistic is that each vendor maintains a copy although it feels a bit inconvenient?
> I agree this is a discussion we should have, and I link it to point 3 in the scope section. It is far from certain that we can reach agreement about this, but it is a topic worth discussion. We could make this explicit by adding one more bullet point to the list under point 3, maybe saying "distribution channels"

That sounds ok to me.

>
>> 2. Native Messaging. This is (IMO...) a very important part of the Chrome extension API but unfortunately it suffers from major usability, deployment, and security issues:
>> https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html
>> Personally I believe Native Messaging should be a separate effort because it differs from the rest by diving into the OS.
> I think Native Messaging is an important part of what extensions need to be able to do, and therefore that it belongs in the scope of this CG. Whether the model proposed by Chrome is acceptable as is, needs adjustments, or needs to be replaced by a different API altogether due to security (or other) concerns is certainly a discussion that needs to happen, but I believe this community group is a good place for this discussion to be had.

Native Messaging is indeed an important extension capability.
After having spent considerable time exploring this feature I have come to the conclusion that it would be very unfortunate making this scheme a standard.  Here are some of the more apparent reasons:

Currently Native Messaging require the installation of two entirely separate software packages, a Chrome extension and the native application it is supposed to work with.  It is true that the manifest stuff of the Chrome extension in some way "controls" the native application.  Unfortunately all bets are off regarding the security of this combination anyway.

Native Applications accessed from the "Open Web" should IMO be self-contained with respect to deployment and security vetting. This is missing from the current scheme making it very unlikely to pass through a standardization process.

Google security folks including Ryan Sleevi have told me that Native Messaging is what they want to get away from and rather create Open Web APIs such as WebCrypto that doesn't need installation etc.

What I don't understand is how Google envision making Apple Pay usable on the Web without de-facto creating a Native Messaging system once again.
https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0064.html

I have tried to raise this issue in TAG and WebAppSec without any success, maybe you have more luck?
https://lists.w3.org/Archives/Public/www-tag/2015Apr/0053.html

Anders

>
> However, we should probably list WebAppSec and/or the TAG as liaisons to be contacted to work on security aspects of the various APIs we will be standardizing. While we're at it, we should probably add the other traditional W3C horizontal review groups (accessibility, internationalization, and privacy) to the Liaison section as well.
>
>   - Florian
>

Received on Tuesday, 27 October 2015 09:14:34 UTC