Social Network TOS

LAST UPDATED: December 13, 2012

Facebook | Twitter | LinkedIn | Yahoo! | Google | Google+ | Windows Live – Live Connect

FACEBOOK

WILL NOT SELL SOCIAL NETWORK DATA

“You will not sell or purchase any data obtained from us by anyone. If you are acquired by or merge with a third party, you can continue to use user data within your application, but you cannot transfer data outside your application.”

“You will not directly or indirectly transfer any data you receive from us, including user data or Facebook User IDs, to (or use such data in connection with) any ad network, ad exchange, data broker, or other advertising or monetization related toolset, even if a user consents to such transfer or use. By indirectly we mean you cannot, for example, transfer data to a third party who then transfers the data to an ad network. By any data we mean all data obtained through use of the Facebook Platform (API, Social Plugins, etc.), including aggregate, anonymous or derivative data.”

Platform Policies (12/12/2012): Section II.9 and II.6

WILL NOT POST TO SOCIAL NETWORK ACCOUNTS WITHOUT PERMISSION

“Subject to certain restrictions, including on transfer, users give you their basic account information when they connect with your application. For all other data obtained through use of the Facebook API, you must obtain explicit consent from the user who provided the data to us before using it for any purpose other than displaying it back to the user on your application.”

“If a user grants you a publishing permission, actions you take on the user’s behalf must be expected by the user and consistent with the user’s actions within your app.”

Platform Policies (12/12/2012): Section II.5 and Section IV.3

WILL NOT SEND PRIVATE MESSAGES WITHOUT PERMISSION

“Subject to certain restrictions, including on transfer, users give you their basic account information when they connect with your application. For all other data obtained through use of the Facebook API, you must obtain explicit consent from the user who provided the data to us before using it for any purpose other than displaying it back to the user on your application.”

“If a user grants you a publishing permission, actions you take on the user’s behalf must be expected by the user and consistent with the user’s actions within your app.”

Platform Policies (11/14/2012): Section II.5 and “Principals”

EMAIL OPT-IN/SPAM

“Quality of content: you are responsible for providing users with a quality experience and must not confuse, defraud, mislead, spam or surprise users. For example, you must monitor your app’s negative feedback in Application Insights to ensure it stays below our thresholds, avoid excessive advertisements or bugs, and ensure the description of your app is consistent with your app’s content.”

“Facebook messaging (i.e., email sent to an @facebook.com address) is designed for communication between users, and not a channel for applications to communicate directly with users.”

“Principles
Create a great user experience
– Build social and engaging applications
– Give users choice and control
– Help users share expressive and relevant content

Be trustworthy
– Respect privacy
– Don’t mislead, confuse, defraud, or surprise users
– Don’t spam – encourage authentic communications”

Platform Policies (11/14/2012): Section III.6, Section IV.5 and Principals

TWITTER

WILL NOT SELL SOCIAL NETWORK DATA

“You will not attempt or encourage others to:
sell, rent, lease, sublicense, redistribute, or syndicate access to the Twitter API or Twitter Content to any third party without prior written approval from Twitter.”

Definition of “Twitter Content”: All use of the Twitter API and content, documentation, code, and related materials made available to you on or through Twitter (“Twitter Content”) is subject to and must comply with these Rules.

Developer Rules of the Road (9/5/2012) Section I(1) and I(4)(A)

WILL NOT POST TO SOCIAL NETWORK ACCOUNTS WITHOUT PERMISSION

“Don’t surprise users
Get users’ permission before:
– sending Tweets or other messages on their behalf. A user authenticating through your application does not constitute consent to send a message.
– modifying their profile information or taking account actions (including following, unfollowing, and blocking) on their behalf.
– adding hashtags, annotations data, or other content to a user’s Tweet. If your application allows users to send Tweets or other content to Twitter, show the user exactly what will be published.
– republishing Twitter Content accessed through means other than via the Twitter API or other tools that may be provided to you by Twitter, or in a manner inconsistent with the Display Requirements.”

