RE: Web Intent review

Thanks Greg,
I will try to have a look at the latest spec.
Regards,
	Youenn

> -----Original Message-----
> From: Greg Billock [mailto:gbillock@google.com]
> Sent: mardi 11 septembre 2012 22:27
> To: FABLET Youenn
> Cc: public-web-intents@w3.org
> Subject: Re: Web Intent review
> 
> Thanks a lot for this review, and sorry for the belated reply. I'm including
> relevant fixes into the spec now.
> 
> On Sun, Jul 29, 2012 at 11:51 PM, FABLET Youenn
> <Youenn.Fablet@crf.canon.fr> wrote:
> > Dear DAP WG,
> >
> >
> >
> > It is good to see the Web Intent task force making progress with the
> > publication of its first Web Intent Working Draft.
> >
> > Please find below some comments and open questions.
> >
> >
> >
> > Regards,
> >
> >                 Youenn
> >
> >
> >
> > 1 Section 3
> >
> > The pick media spec uses '?' to specify whether a particular WebIDL
> > field is optional or not.
> > This is easy to read and could be reused in the web intent
> > specification (e.g. the IntentParameters dictionary).
> 
> Done.
> 
> > 2 Section 3.1
> >
> > The usage of  the "extras" and "data" seems to partially overlap one
> > with the other.
> 
> Yes. Subsequently we've gotten rid of "extras".
> 
> > Basically, both mechanisms allow transferring data from Client to Service.
> >
> >
> >
> > The pick-media and pick-contact intents use the "extras" parameter but
> > not the "data" parameter.
> >
> > The examples in the Web Intent specification use the "data" member but
> > not the "extras" parameter.
> >
> >
> >
> > 'extras' creates an asymmetry  between Web Intent request ('extras'
> > available) and Web Intent response ('extras' not available).
> >
> > In the case of 'symmetric' intents, like Pick and Save intents, the
> > request structure of one intent could be defined as equal to the
> > response structure of the other intent, thus removing the need for 'extras'.
> >
> > Would some guidelines/rationale on why using one or the other be useful?
> >
> > Would it make sense to simplify and have one single way of
> > transferring data?
> >
> >
> >
> > 3 Section 3.3
> >
> > 3.1
> >
> > Section 3.3.1 details when the onFailure callback is called.
> > This section is partially redundant with paragraph 7 of section 4.
> >
> > I wonder whether a single place that details exhaustively when
> > onFailure callback is called would be better.
> 
> This is a good point, and I'd like to address it separately. I'm currently of the
> opinion that our return data for error should be a dictionary with the fields that
> are in the Javascript Error object:
> "name" and "message". This definitely merits another subsection under section
> 4 (User Agent Behavior) detailing when errors must/should be delivered and
> what their names should be.
> 
> 
> > 3.2
> >
> > Related to my previous mail on the pick media intent, it seems that
> > nothing precludes the startActivity function to be called several
> > times using the same Intent object.
> >
> > If so, is a new context created for each startActivity call?
> >
> > Is it possible for a particular user agent to load only on the first
> > call the intent provider page and reuse the same page for the other calls?
> 
> This is something that has come up a few times now, and may merit another
> disposition. Ian Hickson's proposal [1] includes such a disposition, called
> "replace".
> 
> > What happens if startActivity is called several times in parallel on
> > the same Intent object without letting the user complete previous intents?
> >
> > Is it ok? Are the previous startActivity 'cancelled'? Is startActivity
> > returning an error?
> 
> It is allowed by the spec, but not well defined what UA behavior should be in this
> case. There's nothing in the spec about not being able to re-use a particular
> intent, and I don't think there should be
> -- intents are immutable, so can be re-used without a problem. A particular call
> can be bound by the client to different return handlers if they need to
> distinguish calls.
> 
> > 3.3
> >
> > It is not very clear what happens to the service page when it returns
> > a result or an error.
> > Can postResult/postFailure be called once (probably?) or several times
> > for a given startActivity call?
> >
> > If so, does it raise an error if called more than once in a given
> > Service page?
> 
> Yes, this is left up to the UA. Calling postResult/postFailure multiple times should
> throw a JS exception. Fixed in the spec by adding language to 3.4
> 
> > This is probably user agent implementation specific but in the "window"
> > disposition,
> >
> > it would be nice for users if the user agent focus was set back to the
> > calling web intent client tab when postResult/postFailure is called,
> >
> > at least if the current focus is in the intent provider tab.
> 
> Yes. This is Chrome's behavior, and should probably go into the UA best
> practices section.
> 
> > 4. Section 3.5
> >
> > 4.1
> >
> > Beginning of section 3.5 says that "A User Agent must not deliver an
> > Intent to a web app service page which does not include markup
> > describing what intents it can handle which matches the intent being
> delivered".
> >
> > In section 3.4.1, the spec says that window.intent object must not be
> > available for such pages (that have no mark-up) even though it was
> > delivered for the initial page.
> >
> > What is the rationale behind this restriction? security?
> >
> > Would it be simpler to always make available window.intent to pages
> > with the same context and same origin as the page for which the intent was
> delivered?
> 
> The premise of this language is to prevent 'window.intent' to ever be set by the
> UA on pages that aren't expecting it. We need to finish sorting out the evented
> delivery mechanism, but this language is likely to change. I do think the security
> requirements of not sending intent data to pages that haven't been chosen by
> the user means that we must keep the language restricting delivery to pages on
> the same site as the initial delivery page. Even if that page is taken over by a
> third party, it should not be possible for the attacker to redirect intent data to
> another site. (Although if the attacker has successfully taken over a page, they
> will likely be able to intercept intent data at that point, so this doesn't reduce the
> attack surface as much as would be nice.)
> 
> >
> >
> >
> > Going further down this path, is it absolutely needed to have that
> > <intent> mark-up within the page to which the intent is delivered in the first
> place?
> >
> > This approach adds some complexity (window.intent is available only
> > after parsing <intent> markup) and should be compared with its benefit.
> >
> > Is it to cope with obsolete-but-still-registered-providers?
> >
> > Would programmatic unregistration be simpler?
> 
> In Ian's proposal [1], there is programmatic unregistration, and I think we
> should adopt that API. It is nicely parallel to registerProtocolHandler and
> registerContentHandler, and would solve some of these problems. (So does
> evented delivery.)
> 
> > In terms of wording, sections 3.4.1 and 4 use the term "Make
> > available" a window.intent object.
> 
> Done.
> 
> >
> > Is there any difference with the wording "re-deliver" an intent as
> > stated in the HTTP Error Codes section?
> 
> Fixed up this use as well.
> 
> >
> > 4.2
> >
> > The "inline" disposition definition seems a bit vague.
> >
> > Are "inline" intents displayed on top of the web page, or in some
> > reserved user agent UI space?
> >
> > Are there any additional constraint the spec should state on the "inline"
> > behavior? pop-up, iframe-like with highest CSS z-index, banner...?
> 
> Yes, this is left open for UA interpretation. The goal is for "a context directly
> related to the client page context in an overlappable way."
> 
> > If an "inline" intent can be displayed on top of the client page, this
> > may open the door to clickjacking.
> >
> > For good UI integration, it may be nice to allow the client to suggest
> > where/how should appear the Service page.
> >
> > But this may be even worse for clickjacking...
> 
> Yes. We've discussed a true inline disposition (that is, embedded into the client
> page) as a possiblity, but we don't know how to guard that from redress attacks,
> so we've tabled it for now.
> 
> With respect to allowing the client control over where the service appears, that
> information is really known by the service, and unavailable to the client without
> a much more complex negotiation protocol.
> 
> > 4.3
> >
> > In the "Same-origin registration" subsection, it may be good to define
> > what means "when the href attribute points to a different resource".
> >
> > Is it based on normalized URL?
> 
> I'm not sure I follow this. The UA is said to MUST NOT obey a non-same-origin
> registration. What more specific instructions are needed? My impression is that
> "same origin" is the well-known construct to use here, but is there more precise
> language that would be better?
> 
> > 4.4
> >
> > The last sentence of the "Unregistering" subsection may be somewhat
> > tightened.
> >
> > If the new set is a subset of the currently-registered set, everything
> > is fine.
> >
> > If the new set partially overlaps the currently-registered set,
> >
> > the user agent should probably not replace the currently-registered
> > set with the new set,
> >
> > but only remove the items that are in the currently registered set and
> > not in the new set.
> 
> Tightened this up. Thanks.
> 
> > 4.5
> >
> > The "HTTP Error Codes" section title should probably be changed to
> > "HTTP Status Codes on Service Pages".
> 
> Done
> 
> > When retrieving the service page and retrieving a 4xx or 50x, the
> > Intent is dispatched but cannot be delivered.
> >
> > May a user agent go back to the Selection phase directly, especially
> > in the case of a 410 response?
> >
> > It is not clear whether a 4xx/50x response makes the intent to not be
> > dispatched (in which case onFailure will be called) or not.
> 
> Good point. This is a hole I've now filled.
> 
> > In the 'window' disposition, a user could refresh the tab until it
> > works or fails.
> >
> > When user closes the tab, the onFailure callback would be called if
> > the intent is not yet completed.
> >
> > For 'hidden' and 'inline' disposition, this may not work as well.
> >
> >
> >
> > 5. Section 4
> >
> > 5.1
> >
> > Section 4 preamble (before section 4.1) is really dense.
> > It explains both intent registration and intent invocation.
> >
> > It may be easier for readers if split into subsections.
> 
> Done.
> 
> > 5.2
> >
> > The <intent> element advertises an Intent capacity for two purposes
> > apparently: enabling web-based intent discovery/registration and
> > validating intent delivery.
> >
> > Beginning of section 4 seems to apply to the first usage when stating:
> >
> > "When the User Agent loads a page with registration markup, it SHOULD
> > allow the user to configure that page as web intents service".
> >
> > The SHOULD statement seems somehow too strong for "re-delivered web
> pages"
> > that would have mark-up for the second usage typically.
> 
> Delivering intents as events will clear this up, I think. It's true that the
> registration markup is a validation on intent delivery, but when we're delivering
> to a registered callback, we won't need to rely on it for that purpose, so it'll
> decouple the page parse from intent delivery.
> 
> > 5.3
> >
> > "This process SHOULD be configurable on a per-invocation basis for
> > most intents, although..."
> >
> > The word 'most' weakens the 'SHOULD.
> >
> > Would it make sense to detail what 'most' means (all except explicit?)
> > or simply remove 'for most intents'.
> 
> Done.
> 
> > 5.4
> >
> > In section 4.2, it says: 'if the intent action is different from the
> > service action'.
> > Does it mean character-based comparison? How about whitespaces?
> >
> > Same questions applies to service/action type if they are not mime types.
> 
> Yes, this means character-based comparison without regard for whitespace. Is
> there a better way to say that?
> 
> 
> > 6. Section 4.1
> >
> > While section 5 defines use cases and requirements, it is difficult to
> > relate any such requirement with explicit intents.
> >
> > In addition, a well-designed User Agent implementation may well cover
> > most of explicit intents functionality through "normal" intent.
> > Is there a chance that a good blend of defaulting rules plus a single
> > URL as "suggestions" field be sufficient for those use cases?
> >
> > Should additional experimentation be carried on before including
> > explicit intents in the spec?
> 
> This is a good question, and we have an ongoing thread on the list about this
> topic.
> 
> > 7. Section 5
> >
> > This section is useful for WG members.
> >
> > On the other hand, I do not know how useful it is for implementers or
> > users of the specification.
> >
> > Should it be moved to a non-normative appendix or a separate document?
> 
> Yes. 1.2 marks this as informative.
> 
> >
> >
> > 8. Typos
> >
> > Section 3.5.1
> >
> >                 "40X" -> "4XX"
> >
> > Section 5.5, first paragraph
> >
> >              "the use" -> "the user"
> >
> > Section 6 first sentence
> >
> >              "will user" -> "will use"
> >
> > Section 6 second sentence
> >
> >              them -> "the user"
> 
> All fixed.
> 
> 
> [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-
> July/036719.html

Received on Thursday, 18 October 2012 12:59:54 UTC