Closed
Bug 765231
Opened 13 years ago
Closed 13 years ago
Telephony: Implement dialEmergency() to limit call to emergency numbers
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: timdream, Assigned: hsinyi)
References
Details
Attachments
(1 file, 1 obsolete file)
16.26 KB,
patch
|
philikon
:
review+
|
Details | Diff | Splinter Review |
per discussion on dev-b2g, when the phone is connected to a voice network, the emergency keypad on lock screen would need to know whether or not the user is indeed dialing an emergency number or not.
ril_worker.js has already contain the method. We would just need to expose it. Thanks.
Comment 1•13 years ago
|
||
Is anyone already working on this? If not, I would like to take it and start working on it because I have been working on all the stuff related to emergency calls in B2G.
Comment 2•13 years ago
|
||
Go for it!
Note that if we want to make this a synchronous call, we will have to cache the emergency number list at least on the chrome process main thread.
Assignee: nobody → josea.olivera
Updated•13 years ago
|
Comment 3•13 years ago
|
||
I'm just back from vacation so I wasn't able to comment on dev-b2g before but I think this issue should have been raised in dev-webapi actually. The main issue being how to expose the information in the DOM API.
What are the situations where we want to do emergency calls? On top of my heads, I see two:
- no SIM card (or not activated/valid/anything);
- screen locked.
The RIL backend knows about the SIM card status so the call can just be made as usual and would fail. No need for the DOM API to provide any more information except maybe a clear DOMError message.
For the second situation, assuming we actually want to allow emergency calls when the screen is locked, I would prefer if we could know internally or trough an API if making calls is allowed. I guess the lock screen is part of the homescreen app?
If we can't know that information internally, I would prefer a callEmergency() number because it will reduce the leak of personal information via that API. Basically, isEmergencyCall() might allow an application to know in which country you are without requesting SIM or network information. I would prefer if we could prevent that.
(I will try to reply to the thread, better to have that discussion in the mailing-list.)
Reporter | ||
Comment 4•13 years ago
|
||
@mounir Thank you for your analytical insight. In the discussion on dev-b2g, main reason that favor isEnergencyNumber() over callEmergency() is because the former method allow content web applications to "gray out" the dial button before the user hitting it. The later method will prevent web authors from making such UI, since the app would always have to actually make the call to know if it's a real number.
Your concern on privacy is valid, however, it's not impossible to leak personal info with callEmergency(). The app would just have to call out and hang up quickly -- if the error return faster than the hang up, then it's an invalid number.
Security and privacy trumps UI design, but if neither proposal is equally risky then we pick the useful one.
Keep in mind any web app that gets mozTelephony API is likely a certified and trusted app -- if we trust the app to dial any phone number for us, why would we afraid of it knowing the emergency number?
Comment 5•13 years ago
|
||
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #1)
> Is anyone already working on this? If not, I would like to take it and start
> working on it because I have been working on all the stuff related to
> emergency calls in B2G.
José, can I help you to work on it? I have a lot of interest in this part.
Comment 6•13 years ago
|
||
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #4)
> @mounir Thank you for your analytical insight. In the discussion on dev-b2g,
> main reason that favor isEnergencyNumber() over callEmergency() is because
> the former method allow content web applications to "gray out" the dial
> button before the user hitting it. The later method will prevent web authors
> from making such UI, since the app would always have to actually make the
> call to know if it's a real number.
Not being able to do so doesn't seem that bad.
> Your concern on privacy is valid, however, it's not impossible to leak
> personal info with callEmergency(). The app would just have to call out and
> hang up quickly -- if the error return faster than the hang up, then it's an
> invalid number.
IMO, a call shouldn't be placed without user interaction so that would be really hard to do. In addition, it seems impossible for an application to do that without being caught which means the user will uninstall it.
> Keep in mind any web app that gets mozTelephony API is likely a certified
> and trusted app -- if we trust the app to dial any phone number for us, why
> would we afraid of it knowing the emergency number?
We shouldn't design an API assuming it will be used only in a specific context. What you should assume is that WebTelephony will be -likely- restricted, for B2G v1, for certified or trusted apps. However, that doesn't mean any app shoudn't be allowed to use the API someday. Designing an API assuming it will be used on a restricted part of the web isn't the Web.
Also, even if I install an application I trust, that doesn't mean I would trust the application not to try to fingerprint me, track me and get information about me for targeted ads. Any application with in-app advertisement or with an advertisement network will be willing to do so. By giving the right for an application to make and take phone calls I will assume the application will know who I call and who calls me. I'm not expecting it to know in which country I am.
Comment 7•13 years ago
|
||
(In reply to Mounir Lamouri (:mounir) from comment #3)
> For the second situation, assuming we actually want to allow emergency calls
> when the screen is locked, I would prefer if we could know internally or
> trough an API if making calls is allowed. I guess the lock screen is part of
> the homescreen app?
Are you saying you want the RIL to know whether the screen is locked or not? I feel like that's slightly the wrong question that the RIL wants to ask. How about we expose a flag, e.g. "onlyAllowEmergencyCalls", that the homescreen app can set to true whenever the screen is locked?
(In reply to Mounir Lamouri (:mounir) from comment #6)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #4)
> > @mounir Thank you for your analytical insight. In the discussion on dev-b2g,
> > main reason that favor isEnergencyNumber() over callEmergency() is because
> > the former method allow content web applications to "gray out" the dial
> > button before the user hitting it. The later method will prevent web authors
> > from making such UI, since the app would always have to actually make the
> > call to know if it's a real number.
>
> Not being able to do so doesn't seem that bad.
I agree.
I would be ok with introducing a dialEmergency() method (I would recommend not using the "call" word since so far the API uses the "dial".)
Comment 8•13 years ago
|
||
(In reply to Philipp von Weitershausen [:philikon] from comment #7)
> (In reply to Mounir Lamouri (:mounir) from comment #3)
> > For the second situation, assuming we actually want to allow emergency calls
> > when the screen is locked, I would prefer if we could know internally or
> > trough an API if making calls is allowed. I guess the lock screen is part of
> > the homescreen app?
>
> Are you saying you want the RIL to know whether the screen is locked or not?
> I feel like that's slightly the wrong question that the RIL wants to ask.
Never said that. RIL should know if "making calls is allowed".
> How about we expose a flag, e.g. "onlyAllowEmergencyCalls", that the
> homescreen app can set to true whenever the screen is locked?
That or something else. I don't know. I don't really like the idea of adding such a flag in WebTelephony. The homescreen should likely know that information. We could maybe use the hacky MozChromeEvent to pass that information to the chrome. We definitely need that Homescreen API...
> (In reply to Mounir Lamouri (:mounir) from comment #6)
> > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TW) from comment #4)
> > > @mounir Thank you for your analytical insight. In the discussion on dev-b2g,
> > > main reason that favor isEnergencyNumber() over callEmergency() is because
> > > the former method allow content web applications to "gray out" the dial
> > > button before the user hitting it. The later method will prevent web authors
> > > from making such UI, since the app would always have to actually make the
> > > call to know if it's a real number.
> >
> > Not being able to do so doesn't seem that bad.
>
> I agree.
>
> I would be ok with introducing a dialEmergency() method (I would recommend
> not using the "call" word since so far the API uses the "dial".)
Ok for dial instead of call but ideally I would prefer if we could prevent that to be a method and enforce the call to be made only to emergency numbers.
I don't have a strong opinion for specific method VS internal state. If anyhow has thoughts on this..?
Comment 9•13 years ago
|
||
(In reply to Mounir Lamouri (:mounir) from comment #8)
> (In reply to Philipp von Weitershausen [:philikon] from comment #7)
> > (In reply to Mounir Lamouri (:mounir) from comment #3)
> > > For the second situation, assuming we actually want to allow emergency calls
> > > when the screen is locked, I would prefer if we could know internally or
> > > trough an API if making calls is allowed. I guess the lock screen is part of
> > > the homescreen app?
> >
> > Are you saying you want the RIL to know whether the screen is locked or not?
> > I feel like that's slightly the wrong question that the RIL wants to ask.
>
> Never said that. RIL should know if "making calls is allowed".
Fair enough. How are you proposing the RIL will know this if it's not trough a flag (like the `onlyAllowEmergencyCalls` thing I proposed)?
> > I would be ok with introducing a dialEmergency() method (I would recommend
> > not using the "call" word since so far the API uses the "dial".)
>
> Ok for dial instead of call but ideally I would prefer if we could prevent
> that to be a method and enforce the call to be made only to emergency
> numbers.
Ok so you're saying you want to use the existing dial() method we have even for emergency calls, but somehow the RIL is informed that only emergency calls should be allowed, so it will reject any other numbers?
Comment 10•13 years ago
|
||
(In reply to Philipp von Weitershausen [:philikon] from comment #9)
> (In reply to Mounir Lamouri (:mounir) from comment #8)
> > (In reply to Philipp von Weitershausen [:philikon] from comment #7)
> > > (In reply to Mounir Lamouri (:mounir) from comment #3)
> > > > For the second situation, assuming we actually want to allow emergency calls
> > > > when the screen is locked, I would prefer if we could know internally or
> > > > trough an API if making calls is allowed. I guess the lock screen is part of
> > > > the homescreen app?
> > >
> > > Are you saying you want the RIL to know whether the screen is locked or not?
> > > I feel like that's slightly the wrong question that the RIL wants to ask.
> >
> > Never said that. RIL should know if "making calls is allowed".
>
> Fair enough. How are you proposing the RIL will know this if it's not trough
> a flag (like the `onlyAllowEmergencyCalls` thing I proposed)?
>
> > > I would be ok with introducing a dialEmergency() method (I would recommend
> > > not using the "call" word since so far the API uses the "dial".)
> >
> > Ok for dial instead of call but ideally I would prefer if we could prevent
> > that to be a method and enforce the call to be made only to emergency
> > numbers.
>
> Ok so you're saying you want to use the existing dial() method we have even
> for emergency calls, but somehow the RIL is informed that only emergency
> calls should be allowed, so it will reject any other numbers?
Yes. That or a dialEmergency() method.
Updated•13 years ago
|
Assignee: josea.olivera → nobody
Comment 11•13 years ago
|
||
This is a blocker and needs an owner. Hsinyi and Price, can one of you please take this? Thanks!
(In reply to Mounir Lamouri (:mounir) from comment #10)
> (In reply to Philipp von Weitershausen [:philikon] from comment #9)
> > (In reply to Mounir Lamouri (:mounir) from comment #8)
> > > (In reply to Philipp von Weitershausen [:philikon] from comment #7)
> > > > (In reply to Mounir Lamouri (:mounir) from comment #3)
> > > > > For the second situation, assuming we actually want to allow emergency calls
> > > > > when the screen is locked, I would prefer if we could know internally or
> > > > > trough an API if making calls is allowed. I guess the lock screen is part of
> > > > > the homescreen app?
> > > >
> > > > Are you saying you want the RIL to know whether the screen is locked or not?
> > > > I feel like that's slightly the wrong question that the RIL wants to ask.
> > >
> > > Never said that. RIL should know if "making calls is allowed".
> >
> > Fair enough. How are you proposing the RIL will know this if it's not trough
> > a flag (like the `onlyAllowEmergencyCalls` thing I proposed)?
Mounir, you never answered this question. Could you let us know how you would like that question solved? I think then this bug should be good to go for somebody to implement.
Comment 12•13 years ago
|
||
We can add a dialEmergency() method to the Telephony API that will fail asynchrously if the dialed number isn't an emergency number.
Comment 13•13 years ago
|
||
Hi guys,
Is there anyone attempting to taking this so far? If not, may I take this? :) I've already gone through the discussion thread and it makes sense to me. Please feel free to let me know if I'm suitable to take this or not.
Thanks,
Gene
Assignee | ||
Comment 14•13 years ago
|
||
(In reply to Gene Lian [:gene] from comment #13)
> Hi guys,
>
> Is there anyone attempting to taking this so far? If not, may I take this?
> :) I've already gone through the discussion thread and it makes sense to me.
> Please feel free to let me know if I'm suitable to take this or not.
>
> Thanks,
> Gene
Hi Gene,
I discussed with Price about Comment #11 this Monday. How about we waiting for Price's response?
Reporter | ||
Comment 15•13 years ago
|
||
(In reply to Mounir Lamouri (:mounir) from comment #12)
> We can add a dialEmergency() method to the Telephony API that will fail
> asynchrously if the dialed number isn't an emergency number.
I don't think the UX benefit from isEmergencyNumber() than dialEmergency() is really a must-have feature, but Josh is going to check with other UX on that. I think we can implement dialEmergency() if UX does not have strong opinion on that.
Summary: Telephony: Expose isEmergencyNumber() as a DOM API method → Telephony: Expose isEmergencyNumber() as a DOM API method, or implement dialEmergency()
Comment 16•13 years ago
|
||
Sicking and I agreed that dialEmergency() is a better API than isEmergencyNumber(). I think we should go with that.
Summary: Telephony: Expose isEmergencyNumber() as a DOM API method, or implement dialEmergency() → Telephony: Implement dialEmergency() to limit call to emergency numbers
Comment 17•13 years ago
|
||
Great!
This is a blocker without an owner. Price, can you take this? If not, let me know. Thanks!
Assignee: nobody → ptseng
Comment 18•13 years ago
|
||
Following up for UX: Tim put the question to me as follows:
"do we want to check the number dialed in and only enable the dial button if the user dialed a valid emergency number, or we don't check it at all and allow the backend to return error if it's not a emergency number?"
Can you help me to understand the UX flow for the later situation? eg: User enters number, hits "Call" button. If number entered is not a valid emergency number for the calling area, system sounds error audio alert and displays UI prompt (eg: "this is not an emergency number").
If that's the flow, I'm fine with it.
Comment 19•13 years ago
|
||
(In reply to Josh Carpenter from comment #18)
> "do we want to check the number dialed in and only enable the dial button if
> the user dialed a valid emergency number, or we don't check it at all and
> allow the backend to return error if it's not a emergency number?"
Checking ahead of time is tedious and it's questionable whether it's worth the effort.
> Can you help me to understand the UX flow for the later situation? eg: User
> enters number, hits "Call" button. If number entered is not a valid
> emergency number for the calling area, system sounds error audio alert and
> displays UI prompt (eg: "this is not an emergency number").
This flow we can implement.
Comment 20•13 years ago
|
||
Works for me :)
Updated•13 years ago
|
Assignee: ptseng → htsai
Assignee | ||
Comment 21•13 years ago
|
||
Implement dialEmergency() and return 'callError' if not a valid emergency number.
Attachment #643730 -
Flags: review?(philipp)
Comment 22•13 years ago
|
||
Comment on attachment 643730 [details] [diff] [review]
patch
Review of attachment 643730 [details] [diff] [review]:
-----------------------------------------------------------------
::: dom/telephony/Telephony.cpp
@@ +256,5 @@
> return NS_OK;
> }
>
> NS_IMETHODIMP
> +Telephony::DialEmergency(const nsAString& aNumber, nsIDOMTelephonyCall** aResult)
Instead of duplicating this code, I would suggest creating a
Telephony::DialInternal(bool isEmergency, const nsAString& aNumber, nsIDOMTelephonyCall** aResult)
helper and then calling that from `Telephony::Dial()` and `Telephony::DialEmergency()``.
Also, is there a way to test this stuff with the emulator? If so, it'd be nice to have a Marionette test.
r=me with that.
Attachment #643730 -
Flags: review?(philipp) → review+
Assignee | ||
Comment 23•13 years ago
|
||
(In reply to Philipp von Weitershausen [:philikon] from comment #22)
> Comment on attachment 643730 [details] [diff] [review]
> patch
>
> Review of attachment 643730 [details] [diff] [review]:
> -----------------------------------------------------------------
>
> ::: dom/telephony/Telephony.cpp
> @@ +256,5 @@
> > return NS_OK;
> > }
> >
> > NS_IMETHODIMP
> > +Telephony::DialEmergency(const nsAString& aNumber, nsIDOMTelephonyCall** aResult)
>
> Instead of duplicating this code, I would suggest creating a
>
> Telephony::DialInternal(bool isEmergency, const nsAString& aNumber,
> nsIDOMTelephonyCall** aResult)
>
> helper and then calling that from `Telephony::Dial()` and
> `Telephony::DialEmergency()``.
>
Good suggestion. I'll do that in an update. Thanks.
> Also, is there a way to test this stuff with the emulator? If so, it'd be
> nice to have a Marionette test.
>
> r=me with that.
I'll investigate it!
Assignee | ||
Comment 24•13 years ago
|
||
Patch: update mActiveCall and add test cases
Hi Philipp,
Test cases and DialInternal() are provided according to your suggestions. I also updated mActiveCall in 'NotifyError()' to make sure the telephony logic. Thanks.
Attachment #643730 -
Attachment is obsolete: true
Attachment #644829 -
Flags: review?(philipp)
Comment 25•13 years ago
|
||
Comment on attachment 644829 [details] [diff] [review]
Patch (v2)
Review of attachment 644829 [details] [diff] [review]:
-----------------------------------------------------------------
Excellent work! Tests <3 <3 <3
Attachment #644829 -
Flags: review?(philipp) → review+
Assignee | ||
Comment 27•13 years ago
|
||
Comment 28•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Reporter | ||
Comment 29•13 years ago
|
||
@hsinyi Thank you!
You need to log in
before you can comment on or make changes to this bug.
Description
•