Streaming w/ delay for first responder safety
- Thread starter ERIC-KC9MHE
- Start date
- Status
Tweekerbob
Member
- Joined
- May 27, 2004
- Messages
- 614
There's a word for that - Sprint/Nextel...been in use for years.
I know very few criminals who have a scanner...0 know how to use them (at least to any significant use). I don't know where your fear comes from...Hollywood?
Idiots are jamming PS frequencies often. Not too sure how smart that is.
Can we please move this back on topic to how we can or cannot introduce a delay into a feed rather than perpetuating a tired argument?
So, what's the issue?
If very few criminals have a scanner, then why the need for anti-mobile scanning laws?
And a smart crook would jam an open LEO channel, just to delay action from the LEO's...
My point is: Why worry about instituting any sort of delay, when if LEO's really need to keep people from listening, they should encrypt.
There you go, using the "E" word. Private and delayed communications are for different purposes.
I agree with Tweekerbob on keeping this to the original topic.
It's on topic: Why bother with a delay?
Criminals, if they know there is a delay, will just use a regular scanner, and not bother with a stream. If the communications are that vital to keep out of criminal's hands; then encrypt the channel.
Putting a delay on a feed serves no purpose other than a placebo affect for secure communications. Criminals can still eavesdrop, and use the knowledge for nefarious purposes.
You're still off topic and missing the point. A lot of agencies don't want to spend the bucks for encryption or purchase a new system that supports encryption.
I hear all the time about agencies wanting there feed delayed for various purposes. Not just for the criminal element.
Besides very few criminals have scanners. Maybe some of the professional criminals have them but the odds are they have
smart phones more then scanners.
Here's the thing that bugs the crap out of me, although I'd still be willing to implement a delay were it available.
Criminals have far more control over a scanner than they would over an app receiving a scanner feed. As long as the scanner feed is not dedicated to a single frequency or talkgroup the chances of them being able to hear an entire call or operation is marginal.
This for the most part is likely much adieu about nothing. I don't believe that anyone but the actual department should be providing a feed that is dedicated to one single channel or talkgroup. I do believe that if "unofficial" feed providers are doing so they may want to reconsider, or RR may want to consider a policy against such feeds if there is not one already that I'm unaware of.
Criminals have far more control over a scanner than they would over an app receiving a scanner feed. As long as the scanner feed is not dedicated to a single frequency or talkgroup the chances of them being able to hear an entire call or operation is marginal.
This for the most part is likely much adieu about nothing. I don't believe that anyone but the actual department should be providing a feed that is dedicated to one single channel or talkgroup. I do believe that if "unofficial" feed providers are doing so they may want to reconsider, or RR may want to consider a policy against such feeds if there is not one already that I'm unaware of.
So, this is the crux of the matter. Agencies want to complain, but they don't want to do anything to actually keep LEO's safe.
They want a scapegoat:"Well, if it weren't for those rascally scanner websites; our guys would be safe!"
Well, the issue of this thread (For someone who insist we stay on topic) was for first responder safety. Well, adding a delay to an internet stream does nothing to assist with first responder safety. It's a placebo.
If very few criminals have scanners, then why the laws against mobile scanning?
Again, the "why" needs ot be asked here: Why should a private organization be asked to use their own resources to add in a delay, when if anything, it's a placebo. The people who want the instant, as-it's-happening feed would already have access to a scanner.
So, it boils down to: If the departments don't want people listening in real-time, then they should encrypt their comms.
I'm a rescue worker myself, and I don't mind real time audio. News an half hour old is no news anymore. I use RR to listen to the channels so I can hear a ship in need calling before my peapers goes and so win some time, seconds can save lives.
With a delay you can better listen to the recording later with the silent filtert out, with f.i. scanrec.
Henk Wijga, Dutch rescueworker.
With a delay you can better listen to the recording later with the silent filtert out, with f.i. scanrec.
Henk Wijga, Dutch rescueworker.
Let me guess. You are a sales rep for Moto or Harris.
I've never seen anyone here suggesting encryption comms.
I'm not suggesting it, except in those cases where agencies feel the need to secure their communications. If they are worried about "bad guys" using their own equipment against them, then they need to secure it.
As an aside, no. I am not a Moto or Harris sales rep. I'm an IT guy, who specializes in information security. And, I like to play with radios.
What agencies (And some people on this forum) are suggesting is akin to an organization trying to secure a telnet connection just use a non-standard port number. It really does nothing to secure it. It's a placebo. bad guys will still be able to sniff your user names and passwords. If you want to secure it, you can encrypt it.
Will encryption prevent scanner listeners from enjoying one part of their hobby: Yes. However, if first responder safety is the issue, then I'd rather first responders be safe, rather than listen in on them.
Then you don't do much reading. Plenty of people here, including the site owner, share the thought that if Public Safety feels they need to be secure in their radio transmissions then they should encrypt such transmissions. This debate is almost akin to not listing certain talkgroups in the database because of their sensitive nature. Security by obscurity does not work.
Uber you make some excellent points on this
East_Algoma
Member
I am a programmer , and yes a front end can be written on the server side ( your pc your scanner ) to delay 10 or more mins....if I wrte the prog , what would a person pay for this ? Im just curious....
Tweekerbob
Member
- Joined
- May 27, 2004
- Messages
- 614
Like they could have for well over 40 years! My point is simple. The people who know how to use scanners, know what is being said, and use this for their nefarious purpose are so far and few in between, you'll need a new calculator to display all of the digits behind the decimal point. You sure you don't work for DHS?
Your invalidation of the effectiveness of an inherent delay in feed streams has effectively removed you from this conversation, simply because you add no warranted or gainful information to either achieving this goal or seeing its successful implementation. If you wish to continue this discussion, please do so in the already established and well-discussed encryption threads, rather than hi-jacking this one.
If you don't want anyone to recieve, don't send it out or encrypt it.
Again, I 'm a firsr responder and don't have annything agains real time listeners.
That's the least that will put me in danger.
Again, I 'm a firsr responder and don't have annything agains real time listeners.
That's the least that will put me in danger.
Chiming in on this off topic-topic, reddingsdienst does have a point. Criminals listening to a feed won't really put first responders in danger but will only give them an opportunity to leave the scene before they get there. Most agencies do a great job moving to an encrypted channel when they give out their positions and many others use TAC channels which are forbidden on Live Audio here.
I don't see this as off topic or as a hijack.
The OP addresses the issue of first responder safety. Had the OP only asked for such a delay without the part about why, then you'd be right. However, he didn't. In fact he asked the question "Are there any first responders who would like to chime in on the usefulness of such a thing?"
So it's more then fair game to respond to that part of the initial post and hence is not off topic...
Here's a first responder with some input.
My crews recently discovered my feed (it wasn't put up for their benefit, it's something I'm doing as a hobby) and they love it. They use it for listening to on-scene comms when they are out of range of our radio system. The only thing they dislike is the fact that it has a delay (inherent in the design of the feed and the Internet). In other words, they don't think there's a need for a delay, nor do they feel that there is any safety concern with having our dispatch-related audio and wide-area comms audio on the Internet. (Our simplex fireground channels are not streamed, more because it is impractical to do so due to the low power nature of them and the impossibility of getting a consistently strong signal for them due to our huge area.)
The other thing that talks not just to the discussion of the feed, but about the sensitivity about emergency comms (or lack thereof), is that my department is rather open about our responses. We have a Twitter feed which I manually update with calls we are responding on as it happens. Naturally we don't say "We're going to 5432 1st Street apartment 203 to deal with 87 year old Mr. McGillicutty who fell off the toilet", we say "We are responding to the downtown area for a medical assist". Media outlets follow this Twitter account and pay close attention to what is going on. With this, we have a great relationship with a lot of agencies and are getting decent publicity out of it. There's no reason to hide yourself away from the public. Things which are private can be discussed in private - either face-to-face or off the monitorable airwaves. (Anything we wouldn't say shouted from the top of our rescue truck through a megaphone is never broadcast over a radio - instead is communicated over a less-easily monitorable network such as cellular telephone.)
There's nothing inherently unsafe about having your comms broadcast on the Internet (and via smartphone scanner apps, and etc). If you are communicating things on those frequencies that have the potential to jeopardize the safety of your responders, you need to re-evaluate (a) whether those things need to be said in that "forum" and (2) whether or not you should have a more secure "forum" for saying those things. Safety is not compromised by the world knowing that your crews are responding to the intersection of Walk and Don't Walk for a car crash. Neither is privacy of the patients - they're in a public place. People could just as easily tuck in behind the engine as it goes by and follow them out of curiosity, rather than hear it on the scanner, and they'd still get to the scene.
If you (as a radio system operator) have police operations that specifically involve communications to circumvent the movements and/or operations of the bad guys, i.e. gang unit or drug team surveillance, or even tactical/SWAT team positioning on a barricaded subject, it is your responsibility to ensure that these communications are protected from "prying ears". This however does not include general patrol. There is nothing inherently sensitive about routine police work i.e. that you are sending a car to 5678 Xyz St. for a domestic dispute or to the Downtown 7-11 to investigate a shoplifting (or even an armed robbery). It should not be the responsibility of an audio streaming service to obfuscate any of these comms - through delays or other measures - to prevent "the bad guys" from using it to their advantage. A police or public safety department finding itself having such issues needs to evaluate, as I said earlier, what it says on the radio, and whether or not that part of its radio service needs to be secured (if that stuff really has to be broadcast anyway).
My crews recently discovered my feed (it wasn't put up for their benefit, it's something I'm doing as a hobby) and they love it. They use it for listening to on-scene comms when they are out of range of our radio system. The only thing they dislike is the fact that it has a delay (inherent in the design of the feed and the Internet). In other words, they don't think there's a need for a delay, nor do they feel that there is any safety concern with having our dispatch-related audio and wide-area comms audio on the Internet. (Our simplex fireground channels are not streamed, more because it is impractical to do so due to the low power nature of them and the impossibility of getting a consistently strong signal for them due to our huge area.)
The other thing that talks not just to the discussion of the feed, but about the sensitivity about emergency comms (or lack thereof), is that my department is rather open about our responses. We have a Twitter feed which I manually update with calls we are responding on as it happens. Naturally we don't say "We're going to 5432 1st Street apartment 203 to deal with 87 year old Mr. McGillicutty who fell off the toilet", we say "We are responding to the downtown area for a medical assist". Media outlets follow this Twitter account and pay close attention to what is going on. With this, we have a great relationship with a lot of agencies and are getting decent publicity out of it. There's no reason to hide yourself away from the public. Things which are private can be discussed in private - either face-to-face or off the monitorable airwaves. (Anything we wouldn't say shouted from the top of our rescue truck through a megaphone is never broadcast over a radio - instead is communicated over a less-easily monitorable network such as cellular telephone.)
There's nothing inherently unsafe about having your comms broadcast on the Internet (and via smartphone scanner apps, and etc). If you are communicating things on those frequencies that have the potential to jeopardize the safety of your responders, you need to re-evaluate (a) whether those things need to be said in that "forum" and (2) whether or not you should have a more secure "forum" for saying those things. Safety is not compromised by the world knowing that your crews are responding to the intersection of Walk and Don't Walk for a car crash. Neither is privacy of the patients - they're in a public place. People could just as easily tuck in behind the engine as it goes by and follow them out of curiosity, rather than hear it on the scanner, and they'd still get to the scene.
If you (as a radio system operator) have police operations that specifically involve communications to circumvent the movements and/or operations of the bad guys, i.e. gang unit or drug team surveillance, or even tactical/SWAT team positioning on a barricaded subject, it is your responsibility to ensure that these communications are protected from "prying ears". This however does not include general patrol. There is nothing inherently sensitive about routine police work i.e. that you are sending a car to 5678 Xyz St. for a domestic dispute or to the Downtown 7-11 to investigate a shoplifting (or even an armed robbery). It should not be the responsibility of an audio streaming service to obfuscate any of these comms - through delays or other measures - to prevent "the bad guys" from using it to their advantage. A police or public safety department finding itself having such issues needs to evaluate, as I said earlier, what it says on the radio, and whether or not that part of its radio service needs to be secured (if that stuff really has to be broadcast anyway).
Tweekerbob
Member
- Joined
- May 27, 2004
- Messages
- 614
That particular poster moved quickly into a separate, and completely separate, solution of encryption.
The OP never mentioned encryption, but an integral and inherent audio delay. How does one derive encryption versus a several minute delay of non-encrypted communications as being equal? That being said, this poster never bothered with answering the OP's original question (without fully abdicating encryption) as posted above and therefore moved into a separate discussion, which has been discussed at length elsewhere.
It is abundantly clear the OP is looking out for PS safety and believes a delay may possibly be beneficial in the procurement of that safety (this is the "why"), and was simply inquiring for comments and suggestions. Given the parameters of the OP's questions, and the lack of mention of encryption by the OP; but then, a rather completely and separate solution, I can only conclude this thread was hi-jacked by a pro-encryption poster and thus is off-topic.
Last edited:
- Status
