Firmware update?

The "far end" now knows the device is "live"/deployed and (likely) some general idea of WHERE.

For big systems, it's nigh on impossible to assure yourself that there isn't something hiding inside that "isn't needed" (and can potentially be working against your intentions).

This, increasingly, as more folks blindly embrace FOSS codebases in the naive belief that all of the "contributors" were benevolent souls.

The laughable assumption that "lots of eyes" will see and detect these sorts of things shows just how naive adopters are. And, no, NO ONE on your team has a grasp of all the code you're leveraging!

Nice, makes tracking and hitting easier.

I have a lot of Chinese stuff at home, from satellite receiver boxes to speakers, to my 4G Huawei USB modems, to drones, and all sort of chips and toys, OLED displays, LCD displays much more.

All works great and is cheap. China likely now knows everything about me now :-) Ah, forgot Bluetooth stuff

Oops and wall warts of all sorts. Solar powered flashlight.. Just when I look around, Chinese stuff everywhere, And not just China, other countries stuff too.

US stuff? no... Oops using a Logitech keyboard and mouse Logitech - Wikipedia Logitech International S.A. (/ ˈlɒdʒɪtɛk / LOJ-i-tek) is a Swiss multinational manufacturer of computer peripherals and software. Headquartered in Lausanne, Switzerland, [1] with an important operational headquarters in San Jose, California, [3][4][5] the company has offices throughout Europe, Asia, Oceania, and the Americas. It

So some in 'merrica, it is a wireless keyboard, maybe it sends all I type to trump?

Does the US and UK use wireless keyboards? ;-)

Will have to encrypt ;fjmkws;a fs;'[k fs'fwef pwp3q2r4f'f 'wpflg

beep!

Yes it's no longer possible to know what's potentially in most software, due to contributions coming from many places. Back when I used to write a few KB of code for something like a 68020 I knew exactly what was in it. These days I'd probably have to start with a FOSS OS and other FOSS libraries.

AI is likely to become an issue here too. If you use a lot of code generated by AI then how do you know that there isn't anything unwanted hiding in it?

"Contributions", in the past, came from coworkers or *purchased* components. People that have a reputation to protect.

FOSS comes from faceless names with unknown motivations.

Much depends on the scale of the problem you are addressing, it's potential "exposure", value added (i.e., at risk) and expected lifetime.

If you are planing on developing a product/product line, then it behooves you to invest in YOUR codebase instead of inheriting a codebase that you likely will never take the time to analyze, critique, validate, etc. Yet, *yours* will be the reputation at stake when/if things go south in ways that you've not accommodated.

AI cribs from code that it has seen. Folks complain "software is buggy". So, software copied from other software is magically *better*?? And, wait until AI-generated code starts training OTHER AI's... :-/

In message <115e076$2hrq$ snipped-for-privacy@nnrp.usenet.blueworldhosting.com>, Edward Rawde snipped-for-privacy@invalid.invalid writes

" During what the MoD called a "routine cyber vulnerability assessment" of the drones, the cameras were found to have sent a squark – also known as a heartbeat communication – to a Chinese IP address. "

Imagine my astonishment when I found my pings don't get out if I'm off-line.

Perhaps the lesson learned is not to connect your weapon systems to the Internet

Brian

Whether any "successful" communication actually took place isn't the point. Rather, the origins of some part of the weapon system are now of concern. What *else* will it do (or not do)?

And if you do, make sure it keeps a log of what it's talking to. And make sure it has a firewall which only alows talk with MoD IP addresses.

Unless you can control the entire path to destination, an IP address doesn't guarantee a specific endpoint. IP and MAC addresses can be spoofed.

If you can't control the software in a device, then you can't control what it does, doesn't do and under which circumstances.

A camera can selectively decide NOT to see certain things, based on features in the image. You won't know about that until you try to see something and wonder why what the camera reports is not what your own eyes see.

You'd likely never know about:

But then your return packets don't go where you want them to and in any case the endpoints should be verified in advance and encryption used.

True, but you can watch what it does.

Security cameras in people's homes already make me nervous because there's no way to know who may be looking at the pictures and the pictures appear on a mobile phone elsewhere by magic, don't they?

You may not want/need bidirectional communication. E.g., I have designed products that tunnel under DNS to "report" on their activities. It's a very low bandwidth channel (depending on how surreptitious I want to be) but data *does* flow. I can return almost as much data as is delivered to me (without attracting too much attention)

But that requires a fair bit of effort and/or automation. If I try to resolve a bogus name once every 5 hours, will you notice it in all the other traffic? Or, access a bogus website?

