Google said Intellectual Property is very important. But for example, if I search "Among Us" there are like Among Us wallpaper, Among Us chatting (1m downloads), Among Us Tic Tac Toe and so on. I don't think none of them get the permission from Among Us company. How come Google play approved those apps?
I read many developers got experience of being closed their accounts for different reasons including against IP. So first they approved easily, and then randomly they close people's accounts that were against IP? or Google Play will stop these apps when Among Us claims?
when it comes to intellectual property google doesn't take any action regarding your apps , unless the rightful owner files a copyright claim. that's why the app gets accepted and after a while it might get suspended if the owner files a copyright claim against your app and the right resources to prove his case, you might be contacted by playstore with an email of app removal and the cause of it. so if a i create an app called "Facebook profile pictures" i can easily upload it and it stays live on the store in case Facebook didn't take actions against my app
Related
I have written an app which notifies users when someone make them unfollow (As like as any other apps in this area). Then, I got my app approved by Instagram. After six/seven attempts, they don't approve the app till now. I followed their instructions as feedback and fixed any probable privacy problem which my app might have. But I didn't get any bright answer from them as far.
I throw my app on the following use case:
My product helps brands and advertisers understand, manage their
audience and media rights.
And I wrote my API use cases as follows:
Thank you for considering our request to approve our application. The
required information for enabling live mode for our application is
explained in the following lines:
Q1: How your app does use the Instagram API?
First of all, our user (i.e. brands or advertisers) selects the “Unfollow Finder Service” on our application.
We redirect the user to Instagram login page, as indicated in API documentation, to authorize his account to accessing required scopes.
i. Note that we already told the user everything that we are going to
use.
We tend to call follow APIs whenever the authorized user clicks a button in our application.
Ultimately, we inform the authorized user with the information obtained from step 3.
Q2: How does it fall into one of the approved use cases?
The list of users who recently unfollowed/followed an
Instagram account are definitely crucial and beneficial for the brands
and advertisers on Instagram. In this way, they can get feedback
implicitly from their customers. Our service help them to manage their
audiences and provide better content for them. So, according to Q1,
our use case falls into “My product helps brands and advertisers
understand, manage their audience and media rights.” We never violate
the approved scopes and Instagram's privacy.
Q3: Who will be using your app?
In our region, lots of brands and businesses utilize
Instagram to publish their content. They are the users of our service
and can use it to improve their relation with their audiences. Kind
regards,
As you see, I'm trying to tell them everything in detail. But in my last submission, they declined me with the following feedback:
General issues:
Policy Violation ("Like", "Follow", "Comment" Exchange Program): Your
app shouldn't participate, enable or promote any “like”, “share”,
“comment” or “follower” exchange programs. In working to build a high
quality platform experience, we ask that you comply with our Platform
Policy (http://wwww.instagram.com/about/legal/terms/api/).
I just want permission on follower_list scope from them. The surprising part is that they noted me with almost irrelevant feedback. It seems that they do not want to approve my app at all.
Do I violate their privacy?
Does anyone face this problem? How can I fix it and had my app approved?
Sorry for asking this question here since I almost googled entire web (+Stackoverflow) and find no helpful answer. All of my previous attempts were gone away.
Thanks in advance.
I am trying to install an app from Google Play store and I see Device & app history permission.
does anyone know what android permission in manifest causes "Device & app history" permission?
Device & app history
Allows the app to view one or more of: information about activity on the device, which apps are running, browsing history and bookmarks
OK, after researching about this mysteries Android permissions, I got my answer from Adam P. in Android Communities. Thanks Adam.
If you look at the picture below, you will see a description for Device & app history permission for an Android app. At first, this permission description sounds really bad. If you don't know the reasoning behind why all those 3 permissions listed under one group, you would think that this app is really accessing your list of apps, your browsing history and bookmarks. WOW! what a scary thing!
We all know that Google's Android permission system is really broken. From the non tech-savvy people's point of view, this message will scare them and they may not even install your app. Simply, this message on the permission dialog is misleading. Why? actually this sample app needs "retrieve running apps" permission only.
Now, if you pay attention to the message, it reads "one or more of:". What do you mean by "one or more of:"?
Why can't you just display it in a simple format instead of confusing users?
Lesson learned: apparently, one permission from that group is enough to trigger to show that message shown in #1.
Here are the permissions under Device & app history group permission:
Read sensitive log data (android.permission.READ_LOGS)
Retrieve system internal state (android.permission.DUMP)
Read your web bookmarks and history (com.android.browser.permission.READ_HISTORY_BOOKMARKS)
Retrieve running apps (android.permission.GET_TASKS)
Now, if you close the dialog shown on #1 screenshot and then scroll down on the Google Play Store app, you will see a text link reads "View details" shown on #2 screenshot. Click that to see a little bit different version of these permissions. By the way, this link is hidden down in the page and I wonder how many users find that link.
This is what I like. It's clear and concise. Whereas in #1 screenshot, you need to be a linguistic teacher to understand what Google's copyeditors' message mean. Obviously, the first permission dialog in #1 confused me.
OK, this is an extra bonus for you to get confused even more. This sample app apparently requires your phone number to create an account. Nowadays, a lot of social apps started doing that.
Now, if you hold down your app's launcher icon and drag onto App Info button, you will go to your app's details section. Suddenly, you will see this yellow scary message reads "this may cost you money". Well, I know this app does not make a call at all. It just used your phone number to register an account. Google, is it fair to scare people off with that message when the app doesn't really do that?
Conclusion:
Lesson learned; the group permission can be triggered by one permission within and that can cause to show those scary messages.
I am still waiting for the day that Google changes these permissions system. Instead of asking me Yes or No question before installing, I would like to customize the app permissions while I am installing.
Wouldn't it be nice if you check/uncheck each permission and install the app? And, you can turn on more permissions in the app's settings view if necessary. By the way, App Ops won't help with that much.
some more info at: https://support.google.com/googleplay/answer/6014972?hl=en
You're leaving out an essential point concerning these permissions groups. According to Google's Review app permissions (your source) it states the following:
Permissions groups
Permissions groups are designed to show what an app will be able to
access on your device. With permissions groups, you can quickly see
what capabilities or information an app may use before downloading it.
Also, you can review individual permissions at any time using the
Google Play Store Play Store app.
It's a good idea to review permissions groups before downloading an
app. Once you've allowed an app to access a permissions group, the app
may use any of the individual permissions that are part of that group.
You won't need to manually approve individual permissions updates that
belong to a permissions group you've already accepted.
I got an app on my phone that I wanted to update today and noticed that it now asks for access to the Device & app history permission group. As you suggested, the drill down via the Permissions details shows that in reality, it is only requiring the 'retrieve running apps' permission. Great! .. you might think ... but NOT!
If I proceed and accept this now in good faith that I'm OK for this app to see what apps I got running, a subsequent update of this app is NOT going to ask again for access to the Device & app history permission group if they ADD another permission from this same permission group. In other words, today I approve this, granting access to Retrieve running apps (android.permission.GET_TASKS), but as a consequence of that I will not get a new approval request if a next app update adds any of these permissions:
Read sensitive log data (android.permission.READ_LOGS)
Retrieve system internal state (android.permission.DUMP)
Read your web bookmarks and history (com.android.browser.permission.READ_HISTORY_BOOKMARKS)
My conclusion is that if the developers of this app decides they want to obtain eg. my browser history for whatever reason (ads?), they can just add the com.android.browser.permission.READ_HISTORY_BOOKMARKS to their app and I will not be notified when it automatically updates since I have already granted the Device & app history permission group.
Device & app history
Allows the app to view one or more of: information about activity on the device, which apps are running, browsing history and bookmarks
I am developing an app for iOS. I am planning to publish this app in app-store as free app. I would like to authorize app users via outside RESTful webservice. Is this practice against any Apple official guidelines and can be not approved by Apple app review?
The Apple Review Guidelines 11.1 states:
Apps that unlock or enable additional features or functionality with
mechanisms other than the App Store will be rejected.
It sounds clear, but I believe it is open to interpretation on behalf of their reviewers. My company has produced an app exactly as you describe and it not only passed but has been versioned up very recently. Like yours, this app consumes a web service and while the launch screen is public facing, the user must immediately authenticate on the screen after that to go any further.
Our app was not a good candidate for the enterprise store model, since the intention is to distribute to customers, not employees.
Also, and perhaps most telling, when you prepare to upload your binary the iTunes Connect portal has a place for you to enter demo account credentials for the testers to access protected content in your app. So I think you're OK. Screencap below taken from iTunes Connect.
UPDATE
Apparently, when submitting your app you can provide demo account information (#erikr98), implying that an app like yours could be tested by Apple and be approved in the store. I've seen apps like this and worked on them before, but was under the impression that you also had to provide some sort of functionality in the app outside of your "pay wall."
....
I think the answer is maybe. It sounds like you're hovering the line between a public app and an enterprise app. I'm going to assume your question could be rephrased like this:
"I make money from my customers through an existing process (probably on the web) and I want to allow them to use that functionality on iOS without giving 1/3 of that money to Apple via a paid-app or through In-App Purchase. If I build a free app and provide my current customers access to its content via their existing accounts (and through a login process) will Apple reject it?"
Apple's App Store Review Guidelines, Section 11, clearly states that if you allow users to upgrade the content, unlock features or abilities, or purchase content through your application, that purchase must be done through In-App Purchase.
However, in my experience I have found that Apple will not reject an application if it provides value to everyone, not just those with an account. If you provide some sort of benefit for someone without an account you stand a much better chance. In my case we had, 5 features available to the people without an account, and 10 features available for those that could login. Our app was approved and released to the App Store. This was last year.
Also, think about this from a reviewer's perspective at Apple: When you sit down to review an app, its probably not a good sign that you can't access any part of the app without a user name and password.
Look at the model that the newspapers use. Washington Post, for example, has a free app with a $15 In-App purchase that provides you access to their content. You get a limited number of free articles, first, though. See, they provide content for everyone even if on a limited basis. You can also sign into the application, which unlocks all content, if you already have a paying account.
My Passbook-related app was recently rejected based on guideline 23.3:
23.3: Passes must be signed by the entity that will be distributing the pass under its own name, trademark, or brand or the app will be rejected and Passbook credentials may be revoked
I had a few questions and got on the phone with someone at Apple. They told me that to remedy my problem I could create a sign-up form in my application. This sign-up form could then be used to create a certificate and pass type ID for the user based on their credentials. However, I've been combing through the documentation and I've not found anything that allows people to create Pass Type IDs or Certificates without at paid developer membership. Is this correct, would my users need a paid developer membership to create their own Pass Type IDs?
If they don't, is it even possible to create a PassType ID at runtime? For example, using the information in the sign-up form I might make an API request with PassKit / some kind of Passbook server to create a Pass Type ID:
PassID *ID = [PassKit createIDWithName:#"USER_INFO"];
Is there anything like that or was the Apple technician talking about something else?
would my users need a paid developer membership to create their own
Pass Type IDs
As crazy as this sounds - yes! The only way of fully satisfying this guideline is to pay the Apple Tax and sign up as a Developer. There are several long threads in the Apple Developer Forums talking about the reasoning and implications of this. While it is not popular, the majority of us concede there are very good reasons for this, that in the long term, will protect the integrity of the platform (as well as keep the Apple lawyers happy in the short term).
The main reasoning is because in most jurisdictions; coupons, tickets, travel documents and other typical Passbook content create a binding obligation upon the issuer. Legally, in the event of non-fulfilment, the pass issuer is liable to the consumer. In order to protect themselves, Apple needs to ensure that under no circumstances, could they be deemed as the issuer of any Passbook pass.
The Apple Developer programme registration validates the identity of any individual or corporation who is accepted. It also forces Developers to sign the terms of the Developer Agreement which has an entire attachment dedicated to what you can and cannot do with Passbook and with your PassID certificate. This provides Apple with enough legal protection against any claims for unfulfilled goods or services relating to any Passbook pass.
While there has been a lot of pushback and calls for a faster, less US centric process (you would not believe how difficult it is to get a DUNS number for an small entity outside of the US), I don't expect this to change any time soon.
As for auto provisioning. Myself and the creators of the other major Passbook platforms have been calling for this since before iOS6 was launched. I have an open radar dated 7th August requesting a simple API to issue and revoke Pass Type ID certificates. I'm intrigued as to what your Apple Technician was referring to since as far as I am aware, there is no such service.
// rant
What is frustrating about this is that there are a number of approved Apps that allow full pass customisation but issue the passes under the App developer's certificate.
Apple also seem to turning a blind eye to certain services that issue passes under their own certificate that bear the logo and trademark of major brands (and then have the audacity to call on these brands to 'claim their passes').
Even Passtools (now Urban Airship) claim to offer a 'Unique Apple Developer Certificate from PassTools', which technically would be in violation of the Apple Developer Agreement.
So the bottom line is that on this occasion, you may have just been unlucky.
// end rant
I'm not sure what the technician was talking about, but 23.3 refers to a server (likely yours) going through a signing process with the pass before sending the pkpass file to a device.
For high level information, review the "signing and compressing the pass" section of the passbook programming guide.
So I'm in the midst of creating a Facebook Connect enabled site. The site in question will leverage your social graph - as defined by your facebook account - to do social things (what is really not important here). Here's the big question I have:
Are people still rolling their own authentication heuristic when using something like Facebook Connect? That is, are newer (FBConnect) sites today providing only FBConnect as an authentication strategy, or are they pairing it with other auth strategies (such as Google Auth, Open ID, etc)? What do you think is the best way to go? With Facebook having over 300,000,000 users now, is having 1 authentication strategy (FBConnect) enough? Or is it proper netiquette to provide users other means?
Some of the references I have been looking at today:
http://www.kenburbary.com/2009/08/five-reasons-companies-should-be-integrating-social-media-with-facebook-connect/
Increased Registration - Data from Facebook states that sites that use Facebook Conect as an alternate to account registration have seen a 30-300% increase in registration on their sites.
• Citysearch.com – Daily site registrations have tripled in the 4 months since Facebook Connect testing began
• Huffingtonpost.com – Since integrating with Facebook Connect, more than 33% of their new commentor registrations come through Facebook
• Cbsinsider.com – Over 85% of all new user registrations are coming from Facebook Connect
http://www.simtechnologies.net/facebook-connect-integration.php
"according to the current statistics using facebook connect increases 30-40% user traffic as compared to non-facebook connect websites."
http://wiki.developers.facebook.com/index.php/Connect/Authentication_and_Authorization
Our research has shown that sites that implement Facebook Connect see user registration rates increase by 30 - 200%.
No Need to Create Separate Accounts
In general, it's not a good practice to force a new user to create a separate account when registering on your site with Facebook Connect. You'll have the user's Facebook account information, and can create a unique identifier on your system for that user.
Just make sure you understand what Facebook user data you can store, or simply cache for 24 hours. See Storable Information for details.
If the user ever deactivates his or her Facebook account, you have a chance to contact the user to request the user create a new account on your site. When a user deactivates his or her account, we ping your account reclamation URL to notify you of the deactivation. Then Facebook sends the user an email regarding the deactivation. If the user has connected accounts with any Facebook Connect sites, and if your site has specified an account reclamation URL, the email will contain a section with your application logo, name, and reclamation link, in addition to an explanation about the link's purpose. For more information, see Reclaiming Accounts.
http://www.chrisbrogan.com/how-facebook-connect-points-the-way-towards-velvet-rope-networks/
The Drawbacks
Though there are advantages to using Facebook Connect for integration, there are some drawbacks, mostly from the marketer’s point of view. If you build out a social network project using Facebook Connect, Facebook gets all the information and you get none. You don’t get a database of users. You don’t get a way to message people participating in your event, except for “in stream,” the way everyone else is using the app. You don’t have any sense of demographics, nor any control abilities to block trolls or other unwanted types.
Crystal Beasley "All of the FB Connect sites we have built so far have incorporated "standard" accounts as well, even with the added complexity of supporting dual login methods."
There are still people who use mySpace (myself not included), and I know a several people coming out of college that have completely deleted their FB accounts to get rid of information of them they don't want potential employers to find (I know, there are a lot easier ways of doing this). If there are people who for whatever reason do not want to have a FB account, at least give them the option of creating a private google account.
Using ONLY Facebook as the register/login-method seems pretty dangerous to me. If you had a regular user management system, with Facebook Connect to speed up the process from a user-perspective is a good idea.
The Problem is somewhere else
if you really want to leverage the social graph only facebook brings "pure" data
the graphs people build at e.g. myspace arent telling much about that person and its social env. - at google neither
if you are just heading for viral spreading prefer the plattforms that share the best (just facebook again)