W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2013

Re: NSD API security

From: Giuseppe Pascale <giuseppep@opera.com>
Date: Fri, 4 Oct 2013 08:41:39 +0200
Message-ID: <CANiD0ko320NpPVDcG6HYtZqsWqqgg_4PcUziCs-_kXM_KpR6yA@mail.gmail.com>
To: "frederick.hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
Cc: Dominique Hazael-Massieux <dom@w3.org>, FABLET Youenn <Youenn.Fablet@crf.canon.fr>, Bin Hu <bh526r@att.com>, Rich Tibbett <richt@opera.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, public-web-and-tv <public-web-and-tv@w3.org>
If we go for explicit opt-in from services, it will be up to device vendors
to decide if their device is secure enough. I think one of the main concern
was that these devices have not been designed to be exposed to any random
web app out there.


On Thu, Oct 3, 2013 at 12:43 PM, <Frederick.Hirsch@nokia.com> wrote:

> agreed, my point is that if the security flaw in the benign  service
> allows an attack on the sensitive one then the only real solution is not to
> enable that device in our scenario (or to fix the underlying issue of
> course)
>
> I like the phrasing, should be good for the  security considerations
> section :)
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Oct 3, 2013, at 2:50 AM, ext Dominique Hazael-Massieux wrote:
>
> > Le jeudi 03 octobre 2013 à 01:28 +0000, Frederick.Hirsch@nokia.com a
> > écrit :
> >> The fundamental flaw is that one device has two purposes  allowing
> >> flaws from one to affect the other, yet this is also why it is sold
> >> and valued - the convenience, cost reduction, lower hardware
> >> footprint, easier management etc are also benefits.
> >
> > One simple (but of course not 100% effective) solution would be for such
> > a dual serviced device to expose CORS headers only on the benign
> > service, and not on the security-sensitive one.
> >
> > (if a bug in the benign service lets attack the sensitive one, of
> > course, this won't be of much use)
> >
> > Dom
> >
>
>
Received on Friday, 4 October 2013 06:42:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:01 UTC