Exactly. All of the products rely on an external server to deliver content BACK to you (really???)

When I had to develop the user location tracking software for my product, cameras would have been the easy approach. All the user would have to do is "exist" and I could determine his location and movements!

But, I felt people would be uncomfortable with cameras in every (EVERY) room in their "personal residence" (or business, etc.) wondering what was being seen, recorded, etc.

To ensure NOTHING leaves their control, I don't support an out-facing interface (unlike all of these other IoT devices that want to "talk to Mama" instead of doing the job themselves). There's no need for some other "foreign" device(s) to be involved in its operation.

Gotta wonder where YOUR devices are in those totals! :>

Sure. You can tunnel any protocol over any other protocol if you want to wait long enough due to inefficiency.

The bogus web site would be at an unknown and hence blocked IP. I wouldn't believe anything DNS says.

Most people don't know that, and don't care even if you try to explain.

Shodan have to be one of the few with consistent reverse DNS names so you know who it is.

It depends what your goals are. If you already have a payload installed and are just waiting to *activate* it...

Or, if you want to know how many (unique) instances of a particular product exist... Or, that it has been deployed...

Again, depends on the environment. An *employer* likely wouldn't know to block that domain as their employees may opt to resolve a HUGE variety of different names as they "surf the web", etc. Note how many domains are visited by the "mainstream" sites that YOU visit.

One can contract with a firm to determine and maintain a list of blocked domains (our local library does just that) but, that is an ongoing effort -- hence the cost involved in retaining that service. And, chances are, they're efforts will still have holes that defy their intended blocking criteria. E.g., I may be blocked from a particular site -- yet, can access a copy of the site from archive.org. Or, can access a mirror that I might know about but they have yet to discover.

If you take the opposite approach -- of whitelisting ONLY those permitted sites -- then you find yourself always on the receiving end of complaints from folks with legitimate needs that you've effectively blocked out of ignorance.

There is the belief that "there is no privacy" -- which is self-fulfilling, if you LET it be.

Eventually, there will be an "incident" and people will be outraged with how exposed they have become. That *may* lead to legislation that coerces folks to AVOID accessing material/data that is protected thusly (to reduce their legal exposure and financial liability).

Here is the solution for security cameras (I have 16 of those inside and outside my house) -- only use WIRED PoE cameras on their own subnet without ANY Internet access. Do NOT use ANYTHING that requires access to some mama servers (99.99% of which are in China) for anything. ALL those mamas not just require Internet access but also require a port mapping on your router/firewall to their DVR with a login to it. This way you grant access into your internal network with their trojan horse and can only blame yourself for all the consequences.

They all have a pretty valid excuse for putting a trojan horse into your house even if that horse is 100% benign (one would be a total moron to believe that) and their intentions are 100% innocent (see about morons). The excuse is simple -- most of the home Internet external IPs are dynamic and vast majority of those are from 10.x.x.x range so they are not just unknown but also not routable beyond the provider's router. The only way to show you video feeds from your cameras on your moronophone is to let your DVR connect to their server and establish a tunnel giving them full control over your entire infrasystem. Without that you won't be able to control your cameras and DVR from your moronophone. As an added "bonus" you can store your footage in their cloud so it would be "safe".

Everybody with a trace of brain would NOT allow that. Those without brains shouldn't complain about privacy and whatever else.

Do NOT use any moronophones and those totally unknown apps. It might look convenient, but it is no different from leaving all your doors and windows wide open without any locks or whatever. And they don't even have to look for excuses to bring a trojan horse into your house -- it is simply impossible to do it without that horse for 99.9999% of all households here in the US. The total amount of intellect on the planet is constant and population keeps growing without an end in sight...

There is no way it could be fixed by a legislation -- it is simply impossible to get it to the people's moronophones differently with the existing home Internet infrastructure.

The argument for access to their server is:

- they can add functionality at the server (instead of putting it into the actual device)

- they can provide a registered domain that one can access from "outside" the home

The first is laughable, given the amount of smarts many of these devices have "at the edge"; the only advantage a remote server could offer is to augment information that might not be available "locally" (e.g., a smart thermostat being able to adapt to current weather conditions AND FUTURE WEATHER PREDICTIONS)

The second can be accomplished with a DDNS service. Admittedly, this is more involved than having something automagically in place. But, you may not really care about remote "on demand" access; have the camera email you anything of interest and you can view the email (and attachment) using existing software (on your phone, laptop, company workstation, etc.)

