7 years ago
7 years ago


(Reporter: pauljt, Assigned: pauljt)


Firefox Tracking Flags

(blocking-kilimanjaro:+, blocking-basecamp:+)


(Whiteboard: [secreview complete][2012/04/27][target 2012/05/24], )

Conduct a security review of Web Telephony API.

Background and review notes captured here:
Assignee: nobody → ptheriault
Assignee: ptheriault → nobody
Component: General → Security Assurance
Product: Boot2Gecko →
QA Contact: general → security-assurance
Target Milestone: DeveloperPhone → ---
Version: unspecified → other
Questions posted to the b2g team

> To start with, can I just ask a few questions:
> 1. Are you the correct contacts for this API (if not then who)?
Ben Turner, Jonas Sicking (CCed both), and I are probably the best contacts.

> 2. Is the API at a point where it is ready to be reviewed formally?
> (I know the app permissions model is pending, but any other major
> blockers?)
This is a good question. I don't think we have any significant changes planned at this point -- Ben, Jonas?

> 3. Do pages have direct access to the audio streams of a phone call?
> (from the code it seems not?)
No they don't.

> 4. What happens if the dialer loses focus? (nothing I assume, but
> will there be a status notification or something to show the user a call
> is active?)
This is an implementation choice of the UI using the API (Gaia in our case) and very much unrelated to the API itself. Personally I would hope that any UI won't kill the dialer when there's a phone call going on and would also show a notification.

> 5. Can another application record audio while a call is underway, and
> capture the call ( I assume yes?)
I don't know of a way to do that right now. If we had a WebAPI way to record audio data from the microphone, then *maybe* it would be possible to record one half of the phone call (depending on how the audio system is set up, it might not even be possible.) But we don't have an API for this (Yet. When we introduce live microphone access, we need to do a whole set of privacy/security analyses anyway.)

> 6. Are the audio streams buffered anywhere on disk
Not that I know of. We currently use the same audio subsystem that Android uses (audioflinger). There are plans to change that, I think, but I don't think it will ever involve on-disk buffering.

> 7. What data about each call is stored, and where (especially any
> user/private data)?
Gecko stores no such data at all. The UI using the API may do so, of course (and Gaia does).

> 8. Are there any links or documentation that I haven't got links to
> on the review page that I should have?
I can't think of anything at the moment, but I'll make sure to let you know when I do.

> Finally, I have started trying to put together some threats on the
> page linked above - if you could have a quick look through, and let me
> know if there are any other threats you have considered, any that occur to
> you that we need to track, or anything else of note.
Assignee: nobody → ptheriault
Whiteboard: [secr:ptheriault] → [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy]
Summary: Security Review for Web Telephony → [Security Review] Web Telephony
Duplicate of this bug: 749360
I have captured background information and an initial list of threats and mitigations here:

Probably next step is to have a formal meeting.
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [pending secreview][2012/04/27][target 2012/05/24]
Priority: -- → P1
Meeting proposed for 4th June 1pm PST

Contribute information here:
:pauljt - should I schedule this or wait for confirmation that this is the date you all want?
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
(In reply to Curtis Koenig [:curtisk] from comment #6)
> Review Scheduled:
> html?view=month&action=view&invId=130654-130653&pstat=AC&exInvId=130654-
> 181939&useInstance=1&instStartTime=1338840000000&instDuration=3600000

Did this review occur?
Yes, it is linked in the url tab on this bug

This does however have 3 bugs that were generated as follow-up actions that block this bug.
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [pending secreview][2012/04/27][target 2012/05/24] → [secreview complete][2012/04/27][target 2012/05/24]
I think Curtis's most recent mail is saying that our reviews shouldn't be "VERIFIED" until all the dependent bugs are fixed. Moving back to RESOLVED.
Closed: 7 years ago7 years ago
You need to log in before you can comment on or make changes to this bug.