Re: Adding Web Intents to the Webapps WG deliverables

[ + 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:

http://www.w3.org/2008/webapps/wiki/TPAC2011#Agenda_Monday.2C_October_31

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

-ArtB

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