I "solve" this problem with different pipes out of the house for different purposes.

E.g., if in the car (which I consider to be an extension of the house), AND nearby, then the wifi link to the node I've located in the car lets it act like any other node in the house. E.g., I could use it to remove commercials from recorded TV shows. Or, display the contents of the garage to explain why the garage door is refusing to honor the request to open (the dog happens to be in the garage).

Beyond the WiFi range, a cordless phone gives me a narrower pipe that is good to ~1 mile range. So, if I forgot to close the garage door, I can be notified of that and prompted as to whether it should be done FOR me. Or, if approaching the house, I can determine if I've been advised to park in the driveway due to a guest vehicle being in the garage (and needing to be able to get out without worrying that I've parked behind them)

Beyond that, the cell phone gives me limitless range but with restrictions on bandwidth and latency (I may be at a landline and only have voice available).

But, this is an exception. Most consumers are stuck with whatever their phone will offer.

Sadly, it is not limited to cameras. Our refrigerator and stove both have "remote access" (if I had opted to turn it on). Why do I need to be able to turn my oven on/off from across the country?

You can argue that something like a washing machine/clothes dryer should be able to send a notification to your phone -- IF IT IS LOCAL! But, who would want to receive a notification that their clothes are dry when they are away, at work?

They've already given up hope for privacy. They've already swallowed that pill.

No, people are just lazy. In their actions AND their thinking. Businesses know this and exploit it. E.g., all of the "autopay" services that rely on you being too lazy/busy to take time to cancel. Imagine if you had to explicitly RENEW each year, instead! Google (Nest) wants to know if your home is occupied, if you are "active", what your energy needs are, etc. -- so they can use that to THEIR advantage.

You can legislate "opt in" requirements and insist that "basic functionality" must work WITHOUT relying on an external server.

I've repurposed a Nest thermostat as they have more resources available to make something "pretty" that would be a significant task for me. IIRC, as sold, it will perform as a thermostat even if not internet enabled. But, no remote access in that configuration.

Likewise, "real" telephones that connect to the cell service (who the hell wants to carry a cell phone around the house? Or, run to answer it before voice mail?? (with a cell-phone gateway, you can use more traditional phone appliances -- like answering machines that let you screen calls, etc.)

Its not mainstream, but there are internet service providers who give static public IPv4 and IPv6 addresses. It then becomes much easier to run your own servers and avoid sending all your information to China. Some of it is sure to get out though.

If companies were liable for data leaks, privacy breaches, etc. then they would design their products so they were NOT "middle men".

You can subscribe to a DDNS service and have an "appliance" that acts as a "device gateway" ensuring that each port is isolated from all others (so devices can't see each other's traffic or "kabitz").

As it currently stands, there is no reason for a manufacturer to remove itself from the loop (and lots of incentive for it to remain there!)

I run all my servers and services locally. Have Cox Business Internet with a CIDR block of 16 static addresses, own domains, own DNS, own mail and WEB servers and whatever else. Only buying connectivity, nothing else.

However, it is NOT a usual situation and there is ONLY ONE ISP in Las Vegas Valley that provides such option at a reasonable price. Nobody else does that at all. Dunno, maybe even that only one doesn't provide it anymore -- my service is grandfathered; I started it many many years ago...

That won't work if you have a 10.x.x.x external IP. No DDNS would help you

-- those addresses are not routable. You are only able to access the Net because of *NAT on the provider's router.

You have RFC1918 addresses *internally*. What is exposed is assigned (static or dynamic) by your ISP. *That* is what needs to be accessible "from the outside world".

You have an appliance map internal IPs to services on that address.

Many AUPs will contain language that makes this a bit tricky as you are (technically) operating a server -- often expressly prohibited.

The problem comes with ISPs who heavily NAT the addresses that they serve. But, you can still workaround that by having the "appliance" initiate the connection to your remote device. It just needs to be aware that a connection attempt is being made.

Given that phones (the most common "external device") can run apps, you can embed any protocol issues in the "app" so it's hidden from the user.

E.g., my server "hides" from probes and will only acknowledge an attempt at contact if a particular sequence of packets (connection attempts) are made in a narrow window. And, once connected, ignores other IPs that suspect its existence (i.e., a ticket is only granted to the IP that navigated the sequence and that ticket has an expiration)

In ages past (1990's), I would rely on email to establish a connection as neither side knew where the other might be. Slow and tedious but easily automated.

Reminds me of the [probably apocryphal] insurance claim:

"The fog was thick and, as I turned into my driveway, I collided with a tree I haven't got."