Blog

Android M and Privacy: Giving Users Control over App Permissions

Android M promises to deliver several new user-control features built to advance transparency, choice, and predictability. The new App Permissions system allows users to select permissions specific to each app and device feature. The granular system requires apps to request user permissions individually as the features are needed, opposed to the former all-or-nothing prompt at install. Once installed, users can modify the app’s access to device features at any time.

App Permissions simplifies the device-feature access, while providing greater user control.
Android M’s App Permissions model creates eight controllable device-feature groups: Calendar, Camera, Contacts, Location, Microphone, Phone, SMS, and Sensors. Access to each of these features may be selectively denied at the user’s leisure throughout the lifecycle of the app. Lower risk permissions, such as access to the alarm clock and internet, are automatically granted to a requesting app at install. Users can still review these permissions prior to installing, but the current build hides these permissions later.

How to adjust your apps’ permissions.
The Android M Preview build provides users with two methods of accessing and changing permissions to the eight permission groups. First, users can access all permissions that an app has sought by selecting Settings => Apps => [The App] => Permissions. Second, users can view all apps that have sought permissions based on the eight feature categories by selecting Settings => Apps => [3-Dot Menu] => Advanced => App permissions. Whether a user is concerned with the permissions of a specific app or for a distinct device feature, the two methods of access give users a quick and clear means to modify either. Furthermore, users will still have separate access to location requests made by apps via the Settings page.

Users can limit access to the features they want.
Google will no longer allow developers to present users with an all-or-nothing list of permissions. This will address the issue of apps seeking permission for device features unnecessary to the app’s operation, forcing users into undesired permissions if they accept the app. By giving individual-feature choices, users can opt-in to only the permissions – and the associated functionality – that they desire. And the full list of permissions that each app seeks will still be available to users before downloading.

Developers are encouraged to prove the value for users granting apps permissions.
Once an app is installed, users will be able to modify their permission preferences at any time. Permissions may be granted initially. But failing to provide users with an immediate return on investment for their data will lead many to adjust their settings accordingly. At-will modifications provide users with a workaround for use-specific access. For rarely needed features, users can allow access to device features only when they need them.

Developers are rewarded for disclosing the purpose of the app’s feature request.
The Android M permissions model incentivizes developers to explain their reasons for requesting permission to use features. When an app seeks permission to use a feature for the first time, users will be prompted with a choice to allow or deny access. If the user denies access, developers are allowed an opportunity to explain their reasons for seeking access. On the second request for access, the user will be additionally offered the choice “never ask again.” Because users can opt-out of repeated requests, Android M blocks the app from irritating users into submission. Developers must convince users of the permission’s necessity or lose access to the feature.

User decisions are respected by increasing the difficulty of hassling them to change their settings.
Once the user stops future requests, apps will be prohibited from directly linking the user to the app’s permissions. While it may increase the difficulty of adjusting the permission settings, Google took this affirmative step to keep apps from repeatedly questioning the user’s privacy decisions.

Apps should not request permission for one-off features.
Often, apps only need to use a device feature sparingly. But the all-or-nothing model lacked sufficient deterrence to developers seeking unlimited access for these one-off features. Users would have to weigh their concern for this granting disproportionate access against the entire value of the app. Now, not only can users disable access when these one-off features are not in use, but Google provides a simple solution for developers seeking this type of access. Instead of requesting permission for the app to use a feature, the developer can direct the user to an app that has permission and retrieve the information from there. This method gives the user peace of mind and promotes transparency and trust in the app developer, because users know that the app does not seek unlimited access to features which are rarely used.

Users can opt-out of specific permissions for older apps.
Despite early reports to the contrary, App Permissions will give users the same access and choice to device features for apps built using older Android platforms. Because these apps lack the framework to handle granular permissions, Google has chosen to send blocked requests an empty set. Thus, an app seeking contacts from a user who has denied this permission will display that the user has no contacts. While not the cleanest method for handling a denial, retroactively applying granular permissions will encourage developers to embrace the new selective-privacy system.

