Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/2/21 22:40, Sabri Berisha wrote: Aliens always invade New York, so I'm safe up here :) I thought that was Roswell :-). Mark.
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, Jan 3, 2021 at 5:03 PM Keith Medcalf wrote: > >I think the challenge here is that there's a category of people > >who don't have cell phones, who don't have cable TV, but > >receive content over their internet connection. I happen to > >live with someone like that, so I know it's a non-zero portion > >of the population. > > I pay for my Internet connection and I do not want "your shit" to be > spending "my money". If you think this is oh so important then *YOU* can > pay to install at your sole expense, a device which emits your silly > warnings -- I do not want them. You will also have to negotiate for > easement rights on my Private Property and those are not going to be given > away for cheap. > I take it you chant the same diatribe at your television when your video bandwidth is *stolen* by the emergency broadcast notification system, as it marches across the top of your screen? After all, you've paid for your television feed, and you don't want those "emergency broadcast messages" spending *your money*. Dammit, how dare they interrupt those precious seconds of the nightly news to tell you there's a flash flood warning for your county? There's already precedent set. I think that ship sailed long before you started attempting to drill holes through the hull. ;P Matt
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
- Original Message - > From: "Keith Medcalf" >>I think the challenge here is that there's a category of people >>who don't have cell phones, who don't have cable TV, but >>receive content over their internet connection. I happen to >>live with someone like that, so I know it's a non-zero portion >>of the population. > > I pay for my Internet connection and I do not want "your shit" to be spending > "my money". If you think this is oh so important then *YOU* can pay to > install > at your sole expense, a device which emits your silly warnings -- I do not > want > them. You will also have to negotiate for easement rights on my Private > Property and those are not going to be given away for cheap. > > And even if you do pay me %1 Million a month that it will cost to acquire the > necessary easement on my Private Property, I will put your annoying shit > inside > a soundproof faraday cage in the closet. > > So you might as well just not bother. > > This is the same thing I tell shithead politicians and pollsters that cause my > phone to ring. If you wish to speak with me then you can pay to install your > own communications equipment at your own expense. That does not mean that I > will be answer or pay any attention to it or refrain from taking action to > prevent it from disturbing me. For the shitheads that use robotic callers I > have a wonderful digital war-dialer that can tie up a whole central switch -- > one way or the other the assholes will be forced to cease their disgusting > behaviour! Die in the tornado; I got no time for people like you anymore. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 18:00:22 -0700, "Keith Medcalf" said: > This is the same thing I tell shithead politicians and pollsters that cause > my phone to ring. If you wish to speak with me then you can pay to install > your own communications equipment at your own expense. Um... Keith? Pretty much all of them *do* pay for their end of the communications equipment. The bigger question is why you pay for *your* end rather than insisting that everybody who wants to talk to you pay for your end. (Hint: Do you require that the annoying sister in law you don't want to hear from also install gear at their expense? Does the answer change if you usually want to hear from her but not today because reasons?) pgpArJK3hSV4B.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 5:00 PM, Keith Medcalf wrote: I think the challenge here is that there's a category of people who don't have cell phones, who don't have cable TV, but receive content over their internet connection. I happen to live with someone like that, so I know it's a non-zero portion of the population. I pay for my Internet connection and I do not want "your shit" to be spending "my money". If you think this is oh so important then *YOU* can pay to install at your sole expense, a device which emits your silly warnings -- I do not want them. You will also have to negotiate for easement rights on my Private Property and those are not going to be given away for cheap. You pay your money to your ISP and your money ceases to give a shit what you want. Don't like it? Give it to somebody else who does. Mike
RE: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
>I think the challenge here is that there's a category of people >who don't have cell phones, who don't have cable TV, but >receive content over their internet connection. I happen to >live with someone like that, so I know it's a non-zero portion >of the population. I pay for my Internet connection and I do not want "your shit" to be spending "my money". If you think this is oh so important then *YOU* can pay to install at your sole expense, a device which emits your silly warnings -- I do not want them. You will also have to negotiate for easement rights on my Private Property and those are not going to be given away for cheap. And even if you do pay me %1 Million a month that it will cost to acquire the necessary easement on my Private Property, I will put your annoying shit inside a soundproof faraday cage in the closet. So you might as well just not bother. This is the same thing I tell shithead politicians and pollsters that cause my phone to ring. If you wish to speak with me then you can pay to install your own communications equipment at your own expense. That does not mean that I will be answer or pay any attention to it or refrain from taking action to prevent it from disturbing me. For the shitheads that use robotic callers I have a wonderful digital war-dialer that can tie up a whole central switch -- one way or the other the assholes will be forced to cease their disgusting behaviour! -- Be decisive. Make a decision, right or wrong. The road of life is paved with flat squirrels who could not make a decision.
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 2:27 PM, Ask Bjørn Hansen wrote: On Jan 3, 2021, at 13:57, Michael Thomas wrote: I just sent some mail to the myshakes folks at UCB asking if they have an achitecture/network document. In their case for earthquakes it need to be less than ~10 seconds so they are really pushing the limit. If they get back to me, I'll share it here. The two platforms they support have APIs and infrastructure to make it work at large scale. Do you know where to find docs on it? I'd be curious because clearly this is a hard problem. Piggybacking this sort of thing on another connection is trading some connection overhead for a whole lot of application complexity. This being nanog it’s unsurprising that the discussion is focusing on the connection and protocol bits, but those are a tiny part of the overall complexity (for the client, too). Well, the network is an interesting part in its own right because of the latency is so critical. I did notice that at least part of their sensor network is your phone itself. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 2:23 PM, Jay R. Ashworth wrote: - Original Message - From: "Michael Thomas" Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem. As for D'oH, sure; let's centralize the attack surface. The only reason I bring up DoH is because now there are tcp connection when the day before there were none. I haven't noticed any difference since firefox turned it, so they obviously figured out the scaling. Firefox is using one TCP connection to pipeline all the D'oH queries down? I assume so. DoH is just http running http2 or http3. Clearly getting servers to support millions of http sessions is doable these days. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Jan 3, 2021, at 13:57, Michael Thomas wrote: > I just sent some mail to the myshakes folks at UCB asking if they have an > achitecture/network document. In their case for earthquakes it need to be > less than ~10 seconds so they are really pushing the limit. If they get back > to me, I'll share it here. The two platforms they support have APIs and infrastructure to make it work at large scale. Piggybacking this sort of thing on another connection is trading some connection overhead for a whole lot of application complexity. This being nanog it’s unsurprising that the discussion is focusing on the connection and protocol bits, but those are a tiny part of the overall complexity (for the client, too). Ask
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
- Original Message - > From: "Michael Thomas" >> Well, TCP means that the servers have to expect to have 100k's of open >> connections; I remember that used to be a problem. >> >> As for D'oH, sure; let's centralize the attack surface. > The only reason I bring up DoH is because now there are tcp connection > when the day before there were none. I haven't noticed any difference > since firefox turned it, so they obviously figured out the scaling. Firefox is using one TCP connection to pipeline all the D'oH queries down? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
At this point I would assume that nearly every device is persisting at least one long lived TCP connection. Whether it's for telemetry or command and control, everything these days seems to have this capability. As an example, I can hit a button in the Nintendo Switch parent app on my phone and my kid's Switch is reflecting changes a second later. That's not even a platform I would have expected to have that capability. If they have an existing connection then there lots of high connection count solutions in the IOT space that could easily handle this number of connections. A single 12c 32G box running emqttd could handle 1.3M connections. Just picking a random AWS EC2 size machine, m5.4xlarge, would run you about $0.003/year per device to keep that connection open and passing data. I assume you could drive that down significantly from there. On 01/03/2021 03:35 PM, Brandon Martin wrote: On 1/3/21 4:22 PM, Mark Delany wrote: Creating quiescent sockets has certainly been discussed in the context of RSS where you might want to server-notify a large number of long-held client connections very infrequently. While a kernel could quiesce a TCP socket down to maybe 100 bytes or so (endpoint tuples, sequence numbers, window sizes and a few other odds and sods), a big residual cost is application state - in particular TLS state. Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server. Having said all that, as far as I understand it, none of the DNS-over-TCP systems imply centralization, that's just how a few applications have chosen to deploy. We deploy DOH to a private self-managed server pool which consume a measly 10-20 concurrent TCP sessions. I was thinking more in the original context of this thread w.r.t. potential distribution of emergency alerts. That could, if semi-centralized, easily result in 100s of million connections to juggle across a single service just for the USA. While it presumably wouldn't be quite that centralized, it's a sizable problem to manage. Obviously you could distribute it out ala the CDN model that the content providers use, but then you're potentially devoting a sizable chunk of hardware resources at something that really doesn't otherwise require it. The nice thing is that such emergency alerts don't require confidentiality and can relatively easily bear in-band, application-level authentication (in fact, that seems preferable to only using session-level authentication). That means you could easily carry them over plain HTTP or similar which removes the TLS overhead you mention. Several GB of RAM is nothing for a modern server, of course. It sounds like you'd probably run into other scaling issues before you hit memory limitations needed to juggle legitimate TCP connection state.
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 1:50 PM, Mark Delany wrote: On 03Jan21, Brandon Martin allegedly wrote: I was thinking more in the original context of this thread w.r.t. potential distribution of emergency alerts. That could, if semi-centralized, easily result in 100s of million connections to juggle across a single service just for the USA. While it presumably wouldn't be quite that centralized, it's a sizable problem to manage. Indeed. But how do you know the clients are still connected? And if they aren't, there is not much a server can do beyond discarding the state. Presumably the client would need to run a fairly frequent keep-a-live/reconnect strategy to ensure the connection is still functioning. Which raises the question: how long a delay do you tolerate for an emergency alert? I think the end result is a lot of active connections and keep-a-live traffic. Not really quiescent at all. In the end, probably just as cheap to poll a CDN. I just sent some mail to the myshakes folks at UCB asking if they have an achitecture/network document. In their case for earthquakes it need to be less than ~10 seconds so they are really pushing the limit. If they get back to me, I'll share it here. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 1:22 PM, Mark Delany wrote: Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server. Even at 1000 bytes, we're talking about 40GB for the entirety of California. You can get off the shelf cloud VM's with that easily these days, and 10 of those covers the US (ok, redundancy, but still...). That's probably why DoH wasn't a big deal. Throwing memory at a problem these days is probably easier than any heroic measures. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 03Jan21, Brandon Martin allegedly wrote: > I was thinking more in the original context of this thread w.r.t. > potential distribution of emergency alerts. That could, if > semi-centralized, easily result in 100s of million connections to juggle > across a single service just for the USA. While it presumably wouldn't > be quite that centralized, it's a sizable problem to manage. Indeed. But how do you know the clients are still connected? And if they aren't, there is not much a server can do beyond discarding the state. Presumably the client would need to run a fairly frequent keep-a-live/reconnect strategy to ensure the connection is still functioning. Which raises the question: how long a delay do you tolerate for an emergency alert? I think the end result is a lot of active connections and keep-a-live traffic. Not really quiescent at all. In the end, probably just as cheap to poll a CDN. Mark.
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
- Original Message - > From: "Brandon Martin" > The nice thing is that such emergency alerts don't require > confidentiality and can relatively easily bear in-band, > application-level authentication (in fact, that seems preferable to only > using session-level authentication). That means you could easily carry > them over plain HTTP or similar which removes the TLS overhead you mention. Sure. Just signing the alert packet so it can be authenticated is plenty. > Several GB of RAM is nothing for a modern server, of course. It sounds > like you'd probably run into other scaling issues before you hit memory > limitations needed to juggle legitimate TCP connection state. Well, yeah, but I don't know that it's *just* RAM; I suspect it might be data structure as well... Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 4:22 PM, Mark Delany wrote: Creating quiescent sockets has certainly been discussed in the context of RSS where you might want to server-notify a large number of long-held client connections very infrequently. While a kernel could quiesce a TCP socket down to maybe 100 bytes or so (endpoint tuples, sequence numbers, window sizes and a few other odds and sods), a big residual cost is application state - in particular TLS state. Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server. Having said all that, as far as I understand it, none of the DNS-over-TCP systems imply centralization, that's just how a few applications have chosen to deploy. We deploy DOH to a private self-managed server pool which consume a measly 10-20 concurrent TCP sessions. I was thinking more in the original context of this thread w.r.t. potential distribution of emergency alerts. That could, if semi-centralized, easily result in 100s of million connections to juggle across a single service just for the USA. While it presumably wouldn't be quite that centralized, it's a sizable problem to manage. Obviously you could distribute it out ala the CDN model that the content providers use, but then you're potentially devoting a sizable chunk of hardware resources at something that really doesn't otherwise require it. The nice thing is that such emergency alerts don't require confidentiality and can relatively easily bear in-band, application-level authentication (in fact, that seems preferable to only using session-level authentication). That means you could easily carry them over plain HTTP or similar which removes the TLS overhead you mention. Several GB of RAM is nothing for a modern server, of course. It sounds like you'd probably run into other scaling issues before you hit memory limitations needed to juggle legitimate TCP connection state. -- Brandon Martin
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 03Jan21, Brandon Martin allegedly wrote: > On 1/3/21 3:11 PM, Jay R. Ashworth wrote: > > Well, TCP means that the servers have to expect to have 100k's of open > > connections; I remember that used to be a problem. > > Out of curiosity, has anyone investigated if it's possible to hold open > a low-traffic, long-lived TCP session without actually storing state > using techniques similar to syncookies and do so in a compatible manner? Creating quiescent sockets has certainly been discussed in the context of RSS where you might want to server-notify a large number of long-held client connections very infrequently. While a kernel could quiesce a TCP socket down to maybe 100 bytes or so (endpoint tuples, sequence numbers, window sizes and a few other odds and sods), a big residual cost is application state - in particular TLS state. Even with a participating application, quiescing in-memory state to something less than, say, 1KB is probably hard but might be doable with a participating TLS library. If so, a million quiescent connections could conceivably be stashed in a coupla GB of memory. And of course if you're prepared to wear a disk read to recover quiescent state, your in-memory cost could be less than 100 bytes allowing many millions of quiescent connections per server. Having said all that, as far as I understand it, none of the DNS-over-TCP systems imply centralization, that's just how a few applications have chosen to deploy. We deploy DOH to a private self-managed server pool which consume a measly 10-20 concurrent TCP sessions. Mark.
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 3:11 PM, Jay R. Ashworth wrote: Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem. Out of curiosity, has anyone investigated if it's possible to hold open a low-traffic, long-lived TCP session without actually storing state using techniques similar to syncookies and do so in a compatible manner? I suspect no since you don't have control over your peers sequence numbers, but then someone smarter than I came up with syncookies... -- Brandon Martin
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 12:11 PM, Jay R. Ashworth wrote: - Original Message - From: "Michael Thomas" To: nanog@nanog.org On 1/2/21 10:31 PM, Jay R. Ashworth wrote: Yup; it's messy, and in many many different ways. Won't be a snapshot rollout. Not a bad idea, though, if implemented correctly; time to dig out my notes, I guess. Is there a reason not to use an outbound tcp/quic connection? It was unthinkable years ago to use TCP with DNS, but now we have DoH and the world hasn't spiraled out of control. Heck if you made it a websocket you'd have a built in channel for multi-media html, etc. That is, just push a URL down and fire up a webview that the OS makes certain is in focus. Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem. As for D'oH, sure; let's centralize the attack surface. The only reason I bring up DoH is because now there are tcp connection when the day before there were none. I haven't noticed any difference since firefox turned it, so they obviously figured out the scaling. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
- Original Message - > From: "Michael Thomas" > To: nanog@nanog.org > On 1/2/21 10:31 PM, Jay R. Ashworth wrote: >> Yup; it's messy, and in many many different ways. Won't be a snapshot >> rollout. Not a bad idea, though, if implemented correctly; time to dig >> out my notes, I guess. > > Is there a reason not to use an outbound tcp/quic connection? It was > unthinkable years ago to use TCP with DNS, but now we have DoH and the > world hasn't spiraled out of control. Heck if you made it a websocket > you'd have a built in channel for multi-media html, etc. That is, just > push a URL down and fire up a webview that the OS makes certain is in focus. Well, TCP means that the servers have to expect to have 100k's of open connections; I remember that used to be a problem. As for D'oH, sure; let's centralize the attack surface. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, Jan 3, 2021 at 12:02 PM Rich Kulawiec wrote: [snip] > streaming company need to be able to authenticate the alerts from > all those different agencies. Those agencies also need to secure [...] The agencies would already submit their alerts through IPAWS gateways managed by FEMA; otherwise every national satellite & cable provider have a similar challenge. The feds authenticate agencies and authorize those to use that service - the streaming companies only need a way to verify the message originated through that central authority. > And then there's another problem, which is that once all those different > agencies have this facility, they're going to (ab)use it as they see fit. [snip] I suppose abuse of authority or excessive use for any alerting system is bound to be a risk, no matter what. Not really a technical or network issue at all though.. (People could petition local elected officials and/or persuade others within their district, their neighbors, etc, to vote in new officials in that case, etc.) -- -JH
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
Once upon a time, Rich Kulawiec said: > And then there's another problem, which is that once all those different > agencies have this facility, they're going to (ab)use it as they see fit. A year or two ago, Alabama issued a state-wide "blue alert" when a police officer was shot. So my weather/all-hazards radio alarm went off at 3am for something that happened 200 miles away. I then disabled that alert category. I only have severe weather warning categories enabled now (because tornadoes are a thing I do want to know about). -- Chris Adams
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 10:01 AM, Rich Kulawiec wrote: On Sun, Jan 03, 2021 at 03:26:07AM -0500, Valdis Kl??tnieks wrote: Meanwhile, this causes yet another problem - if Hulu has to be able to know what alerts should be piped down to my device, this now means that every single police and public safety agency has to be able to send the alerts to Hulu (and every other streaming company) - and do this securely. And then there's another problem (that I'm going to bet you've already thought of, given what you've written here): Hulu and every other streaming company need to be able to authenticate the alerts from all those different agencies. Those agencies also need to secure their sending infrastructure...and good luck with that. And then there's another problem, which is that once all those different agencies have this facility, they're going to (ab)use it as they see fit. I've noticed that over the last decade or so that weather alerts I've received are covering increasingly-less-severe events, e.g., we've slowly gone from "there's a tornado on the ground" to "there's going to be a thunderstorm". And at this particular point in history, I can think of one person who would be using this every five minutes simply because it's there. ---rsk One of the things that makes this challenging is that not all alerts are created equal. I just checked and the California earthquake alert system is now live. For that you have maybe 10 seconds so it needs to be hella fast at relaying the information. Other alerts are less strict, but still have a real time components like the tornado alerts. And then there are things that effectively have no real time component like Amber alerts. I'm curious how they built this: https://earthquake.ca.gov/ Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, Jan 03, 2021 at 03:26:07AM -0500, Valdis Kl??tnieks wrote: > Meanwhile, this causes yet another problem - if Hulu has to be able to > know what alerts should be piped down to my device, this now means that > every single police and public safety agency has to be able to send the > alerts to Hulu (and every other streaming company) - and do this securely. And then there's another problem (that I'm going to bet you've already thought of, given what you've written here): Hulu and every other streaming company need to be able to authenticate the alerts from all those different agencies. Those agencies also need to secure their sending infrastructure...and good luck with that. And then there's another problem, which is that once all those different agencies have this facility, they're going to (ab)use it as they see fit. I've noticed that over the last decade or so that weather alerts I've received are covering increasingly-less-severe events, e.g., we've slowly gone from "there's a tornado on the ground" to "there's going to be a thunderstorm". And at this particular point in history, I can think of one person who would be using this every five minutes simply because it's there. ---rsk
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/2/21 10:31 PM, Jay R. Ashworth wrote: including foreign locations, generations of emergency alert packets *MUST* be responsibility of *LOCAL* ISPs. A problem is that home routers may filter the broadcast packets from ISPs, but the routers may be upgraded or some device to snoop the alert packets may be placed between ISPs and the routers. Yup; it's messy, and in many many different ways. Won't be a snapshot rollout. Not a bad idea, though, if implemented correctly; time to dig out my notes, I guess. Is there a reason not to use an outbound tcp/quic connection? It was unthinkable years ago to use TCP with DNS, but now we have DoH and the world hasn't spiraled out of control. Heck if you made it a websocket you'd have a built in channel for multi-media html, etc. That is, just push a URL down and fire up a webview that the OS makes certain is in focus. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 09:26:07 +, Mark Foster said:' > Yeah my family got a PS4 for Christmas. But we've had an Xbox One for > the last few years. There are quite a few streaming apps, true. But a > lot fewer of those than worldwide telcos, or jurisdictions, or emergency > services. You missed the point - Hulu would *still* have to deal with every single jurisdiction or emergency service in a secure manner. But any given ISP doing business in a given county would only have to deal with a very small number - and the local sheriff's office would only have to notify the small number of providers actually providing access in the county. > So do you want the streaming service to deliver the alert, or do you > want the underlying device doing the streaming, to deliver the alert? > Because I think you've gone down a layer and didn't need to. How do you deliver the alert if the device is on but no streaming service is currently active? And for a lot of devices, that's the usual state of affairs. As far as I know, most people who have a Google or Alexa smart device have it on close to 24/7, but the devices aren't streaming media that much. That's why I think doing it at the streaming service level is one level too high. pgpdmSdJuOZe6.pgp Description: PGP signature
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/2/21 10:15 PM, b...@theworld.com wrote: Let's just go back to air-raid sirens. I'm old enough to remember when they were tested every day at noon, which also told you it was noon (lunch!) We'd say heaven help us if The Enemy attacked at noon. They still do in San Francisco garbled message and all as it echos through the streets. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 1/3/21 12:26 AM, Valdis Klētnieks wrote: On Sun, 03 Jan 2021 18:59:37 +1300, Mark Foster said: In my mind it's simple.� The streaming companies need to have a channel within their streaming system to get a message to a 'currently active customer' (emergency popup notification that appears when their app is open or their website is active with an authenticated user).� The Oh geez. Just on my PS4, there's streaming apps for Disney+, Netflix, Hulu, Prime, Playstation Store, Peacock, Tubi, ESPN+, AppleTV, YouTube (less than half of which I actually subscribe to, but I haven't found a big enough crowbar to remove the others, they keep returning) - and that's probably not a complete list. It also begs the question of what constitutes a "streaming service". Is my marketing department's slick new ad campaign video a "streaming service"? I could easily get engrossed in its valuable messaging and miss that tornado alert. Inline messaging is a complete dead end on the internet. Inline was because there was no other reasonable way to message on broadcast tv. That is definitely not the case now. Mike
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On 2021-01-03 08:26, Valdis Klētnieks wrote: On Sun, 03 Jan 2021 18:59:37 +1300, Mark Foster said: In my mind it's simple.� The streaming companies need to have a channel within their streaming system to get a message to a 'currently active customer' (emergency popup notification that appears when their app is open or their website is active with an authenticated user).� The Oh geez. Just on my PS4, there's streaming apps for Disney+, Netflix, Hulu, Prime, Playstation Store, Peacock, Tubi, ESPN+, AppleTV, YouTube (less than half of which I actually subscribe to, but I haven't found a big enough crowbar to remove the others, they keep returning) - and that's probably not a complete list. And we get to watch them all do it in subtly different ways, often buggy. Egads. Yeah my family got a PS4 for Christmas. But we've had an Xbox One for the last few years. There are quite a few streaming apps, true. But a lot fewer of those than worldwide telcos, or jurisdictions, or emergency services. Bonus points for figuring out how to keep two streaming apps from stepping on each other's toes, as often these apps stay semi-alive in the background, which may be enough to cause an alert to be sent to the app. Now you need to avoid a "thundering herd" problem if there's 18 different streaming apps on the device, all of which just got woken up. On resource constrained systems, that's often the start of a death spiral as the system either runs totally out of memory or goes into thrashing mode. And the alternative is just saying "only the streaming app in the foreground gets to handle the alert", but that isn't correct either - I might not *have* a streaming app running in the foreground on the device at the time the alert goes out. (You hit another problem as well - now all the apps have to notify upstream So do you want the streaming service to deliver the alert, or do you want the underlying device doing the streaming, to deliver the alert? Because I think you've gone down a layer and didn't need to. Foregrounded App, delivering alert, feels doable. So having every single "streaming" app have to include duplicate code and *still* not get the alert to the user doesn't seem the right direction to go... If one wanted to target the console world or smart TV world, that's another way of doing it - but then you need Microsoft, Sony, Samsung, LG etc to all be doing essentially the same thing. Not impossible, but not precisely within the scope of 'online streaming services'. streaming company will also know the location of their customer (billing information) so will know what geographic locations are relevant to that customer. Billing info may be good enough for stuff that stays at home. It doesn't tell you what zip code a portable device is actually in at the moment - and getting the *right* localized info to the portable device is one of the tricky parts of this. If you're out and about town while visiting your in-laws 3 time zones away from where you live, you want alerts for the town your in-laws live, not for the address the streaming company sends the bill to. The problem that was trying to be solved, was people who literally don't have a mobile device. What category of device are you trying to alert to that wouldn't otherwise be able to receive an emergency broadcast? Seems like we're getting more-and-more niche. And that's assuming that a streaming company even *has* the info in their billing information - I just checked, and Hulu doesn't have a street address for me. So they're going to end up having to do IP based geolocation. ... or simply collect the geographic information required, retrospectively, in order to comply. Meanwhile, this causes yet another problem - if Hulu has to be able to know what alerts should be piped down to my device, this now means that every single police and public safety agency has to be able to send the alerts to Hulu (and every other streaming company) - and do this securely. That's a *lot* bigger problem than "The Blacksburg VA police department only has to set up agreements with network access providers that might be providing access to devices in Blacksburg". Sure. But the likes of Netflix will need a relationship with every single PD in the world? Scales nicely in one direction, but not the other. Seriously guys - having the streaming companies do this is at the entirely wrong level. I dunno. Providing an API and establishing a relationship with what has to be a relatively finite number of streaming providers seems not impossible. If Netflix put up an API and you built a hierarchy for emergency notifications (so perhaps your local PD don't directly talk to Netflix, but maybe they talk to someone at state level? Then there's a managable chain of relationships). If you're going to create a legislative or regulatory framework that requires the streaming operators to provide
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
Mark Foster wrote: On 3/01/2021 2:41 am, Masataka Ohta wrote: Sean Donelan wrote: the Commission shall complete an inquiry to examine the feasibility of updating the Emergency Alert System to enable or improve alerts to consumers provided through the internet, including through streaming services. It is trivially easy to have a dedicated UDP port to receive broadcast packets for such purposes, as "through streaming services" is not the requirement. but "including" is... It's not feasible. The alert should be given by not services but devices running various services including streaming ones. And I don't see that opening up a UDP port on every end-user device to receive some sort of broadcast (unicast?) is going to be great security. Someone will find away to exploit it. It should be the responsibility of local ISPs to generate such packets and not to relay such packets generated by others. I think you're overthinking this. In my mind it's simple. The streaming companies need to have a channel within their streaming system You have successfully made the simple problem complex enough to be unsolvable. > Local Authorities can feed emergency broadcast information to the > streaming companies tagged with a geolocation Local authorities? You can't expect such locality for companies offering streaming or similar services over the Internet. Moreover, there is no reason to give precise definition of "streaming services" and not to give alert to users of similar services. Masataka Ohta
Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study
On Sun, 03 Jan 2021 18:59:37 +1300, Mark Foster said: > In my mind it's simple.� The streaming companies need to have a channel > within their streaming system to get a message to a 'currently active > customer' (emergency popup notification that appears when their app is > open or their website is active with an authenticated user).� The Oh geez. Just on my PS4, there's streaming apps for Disney+, Netflix, Hulu, Prime, Playstation Store, Peacock, Tubi, ESPN+, AppleTV, YouTube (less than half of which I actually subscribe to, but I haven't found a big enough crowbar to remove the others, they keep returning) - and that's probably not a complete list. And we get to watch them all do it in subtly different ways, often buggy. Egads. Bonus points for figuring out how to keep two streaming apps from stepping on each other's toes, as often these apps stay semi-alive in the background, which may be enough to cause an alert to be sent to the app. Now you need to avoid a "thundering herd" problem if there's 18 different streaming apps on the device, all of which just got woken up. On resource constrained systems, that's often the start of a death spiral as the system either runs totally out of memory or goes into thrashing mode. And the alternative is just saying "only the streaming app in the foreground gets to handle the alert", but that isn't correct either - I might not *have* a streaming app running in the foreground on the device at the time the alert goes out. (You hit another problem as well - now all the apps have to notify upstream So having every single "streaming" app have to include duplicate code and *still* not get the alert to the user doesn't seem the right direction to go... > streaming company will also know the location of their customer (billing > information) so will know what geographic locations are relevant to that > customer. Billing info may be good enough for stuff that stays at home. It doesn't tell you what zip code a portable device is actually in at the moment - and getting the *right* localized info to the portable device is one of the tricky parts of this. If you're out and about town while visiting your in-laws 3 time zones away from where you live, you want alerts for the town your in-laws live, not for the address the streaming company sends the bill to. And that's assuming that a streaming company even *has* the info in their billing information - I just checked, and Hulu doesn't have a street address for me. So they're going to end up having to do IP based geolocation. Meanwhile, this causes yet another problem - if Hulu has to be able to know what alerts should be piped down to my device, this now means that every single police and public safety agency has to be able to send the alerts to Hulu (and every other streaming company) - and do this securely. That's a *lot* bigger problem than "The Blacksburg VA police department only has to set up agreements with network access providers that might be providing access to devices in Blacksburg". Seriously guys - having the streaming companies do this is at the entirely wrong level. pgppzHA8EUtxt.pgp Description: PGP signature
