- From: Wojciech Masłowski <wmaslowski@opera.com>
- Date: Fri, 02 Jul 2010 16:54:11 +0200
- To: Robin Berjon <robin@berjon.com>
- CC: public-device-apis@w3.org
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 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 http://www.opera.com
Received on Friday, 2 July 2010 14:54:54 UTC