Summary
In line with Google’s recently announced redesign of their accounts-page privacy settings, Android M creates a simpler and more transparent interface for user control of private information. The feature-specific opt-in approach of the new App Permissions model will provide users with greater transparency, protection, and control over their personal information.
For iOS app permissions, see our post, iOS 8 and Privacy: Major New Privacy Features. Information for developers is also available at our Application Privacy hub.

Local Search Association and Future of Privacy Forum release a simple and concise primer that explains how the Bluetooth devices work and how privacy friendly controls ensure user control.

As competition for fickle and frugal holiday shoppers kicks into high gear, traditional retailers are seeking new ways to bring consumers into stores and provide them with improved shopping experiences. Leveraging near ubiquitous smartphone adoption, Bluetooth beacons have emerged as one of the more popular tools in this quest.

While beacons have many non-commercial uses, the US retail industry is where much of the early beacon adoption has come. And though they’re just one of several indoor location technologies, beacons have emerged as the leader because of their low cost and relatively simple deployment.

“Indoor location and beacons have a very broad array of potential applications,” said Greg Sterling, VP of Strategy and Insights for the Local Search Association (LSA). “Through mobile apps, they can help deliver content, promotions or enhanced information in real-world contexts such as stores, airports and hotels.”

The novelty and excitement surrounding beacon technology has generated considerable media attention. Yet beacons are generally not well understood. The LSA and Future of Privacy Forum (FPF) created “Understanding Beacons: A Guide to Bluetooth Technologies” to address some of this confusion and the many misperceptions about how beacons operate.

“Beacons are a privacy friendly technology because apps that interact with beacons are controlled by users,” explained FPF Executive Director Jules Polonetsky. “The settings on leading mobile operating systems ensure that users opt-in before beacons can be used and before users can be contacted.”

The six-page guide straightforwardly explains how beacons work and provides examples of current use cases in the market. It also clarifies and dispels common misunderstandings about beacons and consumer privacy.

Understanding Beacons explores the following questions:

• What Is Bluetooth?
• What Is “Bluetooth Low Energy”?
• What Are Beacons?
• What Is Apple iBeacon?
• Why Are Beacons Popular?
• Do Beacons Capture User Data?
• Can Beacons Track People?

For those unfamiliar with beacons, their capabilities and technical limitations, Understanding Beacons will provide a very useful overview and introduction. The document is free and available here.

Download: “Understanding Beacons: A Guide to Bluetooth Technologies”

Barclays just launched a beacon technology system in a UK branch to help disabled customers with their accessibility needs. The service, which requires customers to download an app and opt-in, notifies the Barclays staff if a customer with disabilities enters the branch. This way, the staff can provide quicker and more tailored services to any customers with disability needs. The customer also does not have to tell the staff about his or her individual needs every time he or she visits the branch.

Customers with disability can choose to opt-in to the service by downloading an app and registering their information. These customers can enter information about their accessibility needs and even upload a photo of themselves. Once the app senses the beacon, the app will send a notification to a staff member in the branch, which alerts Barclay staff that a customer with accessibility needs is entering the building. Barclays’ Director of Accessibility and Inclusion noted that beacons are an innovative way to address issues that people with disabilities face when entering bank branches.

Right now, the system is being tested with Apple iOS in the Barclays Sheffields branch, but could expand to other branches and operating systems if successful.

This great opt-in use of beacon technology to provide quick, tailored accessibility services to customers with disability needs is just one example of the many ways beacons are being used to provide value to mobile device users in a privacy friendly manner.

San Francisco Airport is testing a beacon system to help blind and visually impaired travelers navigate around one of its new terminals.

