- From: Paul Kinlan <paulkinlan@google.com>
- Date: Thu, 29 Sep 2011 09:55:56 +0100
- To: Adrienne Porter Felt <apf@berkeley.edu>
- Cc: public-webapps@w3.org
- Message-ID: <CADGdg3CoPEgp2RUWMMo+-j8apQuhjq=pcXb=BA-+rptcNwk2dw@mail.gmail.com>
Hi, Thanks for the synopsis of the issues. We didn't want to specifically exclude it from intra-app communication, but the result is like you mention actions can be invoked that they might not have thought would be possible or apps can replace - currently the system requires user intervention to select the service. For this intra-app comms when the developer knows the exact intent we are discussing explicit intents (the app developer knows the intent the developer should use). Developers will have to trust the data as from an untrusted source - unless we have some whitelist part of the API which the UA would restrict to a subset of domains that the service specifies..... (but we haven't discussed this) System generated broadcast intents are out of the scope of web intents at the moment, however system generated intents are not, the UA could trigger a "share" for instance if the vendor had put a native menu item in to the browser etc. It would be up to the UA to decide who could invoke specific intents, currently in the spec we are not defining any intents directly so we are not planning on telling the vendors to restrict access to certain ones - but it could defiantly be managed. P On Wed, Sep 28, 2011 at 8:09 PM, Adrienne Porter Felt <apf@berkeley.edu>wrote: > Android developers chronically misunderstand and misuse Android Intents, > and these mistakes lead to security bugs. To illustrate how prevalent the > confusion is, Erika Chin and I found that 9 of 20 popular Android > apps (45%!) contain security vulnerabilities due to misusing Intents. I've > also found these same types of bugs in Google-produced Android applications > (the default ones that ship as built-in apps). I posted examples & details > of two real-world applications that exhibit these vulnerabilities: > http://www.adrienneporterfelt.com/blog/?p=313. > > It's my hope that Web Intents can be designed to prevent developers from > making the same mistakes. > > There are two common types of errors: > > 1) Android Intents can be used for both inter- and intra-application > communication, and developers don't know the difference. A canonical > accident occurs when a developer creates a "unique" action string like > foo.bar.xyz and uses it for internal communication. The problem is that any > other application can register for the same action string, even if it's > supposedly hard to guess. This introduces two security bugs. (1) The > component that receives foo.bar.xyz has been unintentionally made public, > since anyone can send that action string to it. (2) Another application > could register to receive foo.bar.xyz and steal any data associated with it, > or simply gain the user's attention away from the original app. > > 2) The Android OS sends Intents to applications as notifications. > Developers register components to receive these system Intents. By > default, registering for a system Intent makes a component public. > Developers don't realize that these components become public by default, so > they don't check that the Intent was really sent by the OS. > > I have two suggestions to prevent these same errors from appearing in Web > Intents: > > 1) Developers need to be discouraged from using Web Intents for internal > application communication. One way to do this is to make it so that Web > Intents are only delivered after the user selects a service in a browser > popup window. (Nothing hidden in the background!) This would be annoying > for intra-application communication, so I think developers would avoid it. > > 2) If a developer registers to receive a Web Intent from the browser (like > for a system notification), that component should NOT be invocable by any > other application unless it's registered for a second Intent as well. > > Adrienne > > -- Paul Kinlan Developer Advocate @ Google for Chrome and HTML5 G+: http://plus.ly/paul.kinlan t: +447730517944 tw: @Paul_Kinlan LinkedIn: http://uk.linkedin.com/in/paulkinlan Blog: http://paul.kinlan.me Skype: paul.kinlan
Received on Thursday, 29 September 2011 08:56:27 UTC