Hacker News Reader

Comment by LudwigNagasena | Hacker News Reader

Disincentivize similar behavior in the future.

Which is?

Unless there is malicious intent, I do not really see the added benefit of a lawsuit or complaint to the regulator.

To prevent this from happening again. To force their hand to ensure that their incentive structure changes to test and verify emergency calls _first_ regardless of how long it takes even if it slows revenue generation before releasing their products to production. To hold them accountable to society for brazenly ignoring one of our major rules while still selling products pulling in a ton of cash. Lots of reasons to raise an official complaint. So they don’t just get to walk away with an “oops my bad”, much like many of us wouldn’t be able to if we messed up big time.

It’s not like this is some random Joe shop that missed a small feature. This is Google and Microsoft, two of the biggest tech companies out there, making billions while not even caring to follow society’s rules (move fast and break things right? All in the name of scaled super fast profit)

So every app vendor now needs to make a 911 call as part of their CI process? I don't think 911 call centers are very happy about this.

Every app vendor who sells a phone product in the US? Uh, yes? It’s the law. 911 Call centers literally make testing available for this. And all you really need to test is that you’re making the outbound call properly without shit hitting the fan.

What’s the alternative? Just have 911 calls fail every once in a while since everybody is too busy with their feature work to look into it?

Ok, how do I test-dial 911 from Android Studio?

How do you test anything in Android Studio? Do it that way.

(googling says: https://developer.android.com/guide/topics/connectivity/tele... and hook up a test device )

If you can't test it on Android Studio, you can still, you know, use a phone. And try calling.

I feel like you’re being obtuse. They would need to verify that the call can be made and make it out the phone to the network, not actually make the call to a 911 operator. This can be part of an automated test suite even. Just ensure specific phone numbers cannot be intercepted by applications and diverted.

@nikanj since I can’t reply directly to you. I would say you don’t worry about that, what purpose does your app have intercepting it? It should be something that the OS picks up on, and handles. If you are writing a dialler, you should be confident when you hand it off to the OS that it won’t pass it along to another app. I’m not sure why the radio portion is relevant when the issue is that Teams intercepted the call and caused it to fail. It never made it off the phone.

> If you are writing a dialler, you should be confident when you hand it off to the OS that it won’t pass it along to another app.

I've no idea how exactly this bug happened and therefore whether the following has any relation to that issue or not, but if you want VOIP apps and similar things to work, you do need to allow the "I've got a phone number and I want to place a call" step to be intercepted, because otherwise how are you supposed to make a call via VOIP etc. when selecting a number from your contacts list, a phone link in a browser, etc. if that step was hardcoded to the regular phone app?

There's a difference between a phone call, and an emergency phone call. The documentation for the ACTION_CALL intent even says that emergency calls won't work for the intent.

Android already differentiates between normal calls and emergency calls. Normal will be intercepted, emergency shouldn't be. And an emergency call is required to still work even if a SIM card is not present in your device.

You're assuming Android devices have cellular modems. Tons of Android devices do not have cellular modems. Think tablets, desk phones, etc.

No, I'm not. Android's documentation says it handles emergency calls through a separate workflow. The law requires Android to handle emergency calls through a separate flow. Neither of those things is predicated upon a cell connection.

Emergency is required to work a certain way, by law, and is documented to work that way, but didn't happen in the case of this bug. The OS is responsible for emergency calls, the dialler, which may be third party, for normal calls.

How do I, an lone app vendor, verify that my call makes it out of the phone, or abort it without 911 noticing a dropped call? The radio+network part is a black box from my perspective

PS: At least where I live, emergency services will show up at your house if you make a few 0-second 911 calls

You can contact your 911 call center through a non emergency line (numbers available here when you enter your state/region: https://www.nasna911.org/contact-911). You can then call and set up a time window for outbound test calls to be placed where they won’t send emergency services.

I've worked on some custom Android firmwares before, and I did this for our releases. It's easy, the 911 call center doesn't mind (it's scheduled beforehand), and it ensures that the phone can dial 911. If you can't manage to test emergency calls, don't release phone software.

If you can't test this, don't make a call-hijacking phone app. Simple as that!

Yes, that's the clear and obvious answer. We have regulations around things like being able to make 911 calls for a reason, because it's literally a life and death issue. Nobody should be making or selling a call-hijacking app if they can't perform even the most basic level of testing to ensure 911 calls still work.

You call the PSAP's non-emergency number and ask to schedule a few test calls. If you don't know how to reach them, call your local police non-emergency number, they'll be able to put you in touch.

You're supposed to do this when setting up new VOIP service too, to make sure location information is reported correctly. It's quite a normal thing and they're not at all surprised by it.

I would go so far as to say there are 2 types of phone people: Those who've placed a lot of 911 test calls, and those who're placing their users at risk.

Can’t seem to reply any deeper on the thread, but also I never specifically mentioned CI. The only rule is that if you release a phone app, 911 has to work 100% of the time, no exceptions. That is the law. Also, this is Google and Microsoft, both of whom have basically unlimited resources. However they figure out how to do it reliably is up to them. Note that no other apps or service providers seem to be out of compliance.

Emergency calls working as expected is a live and death issue and I don't think you'd be so blasé about this if it had been you vainly trying to call 911 and someone you loved died because of this bug.

I assume you see this through the lens of "bugs happen, as long as developers make a sincere effort that's fine" under which most software development takes place. But this is absolutely the wrong way to look at this, and I bet you wouldn't apply this framework to physical engineering artifacts which are subject to legislation ensuring safety standards like bridges, cars or heaters.

It's a life critical system, so it shouldn't need to rise to malicious intent. Regulators don't handle malicious intent, they handle negligence. Police handle malicious intent. Look at Takata air bag recall. No malicious intent but regulator had to step in order a larger recall.

Negligence in testing also needs to be disincentivized.

If they've BUILT a system where apps can interfere with the ability to place calls, AND NOT written appropriate exceptions for 911 calls to bypass all such interference, AND NOT tested such exceptions, then there's a huge problem. That is absolutely the regulator's business.

I can't speak to the way modern phones are designed, but in earlier ones, 911 calls have all sorts of special status. They override pretty much all the phone's self-preservation mechanisms:

Transmitter deck too hot, normal calls can't be placed? 911 overrides that; the phone will melt itself if that's what it takes to get your call through.

Battery too low, normal call would be dropped so the phone can shut itself down without corrupting its flash filesystem? 911 overrides that, it will run until the circuitry physically ceases to function, in case that buys you a few more minutes of contact with the operator who might save your life.

Power control? Some phones would allow higher wattage when docked in a car-kit, but limit themselves to a lower power level when hand-held, to comply with tissue absorption regulations. Guess what limits go out the window when you call 911! Of course it's not gonna use the power unless it needs it, but if weak signal would cause a normal call to drop, 911 calls can tap into extra capability.

They will do ANYTHING to make that call go through.

And for software to fuck it up in the name of some obscure feature that clearly didn't get adequate testing, is unconscionable and spits in the face of literal decades of engineering effort.

Reply on news.ycombinator.com