John, I know it doesn't introduce anything new (per my original post).
I had a hard time coming up with an example but here's the best I could do. When I authorize application FOO to access my account I am giving them permission to poll for my direct messages. [Agreed] I am also giving them permission to listen to a stream which contains my direct messages. [Agreed] I am also giving Twitter permission to mail them a CD every month with all my direct messages. [Agreed] My point is...it's not about a violation of the existing terms. But there is a line - which I'm sure you'd draw before mailing out CDs - which I think the Site Stream is approaching. I'm not opposed to the Site stream - in fact I hope to use it. But I also don't have much personal information on Twitter (it's generally public - incl. DMs). But it could be for others. I'm sure you guys thought about it more than I have but it's worth bringing up. On Aug 30, 12:07 pm, John Kalucki <j...@twitter.com> wrote: > Site Streams do not change anything in the Twitter privacy model. OAuth'ed > applications have always been able to pull your direct messages via the REST > API. > > -John Kaluckihttp://twitter.com/jkalucki > Twitter, Inc. > > On Mon, Aug 30, 2010 at 12:05 PM, jmathai <jmat...@gmail.com> wrote: > > I haven't kept up on the streaming API but read about the new Site > > Steam and it raised some privacy concerns. Specifically the fact that > > direct messages would be streamed from anyone that added your > > application. I understand this was always possible but the stream API > > makes it fairly trivial to collect all that data. > > > It's also a privacy concern because of user intent. When someone adds > > an application my guess is that they're not intending on saying "yes, > > gain access to my direct messages" much less "sign up to receive all > > my direct messages via a stream". > > > Anyways, the stream API is awesome...but it's important to understand > > how users interact with applications and what their intentions are > > when they add (regardless of what they are in fact signing up for). I > > also realize all of this was previously possible but by making it > > easier it increases the chances that apps are accessing this data. > > > Just thought I'd bring it up for discussion :) > > > -- > > Twitter developer documentation and resources:http://dev.twitter.com/doc > > API updates via Twitter:http://twitter.com/twitterapi > > Issues/Enhancements Tracker: > >http://code.google.com/p/twitter-api/issues/list > > Change your membership to this group: > >http://groups.google.com/group/twitter-development-talk?hl=en > > -- Twitter developer documentation and resources: http://dev.twitter.com/doc API updates via Twitter: http://twitter.com/twitterapi Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list Change your membership to this group: http://groups.google.com/group/twitter-development-talk?hl=en
