W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CSP: Drop IP-matching? (was Re: [CSP] URI/IRI normalization and comparison)

From: Oda, Terri <terri.oda@intel.com>
Date: Thu, 5 Feb 2015 10:50:54 -0800
Message-ID: <CACoC0R99ZGg5u6oyXs76QayHwsgcip4mNOEDSvuNEekrBVvjHg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mike West <mkwst@google.com>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Feb 4, 2015 at 3:15 PM, Martin Thomson <martin.thomson@gmail.com>

> On 4 February 2015 at 21:24, Mike West <mkwst@google.com> wrote:
> > My justification for allowing IPv4 is not IoT in itself, but the fact
> that
> > IPv4 is being used today, by the
> > internet-of-things-that-happen-to-be-webservers-in-datacenters.
> Can you explain how those iotthtbwid devices might benefit from CSP?
> I don't want to be obtuse, but I'm not seeing a case there.

Beyond the data center, I was thinking in terms of the many sensors I've
seen that just export a rest or web interface.  I can totally picture some
management device that loads and possibly aggregates content directly from
a big pile of sensors. It seems reasonable that there are applications
where you'd know ip address data for your sensors, but maybe not want to
generate hostnames for them due to low resources in a larger sensor network.

Or equally, some similar web management/data display utility for a home
user with a few sensors who isn't going to know how to set hostnames for
individual devices unless their router does it for them.  Those management
utilities are going to be written by folk who won't know what the internal
network topography will look like, and if your device discovery/pairing
routines have the potential to return instead of
thermostat1.myhouse.com because someone's on an older home router, then no

I agree with Mike that this maybe isn't something we want to encourage, but
I do suspect it's something we're going to see.
Received on Thursday, 5 February 2015 18:51:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:46 UTC