Closed Bug 741955 Opened 12 years ago Closed 12 years ago

[Security Review][Action Item]WebRT - 3rd party navigation


( :: Security Assurance, task)

Not set



blocking-kilimanjaro +


(Reporter: curtisk, Assigned: dveditz)




(Whiteboard: [Desktop WebRT], [pending secreview])

if whitelisted 3rd party pages/domains are allowed those need to be clearly identified in chrome when they're opened
Curtis - Is an example use case such as what is stated below an example of what this bug means?

1. Install and launch Forces of War native application (
2. Select facebook login button (

Case 1: Application has whitelisted

3. The pop-up for facebook appears to prompt for login
4. ... (more steps after this, outside of the scope of this bug's interest)

Case 2: Application has not whitelisted

3. An error is reported to the user indicating that the application has blocked access to a third-party site not allowed by the author

Note - This sounds like this applies to more than just desktop - sounds like this applies to anything that uses the manifests (Desktop Firefox, Fennec Native, Boot to Gecko). We'll want to make sure each respective product knows of this requirement.

Myk - As for implementation, this sounds like something that would be specified in the manifest, right? Then, each integration point (e.g. desktop firefox) would need to utilize what's specified in the manifest. Something like this:

... (manifest details)
trusted_sites: {
... (more manifest details)
Whiteboard: [marketplace-beta?]
This isn't my call. This is security's call. I'm not the gate keeper for security compliance. 

Please remember that this release has a very small internal audience and there are not that many apps.
Curtis - Can we merge to FF 14 Aurora with this issue outstanding?
I believe you all can merge to aurora with this issue but we would prefer this is fixed before beta merge and absolutely before final release.

:yvan & :deveditz - could you please weigh in on comment 1?
Whiteboard: [marketplace-beta?]
Blocks: 731054
Blocks: 737571
No longer blocks: 731054
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [marketplace-beta-]
Curtis - For tracking purposes, could this bug be moved into Web Apps --> Desktop Runtime, since this is a bug in relation to this component? Or would you like to track the security issue specifically in the security assurance component?
I'm trying to track items that are outcomes of our security reviews in the assurance component so I know they came from us and so I can track that they get done. I think we can move this if you all want as the sec-review wiki for this has this but for tracking. I don't plan to be cc'd on all these bugs or I would get buried, so if you do move it please let me know when it is closed out so we can track that.
Assignee: myk → curtisk
blocking-kilimanjaro: --- → +
No longer blocks: 737571
Blocks: k9o-webrt
Whiteboard: [marketplace-beta-] → [Desktop WebRt]
Whiteboard: [Desktop WebRt] → [Desktop WebRT]
Assignee: curtisk → nobody
Whiteboard: [Desktop WebRT] → [Desktop WebRT][pending secreview]
Assignee: nobody → dveditz
Can the destkop webrt team get clarification from the security team on the implementation details of what needs to be done?
Whiteboard: [Desktop WebRT][pending secreview] → [Desktop WebRT], [pending secreview], [blocking-webrtdesktop1+]
Depends on: 771395
In the security review, dveditz said we could address this issue by showing the origin of the page in the window title when the origin is different from the origin for the webapp.  I filed bug 771395 to implement that strategy.
Removing the blocking flag, as the implementation bug has been filed to take care of this. Will triage against that bug - bug 771395.
Whiteboard: [Desktop WebRT], [pending secreview], [blocking-webrtdesktop1+] → [Desktop WebRT], [pending secreview]
The dependent bug is fixed now to meet the security review action item requirement. Marking as resolved fixed.
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.