https://www.bbc.com/news/articles/c4gwl3n7ne7o"Sensitive data" need not be transmitted to expose a vulnerability!
"Edward Rawde" <invalid@invalid.invalid>wrote: >>https://www.bbc.com/news/articles/c4gwl3n7ne7o
On 8/10/2026 7:08 PM, Edward Rawde wrote:
https://www.bbc.com/news/articles/c4gwl3n7ne7o"Sensitive data" need not be transmitted to expose a vulnerability!
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.
<https://www.faegredrinker.com/en/insights/publications/2022/3/open-source-vulnerabilities-the-newest-vector-of-attack>
<https://www.reversinglabs.com/blog/the-changing-face-of-open-source-security>
<https://www.yeswehack.com/news/chocopocs-vulnerability-researchers-trojanised-exploits>
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!
"Don Y" <blockedofcourse@foo.invalid> wrote in message news:115e1s5$3kp2t$1@dont-email.me...
On 8/10/2026 7:08 PM, Edward Rawde wrote:
https://www.bbc.com/news/articles/c4gwl3n7ne7o"Sensitive data" need not be transmitted to expose a vulnerability!
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.
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.AI cribs from code that it has seen. Folks complain "software is buggy".
If you use a lot of code generated by AI then how do you know
that there isn't anything unwanted hiding in it?
In message <115e076$2hrq$1@nnrp.usenet.blueworldhosting.com>, Edward Rawde <invalid@invalid.invalid> writes
https://www.bbc.com/news/articles/c4gwl3n7ne7o" During what the MoD called a "routine cyber vulnerability assessment" of the
drones, the cameras were found to have sent a squark rCo also known as a heartbeat communication rCo to a Chinese IP address. "
Imagine my astonishment when I found my pings don't get out if I'm off-line.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.
Perhaps the lesson learned is not to connect your weapon systems to the Internet
In message <115e076$2hrq$1@nnrp.usenet.blueworldhosting.com>, Edward Rawde <invalid@invalid.invalid> writes
https://www.bbc.com/news/articles/c4gwl3n7ne7o" 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
--
Brian Howie
"brian" <nospam@b-howie.co.uk> wrote in message news:wBOpKpj5rCfqFwsP@b-howie.co.uk...Unless you can control the entire path to destination, an IP
In message <115e076$2hrq$1@nnrp.usenet.blueworldhosting.com>, Edward Rawde <invalid@invalid.invalid> writes
https://www.bbc.com/news/articles/c4gwl3n7ne7o" 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
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.
On 8/12/2026 10:03 AM, Edward Rawde wrote:
"brian" <nospam@b-howie.co.uk> wrote in message news:wBOpKpj5rCfqFwsP@b-howie.co.uk...Unless you can control the entire path to destination, an IP
In message <115e076$2hrq$1@nnrp.usenet.blueworldhosting.com>, Edward Rawde <invalid@invalid.invalid> writes
https://www.bbc.com/news/articles/c4gwl3n7ne7o" 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
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.
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:
<https://en.wikipedia.org/wiki/EURion_constellation>
until you made an attempt to do what it is designed to prevent!
Unless you can control the entire path to destination, an IPImagine 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
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.
address doesn't guarantee a specific endpoint. IP and MAC
addresses can be spoofed.
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.
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.
True, but you can watch what it does.
Exactly. All of the products rely on an external server to deliver content BACK to you (really???)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:
<https://en.wikipedia.org/wiki/EURion_constellation>
until you made an attempt to do what it is designed to prevent!
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?
On 8/12/2026 3:16 PM, Edward Rawde wrote:
Unless you can control the entire path to destination, an IPImagine 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
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.
address doesn't guarantee a specific endpoint. IP and MAC
addresses can be spoofed.
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.
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)
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.
True, but you can watch what it does.
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???)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:
<https://en.wikipedia.org/wiki/EURion_constellation>
until you made an attempt to do what it is designed to prevent!
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?
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.
<http://shodan.io>
Gotta wonder where YOUR devices are in those totals! :>
"Don Y" <blockedofcourse@foo.invalid> wrote in message news:115isnt$16fv4$1@dont-email.me...
On 8/12/2026 3:16 PM, Edward Rawde wrote:
Unless you can control the entire path to destination, an IPImagine 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
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.
address doesn't guarantee a specific endpoint. IP and MAC
addresses can be spoofed.
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.
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)
Sure. You can tunnel any protocol over any other protocol if
you want to wait long enough due to inefficiency.
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.
True, but you can watch what it does.
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?
The bogus web site would be at an unknown and hence blocked IP.
I wouldn't believe anything DNS says.
Security cameras in people's homes already make me nervous becauseBACK to you (really???)
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?
Exactly. All of the products rely on an external server to deliver content
Most people don't know that, and don't care even if you try to explain.
On 8/12/2026 6:25 PM, Edward Rawde wrote:
"Don Y" <blockedofcourse@foo.invalid> wrote in message news:115isnt$16fv4$1@dont-email.me...
On 8/12/2026 3:16 PM, Edward Rawde wrote:
Unless you can control the entire path to destination, an IPImagine 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
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.
address doesn't guarantee a specific endpoint. IP and MAC
addresses can be spoofed.
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.
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)
Sure. You can tunnel any protocol over any other protocol if
you want to wait long enough due to inefficiency.
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...
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.
True, but you can watch what it does.
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?
The bogus web site would be at an unknown and hence blocked IP.
I wouldn't believe anything DNS says.
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.
Security cameras in people's homes already make me nervous becauseBACK to you (really???)
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?
Exactly. All of the products rely on an external server to deliver content
Most people don't know that, and don't care even if you try to explain.
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).
Security cameras in people's homes already make me nervous becauseBACK to you (really???)
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?
Exactly. All of the products rely on an external server to deliver content
Most people don't know that, and don't care even if you try to explain.
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 simplyYou can legislate "opt in" requirements and insist that "basic functionality" must work WITHOUT relying on an external server.
impossible to get it to the people's moronophones differently with the existing home Internet infrastructure.
Don Y <blockedofcourse@foo.invalid> wrote:
On 8/12/2026 6:25 PM, Edward Rawde wrote:
"Don Y" <blockedofcourse@foo.invalid> wrote in message news:115isnt$16fv4$1@dont-email.me...
On 8/12/2026 3:16 PM, Edward Rawde wrote:
Unless you can control the entire path to destination, an IPImagine 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
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.
address doesn't guarantee a specific endpoint. IP and MAC
addresses can be spoofed.
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.
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)
Sure. You can tunnel any protocol over any other protocol if
you want to wait long enough due to inefficiency.
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...
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.
True, but you can watch what it does.
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?
The bogus web site would be at an unknown and hence blocked IP.
I wouldn't believe anything DNS says.
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.
Security cameras in people's homes already make me nervous becauseBACK to you (really???)
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?
Exactly. All of the products rely on an external server to deliver content
Most people don't know that, and don't care even if you try to explain.
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.
---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
Its not mainstream, but there are internet service providers whoIf companies were liable for data leaks, privacy breaches, etc.
give static public IPv4 and IPv6 addresses.-a It then becomes much
easier to run your own servers and avoid sending all your information
to China.-a Some of it is sure to get out though.
On 13/08/2026 05:16, Sergey Kubushyn wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
On 8/12/2026 6:25 PM, Edward Rawde wrote:
"Don Y" <blockedofcourse@foo.invalid> wrote in message news:115isnt$16fv4$1@dont-email.me...
On 8/12/2026 3:16 PM, Edward Rawde wrote:
Unless you can control the entire path to destination, an IPImagine 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
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.
address doesn't guarantee a specific endpoint. IP and MAC
addresses can be spoofed.
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.
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)
Sure. You can tunnel any protocol over any other protocol if
you want to wait long enough due to inefficiency.
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...
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.
True, but you can watch what it does.
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?
The bogus web site would be at an unknown and hence blocked IP.
I wouldn't believe anything DNS says.
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.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 theBACK to you (really???)
pictures appear on a mobile phone elsewhere by magic, don't they? >>>>>>> Exactly. All of the products rely on an external server to deliver content
Most people don't know that, and don't care even if you try to explain. >>>
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.
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.
On 8/12/2026 11:37 PM, John R Walliker wrote:
Its not mainstream, but there are internet service providers who
give static public IPv4 and IPv6 addresses.-a It then becomes much
easier to run your own servers and avoid sending all your information
to China.-a 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!)
Don Y <blockedofcourse@foo.invalid> wrote:
On 8/12/2026 11:37 PM, John R Walliker wrote:
Its not mainstream, but there are internet service providers who
give static public IPv4 and IPv6 addresses.-a It then becomes much
easier to run your own servers and avoid sending all your information
to China.-a 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").
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.
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
Don Y <blockedofcourse@foo.invalid> wrote:
[...]
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
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."
On 8/13/2026 12:07 AM, Sergey Kubushyn wrote:
Don Y <blockedofcourse@foo.invalid> wrote:
On 8/12/2026 11:37 PM, John R Walliker wrote:
Its not mainstream, but there are internet service providers who
give static public IPv4 and IPv6 addresses.-a It then becomes much
easier to run your own servers and avoid sending all your information
to China.-a 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").
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.
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.
Sure. The only problem is that the appliance is the ISP's router that you don't have any control over. It exposes ONE IP for all the devices it NATs and you don't know what that address is. Then, it only works ONE WAY, from the internal network to outside world. There is no way to the internal network from outside world. It DOES forward (and de-NATs) the packets from ESTABLISHED connections but there is no way to ESTABLISH connection from outside world to a device behind the NAT.
Thw only way how it is done is having a trojan horse in the DVR (or
whatever) that establish a connection to mama server from inside the local net, over NAT as if it is a usual user connection to a web site or whatever.
Then, the reverse tunnel is established so that mama server gets connected
to your internal net and can do whatever it wants inside your [now breached] security perimeter.
Nothing special here but it requires bringing a trojan horse inside your perimeter and let it talk to external world, no matter over NAT or not.
There is no way inside the perimeter WITHOUT that trojan horse.
The mama server lives on a routable legal IP so all those moronophones can access it from anywhere and see videos from their cameras. That is a USEFUL hack which is the only way possible to somehow feed your videos (and perform some control) through that NAT on a provider's router. It is still a HACK
and it gives the mama server (and whoever might hide behind it) the full access INSIDE your security perimeter i.e. it is a full blown 100% security breach. And it is made not by somebody finding a tricky way to get in but
the user himself opening his door wide open without any guards.
On 8/13/2026 9:48 AM, Sergey Kubushyn wrote:
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.
Sure. The only problem is that the appliance is the ISP's router that you
don't have any control over. It exposes ONE IP for all the devices it NATs >> and you don't know what that address is. Then, it only works ONE WAY, from >> the internal network to outside world. There is no way to the internal
network from outside world. It DOES forward (and de-NATs) the packets from >> ESTABLISHED connections but there is no way to ESTABLISH connection from
outside world to a device behind the NAT.
No. This is a commodity function. You can purchase it from
whomever you trust, roll your own, etc. Likewise the "mama"
service can be provided by any party.
You can select end-to-end encryption whereby the "mama" doesn't
see any of your content but just provides a connection to your
"remote" -- which decrypts the content. *YOU* take on
the responsibility of selecting the service that fits your needs,
monetary budget and technical level of expertise. Instead of letting
the manufacturer "make it easy for you" -- and inserting themselves
into the process and data stream.
Thw only way how it is done is having a trojan horse in the DVR (or
whatever) that establish a connection to mama server from inside the local >> net, over NAT as if it is a usual user connection to a web site or whatever.
At your level of paranoia, ANY software that you are running on your
machines -- or on any appliances inside your firewall -- is a trojan.
If you feel that away, then you can "roll your own" and still avoid
being "hardwired" to a particular "mama".
Then, the reverse tunnel is established so that mama server gets connected >> to your internal net and can do whatever it wants inside your [now breached] >> security perimeter.
You can isolate ports so a device on one port of your router/appliance
can't see or access devices on the other ports.
<https://www.xda-developers.com/port-isolation-best-switch-security-feature-youre-not-using/>
None of this is magic.
Nothing special here but it requires bringing a trojan horse inside your
perimeter and let it talk to external world, no matter over NAT or not.
There is no way inside the perimeter WITHOUT that trojan horse.
All of the above indicate how that "trojan horse" can be constrained so
that only the device of interest has access to the outside world and
NOT the inside world.
Unless you are expecting everyone (device, appliance manufacturer,
service providers, etc.) to be conspiring to give the appearance
of security while secretly opening backdoors for exploitation.
The mama server lives on a routable legal IP so all those moronophones can >> access it from anywhere and see videos from their cameras. That is a USEFUL >> hack which is the only way possible to somehow feed your videos (and perform >> some control) through that NAT on a provider's router. It is still a HACK
and it gives the mama server (and whoever might hide behind it) the full
access INSIDE your security perimeter i.e. it is a full blown 100% security >> breach. And it is made not by somebody finding a tricky way to get in but
the user himself opening his door wide open without any guards.
No, the topology doesn't. Current implementations *might* -- for folks
who don't know how to configure their network infrastructure. But, it
is not a necessary consequence of that.
You can LIVE in our guest bedroom and access the internet using
software of your own *design* -- and still not access any of the
hundreds of other hosts within the outer perimeter. Because I
considered that an important criteria when designing the network.
[*My* "stealth server" sits at a friend's business. Despite my having
remote access to it -- and it having considerable compute and storage resources -- there's nothing that I can do to interfere with his
business operation. To him, I am as trustworthy as some no-name IoT
device.]
There is nothing that constrains a manufacturer to AVOID putting itself
in the middle -- or, to avoid accessing personal/private data.
And, as there is financial value to them doing so, they, naturally, do!
If legislation enforced a "fiduciary" duty on anyone holding or
processing such data, then lawsuits arising from breaches would
quickly prove the data to be worth less than the associated risk.
Sure. The only problem is that the appliance is the ISP's router that you >>> don't have any control over. It exposes ONE IP for all the devices it NATs >>> and you don't know what that address is. Then, it only works ONE WAY, from >>> the internal network to outside world. There is no way to the internal
network from outside world. It DOES forward (and de-NATs) the packets from >>> ESTABLISHED connections but there is no way to ESTABLISH connection from >>> outside world to a device behind the NAT.
No. This is a commodity function. You can purchase it from
whomever you trust, roll your own, etc. Likewise the "mama"
service can be provided by any party.
OK, I'm tired and won't go any further...
The function is commodity. You can NAT any address to any address. The problem is you don't have a ROUTABLE external address. Whatever the ISP gave you on your external interface is NOT routable. It is from RFC1918 range. It
is NAT'd further down, in an ISP router, into some routable address that you don't know. There is no way you can INITIATE connection from outside to your RFC1918 address which is the only one you have on your external interface.
It doesn't matter what you have inside. And you can't initiate connection to your internal network using that IP you've been NAT'd to even if you knew
it.
Your moronophone lives OUTSIDE your internal network. It might be also NAT'd or not. It can only access whatever is accessible over the Internet. 99.99% of "home" internet setups don't have ANY exposed IP addresses that could be accessed over the Internet.
The only way how it can connect to your DVR controlling all your cameras is by using a HACK. You setup some middleman server accessible from Internet
and make a trojan horse in that DVR, which is somewhere inside your perimeter, connect to that middlemen and establish a tunnel thus breaching your perimeter. The DVR and its cameras might be on their own network, firewalled from the rest of your internal net[s] but that doesn't matter.
You ONLY have ONE external IP for your ENTIRE infrastructure so everything goes via that interface. Even if you somehow firewall that cameras' network, the mama middleman still have FULL control over your DVR and all security cameras. It can't be done other way because your moronophone app must be
able to control your cameras and DVR -- it won't make sense otherwise.
You can select end-to-end encryption whereby the "mama" doesn't
see any of your content but just provides a connection to your
"remote" -- which decrypts the content. *YOU* take on
the responsibility of selecting the service that fits your needs,
monetary budget and technical level of expertise. Instead of letting
the manufacturer "make it easy for you" -- and inserting themselves
into the process and data stream.
Sure you can. But that is not something that 99.9999% of the "home" users
are able to do. Furthermore, you will have to build your own DVR that would talk to that your own server and make your own monophone's app that would talk to that server using your own protocol.
Thw only way how it is done is having a trojan horse in the DVR (or
whatever) that establish a connection to mama server from inside the local >>> net, over NAT as if it is a usual user connection to a web site or whatever.
At your level of paranoia, ANY software that you are running on your
machines -- or on any appliances inside your firewall -- is a trojan.
If you feel that away, then you can "roll your own" and still avoid
being "hardwired" to a particular "mama".
Who paranoid?! I'm paranoid? Hm... Yes, I AM paranoid. But am I paranoid ENOUGH?
Then, the reverse tunnel is established so that mama server gets connected >>> to your internal net and can do whatever it wants inside your [now breached]
security perimeter.
You can isolate ports so a device on one port of your router/appliance
can't see or access devices on the other ports.
<https://www.xda-developers.com/port-isolation-best-switch-security-feature-youre-not-using/>
None of this is magic.
Nothing special here but it requires bringing a trojan horse inside your >>> perimeter and let it talk to external world, no matter over NAT or not.
There is no way inside the perimeter WITHOUT that trojan horse.
All of the above indicate how that "trojan horse" can be constrained so
that only the device of interest has access to the outside world and
NOT the inside world.
Unless you are expecting everyone (device, appliance manufacturer,
service providers, etc.) to be conspiring to give the appearance
of security while secretly opening backdoors for exploitation.
They all do. Ever heard of, e.g. Imperva and such? And all devices have
their own firmware with essentially ALL "US" security cameras providers
like, e.g. Lorex are just a tiny storefronts for the Chinese companies.
On 8/12/2026 1:12 AM, brian wrote:
In message <115e076$2hrq$1@nnrp.usenet.blueworldhosting.com>, Edward >>Rawde <invalid@invalid.invalid> writesWhether 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)?
https://www.bbc.com/news/articles/c4gwl3n7ne7o" During what the MoD called a "routine cyber vulnerability
assessment" of the drones, the cameras were found to have sent a
squark rCo also known as a heartbeat communication rCo 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
In message <115hff6$n3ef$1@dont-email.me>, Don Y <blockedofcourse@foo.invalid>If the message is unique (S/N based), then it can be used to tally
writes
On 8/12/2026 1:12 AM, brian wrote:
In message <115e076$2hrq$1@nnrp.usenet.blueworldhosting.com>, Edward RawdeWhether any "successful" communication actually took place isn't the point. >> Rather, the origins of some part of the weapon system are now of concern.
<invalid@invalid.invalid> writes
https://www.bbc.com/news/articles/c4gwl3n7ne7o" During what the MoD called a "routine cyber vulnerability assessment" of >>> the-a drones, the cameras were found to have sent a squark rCo also known as a
heartbeat communication rCo to a Chinese IP address. "
-a Imagine my astonishment when I found my pings don't get out if I'm off-line.
-aPerhaps the lesson learned is not to connect your weapon systems to the >>> Internet
What *else* will it do (or not do)?
I suppose it could be of use to the "Find my drone/missile etc" app on a smart
phone.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 01:01:16 |
| Calls: | 1,102 |
| Calls today: | 2 |
| Files: | 1,339 |
| Messages: | 276,780 |