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 Tuesday, 11 September 2012 20:27:04 UTC