No more IP addresses in permissions strings

[Reilly Grant]

While working on a patch to make the host permissions strings more IoT-friendly by referring to "devices" instead of "computers" I noticed that we can generate permissions strings like this one:

"Exchange data with the device named 127.0.0.1"

This message is meaningless to most people. I suggest banning IP addresses from these permission strings and replacing all messages containing them with one of the following:

"Exchange data with other applications on your computer." (IPv4 and IPv6 loopback addresses)

"Exchange data with other devices on your local network." (IPv4 and IPv6 link local and private addresses)

"Exchange data with other devices on the Internet." (all other addresses)

Thoughts?

[Benjamin Kalman]

Definitely sounds like an improvement, but I question why a message like "exchange data with other devices on the internet" is useful. A website can exchange data with other devices on the internet - so long as they support HTTP. Perhaps it'd be useful to try to emphasize "exchange data with any device on the internet" (same for local network).

[Mike Tsao]

+Mustafa Emre Acer, do you have notes from our original discussions on this topic? It's been a while, but I recall a tradeoff between specificity and usability.

[Mustafa Emre Acer]

The original discussion was at crbug.com/152713 with a more ambitious goal to convert ports to protocol and app names, but that turned out to be overly specific and too complicated to implement.

I agree the warning itself isn't meaningful for most users, but I don't think removing it altogether is better. Emphasizing and generalizing as "exchange data with any device on the internet" sounds better to me.

[Reilly Grant]

Adding net-dev for their opinion on whether the loop back/local/global split makes sense.

[Ryan Sleevi]

On Thu, Apr 9, 2015 at 8:40 AM, Reilly Grant <rei...@chromium.org> wrote:

Adding net-dev for their opinion on whether the loop back/local/global split makes sense.

In the IoT world, I think our security posture must assume that "on your local network" is equivalent to "any other devices on the Internet"

For example, I suspect that if we were do to a usability study, we'd find users who thought installing extension X, while at home, would be secure, they wouldn't think taking their laptop to ${coffee_shop} would leave them exposed.

So I mean, -1 split from me?

[Randy Smith]

Hmm. Doesn't this depend on your image of what IoT means? My
assumption when I think IoT is devices that are at fixed locations on
fixed network (e.g. my fridge). That assumption may be inaccurate,
but if there's a large group of items for which it *is* accurate,
maybe we could split our device policies based on fixed/variable
locations?

-- Randy

>
> So I mean, -1 split from me?
>

> --
> You received this message because you are subscribed to the Google Groups
> "net-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to net-dev+u...@chromium.org.
> To post to this group, send email to net...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/net-dev/CACvaWvbhK2FJ%2B%3DA4iLVqbQt2wawMyAfU768s296_xe3Wrdb%2Bew%40mail.gmail.com.

[Ryan Sleevi]

On Thu, Apr 9, 2015 at 2:57 PM, Randy Smith <rds...@chromium.org> wrote:

Hmm.  Doesn't this depend on your image of what IoT means?  My
assumption when I think IoT is devices that are at fixed locations on
fixed network (e.g. my fridge). 

I'd say that's not in line with what most of the industry is going towards :)

Ubiquitous always on devices. Certainly, regardless of where your fridge is (and I hope your fridge doesn't follow you every where you go), the IP 192.168.0.1 could be your Fridge when you're home, could be your Toaster when you're in the office kitchen, and could be the Bean Roaster when you're at your nearby coffee shop.

 

That assumption may be inaccurate,
but if there's a large group of items for which it *is* accurate,
maybe we could split our device policies based on fixed/variable
locations?

I don't think we can. We certainly don't _know_ that 192.168.0.1 is a fixed device. Nor do I think we should be trying to do heuristics like "Oh, it looks like you're at home based on your router's MAC address, I'll just let the security policy down" - since that just means to bypass the security policy, I only need to guess your router's MAC address (as a hypothetical) 

[Randy Smith]

On Thu, Apr 9, 2015 at 3:09 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
>
> On Thu, Apr 9, 2015 at 2:57 PM, Randy Smith <rds...@chromium.org> wrote:
>>
>>
>> Hmm. Doesn't this depend on your image of what IoT means? My
>> assumption when I think IoT is devices that are at fixed locations on
>> fixed network (e.g. my fridge).
>
>
> I'd say that's not in line with what most of the industry is going towards
> :)
>
> Ubiquitous always on devices. Certainly, regardless of where your fridge is
> (and I hope your fridge doesn't follow you every where you go), the IP
> 192.168.0.1 could be your Fridge when you're home, could be your Toaster
> when you're in the office kitchen, and could be the Bean Roaster when you're
> at your nearby coffee shop.

Sorry, when we disagree like this you're generally right and I'm
generally confused, but why isn't the issue treating "my local
network" differently depending on whether "I" am a mobile versus a
fixed location device? I.e. my fridge trusting "all devices on the
local network" might mean something, even if for my laptop that's
equivalent to trusting the world.

-- Randy

[Ryan Sleevi]

On Thu, Apr 9, 2015 at 3:56 PM, Randy Smith <rds...@chromium.org> wrote:

Sorry, when we disagree like this you're generally right and I'm
generally confused, but why isn't the issue treating "my local
network" differently depending on whether "I" am a mobile versus a
fixed location device?  I.e. my fridge trusting "all devices on the
local network" might mean something, even if for my laptop that's
equivalent to trusting the world.

-- Randy

Yes, but that prompt is shown on your laptop, not your fridge.

That is, you may trust your fridge, but we have no way to know when we ask "Do you trust your fridge" that it's your fridge (you're mobile).

