On Mon, Dec 14, 2015 at 8:02 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> On Mon, Dec 14, 2015 at 9:29 PM, Eric Rescorla <e...@rtfm.com> wrote: > >> On Thu, Dec 10, 2015 at 1:36 AM, Martin Thomson <m...@mozilla.com> wrote: >> >>> On Thu, Dec 10, 2015 at 5:17 PM, Robert O'Callahan <rob...@ocallahan.org> >>> wrote: >>> > On Fri, Dec 4, 2015 at 4:56 PM, Eric Rescorla <e...@rtfm.com> wrote: >>> > >>> >> (4) Have the APIs hidden behind access controls that need to be >>> enabled by >>> >> an extension >>> >> (but a trivial one). Perhaps you think this is #2. >>> >> >>> > >>> > I realized I don't understand exactly what this means. >>> >>> >>> The basic idea is similar to what we are currently doing for >>> screensharing. Maintain a whitelist of sites that can access USB (or >>> origin+device pairs). The extension/addon just adds a set of things to >>> this whitelist. And yes, because this is installed in the same way >>> that the worst of our addons is installed, we gain the same (limited) >>> protections that we get from the addons, including the ability to >>> block the addon if it turns out to be bad. >>> >> >> Yes, as Martin says. The usual reasoning here is "if I could get you to >> install an add-on like this, it's game over anyway" >> >> >> For the record: I think is an awful solution, but it might work here. >>> >> >> I too think it's an awful solution, just less awful than being in the >> business >> of enforcing vendor lockin for these devices. >> > > What if we allow such addons but also whitelist the vendor origin reported > by the device? > This is certainly something one could consider, but it it seems like it confers a major advantage on the vendor vis-a-vis everyone else. If we're going to have an add-on mechanism, I don't see why vendors can't use it too. -Ekr _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
