[ + 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 <[email protected] <mailto:[email protected]>> 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
    <[email protected] <mailto:[email protected]>> 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



Reply via email to