On Apr 26, 2012, at 8:21 AM, Justin Lebar wrote: > (cc only dev-b2g, per Mounir's plea that we stop mass cross-posting.)
I realize Mounir doesn't like cross-posting because doesn't want to be on all those lists, but I'm not sure why he thinks in turn everyone else should subscribe to his list just to participate in the API discussions. If there's a single list these discussions should be happening on its dev-webapps not b2g. This is different from most typical Mozilla discussions as it requires the participation of a broad set of stakeholders, all of whom should not be expected to subscribe to dev-b2g to participate. I realize that sucks, but it sucks less than having a minority of people participating then having to restart the conversation when all of the other stakeholders are added. >> The following discussion is still accurate > > No, it has a number of basic problems, which I pointed out in an > earlier post. Perhaps you missed it? Huh? My link was to the discussion of the types of applications per Ben's previous question, not directly related to browser API. Sorry for the confusion. > Here's what I'd written: > > ====== > >> Potential mitigations: container should not be able to script into browser >> iframe > > In general, you cannot mitigate risk from an untrusted browser. > > An untrusted browser can arbitrarily phish you. You type in > "bank.com", the browser takes you to evil.com and displays "bank.com" > in its URL bar. It even displays a lock icon. You type in your > username and password. Evil.com records it. > > I think it is a mistake to talk about things like preventing the > container from injecting script into the iframe. That is only useful > for preventing a tiny class of attacks out of many, many possible > attacks. In this model the untrusted browser has access to the shared cookie and password stores, right? This allows an app to load arbitrary website content and script into it, becoming a mass XSS and password stealing vector. Not something I'd want every app to have access to, and the permission dialog would have to be carefully worded to communicate the risk. Quite likely this would be unavailable to unauthenticated apps, and authenticated apps would have a pretty scary warning. >> Use cases for authenticated code: Display remote content (e.g. from >> developer's site, or the contents of a tweet), or perform interactions with >> web-based services, including OAuth, OpenID, >> PayPal, Facebook Connect, etc. etc. > > <iframe mozbrowser> is explicitly not for this. We need to be able to > run the mozbrowser in a separate process, and that precludes any > interaction of this sort between the parent and the child. So is this really intended just for implementing browsers rather than interacting with content, and we can live with a fairly scary permission dialog (i.e. "has access to passwords and your private online data")? >> [Given that the browser is built in to b2g, what would a replacement browser >> actually be?] > > The browser is built in just like the calculator app. A user could > download another calculator app. They could also download another > browser app (modulo security constraints). Not as worried about calculator apps. :) Lucas. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
