Re: New Contacts API published

W dniu 2010-07-02 13:46, Robin Berjon pisze:
> Hi,
> just a FYI that this has been updated:
> 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

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?

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). 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.

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).

Wojciech Masłowski
Engeneering CORE Wrocław
Opera Software ASA

Received on Friday, 2 July 2010 14:54:54 UTC