“Respect the privacy and sharing settings of Twitter Content. Do not share, or encourage or facilitate the sharing of protected Twitter Content. Promptly change your treatment of Twitter Content (for example, deletions, modifications, and sharing options) as changes are reported through the Twitter API.”

Developer Rules of the Road (9/5/2012) Section II (1)(b) and I(1)(D)

WILL NOT SEND PRIVATE MESSAGES WITHOUT PERMISSION

“Don’t surprise users
Get users’ permission before:
– sending Tweets or other messages on their behalf. A user authenticating through your application does not constitute consent to send a message.
– modifying their profile information or taking account actions (including following, unfollowing, and blocking) on their behalf.
– adding hashtags, annotations data, or other content to a user’s Tweet. If your application allows users to send Tweets or other content to Twitter, show the user exactly what will be published.
– republishing Twitter Content accessed through means other than via the Twitter API or other tools that may be provided to you by Twitter, or in a manner inconsistent with the Display Requirements.”

“Respect the privacy and sharing settings of Twitter Content. Do not share, or encourage or facilitate the sharing of protected Twitter Content. Promptly change your treatment of Twitter Content (for example, deletions, modifications, and sharing options) as changes are reported through the Twitter API.”

Developer Rules of the Road (9/5/2012) Section II (1)(b) and I(1)(D)

EMAIL OPT-IN/SPAM

Note: You need specific permission to even store non-public Twitter Content.
Definition of “Twitter Content”: All use of the Twitter API and content, documentation, code, and related materials made available to you on or through Twitter (“Twitter Content”) is subject to and must comply with these Rules.
“Do not store non-public Twitter Content except at the explicit direction of a Twitter end user.”

Additionally, the following FAQ clarifies that the Twitter API does not currently provide a user’s email address: https://dev.twitter.com/docs/faq.

Q: How do I obtain a user’s email address?
A: If you’d like a user’s email address, you’ll need to ask a user for it within the confines of your own application and service. The Twitter API does not provide the user’s email address as part of the OAuth token negotiation process nor does it offer other means to obtain it.

“Principles
You agree that you and your Service will follow these four principles:
– Don’t surprise users
– Don’t create or distribute spam
– Respect user privacy
– Be a good partner to Twitter”

“Don’t create or distribute spam
A. Spam can take many forms. Please abide by the spam rules here.
B. If your application performs automatic actions (including tweeting or other content updates), make sure you comply with the Automation Rules found here.”

Developer Rules of the Road (9/5/2012) Section II (2) and Section II(3) (F)

LINKEDIN

WILL NOT SELL SOCIAL NETWORK DATA

“The use scenarios below are not permitted under these Terms. You must never do any of the following:
Sell, lease, share, transfer, or sublicense any Content or access to any Content, directly or indirectly, to any third party, including any recruiter, data broker, salesperson, or advertising-related entity.”

“Content” means Profile Data and any other data or content from the Website or accessed via the APIs.

“Profile Data” means the name, photo, headline, contact information, experience, education, summary, and location of a LinkedIn member. Profile Data excludes connections, network updates, jobs, groups, and companies.”

“You may not transfer LinkedIn data to anyone beyond displaying it to the user engaged with your application.”

API Terms of Use (8/6/2012): Section III A.(2)(d)and Section J (Definitions) and Platform Guidelines Section 3(3) (no date)

WILL NOT POST TO SOCIAL NETWORK ACCOUNTS WITHOUT PERMISSION

“The use scenarios below are not permitted under these Terms. You must never do any of the following:
Use the Content for any of the following: generating messages, promotions, offers or mass messages, or for any other purpose other than, and solely to the extent necessary for, allowing end users to use the Content in your Application.”

“Content” means Profile Data and any other data or content from the Website or accessed via the APIs.

“Profile Data” means the name, photo, headline, contact information, experience, education, summary, and location of a LinkedIn member. Profile Data excludes connections, network updates, jobs, groups, and companies.”
“Additional information for Posting Network Updates:

13. Network updates should communicate significant professional activities by the user and as such often should only be initiated when users generate content on your site. For example, simply registering with your site or application is not a significant activity, and should not generate a network update.

14. You cannot send a network update for visits to your site or registrations on your site.

15. You cannot send a network update to suggest or require users visit or register on your site. Updates are to communicate the activities of your users that their connections will gain from knowing.

16. Network updates associated with a user action must only be posted once. “
“Getting and Displaying Network Updates

1. Network updates are private to the user for which they are intended. You may not request network updates for one person that you show to another person.

2. You cannot modify the content of a network update or do anything that would misrepresent the original content and intent of the update.

3. When displaying network updates, you must include the name of the person who made the update, the complete text of the update, and all links included in the update. Optionally, you should also include the picture of person who made the update.

4. When displaying network updates, you must include all standard LinkedIn actions with that update, including the ability to like, comment, and send a private message to the poster of that update. These abilities are all provided via the LinkedIn API.

5. When displaying a share update with rich content, you must display the image, source, title, and summary data provided, in addition to the text of the update.

6. Where LinkedIn members are mentioned in the update, those user names must have a link back to the user’s LinkedIn profile. That profile can be displayed on your side via an API call or can be a link to the LinkedIn website. API calls return the links you need.

7. If you allow commenting on network updates, you must post those comments back to LinkedIn using the API.

8. If you display a group of updates (“stream” or “feed”), you can add advertising or other promotional messages within that group of updates only if you clearly mark the advertisement or promotional content as such. Users should not mistakenly think your content is coming from their LinkedIn network updates.

9. You may not include advertising within the content of a network update. You must always keep the name, update, picture, and links together without intervening content.”

API Terms of Use (8/6/2012): Section III A.(2)(d) and Platform Guidelines Section 7 and 8 (no date)

WILL NOT SEND PRIVATE MESSAGES WITHOUT PERMISSION

“The use scenarios below are not permitted under these Terms. You must never do any of the following:
Use the Content for any of the following: generating messages, promotions, offers or mass messages, or for any other purpose other than, and solely to the extent necessary for, allowing end users to use the Content in your Application.”

“Content” means Profile Data and any other data or content from the Website or accessed via the APIs.

“Profile Data” means the name, photo, headline, contact information, experience, education, summary, and location of a LinkedIn member. Profile Data excludes connections, network updates, jobs, groups, and companies.”
“These features represent ways the user can message others. The “message” referred to below is the message, invitation, status update, or network update sent.

1. Messages are a mechanism for your users to communicate about themselves to their connections. They should not be used to promote your product or service.

2. A message must be triggered by a specific user action, not sent as an automated or scheduled event. A user simply navigating through your application is not a specific event.

3. The user must be given a choice about whether to send the message. The user must opt into the messages being sent rather than opt out.

4. For all messages but network updates, the user must be presented with the exact body and subject of the message and have the opportunity to customize both the subject and the body. Pre-prepared messages are allowed only if the user has full control over what is ultimately posted on their behalf.

5. Message text you present by default must not contain superfluous characters for the purpose of becoming more noticeable than other messages. Message text must not be in all capital letters. For example, you may not propose to a user that they send a message such as **** HOW ARE YOU?!?!

6. Message text you present by default must not contain profanity.

7. If you include a URL in your message, it must not point directly to an executable or installer file of any type.

8. The option to cancel without sending a message must have a presentation equal to the option to send the message.

9. A message must come at or around the time the user took action to send the message.

10. You must not offer any direct incentive as a reward for sending a message.

11. You cannot use invitations as general messages. Invitations should be used only for the purpose of requesting an invitation to join the user’s LinkedIn network. You may not use invitations to send messages that contain proposals, requests, offers, recommendations, or other non-invitation text.

12. For messaging between connections, each message can be sent to up to 10 connections. Messages cannot be resent with the purpose of reaching more than 10 connections with the same message.
API Terms of Use (8/6/2012): Section III A.(2)(d) and Platform Guidelines Section 7 and 8 (no date)

EMAIL OPT-IN/SPAM

Note: You need specific permission to even store LinkedIn data (i.e. emails) and LinkedIn does not allow the sending of any promotional messages:

“No LinkedIn data can be stored: The only exceptions are storing the Member ID for subsequent API calls, and storing the user’s profile data when given explicit user permission by the owner of the profile using a LinkedIn-provided interface to obtain the user’s consent.” (NOTE: There currently is not LinkedIn provided interface)
“If you specifically ask the profile owner to store his/her profile and make it clear that you will be storing it, then you may store the profile of the user who granted you access. The details of this are provided in Section 3.4 of the API Terms. You may only store the profile of that person, not the profile data of that person’s connections, network updates, or other network information.”

“If you obtain a member’s consent to store that member’s profile, you may perform a one-time capture of the Profile Data for that member and store that Profile Data. The process for obtaining member consent must meet the specifications provided by LinkedIn and explicitly inform the member which parts of his or her profile you are storing. Each future request for revised Profile Data must be accompanied by another request for consent from that member and consent from that member. You must use stored Profile Data solely for the benefit of the LinkedIn user that granted you permission to access it. You must not monetize it, directly or indirectly. For example, you may not sell access to an aggregated collection of profiles or the most relevant people for a position.”
“The use scenarios below are not permitted under these Terms. You must never do any of the following:

Use the Content for any of the following: generating messages, promotions, offers or mass messages, or for any other purpose other than, and solely to the extent necessary for, allowing end users to use the Content in your Application.”

“Content” means Profile Data and any other data or content from the Website or accessed via the APIs.

“Profile Data” means the name, photo, headline, contact information, experience, education, summary, and location of a LinkedIn member. Profile Data excludes connections, network updates, jobs, groups, and companies.”
“These features represent ways the user can message others. The “message” referred to below is the message, invitation, status update, or network update sent.

13. Messages are a mechanism for your users to communicate about themselves to their connections. They should not be used to promote your product or service.

14. A message must be triggered by a specific user action, not sent as an automated or scheduled event. A user simply navigating through your application is not a specific event.

15. The user must be given a choice about whether to send the message. The user must opt into the messages being sent rather than opt out.

16. For all messages but network updates, the user must be presented with the exact body and subject of the message and have the opportunity to customize both the subject and the body. Pre-prepared messages are allowed only if the user has full control over what is ultimately posted on their behalf.

17. Message text you present by default must not contain superfluous characters for the purpose of becoming more noticeable than other messages. Message text must not be in all capital letters. For example, you may not propose to a user that they send a message such as **** HOW ARE YOU?!?!

18. Message text you present by default must not contain profanity.

19. If you include a URL in your message, it must not point directly to an executable or installer file of any type.

20. The option to cancel without sending a message must have a presentation equal to the option to send the message.

21. A message must come at or around the time the user took action to send the message.

22. You must not offer any direct incentive as a reward for sending a message.

23. You cannot use invitations as general messages. Invitations should be used only for the purpose of requesting an invitation to join the user’s LinkedIn network. You may not use invitations to send messages that contain proposals, requests, offers, recommendations, or other non-invitation text.

24. For messaging between connections, each message can be sent to up to 10 connections. Messages cannot be resent with the purpose of reaching more than 10 connections with the same message.

Platform Guidelines (no date): Sections 1, 3 and 8 and API Terms of Use (8/6/2012): Section III A.(2)(b)

YAHOO!

WILL NOT SELL SOCIAL NETWORK DATA

“YOU SHALL NOT…

Sell, lease, share, transfer, or sublicense the Yahoo! APIs or access or access codes thereto or derive income from the use or provision of the Yahoo! APIs, whether for direct commercial or monetary gain or otherwise, unless the API Documents specifically permit otherwise or Yahoo! gives prior, express, written permission”

Yahoo! clarifies this in an FAQ – http://developer.yahoo.com/faq/:

Can user data be sold to a third party?
No. Selling user data to a third party is in violation of the Yahoo! APIs Terms of Use. In the event of a violation of the Terms of Use, your developer’s license to use the Yahoo! APIs may be revoked.

Yahoo! API Terms of Use (no date): Section 1(g)(iv)

WILL NOT POST TO SOCIAL NETWORK ACCOUNTS WITHOUT PERMISSION

“Securing User Consent. You are solely responsible for securing clear, express consent from the user, granting you permission to access such user’s Yahoo! account using OAuth-enabled APIs or BBAuth-enabled APIs, including if applicable, retrieving user-specific information, or writing information to such user’s account. You will strictly comply with the scope of express consent they granted you when accessing such user’s Yahoo! account.”

Yahoo! clarifies this in an FAQ – http://developer.yahoo.com/faq/:
How do users give permission for sharing user data with third parties?

To provide permission for the use of non-public user data, a user must provide consent to the third party (for example, through OAuth): A user is presented with a consent-flow interface when asked to share data with a third party through a Yahoo! API. This interface informs users of what information about them and their activities will be shared with the third party. Users have the option to retract this permission at any time by visiting their Manage Account page.

In general, the use of public user data, such as through the Updates Firehose API, does not need explicit user consent. Users are able to control what data is made public via the Manage Updates area of Yahoo! Pulse or at the location where they post an update on Yahoo!.”
API Terms of Use (no date): Section 1(h)(ii)

WILL NOT SEND PRIVATE MESSAGES WITHOUT PERMISSION

“Securing User Consent. You are solely responsible for securing clear, express consent from the user, granting you permission to access such user’s Yahoo! account using OAuth-enabled APIs or BBAuth-enabled APIs, including if applicable, retrieving user-specific information, or writing information to such user’s account. You will strictly comply with the scope of express consent they granted you when accessing such user’s Yahoo! account.”

Yahoo! clarifies this in an FAQ – http://developer.yahoo.com/faq/:
How do users give permission for sharing user data with third parties?

To provide permission for the use of non-public user data, a user must provide consent to the third party (for example, through OAuth): A user is presented with a consent-flow interface when asked to share data with a third party through a Yahoo! API. This interface informs users of what information about them and their activities will be shared with the third party. Users have the option to retract this permission at any time by visiting their Manage Account page.

In general, the use of public user data, such as through the Updates Firehose API, does not need explicit user consent. Users are able to control what data is made public via the Manage Updates area of Yahoo! Pulse or at the location where they post an update on Yahoo!.”
API Terms of Use (no date): Section 1(h)(ii)

EMAIL OPT-IN/SPAM

Note: Yahoo! does not allow you to store user data (i.e. emails) except in 3 very limited circumstances.
– GUID (Global Unique Identifier)
– Authenticated Token Value.
– User data obtained through the Yahoo! Updates API or Yahoo! Updates Firehose API, for which no request for deletion has been made

“Data Collection, Storage, and Use.

a. You may not retain or use, and must immediately remove from any Application and any data repository in your possession or under your control any Yahoo! user data obtained through the Yahoo! APIs not explicitly identified as being storable indefinitely in the API Documents within 24 hours after the time at which you obtained the data, or such other time as Yahoo! may specify to you from time to time, including pursuant to notification received from application uninstall event handlers.

b. You may not disclose any Yahoo! user data or store any Yahoo! user data in any data repository which enables any third party (other than the Yahoo! user) access unless such disclosure or third party access is expressly permitted by the Yahoo! user and disclosed in your privacy policy, which must be directly accessible through a link in your Application using Yahoo! APIs.

c. You may not share GUIDs (Global Unique Identifiers) with any third party.”

API Documents (from reference above):

“Collection and Storage of User Data

Access to Yahoo! user data is only permissible using approved authentication methods, such as Browser Based Authentication and OAuth.

Per the Yahoo! API TOU and the YAP Developer Terms of Use, you may not store any user data collected through the Yahoo! APIs for more than 24 hours, with the exception of information that is explicitly permitted to be indefinitely stored. Only the parameters listed below are storable indefinitely; all other information must be requested from Yahoo! each time.

Yahoo! user data that is storable indefinitely:
– GUID (Global Unique Identifier)
– Authenticated Token Value.
– User data obtained through the Yahoo! Updates API or Yahoo! Updates Firehose API, for which no request for deletion has been made.”

Developer Network Guidelines (no date) and API Terms of Use (no date): Section 2

GOOGLE

WILL NOT SELL SOCIAL NETWORK DATA

Google (for Auth APIs only, not Google+ (see below for Google+)):
There is nothing explicitly stated in the Developer Terms about selling, but see:
“When a user’s non-public content is obtained through the APIs, you may not expose that content to other users or to third parties without explicit opt-in consent from that user.”

API Terms of Service (12/9/2011); Section 5

https://developers.google.com/terms/

WILL NOT POST TO SOCIAL NETWORK ACCOUNTS WITHOUT PERMISSION

Google (for Auth APIs only, not Google + (see below for Google+)):
“When a user’s non-public content is obtained through the APIs, you may not expose that content to other users or to third parties without explicit opt-in consent from that user.”

API Terms of Service (12/9/2011); Section 5

https://developers.google.com/terms/

WILL NOT SEND PRIVATE MESSAGES WITHOUT PERMISSION

Google (for Auth APIs only, not Google + (see below for Google+)):
There is nothing explicitly stated in the Developer Terms

https://developers.google.com/terms/

EMAIL OPT-IN/SPAM

Google (for Auth APIs only, not Google + (see below for Google+)):
There is nothing explicitly stated in the Developer Terms

https://developers.google.com/terms/

GOOGLE+

WILL NOT SELL SOCIAL NETWORK DATA

“You may not use user data from your API Client for advertising purposes, unless: (i) you are explicitly authorized by Google, or (ii) you are using an advertising solution that Google provides for this purpose. You may not sell or transmit any user data received from your API Client(s) to a third-party ad network or service, data broker, or other advertising or marketing provider. For the avoidance of doubt, user data from the API Client(s) may not be used for Third-Party Ad Serving (“3PAS”).”

“Don’t sell, rent, or otherwise provide a user’s personal information to any third party without getting specific opt-in consent from the user. Opt-in consent isn’t required to provide users’ personal information to third parties, like infrastructure providers or customer service contractors, whose services are reasonably necessary to help you build or run your applications. You’re responsible for how those third parties handle this information, and you must contractually require them to keep it confidential.”

Google+ Platform Terms of Service (6/25/2012), Section 2; Google+ Platform Developer Policies (6/25/2012), Section B(1)(b))

WILL NOT POST TO SOCIAL NETWORK ACCOUNTS WITHOUT PERMISSION

“Be transparent
– Be honest about the intention of your application.
– Show users what you will do on their behalf and get their explicit permission before you do it.”

“Respect user data
Keep users’ private information private, in accordance with your privacy policy.”

“Don’t use users’ personal information for purposes beyond the limited and express purpose of your application (including as it may reasonably evolve due to ongoing development), without getting specific opt-in consent from the user.”

“Non-public information from the API
For non-public personal information obtained through the Google+ API, whether originally from your users or from people who have shared with your users:

– Don’t expose that information to other users or to third parties without explicit opt-in consent from the user.”

“Posts to the stream and notifications initiated by your application

a. Don’t do any of the following without the user taking an explicit action each time to initiate it:
1. Post an update to the user’s stream or send a notification (including invite).
2. Modify the user’s circles in any way.
3. Share the user’s location information.

b. Don’t send any posts on behalf of the user without:
1. Showing an accurate preview of what’s about to be posted and making sure the user is aware of what will cause the share action.
2. Allowing users to append their own text.
3. Letting users pick the individuals or circles with whom they want to share.
4. Indicating that your application is the source of the post or notification.

c. Don’t circumvent a user’s Google+ privacy settings, including the user’s circles or other permission settings.

d. Don’t circumvent technical limitations on your use of Google-provided APIs, such as limits on the number or frequency of stream posts. Don’t screen scrape or use any non-documented APIs.

e. Don’t circumvent any Google+ user interfaces that ensure the user is aware of and agrees to stream posts or the like made on his or her behalf.

f. Don’t circumvent any Google+ user interfaces or settings that limit the visibility of information, such as stream posts, from others.