Working with beacon company Indoo.rs, SFO has set up hundreds of beacons all over the terminal.  Each beacon broadcasts signals using Bluetooth low energy.   If a user downloads the app onto his or her smartphone, the beacon signals can connect to the phone and push notifications with information to the phone when a user gets within range of each beacon.   For the blind or visually impaired, the mobile phone uses voiceover technology to announce points of interest, like bathrooms or close by coffee shops.  If successful, the program could be launched throughout the entire airport.

This great use of beacon technology to help blind travelers navigate airports is just one of the reasons we like beacon technologies, when paired with apps providing a clear and explicit opt-in.

Developers take note: COPPA is a very big stick. Yelp and children’s mobile developer TinyCo recently settled with the FTC over charges that they improperly collected kids’ information.

According to the FTC, a recent complaint against Yelp alleged that “several thousand users who registered through Yelp’s mobile app provided a date of birth that showed they were under 13 years old. Yelp collected information from them anyway, including names, e-mail addresses and locations, as well as any content they posted on Yelp.” If you ask for age during registration, you must bar children under the age of 13 from registering – even if your app is not aimed at kids.

The FTC also addressed a complaint against TinyCo, which makes mobile gaming apps for kids. TinyCo allegedly collected email addresses from some children. COPPA requires companies with apps and websites directed to kids to notify parents about information they collect from kids under the age of 13. These companies also must get permission from parents and explain how they will use the information.

It looks like the FTC is continuing its enforcement focus and scrutiny on mobile apps and kids. To learn more about COPPA and how to make sure you’re in compliance, visit our COPPA Guide and www.coppa.org.

We are pleased to see a search tool to help families find apps for their kids. ACT has worked with Moms With Apps to launch the new Moms With Apps parent-facing site. Moms With Apps provides parents with information to help them decide which app is right for their kids. You can check out the site at http://momswithapps.com.

Apple iOS 8 includes several new privacy features founded on Apple’s core privacy principles of consent, choice and transparency. With these principles in mind, Apple created and incorporated increasingly granular controls for location, opportunities for developers to communicate to users how and why they use data, and limits on how third parties can track your device.

Users now have greater visibility regarding application access to location information.

In previous versions of iOS, apps could prompt users for permission to use Location Services, and, once a user gave an app access, the app could access the user’s location any time it was running, including when the app was not on screen (i.e. in the background). In iOS 8, Location Services has two modes: “While Using the App” – whereby the app can only access location when the app is on screen or made visible to a user by iOS making the status bar blue – or “Always.” Apps have to decide which Location Services mode to request and are encouraged by Apple to only request access “Always” location permission when users would “thank them for doing so.” In fact, iOS 8 will at times present a reminder notice to users if an app that has “Always” location permission uses Location Services while the app is not on screen.

Users will be able to limit access to their contacts.

In iOS 8, users can use a picker, controlled and mediated by iOS, that allows users to share a specific contact with an app without giving the app access to their entire address book.

Apps will be able to link directly to privacy settings.

With iOS 8, apps will be able to link directly to their settings, including their privacy settings, making it easier for users to control their privacy. Before, apps could only give instructions on how to go to the phone’s settings to change the privacy controls. This new feature makes control over privacy settings more accessible to users.

Apple’s new Health app implements additional protections for user’s health data.

Apple’s new Health app and HealthKit APIs give third party health and fitness apps a secure location to store their data and gives users an easy-to-read dashboard for their health and fitness data. Apple has implemented a number of features and safeguards to protect user privacy. First, a user has full control as to which apps can input data into Health and which apps can access Health data. Second, all Health data on the iOS device is encrypted with keys protected by a user’s passcode. Finally, developers are required to obtain express user consent before sharing Health data with third parties, and even then they may only do so for the limited purpose of providing health or fitness services to the user. These features and restrictions allow users to have control over their HealthKit data.

Apple requires apps accessing sensitive data to have a privacy policy disclosing their practices to users

Apple requires apps that utilize the HealthKit or HomeAPIs, offer third party keyboards, or target kids, to have a privacy policy, supporting industry standards and California law. App privacy policies should include what data is collected, what the app plans to do with that data, and if the app plans to share it with any third parties, who they are. Users will be able to see the privacy policy on the App Store before and after downloading an app.

