[iot-wg] "The Internet of Threats: Fighting FUD with MUD"

>> The question here to me seems what we want to achieve. I’m totally on
>> your page in terms of data collection and privacy. But that’s to a large part
>> the end users choice - even if I have to admit most of them simply don’t care, 
>> just look at the amount of data people share via facebook: Happy social
>> engineering!
> 
> Yes and no. I’d like to think that most people would be *far* more careful about their use of social media if they knew how their data were being exploited and/or thought about the long term consequences of that. 

I agree but I have no real idea how to make people aware. Most of the end users focus on convenience - do we really have to see more cases of misuse of personal data? I don’t know...

>> MUD files can help to identify what’s a devices purpose and monitoring if
>> the device is doing what it’s supposed to do. I agree that we should not
>> have much hope that the device makers will do their job.
> 
> Indeed. However at least MUD files should (in principle anyway) give people an idea of what their latest IoT toy will do once it’s plugged in. Though just saying it phones home to google/Amazon/Facebook every so often isn’t much help if you don’t know what it's sending and receiving. Or why it’s doing that.
> 
> MUD files are a small step in the right direction. Hopefully we’ll one day see this information printed on the IoT device itself and the box it comes in.

I absolutely agree. But as long as the device makers don’t see a benefit in providing (correct) MUD files we have to seek ways to create them. Also a MUD file provided by the device maker with detailed information would not prevent the device from sending personal data or doing things the end user doesn’t like as long as it’s encoded correctly in the MUD file. I did like the MUD proxy idea from Michael’s presentation that provides „correct“ MUD files.

Another concern is how far CPE/home gateway manufacturers would adopt related technical proposals. So far most firmwares are based upon chipset maker’s SDKs that serve the purpose of selling chipsets instead of providing reliable and secure solutions. The lastest FCC and ETSI rulings (=> RED discussion) did also not make it easier to provide alternative firmware solutions (i.e. OpenWRT), let’s see how the RED ruling goes.