That's why the distinction is less clear if prompting. If you grant access, you're not just trusting your fridge, you're trusting every device your fridge has ever talked to or had network exchanges with. Similarly, you're not just trusting your fridge, you're trusting every device your laptop may ever talk to.

So it's akin more to the Internet question 

[Reilly Grant]

Okay, sounds like no objections to splitting between loop back and the Internet at large but we might want to just lump link local traffic into "the internet."

Do you think the following makes it clearer that the middle category covers both the home and a coffee shop:

"Exchange data with nearby network devices."

Remember, we're talking about the install-time permission prompt for Chrome Apps. This allows them to create and listen for TCP connections and UDP packets.

[Ryan Sleevi]

On Thu, Apr 9, 2015 at 6:36 PM, Reilly Grant <rei...@chromium.org> wrote:

Okay, sounds like no objections to splitting between loop back and the Internet at large but we might want to just lump link local traffic into "the internet."

Do you think the following makes it clearer that the middle category covers both the home and a coffee shop:

"Exchange data with nearby network devices."

Remember, we're talking about the install-time permission prompt for Chrome Apps. This allows them to create and listen for TCP connections and UDP packets.

I guess my concern with "nearby" is that by creating that demarcation, it suggests that the data will ONLY be shared with nearby network devices. We're not sure that the device isn't going to just rebroadcast it to the Internet. Indeed, that's exactly what some of these devices exist to do (think your smart webcams and the like).

That is, I think it's (more) accurate as you suggest, but it might be misleading (as users expect). But on the question of misleading, I defer to the far brighter enamelites and their more refined sense of "the average user" and their expectations.

[Reilly Grant]

I think that as with incognito mode we can only give so much warning about what other systems may do with the user's data.

I think it's important to not be alarmist as well. The proposed connected fridge app shouldn't be penalized if it carefully constructs its permissions so that it can only use link local addresses.

[Ryan Sleevi]

On Thu, Apr 9, 2015 at 6:51 PM, Reilly Grant <rei...@chromium.org> wrote:

I think that as with incognito mode we can only give so much warning about what other systems may do with the user's data.

I think it's important to not be alarmist as well. The proposed connected fridge app shouldn't be penalized if it carefully constructs its permissions so that it can only use link local addresses.

I don't think it's fair to call it alarmist - it's exactly what it could do, and what many of these devices already do.

Your hypothetical Fridge and hypothetical FridgeTheMilk App would very likely do something like you have the app, you browse the Internet, you remember "Oh gosh, I wonder if I have milk and eggs" while looking at delicious cake recipes, the FridgeTheMilk app sends a message to your fridge to check the status, sees your empty, and then the _Fridge_ (not the _FridgeTheMilk_ app) orders milk and eggs from your Google Shopping Express account.

I guess where I'm going is that my experience so far looking at most of the IoT things is that the information they ingest, they reflect back somewhere. Maybe it's a central server (Nest Thermostat, Dropcam, PetCube), maybe it accepts direct connections (Routers, Switches), maybe it makes outbound connections to the general Internet (Chromecast, Fire). Part of the "IoT" idea is that these devices are not just on your local network, they're on the Internet, and they're going to take whatever data you send them, shuffle it around, and reflect back.

Sometimes these are devices you know and trust. However, as users start whitelisting these, I think we'll see more Firesheep-level coffee-shop attacks where they impersonate the device you want to talk to. This has been a real challenge to defend against for when designing devices like Chromecast, and not every company has such an amazing security team, so at the end of the day, the user's at risk.

Basically, I consider local network access to be the "HTTP" of information. Yes, your information "probably" is going to the person you think. But you've got no guarantees, and the messaging should reflect that.