W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Adding Web Intents to the Webapps WG deliverables

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 07 Oct 2011 06:37:26 -0400
Message-ID: <4E8ED666.3090603@nokia.com>
To: ifette@google.com
CC: Charles Pritchard <chuck@jumis.com>, Adrienne Porter Felt <apf@berkeley.edu>, "public-webapps@w3.org" <public-webapps@w3.org>, Robin Berjon <robin.berjon@gmail.com>, "Hirsch Frederick (Nokia-CIC/Boston)" <Frederick.Hirsch@nokia.com>, Dominique Hazael-Massieux <dom@w3.org>
[ + DAPI Chairs and Team Contact ]

Hi Ian, All - for now, I think it is OK to use public-webapps for 
*technical* discussions regarding James' proposal.

Let's plan to continue the charter-related part of this discussion 
during WebApp's TPAC meeting. I added it to the Monday October 31 
13:00-15:00 time slot:


(FYI, Robin added a "Merge DAP into WebApps, proposed by Robin Berjon" 
topic ins this same time slot.)


On 10/4/11 1:22 PM, ext Ian Fette (イアンフェッティ) wrote:
> Circling back to the original topic, it seems like there's a good 
> amount of interest and opinions, and that the spec would probably 
> benefit from the input of the people in this WG, especially since 
> multiple platforms are all shipping something similar in approach 
> (android intents, contracts in win8 and whatever implication that has 
> for Metro/IE, and the proposed web intents). This is good to see.
> -Ian
> On Thu, Sep 29, 2011 at 11:34 AM, Charles Pritchard <chuck@jumis.com 
> <mailto:chuck@jumis.com>> wrote:
>     Top posting: in web messaging, we typically set an origin property
>     on events and authors are expected to check that property.
>     Are your concerns addressed by that practice?
>     It is an added step, an added nuance. And developers may neglect
>     it. But, if they are neglecting origin, they are just plain
>     leaving security holes.
>     On Sep 28, 2011, at 12:09 PM, Adrienne Porter Felt
>     <apf@berkeley.edu <mailto: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
Received on Friday, 7 October 2011 10:38:22 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC