I received an e-mail from Facebook that i need to include a privacy policy in my Facebook tab. I thought privacy policy's were only needed in Facebook Apps.
Were can i find an example of a privacy policy?
Simply put, the reason for Facebook's strict requirements are mostly because of them wanting to demonstrate that they do everything to educate their users "we told the user to have a privacy policy". Therefore you receiving that email may not necessarily be related to you doing anything related to privacy.
In theory it's still possible to gather data from a tab/page with input forms.
iubenda has been specialising in this kind of problem with a dedicated privacy policy generator for Facebook apps and a hosting service for privacy policies built in: http://iubenda.com/facebook/
There's also a basic free version to be had for the general privacy policy here http://iubenda.com (edit: I haven't pointed out that the free version only works for web policies, as commented on by one user)
(disclosure: I work with the iubenda team to keep this being the best possible tool out there)
I would recommending using http://termsfeed.com/free/privacy-policy-generator
in preference to http://www.freeprivacypolicy.com/free-privacy-policy-generator.php since the latter has a terms of use that includes:
Permission is granted ... for the sole purpose of placing an order with FreePrivacyPolicy.com or purchasing FreePrivacyPolicy.com products. Any other use, ... is strictly prohibited, unless authorized by FreePrivacyPolicy.com.
Sorry I couldn't send a link to their terms of use, it appeared as a javascript popup, at the end of their wizard questionaire.
http://www.generateprivacypolicy.com/
I use this to create a privacy policy for just several seconds.
I got the same mail aswell and I don't really understand why. I used this one to create it: http://www.freeprivacypolicy.com/free-privacy-policy-generator.php
Do you gather any data (forms, etc.) from that particular tab? They may simply have changed the requirements.
You should try to re-write any privacy policy depending the type of data you gather (or not).
You can also use the following from Termsfeed (free generator): http://termsfeed.com/free/privacy-policy-generator
Simple Facebook features like Page Plugin (which used to be called Tabs) do not require a Privacy Policy or TOS. The essential fact I found when when trying to work this out was in the FAQ. You don't need an "app," or even a developer account. https://developers.facebook.com/docs/plugins/faqs says it. That means you don't need an app Privacy Policy or TOS.
A problem arises when you are logged in as a developer and click "Get code" in the wizard at https://developers.facebook.com/docs/plugins/page-plugin/. It gives you the developer version of the javascript SDK. It has the line js.src = 'https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.12&appId=...&autoLogAppEvents=1', with your most recent appId filled in.
The workaround is to log out of Facebook before using the wizard. Then you will get the correct code which does not require Privacy/TOS: js.src = 'https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.12'.
I found an excellent one (which even generates and hosts your privacy policy) here by privatychoice.org
Related
i'm developing a tumblr theme that hinges a lot on the user being able to add redirect pages, but when you create a new tumblr account that option is unavailable at first. the only official word on this that i can get is:
"In order to prevent spam and other types of abuse on Tumblr, that
feature is locked on new accounts. After you’ve used the account for
awhile to do things like following other blogs and choosing your
blog’s appearance, the feature will be unlocked so you can use it. We
apologize for the inconvenience."
i understand why they are purposefully vague but i need to know so i can tell clients what to do in order to use my theme!
anyone know what it takes?
My app is a sync solution (imagine dropbox).
The user needs to sign in to access the app's features, and if he does not have any account already created, he can sign up.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
but Apple has rejected this app saying:
17.2: Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected
We found that your app requires customers to register with personal information to access non-account-based features, which is not in compliance with the App Store Review Guidelines.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user. User registration that requires the sharing of personal information must be optional or tied to account-specific functionality. Additionally, the requested information must be relevant to the features.
Although guideline 11.6 of the App Store Review Guidelines requires an application to make subscription content available to all the iOS devices owned by a single user, it is not appropriate to force user registration to meet this requirement; such user registration must be made optional.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Please help me solve this. Many apps like dropbox/facebook require login.
I don't get the exact reason why they rejected my app.
Also, please guide about the in app purchase, why registering cannot be mandatory
Asked App Store Review people for clarification on their rejection.
They accepted it. and the app got approved :D
Its on Appstore now :)
I also Faced this kind of Problem and my app also Rejected due to this.And Again I Changed my App flow Like User Registration will be Optional. User can See all the Feature of the app with out Registration by skipping this step.If he want to do something user-specific then you can ask to register such as : (user like,comment,photo upload etc) or else he can use the contents and features which are public.
in Case of in-app Purchase You can Prompt user that if He will Register with your app he can able to use this Content in his all devices.
It would be appropriate to make it clear to the user that registering will enable them to access the content from any of their iOS devices, and to provide them a way to register at any time, if they wish to later extend access to additional iOS devices
Apple does not allow apps that require you to share person information to work, like an e-mail address.
You options are, remove the need for an e-mail address or remove account creation form you app and move it to a website.
It also states that you app is asking to create an account to access the full app and even needs the account or acces features that do not require the user to have an account. You can make those features available with out the account creating you might be able to get thru the review.
The reason apps like Facebook and Dropbox got thru the review proces is because they don't have a register option which is in app only. They redirect to a website.
I recently spoke to an Apple Rep over the phone in regards to an app of mine that was also accused of violating clause 17.2.
I explained to him that the email would be used for password recovery, monitoring transactions within the marketplace, and managing any inappropriate behavior (such as users uploading offensive or copyrighted content). The rep responded, "Sir, the clause states 'Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected'. I cannot allow you to require your users to submit their emails if its not account-based". He did not seem to understand that the emails are account-based for the very sole purpose of security.
I did mention to him that Instagram and Facebook alike require logins at startup. He simply replied, "Yes but those apps are entirely account-based."
Honestly, I felt he was blindly following Apple's Guidelines ("Because that's what it says we must strictly follow!"). He had little understanding of how social networking apps operate, and even less understanding of the law (specifically the DMCA - on a separate issue). Explaining to them how all that works proves to be futile; they wont budge because they are asked to follow Apple's BROAD Clauses as strictly as they do.
My conclusion: I had to compromise the app's user flow such that the app's registration page can be skipped, and all other functions within its marketplace were locked to non-registered users. It makes no sense.
The sign up asks for email id verification, and this email id is also used if the user has forgotten his password to send him one.
Apps cannot require user registration prior to allowing access to app features and content that are not associated specifically to the user.
It seems to me that the point is that you are asking the user to provide his email address as a step towards the creation of a user account. This is different from what dropbox and other apps do (i.e, you provide your credentials for your dropbox account, which is different from your email address, although it can be the same).
You may either remove altogether email verification, or you could postpone it to a later point when you have made clear to the user that this is required to access private information.
I got the same thing last week and this is Apple's reply:
As for the 17.2 issue, a nickname, avatar, or sharing are not inherent or specific features of those social networks, and thus, the user should not be required to register with those services, or provide you with access to their social network accounts. The user should not be prevented from using your app and service if they do not provide this information.
Instead, it would be appropriate use your own authentication method and give users the option to create a nickname and upload an avatar, independent from those networks.
Moreover, we realize that these social networks may be very popular. However, the popularity of the social network is not an appropriate reason to force a user who has not, or chose not to register and provide their personal information to those services, before they can use your app.
Therefore, we ask that you to include your own authentication mechanism to allow the user the option to register only with you, creating an account with only the information needed and relevant to your app's features.
Best regards,
App Store Review
So in short, you have to provide custom authentication and not just use Facebook. Although I've seen many Apps who do require you to login with Facebook.
Thanks,
James
It happened same for me, although the first version was approved, the second version was rejected for this reason, I added the Skip button at the landing view.
It's all summarized in the last paragraph. Apparently, your application doesn't inform the user (in a clear way) that registering is for syncing and from their reply, it seems that your application is useless without the Sign Up.
If that's the case, you should be more specific why you need the user to register.
On a side note, I personally don't like the applications/websites that force you to register before you see or try anything. I hope your application isn't the same.
I've been storming the internet for information on how to obtain "credit_balance" from Facebook user.
To get user credit_balance, I'm using: Facebook Credits - Getting error code 13 when trying to get credit balance
I'm aware of the fact that you have to use "application access_token" instead of user's one (I've been trying both tokens lately just to be sure).
And I'm fully aware of multiple posts which are saying that getting "credit_balance" is whitelisted feature.
So my conclusion is, that our app has not been whitelisted yet, that's why I'm receiving "Exception: 13: The underlying FQL query made by this API call has encountered the following error: credit_balance is not a member of the user table." exceptions ... so it should be end of story ... but, one of the Facebook officials told me, that "credit_balance" IS NOT whitelisted feature. Now I'm confused...
My two questions:
(1)
So where the truth lies? Please, can someone confirm or refute whether "obtaining credit_balance" from Facebook is whitelisted feature and that I have to undergone the whitelisting procedure which begins with filling the form here: https://www.facebook.com/help/contact_us.php?id=157379954315015
And then wait for the eternity to get whitelisted (obviously, we've already asked to get whitelisted...). (I'm also aware of fact that after whitelisting you have to re-authenticate your users, done that as well, still no luck.)
(2)
Also is there any chance how to check whether my application is whitelisted?
Thank you in advance
Jakub
Finally, an official answer. Our application has been whitelisted for: frictionless payments, get_balance (== get_credits == credit_balance), and gamer_status.
So if anybody has problem with "getting number of facebook credits", be sure you are whitelisted first.
Facebook whitelisted us after about 1.5month, so you should apply for "whitelisting" as soon as you start your project + you should be kicking (with all respect) Facebook to reply you as soon as possible.
Jakub
I don't know the specific answer to your question, but I know that the Facebook API keeps changing rapidly, and so many of the posts/guides on the internet are outdated.
Also, a quick look on the official Facebook credit API page yields the following:
This whitelisted feature is an API call that allows an application to
determine a user's balance. It is only available to developers who
have designated Credits as their in-game currency. You can apply here.
Please Note: This feature is currently only available through the old
PHP SDK. You also must re-authenticate the user after whitelisting,
before making the function call.
Perhaps the note is relevant to you?
We want to streamline the user registration and login process. The goal is to reduce the time and effort for users to register and login to our site.
At the same time, we don't want to overwhelm users with choices. We don't like how some web sites present registration/login options via multiple channels (e.g., Facebook, Twitter).
What are the pros/cons of each of these systems? Which do you use, and what are your main gripes?
Offer all of them, don't take the time to ask "why?".
It's always worth it to get users on board.
The biggest (IMO) pro is that you are no longer storing passwords in your db. Leveraging one of those other site's authentication service relieves you of this. It doesn't relieve you of having a secure design. I'm also not sure that your average end user really cares. If your service is highly aligned with one of those services, maybe. However, if you are not targetting those end-users, then probably not.
Rob Conery did a recent write up of his experience with OpenId. This might be a good read:
http://blog.wekeroad.com/thoughts/open-id-is-a-party-that-happened
Hope this helps.
Bob
Well, yes, it does all depend on your user audience.
In any case, I would say that Facebook Connect is probably your best bet due to the sheer number of people using Facebook. Still, as far as I've noticed, it's not really "professional" websites that use Facebook Connect, mostly forums and unofficial (but popular) news blogs.
Many "professional" websites (catering to... well, professionals) will use a normal Register/Login rather than Twitter, Facebook, or OpenID. Still, a professional website would likely need a more professional solution, so I would suggest OpenID, which also supports websites such as Yahoo! Mail and developer communities (such as Stack Overflow!). You can see the full list of sites here.
In all honesty, I don't really think that using a Twitter login would be very efficient. Think of it this way: for one, I've noticed (but I could be wrong) that Twitter is mainly used by the small hobbyist or the people who use it to give updates on things they're doing or making (and sometimes just the people who want to be in on the times). So unless your website is aimed at these type of people, it wouldn't really be useful. On top of that, I don't know of many people who particularly like it, partially because of its over-popularity. Still, it could be the same way with Facebook, but this is all subjective, so if you really want to pick Twitter, go for it.
Anyway, that's my take on things. I don't personally use these systems on websites I've built, but I know how they work.
For one, when you log in using any of these for the first time, they take the user to a new page or open a popup window asking them to confirm if they want to connect their [Whatever] account to your [Website Name]. After that, it's a bit easier to use just because they don't have to keep repeating the process unless they disallow your website on their service.
With OpenID, you have to log in to your OpenID-enabled webpage using http://myusername.myopenid.com/ or myusername.myopenid.com. If they don't choose to remember their password, this can become a bit tedious to type in every time.
With Facebook Connect, it usually automatically connects all of their information to the website, including full name and profile picture (meaning that if they have a profile picture of that snazzy tattoo on their inner thigh, other users will be able to see that).
Finally, as far as I can see, Twitter doesn't do much other than connect whatever name you had on your profile page (if it's "John Doe" or "Weiner Schnitzel", it'll show on your website) and your profile picture, just like Facebook.
To finish up, those are pretty much all the pros and cons that I can tell about the services. Good luck!
What is your target group?
If you want that many normal people uses your application than use Facebook.
If there are many coder / blogger / internet junkies than use Twitter.
If you have a lot of open source guys than OpenID will do the job.
If i'm is not wrong, previously there is a website providing kinda service about providing login platform to allow user connect to your site. Of course it is not free and i was abandon it because of high annual fees and mind change after research being done.
While you using their service to growing your business or website, you can save their time it's true. but honestly, will they really care on how long time taken to connect their facebook with your website either register as a new member in your website. While you can give confidence to you client, they do. they willing to spent few minute to fill up simple information to make an account for them self if they felt they worth to spent the minute to get service from your website.
Totally agreed to what rcravens said, if they connect through third party website, means you are gonna giving you user information to that website. For example, to archive FACEBOOK CONNECT you will need to create an application for them to trust them you only can get authority to access. while they accept and login to your site, it is good for FREE advertise because while they connect, can use their account as medium to post your information to public. BUT mostly site will sell their information gather or share them in any way to some organization who need them for decision.
My point is, how many people using your site and mostly who is using, what characteristic of your site user and so on... everything is no more under your control !!!
Perhaps, you may use it but what if their service shut down few hour for maintainance...
I'd recommend using something like RPXNow (https://rpxnow.com/) or Gigya (http://www.gigya.com/) as an intermediary to the various authentication providers. Facebook and Twitter are notorious for always changing their APIs. It is a pain to keep up with them. These services give you a simple abstraction layer, so that you don't need to change anything on your end when the providers change their APIs.
i like facebook but..
facebook is block in some country.
open id is not famous.
twitter is famous and simple.
so use twitter is the best :)
Use OpenID as it is a standard that is also integrated into many Mail Accounts, like Google or Yahoo. You never know how long Facebook will stay around and therefore it's better to have something people just don't throw away (there Mail address). If you make a nice selection screen (e.g. stackoverflow), the people don't even know that they're using OpenID. If you just want to get authorized Comments, picture uploads for twitter or fb, a game connected with social features don't use it.
Facebook Connect is very usable for one time comments or stuff like this. If you want to store your own data about the user (e.g. blog service, saas), not dependend on "social networks" don't use it.
Twitter Login makes only sense if you connect your service with Twitter, otherwise forget about it.
I would use a hidden OpenID approach.
Facebook is great for keeping tabs on family and friends. Beyond that I, personally, wouldn't use it in support of any other app. It's just not bullet-proof enough from a security/malware standpoint. There is too great a chance someone could have issues of that sort with Facebook and attribute it to your site, whether reasonably so or not.
I like OpenID. Not thrilled with the notion of hitching my wagon to any of the social networking sites/services at all.
Is this a technical or commercial question?
The answer to my mind is it depends what you want to do with the data.
If you just want to provide a service to a broad list of people then the answer has to be to gun for openness, not proprietary - particularly since the open standard is supported elsewhere, Gmail, Yahoo et al.
However, if you want to demographically profile that database at some point to offer targeted services, then you need to understand the questions you're likely to require answered and whether a third party method is going to enable that or not.
Will Apple accept an application that requires a login to an online account the first time it boots? I'd like use this to link the user to an online highscores system for a game and for some analytic purposes.
Yes, there's many, many games that do this already. In fact when you submit your app for testing, there's an optional text field that lets you provide the test engineer with a pre-existing test account name & password.
I'm not sure I like the idea of requiring a login account. Optional logins are fine, but requiring such activity is too much of a hassle or privacy concern for some people.
As a consumer, I like having the option to opt out of signing into such services. I would recommend supporting your customers' prerogative to choose anonymity or privacy over the benefit of being eligible for the high score system.