Re: Proposal for incorporating explicit intent invocation into the object literal constructor

Submitted a new version of the spec with mercurial, incorporating
these changes, the object literal, and some other syntactic
adjustments suggested by Josh and Ian Hickson.

I've left the existing Intent constructor in for now, as it didn't
sound like we had enough discussion to remove it. Any other opinions?

-Greg


On Thu, Apr 5, 2012 at 3:52 PM, Charles Pritchard <chuck@jumis.com> wrote:
> On 4/5/2012 3:42 PM, Greg Billock wrote:
>>
>> On Thu, Apr 5, 2012 at 3:25 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>>>
>>> On 4/5/2012 3:10 PM, Greg Billock wrote:
>>>>
>>>> The User Agent MAY ask the user if they wish to install this service,
>>>> just like for any other visit of the page, but SHOULD NOT do so
>>>> automatically.
>>>>
>>>> --------------
>>>> Another question: I'd pondered putting "MUST NOT" instead of "SHOULD
>>>> NOT" in the last sentence about automatic installation. I'm worried
>>>> that this might be a super-cookie, so I think it is probably a bad
>>>> idea, but on the other hand, I don't want to restrict user agents too
>>>> much, as automatic installation may be a really good UI strategy.
>>>
>>> What's the concern about super-cookie exploits? Explicit invocation seems
>>>
>>> like it'd just rely on applicationCache for speed.
>>
>> It's not a powerful super-cookie, but if the user agent auto-installs
>> the service, and then the user clears history, this is a piece of
>> history that doesn't get cleared. That's not really easy to exploit,
>> but, for instance, a timing attack could potentially reveal such a
>> piece of history, given the practice of explicit intents not involving
>> the picker.
>>
>> I'm not sure a 1-bit super-cookie is worth worrying about, given the
>> availability of 1-bit fingerprints in the platform. Perhaps that's not
>> the only attack opportunity, though.
>
>
> A timing attack was all I could come up with, also.
>
> It's just a cache based timing attack though, isn't it?
> Same thing as running <iframe onload> with a timer and guessing that the
> page is in cache.
>
>
>>> It's possible that a UA will prompt a user when launching an Intent
>>> anyway:
>>> UAs like FF have prompted users to accept applicationCache and/or local
>>> storage.
>>
>> Correct. Nothing here prevents the UA from doing that, which would
>> make it a partial-bit super-cookie.
>
>
> I don't see any new vulnerability here when combined with existing web apps
> APIs: applicationCache, IndexedDB and requestFileSystem.
> But, that's why I'm asking. If I think of something, I'll voice it up.
>
> From the UA perspective, registered web intents are just another storage
> property, WebKit Inspector could list them right underneath
> Databases, Local Storage, Session Storage, Cookies and Application Cache in
> the "Resources" section.
>
> Registration and de-registration can be automatic or manual; it's entirely
> up to the UA. It's certainly the case that the UA should not ever block the
> UI for registration.
>
> The only thing that blocks the UI is the picker.
>
> -Charles

Received on Wednesday, 11 April 2012 01:24:14 UTC