g. Don’t share with any third party any personal authentication mechanism granted by Google or by any user to you, including your personal certificate or a user’s authorization token.

h. Don’t override the default sharing option to be “Your circles,” “Extended circles,” or “Public.”

i. Don’t encourage stream posts for banal purposes.

j. Don’t mislead users about requirements to access any functionality in your application.

k. Don’t require your users to post to the stream or issue a notification (including invites) in order to access application functionality. Posts to the stream and notifications should always be optional.”

Google+ Platform Developer Policies (6/25/2012), Sections B(1)(a), B(2)(a), C(3)(a)-(k)

WILL NOT SEND PRIVATE MESSAGES WITHOUT PERMISSION

There is nothing explicitly stated in the Google+ Terms or Platform Developer Policies, but see:

“Don’t use users’ personal information for purposes beyond the limited and express purpose of your application (including as it may reasonably evolve due to ongoing development), without getting specific opt-in consent from the user.”

Google+ Platform Developer Policies (6/25/2012), Section B(1)(a)

EMAIL OPT-IN/SPAM

There is nothing explicitly stated in the Google+ Terms or Platform Developer Policies

WINDOWS LIVE – LIVE CONNECT

WILL NOT SELL SOCIAL NETWORK DATA

Windows Live – LiveConnect (not a review of Messenger Connect or any social login outside of LiveConnect terms)

There is nothing explicitly stated in the LiveConnect Terms

WILL NOT POST TO SOCIAL NETWORK ACCOUNTS WITHOUT PERMISSION

Windows Live – LiveConnect (not a review of Messenger Connect or any social login outside of LiveConnect terms)

You may not:
– Take any action on behalf of an end user unless the end user has expressly granted you permission to take that action.”
“You are responsible for providing end users with adequate notice of your own privacy practices. At the time you retrieve information from a Microsoft Service, you will obtain informed consent from the end user concerning how you will use their data, and with whom it will be shared. Unauthorized use of end users’ personal information or email addresses will be subject to immediate revocation of your Client ID.”

“End user information: Where an Authorized Application seeks permission from an end user to access Personal Information (as defined in the Microsoft Online Privacy Statement) from Microsoft Services, the Authorized Application must provide a link to http://consent.live.com/manageconsent.aspx, or such other location as we may specify from time to time, with a clear indication that end users can go to that Microsoft site to revoke such permission at any time. If end users must take additional steps to disable the Authorized Application’s access to end user information, then the Authorized Application must clearly indicate to end users the additional steps required to disable access. These requirements do not apply where Microsoft provides the end user interface.”

Live Connect Terms of Use (2/2012) Section 3(a)(iv) and Section 6

WILL NOT SEND PRIVATE MESSAGES WITHOUT PERMISSION

Windows Live – LiveConnect (not a review of Messenger Connect or any social login outside of LiveConnect terms)

You may not:
– Take any action on behalf of an end user unless the end user has expressly granted you permission to take that action.
“You are responsible for providing end users with adequate notice of your own privacy practices. At the time you retrieve information from a Microsoft Service, you will obtain informed consent from the end user concerning how you will use their data, and with whom it will be shared. Unauthorized use of end users’ personal information or email addresses will be subject to immediate revocation of your Client ID.”

“End user information: Where an Authorized Application seeks permission from an end user to access Personal Information (as defined in the Microsoft Online Privacy Statement) from Microsoft Services, the Authorized Application must provide a link to http://consent.live.com/manageconsent.aspx, or such other location as we may specify from time to time, with a clear indication that end users can go to that Microsoft site to revoke such permission at any time. If end users must take additional steps to disable the Authorized Application’s access to end user information, then the Authorized Application must clearly indicate to end users the additional steps required to disable access. These requirements do not apply where Microsoft provides the end user interface.”

Live Connect Terms of Use (2/2012) Section 3(a)(iv) and Section 6

EMAIL OPT-IN/SPAM

Windows Live – LiveConnect (not a review of Messenger Connect or any social login outside of LiveConnect terms)

There is nothing explicitly stated in the LiveConnect Terms