Addressing user concerns about using Content Delivery Network files

Use cloudflare CDN for jquery.flot.time.js

This actually brings up something that doesn’t affect me yet, but I did notice and made a foodnote about…

I’m starting to more aggressively lock down the subnets on which I put automation gear. Video for example is 100% locked out, it cannot reach the internet at all, and very limited paths to other subnets.

But at present most of my other automations can reach the internet, including IoTaWatt. But they are on my list to start separating those that must (e.g. because of cloud requirements) and maybe limiting them.

Have you given any consideration to an option to putting all resources locally instead of using the internet? Are there licensing issues for example? Do you not because of space concerns?

Again, not a big deal now, but I suspect over time people will give more and more attention to what their automation devices are touching.

1 Like

People are implicitly telling google and facebook what they will not tell their spouse. They are sending a trail of their daily life to anybody that gives them a cheesy app that innocently asks for permission to access their location. I don’t think accessing a CDN is ever really going to become an issue. It’s nearly impossible to have an app that doesn’t require these services. Only the IoTaWatt configuration app doesn’t require CDN modules, and it is painful to do things without the tools they provide.

Graph+ loads all of the CDN stuff from cloudflare. You can load it all to the IoTaWatt file system and change those loads to go to the IoTaWatt. It will significantly slow down the initialization, but should work. Another approach would be to use a smarter filter that allows access to the major CDNs.

People are implicitly telling google and facebook what they will not tell their spouse…

I don’t think accessing a CDN…

I think you misunderstand. It’s not the CDN per se, it is the techniques I think people may want to use. It’s easier to just prevent internet access for a group of devices entirely than it is to specify what “safe” access means. I can always either do as you suggest, or intercept the DNS queries and redirect to my own server; I know I can “fix” this situation.

I just wanted to raise it for your consideration. Done.

PS. I wonder if for most people access over the internet is really faster than from the built in SD card?

Hosting a static file like this on a CDN doesn’t cause the IoTaWatt to require Internet access. This file will actually be loaded by your web browser when you view the IoTaWatt’s web UI; the IoTaWatt itself will never access it. I don’t know whether the IoTaWatt would, or would not, work without Internet access… but static content in the web UI would not affect whether it does or does not.

There are some other potential reasons to use local hosting, but IoTaWatt’s implementation also uses a technology called sub-resource integrity to ensure that the CDN-hosted files match the expected content. This eliminates some potential security risks with using a CDN for this content.

1 Like

Gesh, I’m embarrassed, I was not thinking. Can I plead temporary insanity while debugging a bunch of node-red flows?

Of course you are correct. The only relevancy is in what works (and doesn’t) if your internet is down.

To the extent that the browser is usually on the same LAN to access the IoTaWatt, it therefore might be subject to the same restrictions regarding an internet access policy. As soon as you open up a port to move the browser into a more accommodating environment, there is a set of new issues regarding LAN security, and in particular the integrity of the IoTaWatt to not become a wormhole. While I can speak to the precautions taken at my level, they are only as good as the underlying layers in the stack. If you have a LAN that needs to be protected against internet access, you probably don’t want an IoTaWatt or any other IoT devices on it.

To the extent that the browser is usually on the same LAN to access the IoTaWatt,

Yeah, wish I could use that as an excuse for my mis-interpretation. I’m keeping all the PC’s and “regular” linux systems on a separate VLAN that is open to the internet, and has access to the automation VLAN. Right now the automation VLAN is also open to the internet, as at least half of it needs access (google speakers mostly, but also two garage doors I can’t figure out how to hack directly, and a heat pump hot water, plus a Lutron Caseta).

The video cameras, with all their publicity of hacks, went on a separate LAN and is locked down completely. The VMS system that accesses it actually has a separate NIC (no point in that steady load on my router). So if any have back doors trying to report back somewhere they can’t.

But the regular automation items, which include IotaWatt, are going to be a lot more difficult. I can’t decide if I want two separate VLAN segments, one for internet-connect and one not, or build separate rules, or…

Doesn’t help that many, like google, are likely to have wide ranging IP’s for their use, so it is hard to lock them to specific sites also. My guess is IotaWatt would be easy in that regard, but Google may be hopeless.

It’s a work in progress.