W3C home > Mailing lists > Public > public-web-security@w3.org > January 2015

[WebCrypto.Next] Resurrecting Browser Plugins?

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 06 Jan 2015 11:00:44 +0100
Message-ID: <54ABB24C.4050508@gmail.com>
To: "public-web-security@w3.org" <public-web-security@w3.org>
Dear Reader,

Please begin by taking a peek in this one-page document which is supposed to hi-light
the core issue: http://webpki.org/papers/web-browser-security-enigma.pdf

In spite of many months of work on WebCrypto++, I have just begun exploring an
entirely different path which is "Resurrecting" the currently "Outlawed" browser
plugin concept since plugins also have uses outside of identity and payments.

Why? Aren't browser plugins supposed to be non-secure, platform-dependent, etc?
Yes, that's true but let's take one feature at a time:

Security:
=========
A browser plugin is usually downloaded from the service provider itself and
its security is vouched for by a code-signing certificate which anybody can
buy for a couple of hundred bucks.  Such a plugin can hijack important browser
functionality including impersonating the user.  It is obvious that this way of
distributing security-critical software simply put isn't acceptable.

Workaround/Solution:
A service provider may reference a plugin using a "Virtual Plugin ID" which would
force the platform to look for a matching implementation in its cache and invoke it.
if no such implementation is available, the platform would look for this in a
platform-specific "AppStore" which only holds vetted ("good") plugins.

Platform-Dependency:
====================
Although we are talking web with HTML5 and JavaScript, the truth is that most
native platforms still are more powerful, not to mention that they usually
already have all the APIs needed for payments, authentication, networking, etc etc.

What's more, you probably _want_ web-based payment plugins to look similar to local
wallets used in brick-and-mortar shops.  Locale is also an important factor here.
That is, how plugin are implemented would _not_ be a part of the specification.

By relying on platform-specific app-stores, service providers do not have to worry
about different platforms, either there is an implementation or it is not; they only
have to call the proper WebIDL methods or performing postMessage() to use a plugin.

Does this sound totally off?

Sincerely,
Anders Rundgren
WebPKI.org
Received on Tuesday, 6 January 2015 10:01:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:22 UTC