Re: New Contacts API published

2010/7/2 Wojciech Masłowski <wmaslowski@opera.com>

> W dniu 2010-07-02 13:46, Robin Berjon pisze:
>
>  Hi,
>>
>> just a FYI that this has been updated:
>>
>>   http://www.w3.org/TR/contacts-api/
>>
>> Thanks to Richard and all who helped!
>>
>>
>>
> Some remarks about new draft
>
> 4.2.1 Methods
>
>> If a current find(), save() or remove() operation is pending a response,
>> invoke the errorCB with a PENDING_OPERATION_ERROR code.
>>
> ..
>
>> If successful, invoke the associated successCB. If the attempt fails, and
>> the method was invoked with a non-null errorCB argument, this method must
>> invoke the errorCB with a ContactError object as an argument.
>>
> This might be fussy but it seems inconsistent to me to explicitly specify
> that errorCB has to be non-null in one case and not in the other. Same
> applies to 4.3.2
>

Right, errorCB is optional and therefore may also be null in both cases.

Fixed for find(), save() and remove() operations.


>
> 5.1 Search Qualifiers
>
>> The search qualifier provides an application with a way to request the
>> specific subset of ContactProperties it wishes to obtain in any resulting
>> successful callback. The search qualifier is deployed to minimize the data
>> that needs to be shared with an application in order to let that application
>> fulfill its function on behalf of the user. The search qualifier is included
>> within a Contacts find() operation as the *filter* parameter.
>>
> There is no filter parameter for find() function. You probably meant
> fields.
>
>  If a specific search qualifier element provided, or filter[x], does not
>> match any well-known ContactProperties attribute, filter[x] should be
>> ignored when executing the current Contacts find() operation.
>>
> The whole *or filter[x]* makes the sentence hard to understand. Aside from
> that what is *well-known* ContactProperties attribute? Isn't it just
> ContactProperties?
>

Fixed.


> 5.2.3 Search Filters
>
>> A search filter is used to search all the fields of a Contacts database
>> and represents the logical union, or ∪, of provided values that are matched
>> therein.
>>
>> All contact searching must apply a loose-matching policy to the search
>> filter provided. If a ContactProperties attribute being searched in a
>> Contact object, stored within the Contacts database, is a partial value
>> match of the input filter value, that Contact object must be returned as
>> part of the resulting ContactFindSuccessCB.
>>
> Nitpicking, but this may be ambiguous. Do we search all fields(first
> paragraph) or only ContactProperties (second paragraph).


Updated.


> The main point is do we include id and serviceId in searching or not? To
> add to the confusion in appendix B. Search Weights id is included but
> serviceId is not, which may suggest that we search only ids but not
> serviceIds. This should be clarified.


serviceId was not included in Appendix B though had the serviceId attribute
remained it probably should have been. Pending a workable outcome to [1]
the serviceId attribute has been removed from the specification.

Regarding id, it may make sense AFAICS to make this searchable, considering
it is always returned to the web app, that a web app may know from previous
user interaction that it requires a very specific Contact object, and that
'id' does not need to be explicitly specified within a 'search qualifier'.
The update mentioned below to section 5.3.2 also reads '[A conforming
implementation must only allow the provided search filter to be applied to
fields requested in the provided search qualifier.] The id attribute must
always be implicitly searchable from any requesting web application
regardless of whether it has been included as part of any provided search
qualifier.'.



>
>
> Apart from this I was wondering if searching in all the fields when we
> request access only to a subset is such a good idea and if we shouldn't just
> search in the fields requested by the search qualifier. Apart from
> performance gain(we dont need to search fields that don't interest us) and
> possibly better match results (we don't get trashed by the matches on fields
> we don't have access), there is a possibility of circumventing security
> policy. Lets say we agreed to give our page access to name property. The
> script can then easily get a person birthday/anniversary by just querying
> about all the dates in the year. You should end up with 1-2 dates for each
> contact. If you get 1 it is most likely birthday. If there are 2 you can
> query about different years for each contact and get full dates and
> anniversary will be later than birthday. Alternately if a malicious website
> obtains a large database of such a pairs it can try to apply some heuristics
> as assuming that if you got 2 people have the same date and same last name
> we can assume it is anniversary. These methods will not be 100% accurate but
> I think they may yield quite good results. I guess you could more or less
> make similar methods using specific features of different fields for
> indirectly obtaining them(gender, utcOffset, email, and phone number come to
> mind as they have quite structured form).
>

I did wonder whether we needed to be more strict here and you seem to
confirm this. As you point out, if the search is over all fields then there
is potential for an application to phish for information within fields that
it may not ultimately be able to access.

I've added the fourth paragraph to section 5.3.2 to say that only fields
being requested can be searched upon. I have also updated the example
provided in section 5.3.2.1.


Please do look over the changes (the W3C CVS diff tool may be helpful for
this [2]) and let me know if I've captured your comments adequately.

Thanks!

Richard


[1] http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0321.html

[2]
http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html.diff?r1=1.66&r2=1.67&f=h