iOS 8 places additional emphasis on disclosure of why developers want access to data.

Apple strongly encourages developers to explain why their apps request a user’s data or location when a user is prompted to give an app access. Developers can do so in “purpose strings,” which are part of the notice that appears when an app first tries to access a protected data class.

Apple’s iOS encourages a “just in time” model, where users should be prompted for access after they take an action in an app that requires the data. The “just in time” prompt and access flow is mediated by iOS and replaces consent models such as those consisting of strings of permissions that pop up after installation like a conga line or users having to give an app access to all data if they want to use an app. Moreover, Apple continues its practice of encouraging app developers to only ask for access to data when needed, and to gracefully handle not getting permission to access a user’s data.

MAC address randomization makes it more difficult to track and individualize iOS devices.

Wi-Fi enabled devices generally scan for available wireless networks. These scans include the device Media Access Control (MAC) address, which is a 12 character string of letters and numbers, required by networking standards to identify a device on a network and assigned by the manufacturer. Mobile Location Analytic companies have, at times, relied on these scans, and the fact that Wi-Fi devices’ MAC addresses do not change, to track individual mobile devices as they move around a venue.

In iOS 8, Apple devices will generate and use random MAC addresses to passively scan for networks, shielding users’ true MAC addresses until a user decides to associate with a specific network. Randomizing MAC addresses makes this kind of tracking much more difficult. However, your device can still be tracked when you are connected to a Wi-Fi network or using Bluetooth. FPF’s Mobile Location Analytics Code of Conduct governs the practices of the leading location analytics companies and provides an opt-out from mobile location tracking. Visit Smart-Places for more details or to opt-out.

Summary

iOS 8’s new “prompting with purpose” disclosures, refined location settings, strict requirements for HealthHit, HomeKit, and kids apps, and MAC address randomization will present greater transparency, protection, and control over privacy for iOS users.

According to a new study from the Pew Internet Project, more than half f all U.S. teenagers are concerned about privacy when using mobile devices. The study, done in conjunction with Harvard University’s Berkman Center for Internet & Society, surveyed about 800 teens aged 12 to 17. Key findings in the report include:

• 58% of all teens have downloaded apps to their cell phone or tablet computer.
• 51% of teens that use appshave avoided certain apps due to privacy concerns.
• 26% of teen apps users have uninstalled an app because they learned it was collecting personal information that they did not wish to share.
• 46% of teen apps users have turned off location tracking features on their cell phone or in an app because they were worried about the privacy of their information.

As the Wall Street Journal remarked, “teenagers aren’t exactly the reckless app devourers you think they are.” Indeed, the Family Online Safety Institute (FOSI) recently discussed this topic during its briefing on Capitol Hill supported by Congressman Honda (D – Cal.).  Panelists Tim Sparapani of the App Developers Alliance, Emma Llanso of the Center for Democracy & Technology, Carl Szabo of Net Choice and Heather Federman of the Future of Privacy Forum responded to moderator Jennifer Hanley of FOSI’s questions on the implications of regulatory efforts geared towards minors. The panel discussed the NTIA’s Multistakeholder process on mobile app transparency, U.S. state actions – especially those in California and Maryland, the impact of international proposals, and current industry efforts around promoting privacy and parental controls.

Both the FOSI panel and the Pew study found that the “privacy concerns” of teens are different than adults. As Amanda Lenhart, the Pew study’s lead author, stated in a CBS News interview: ” Teens are more concerned about privacy from their parents, their teachers, their schools.” In other words, teens care more about whether an app is “creepy” or whether they have “social privacy” versus advertising or governmental surveillance concerns. Perhaps when it comes to teenagers and online privacy then, context is key.

 

