Alexro wrote: > not to ignore privacy issues but just to simplify the situation a bit ... > What currently protects a user from a malicious (desktop) application stealing all > kinds of user data via submitting tweets through it's proxy? And even by > submitting such information directly to it's website?
That is a very good point. It is an unsolved problem that affects nearly all installable software, and that is a problem that needs to be solved at the operating system level. iPhone OS and the upcoming Windows 7 Phone do have measures to protect against that kind of data theft and inadvertent information disclosure; in fact, basically all of the API limitations in Windows 7 Phone (no background apps, no access to the user's personal information, warnings about GPS usage) can be traced back to privacy protection. Similarly, even in desktop Windows, access to PIM information (email and contacts in particular) is severely restricted with the official APIs. Location is a different because Twitter has special privacy protections for its geo feature, including technical limitations that control whether applications may use it, and a way to remove the location information from tweets after the fact. I don't think it makes sense to have a lock for the built-in location feature and at the same time allow applications to use annotations to disclose the same (or even more precise) location information regardless of that lock. If you can trust applications not to disclose location information via annotations without the user's consent, why can't you trust those same applications to not use the built-in geo feature without the user's consent? If an application isn't trusted enough to be able to flip the geo switch, why should it be trusted to not disclose the user's location in a different way without the user's consent? At least with the built-in geo feature, there is a built-in mechanism for the user to remove the geo annotations, unlike other annotations. It is the same deal with Twitter XAuth and website-only functionality. A malicious Twitter XAuth application has full access to everything in the user's account because it has the user's password. Meanwhile, the API doesn't expose useful actions (sign up, approve followers, change password, read email address) in an effort to prevent malicious applications from using that functionality. But, of course, malicious applications don't *need* any official API at all to perform those actions. My conclusion is that the API restrictions punish well-behaved applications due to fear that they may be malicious, but they don't actually prevent any unwanted behavior by applications that actually are malicious. This is something that Raffi touched on when he blogged about how he thinks that every OAuth approval should be going through the Twitter website (i.e. no Twitter XAuth). The annotations feature would compound that problem in a way that can't be solved by disabling Twitter XAuth access to applications. (Note that "Twitter XAuth" is different from, xauth.org XAuth.) Regards, Brian -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
