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 (forcesofwargame.com) 2. Select facebook login button (facebook.com) Case 1: Application has whitelisted facebook.com 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 facebook.com 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: { "https://www.facebook.com/", "https://plus.google.com/" } ... (more manifest details)

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?

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.

Can the destkop webrt team get clarification from the security team on the implementation details of what needs to be done?

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.

The dependent bug is fixed now to meet the security review action item requirement. Marking as resolved fixed.