The new Children’s Online Privacy Protection Act (COPPA) rule that went into effect earlier this month restricts almost all forms of tracking across child-directed sites other than for a set of limited “internal operations purposes.”  Child-directed sites are now strictly liable for any third party tracking on their sites that do not meet COPPA’s limited exceptions, unless they obtain verified parental consent.

Third party code providers, such as analytics companies, ad networks, or social plug-in providers, can also be liable under the new COPPA rule if they have “actual knowledge” they are dealing with children – that is, if the first party site has effectively communicated its online status to the third party or if a “representative of the online service recognizes the child directed nature of the site.”  Yet for many third party code providers, who distribute their code freely to millions of web developers, there is no way to assess whether they are being used by services directed at children.

Earlier this month, the Future of Privacy Forum (FPF) announced its support for a model proposed by FTC Chief Technologist Steve Bellovin calling for a special “flag” to be passed between companies that would indicate the child directed status of a site.  FPF has been working with a number of stakeholders to refine a technical proposal that could help standardize this type of communication, effectively creating a limited “Do Not Track for Kids” signal.  We have urged the FTC to provide a “safe harbor” for users of this flag in order to provide more certainty in this area and to help ensure compliance from web publishers and third parties.

Last week, the FTC released updated FAQs to help businesses comply with the COPPA rule.  These FAQs include a provision recognizing the COPPA flag as a viable tool for compliance; the FAQ sets forth a technical system for a site to affirmatively certify whether it is “child-directed” or “not child-directed.”  According to the FAQs, companies may rely on a signal that a site is “not child-directed,” but “only if first parties affirmatively signal that their sites or services are ‘not child-directed.’”  Companies cannot set this option for their clients as a default, if they wish to limit their liability. The FTC is requiring a “forced choice” or a “double flag” process, rather than the single flag that Bellovin proposed and that FPF championed.

We are pleased that the FTC recognized the COPPA flag as an effective way to both protect children and ensure that companies meet their obligations.  Technology can offer a meaningful, low-cost solution that can be widely implemented across industry to encourage compliance.

The new FAQs describe stringent requirements that must be met for a COPPA signal that companies “may ordinarily rely on.”  Our view is that this FTC language creates a safe harbor of sorts, providing protection for companies worried that they will be arbitrarily imputed actual knowledge.

While the FTC’s version of the flag will work for some companies, it will not be practical for many others.  And for those who it will work, it will likely be feasible for their new clients only, because retroactively forcing many thousands of current clients to make a forced choice or be terminated is not realistic.

A number of leading companies, including Facebook, AdMob, Twitter, The Rubicon Project, and Yahoo!, began to roll out a single flag option to their clients even before the FTC released its new FAQs.  We believe this single “Do Not Track for Kids” option still has value even though it may not meet the FTC standard for a safe harbor.  The FTC has reiterated that “actual knowledge” requires a fact-specific inquiry.  As a practical matter, companies that send and receive a COPPA flag as part of their compliance efforts are demonstrating a good-faith attempt to meet their obligations under the new COPPA rule.  Those who implement such technology as part of a broader compliance strategy will be in a far better position should the FTC come calling than those who do not.

The next step for companies is to standardize a format for the COPPA flag signal so that it can more easily be passed along from company to company.  If you are interested in learning more about the FPF’s efforts to standardize this Do Not Track for Kids signal, please email [email protected].

 

 

Mary Ellen Callahan of the law firm, Jenner & Block, co-wrote an article with Associates Michael T. Borgia, David M. Didion and Sabrina N. Guenther that examines recent federal and state initiatives to define consumers’ privacy rights when they use mobile devices. The authors eloquently explain that various state and federal agencies have similar goals when determining mobile privacy standards, but without a comprehensive nationwide framework, their efforts have resulted in a patchwork of binding and nonbinding forms. The article appeared in the June 2013 edition of Communications Lawyer, the publication of the ABA Forum on Communications Law.

An excellent read for your Friday afternoon on recent initiatives and legal developments  in the mobile privacy space!