My app needs the 'always' location permission. Apple complicated location permission options if apps ask for 'always' directly, so I started asking for 'while using' and then 'always'. This gives the user a first dialog, for 'while using', with buttons of 'Don't Allow' and 'Allow', which is great. However, I'd like the next dialog to have these same buttons (assuming they allow 'while using'), and I was getting this before my upgrade to iOS 11 Beta 5 (I'm not sure - I might have skipped a couple betas).
With iOS 11 Beta 5, I see complicated button text (like 'While using the app' and 'Always' instead of 'Don't Allow'/'Allow') EVEN IF the 'while using' permission is already granted.
I want to give users the simpler options. I think users read these permission dialogs about as often as they read EULAs, and that if it's not a simple allow/don't allow, most will just pick a random option instead of reading, and my app won't have the permission it needs.
Is this possible with the latest iOS 11 Beta? And will it be possible in the final iOS 11? I thought this was what Apple was suggesting - here's some advice (from https://m.rover.io/wwdc-2017-update-significant-updates-to-location-permissions-coming-with-ios-11-41f96001f87f):
For those seeking always permission levels, Apple is now recommending a new permission flow which is essentially a two-phased approach. The first phase or initial onboarding, should only ask for ‘when in use’ permissions...
The dialog stays the same for iOS 11.
With requestWhenInUseAuthorization() iOS will present these options:
If the user allowed location access while in use and you later ask to always access location with requestAlwaysAuthorization(), iOS will present these options. You are already getting the benefit here that Don't Allow Any Access is not offered:
If you ask for requestAlwaysAuthorization() right away before asking for requestWhenInUseAuthorization(), iOS will present these options:
So solve your problem, it is advisable to not just request the iOS dialogs but prepare the user with your own pre-dialog. Only request the iOS dialogs when you are sure that the user will accept. This will lower the chances that a user denies access this time, but maybe would have allowed access in other circumstances. Once the user denies, you cannot request the iOS dialogs anymore.
On a general note:
I think users read these permission dialogs about as often as they
read EULAs
Frankly said, that should not be the fundamental assumption on which we develop app workflows and govern user privacy.
Tech companies and the public discourse are increasingly focusing on user privacy. Giving choices is clearly not enough, part of the job is educating users that granting their location 24/7 to some possibly unknown hobby developer or a company in a country with unknown data protection laws is not the same as clicking Yes on an EULA. Also legal changes require that sharing of such sensitive information as your live location cannot be hidden somewhere in an EULA but must be explicitly opted-in by the user.
Thankfully the efforts of companies like Apple ensure responsible access to user data for developers to build great features. This can only be done by giving the choice to the users through conspicuous prompts like the one you are referring to. Because the alternative could be no data sharing or higher hurdles by law.
Update March 2018
To emphasize on the point made above: The recent lack of trust in tech regarding data privacy (Facebook & Cambridge Analytica) confirmed how important is it to understand the responsibility that comes with personal data. The result will be more external regulation - and rightly so. The conclusion for designing data access permission workflows can only be to inform and educate users and to transparently disclose what data is used for what purpose and give an easy to access option to un-share / delete data.
Update May 2018
With the European Union's General Data Protection Regulation (GDPR) coming into effect, it also became mandatory that you need to communicate information about how you process personal data in a way that’s concise, transparent, intelligible, easily accessible and in clear and plain language.
Related
I recently asked this question and user's #DalmTo and #Sergio NH they gave me an exhaustive answer for which I thank them very much.
Moving forward to question, we started publishing the application, and its verification was not required, since no scope was added (here it is a little unclear why the requests worked in an application with a test mode in which these scope were not added (google drive, google sheet and google ads)).
However, this time the application in the "In Production" mode began to give us an "Unverified app screen" (see Unverified app screen). We decided that we still need to add scope to the list, and, of course, that the scope list (their list is described above) requires verification by Google.
We started filling in the necessary fields, while studying the Google documentation at the same time, and came across the following information (see block Verification process -> What are the requirements for verification?):
Apps not applicable for verification
Apps for internal use only
(single domain use) Apps for personal use only Apps that are Gmail
SMTP plugins for WordPress Apps that are in development or
staging/testing
Apps for personal use only
And this is just our case: we have already received permission from Google Ads and are just generating simple reports that we want to integrate with Google Sheet. I.e., this is an elementary script that works within this account (however, we still need to request the first concert screen, even for this developer account) and cannot be distributed to any other accounts.
But when adding our scope, Google requires us to pass verification, forcing us to fill in the required fields, in the form of domains and their verification via the Search Console (we have already done this and this stage does not cause difficulties) and links to Youtube videos - where we must show how scope is used.
And just this stage is not clear. We do not allow other people's accounts to connect to this application, and the software does not have any interface, it is just a script that receives data from Google Ads and saves it to Google Sheet (creating a file via Google Drive). We have described all this in the scope usage description field. But the link to the Youtube video is require field, and we sincerely do not understand why (considering our case) we should record something, and most importantly, what exactly we should record in this case. If the documentation itself says that in our case we do not even need a verification.
Maybe we did not understand something and now we are doing it wrong? We will be glad to receive any tips from experts working with Google Cloud Console and apologize in advance for broken English.
We also apologize in advance to the StackOverflow community that we have to publish such elementary (which we are absolutely sure of from our side) questions here. We come here from Google Cloud Console - > Support - > Community support, and we must first try to publish posts in the Google Groups specified there, but they simply do not answer us, apparently considering our questions too elementary and not worthy of attention (however, these same questions in Google Groups are moderated) (for example, the previous question). And we are no longer able to contact any other support. Once again, we apologize for having to ask about this here.
It is true that if your app is a single use app then you do not need to be verified.
However if you don't get your app verified then there will be some restrictions.
you will see the unverified app screen
your refresh tokens will probably only be good for two weeks.
In the case of the YouTube api uploaded videos will be suck private.
If you can live with those points then you don't need to verify your app and you can continue as is.
If on the other hand you don't want to see the unverified app screen and you want a refresh token that will last longer then two weeks. You will need to verify your app. Yes, Even if your app is a console application running as a job some where you still show the consent screen. This is the YouTube video you will need to show Google. Show the consent screen popping up show the URL bar and then show your script running. You also need to set up the homepage and privacy policy screens. Yes i 100% agree with you that this is silly.
When you go though the process. Explain to google that this is a single use script running as a job some where.
Unfortunately when Google changed it so that Refresh tokens expire for unverified apps they pretty much tied the hands of all developers who are running such single user scripts. We now have to get our apps verified if we don't want to have to request a new refresh token every two weeks.
If your program needs to access the requested scopes of the Google account privacy, even though the user is yourself, you also need to provide a youtube video to demonstrate how you use this program. The auditor cannot guarantee whether you will make this program public.
On the submission properties tab on my UWP application, I cannot select "No" for the "Does this product access, collect, or transmit personal information (data that could be used to identify a person)?" question.
It is saying "Based on the capabilities your submission declares, a privacy policy URL is required."
I have reviewed my capabilities (which is empty), and I am not using any personal information on my application.
If the internetCapability is enabled, you will be required to provide a privacy policy, as your app could theoretically send any personal data over the internet.
You can easily generate a privacy policy with a tool like this.
Although #Martin's response is technically correct, it's incomplete.
Because you are submitting a Desktop Bridge app (with runFullTrust capability) your app has access to essentially everything the user has access to, and thus internetClient is redundant (unless you also have UWP components like a background task). According to the Store product page, your app has access to "all system resources" so in your privacy policy you might want to mention more than just network usage - you could mention that you don't collect or use any personal data, won't read files or access the microphone or the camera or location etc. I don't believe that's required, but it might make customers feel better.
(Note that the Store text might change to something more descriptive in the future).
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.
I know that iOS 4 and 5 do not allow the access of a user's phone number since its outside the sandbox of an application (if it needs to be accepted by apple).
I would like to know whether this has changed in iOS 7 - with permissions whether it can be accessed etc.
Thanks in advance.
No. Apple APIs do not provide access to this information. What's more, attempting to get this information without asking the user is generally considered a huge breach of privacy.
"For security reasons, iPhone OS restricts an application (including its preferences and data) to a unique location in the file system. This restriction is part of the security feature known as the application's "sandbox." The sandbox is a set of fine-grained controls limiting an application's access to files, preferences, network resources, hardware, and so on."
The device's phone number is not available within your application's container.
please find apple response in this link apple response
i found some thing interesting here this
thanks
I was wondering if anyone has any experience of submitting location-specific apps to the Apple App store.
What I mean by location-specific is an app that only works when you are at a particular location. For example, a GPS tour of a historical battleground might have content that is triggered at particular lat/long coordinates when the user is at the actual physical location.
So my question is: In order to make the app be likely to be accepted on the app store do I..
(1) Not worry about it as there's evidence that the Apple Reviewers have some way of simulating the GPS. I can then supply lat/long coords to the reviewers so they can experience some of the content.
or (I suspect more likely)
(2) I Need to make it work anywhere in order for the reviewer to see at least some of the content (e.g. have a menu or map interface that allows direct access). This could be a 'secret' option explained in the review notes accessed via a special key combination or something.
Has anyone else run into a situation like this?
Regards,
Ben
Edit: Thanks for the responses. My app has now been accepted by Apple. Interestingly I didn't need to make the app work anywhere or add any new methods of using the app at all, they simply asked me for a video of the app in action. I made a YouTube video of the app (unlisted of course) and sent it to the reviewers.. and now it's accepted! I was very surprised that this is how it worked out!
I asked this same question (and answered it myself) a while back. I basically added a "Drop Pin" feature so the testers (and users) could pretend to be somewhere else.
I submitted an app recently that "works anywhere" (and uses GPS) but "works best" in New England when looking for data (on our server) that is near your current location. The app also supports entering a city & state or zip code to perform searches. So, in the submission, you can tell the reviewers how to test it, and we explained the nature of the app and how to test the functionality by using specific New England locations. The app was approved, for what it's worth.
Basically, when you submit an app, there is an opportunity to give the reviewers guidance. So definitely tell them what they need to know to make your app work for them, wherever they might be in the world! :-)