Tag Archives: mobile devices

DiOS Mio! Apple’s License for Internal Apps (Part 2 of 3)

In this second part of the three-part post discussing the Apple iOS Developer Enterprise Program (the “Program”), I will continue by describing the terms of Apple’s iOS Developer Program Enterprise License Agreement (the “License”) that specifically govern the apps developed from the Apple Software.  Where Part 1 was limited to the rights and restrictions as they relate to the use of Apple Software, this Part 2 focuses on the rights and restrictions as they relate to the use of Internal Apps.  These “Internal Apps” are software programs developed for specific use with an iOS Product (e.g., iPhone or iPad) for internal deployment to, and use by, the company’s (i.e., the “Licensee’s”) employees.

Attribution: Zacfranks
Attribution: Zacfranks
Note: Yes, I am aware that this is an Android App :)

As I mentioned in Part 1, the Licensee retains all ownership and interest in the Internal Apps it develops using the Apple Software.  Nevertheless, the Licensee should be well advised that Apple will not treat them as confidential.  Apple expressly disclaims any confidentiality obligations or use restrictions with respect to information that a Licensee provides in connection with the Program, including the Internal Apps.  This means that Apple may use and freely disclose any such information on an unrestricted basis without notifying the Licensee.

APIs and Functionality

The following are requirements that a Licensee’s Internal Apps must adhere to with respect to Application Programming Interfaces (APIs) and functionality.

  • Internal Apps may use documented APIs only in the manner prescribed by Apple
  • Internal Apps must not use or call any private APIs
  • Internal Apps must not download or install executable code
  • Internal Apps must not facilitate commerce, credits, or purchases of any kind
  • Internal Apps may only read data from, or write data to, the Internal App’s designated container area on the device
  • Internal Apps must have at least the same features and functionality when run by a user in compatibility mode on an iPad, except where any feature or functionality is not supported by a particular hardware device
  • Internal Apps must comply with Apple’s Human Interface Guidelines

Data & Privacy

Under the License, a company’s Internal Apps may not collect user or device data without prior end-user (i.e., employees’) consent.  This consent requirement means the Licensee must provide clear notice to users regarding the company’s collection, use, and disclosure of user or device data.  Further, even where consent is obtained, the data collected can only be used to provide a service or function that is directly relevant to the use of the Internal App.  Under no circumstances, can a Licensee use analytics software in their Internal Apps to collect and send device data to a third party.  Additionally, the Licensee must take appropriate steps to protect such data from unauthorized use, disclosure, or access by third parties.  If a user ceases to consent or affirmatively revokes consent for the Internal App’s collection, use, or disclosure of his or her user or device data, the Licensee must promptly cease all such use.  In other words, the company must provide its employees with an opt-out mechanism.

Internal Apps that offer location-based services or functionality must notify and obtain consent from an end-user before his or her location data is collected, transmitted, or otherwise used by the Internal App.  If such Internal App uses location-based APIs to provide real-time navigation, the Licensee must have an end-user license agreement (e.g., a Terms of Service) that includes the following notice: YOUR USE OF THIS REAL TIME ROUTE GUIDANCE APPLICATION IS AT YOUR SOLE RISK. LOCATION DATA MAY NOT BE ACCURATE.

If the Licensee develops Internal Apps that collect or record images, pictures, or voice content (collectively “Recordings”), then the company must comply with all applicable privacy laws and regulations.  Depending on the type of Recording and the intended use of such Recording, this may require notice be provided and/or consent be obtained from employees; as, for example, consent to use the employees’ likeness or image, to the extent the Internal App contains photo-capture functionality.  In addition, per the License, a company’s Internal Apps must display an obvious audio, visual, or other indicator to the end-user as part of any Internal App that is making an active Recording.

Specific Types of Content

All content used within the Licensee’s Internal Apps must either be owned by the company, or properly licensed by the company from the content owner.  If the company’s Internal Apps allow employees to send SMS messages, then the company must inform its employees, prior to their use of such functionality, that standard text messaging rates or other carrier charges may apply.  Internal Apps may include sweepstake or contest functionality; however, the Licensee must be named as the sole sponsor of the promotion.


The Licensee is responsible for preventing any unauthorized person from having access to Provisioning Profiles, digital certificates, and corresponding private keys.  Additionally, the Licensee must immediately notify Apple in writing if it has any reason to believe there has been a compromise of any Provisioning Profiles, digital certificates, or corresponding private keys.  The Licensee cannot provide or transfer Apple-issued digital certificates or Provisioning Profiles provided under the Program to any third party, except for a third party who is developing an Internal App on the company’s behalf.

Additional Functionality

The following sections describe terms that are specific to certain services available with the Apple Software that may be used to develop additional functionality in connection with a Licensee’s Internal Apps.

  • APN (Apple Push Notification service) or Local Notifications

If the Licensee’s Internal Apps send Push Notifications via the APN or Local Notifications, the Licensee must first obtain end-user consent prior to receiving such notifications.  The company cannot disable or interfere with any Apple implemented consent panels or any Apple system preferences for enabling or disabling Notifications functionality.  If an employee’s consent to receive Push Notifications is denied or later withdrawn, the company may not send that employee any further Push Notifications.  As a condition to using the APN or delivering Local Notifications, the company may not transmit sensitive personal or confidential information belonging to an individual (e.g., a social security number, financial account or transactional information, or any information where the individual may have a reasonable expectation of secure transmission) as part of any such notification.  Any Push Notifications that the Licensee sends via the APN, may be transmitted across various public networks, in various forms of media.

  • Mobile Device Management (MDM) Service

Like the Internal Apps themselves, the Licensee’s use of the MDM Service is solely for its internal, in-house management of employees’ Deployment Devices.  Before a company can use the MDM Service, it must install an MDM Profile on each iOS Product that will be managed under the MDM Service.  Use of the MDM Service requires the Licensee to maintain a secure server to interact with Apple’s APN server.  As part of the MDM Service, Apple will provide the Licensee with the “MDM Protocol”, which must be treated as Apple’s Confidential Information.

Prior to installation of the MDM Profiles, the Licensee must provide notice to its employees that it will be able to interact with their Deployment Devices remotely.  Such interaction includes: inspecting, installing, or removing profiles; viewing which Internal Apps are installed; using secure erase functions; and, enforcing device passcodes.  All information that the Licensee obtains through the use of the MDM Service may only be used for the company’s internal information technology and device management purposes; such as, locking the device for security purposes, or remotely wiping a lost device.

  • iCloud Storage

The Licensee’s use of the iCloud Storage APIs and the iCloud service is governed by additional terms governing the iCloud service for software development and testing in connection with the Licensee’s Internal Apps.  Most importantly, the Licensee’s Internal Apps are only permitted to use the iCloud service and the iCloud Storage APIs for the purpose of (1) storage and retrieval of key value data (e.g., a list of stocks in a finance App) for Internal Apps, and (2) allowing its employees to access user-generated documents and files through the iCloud service.

  • Passbook

The Licensee’s development of Passes, and use of Pass IDs, must be in accordance with the terms of the License and the Additional Terms for Passes.  “Pass(es)” are one or more digital passes (e.g., movie tickets, coupons, loyalty reward vouchers, boarding passes, membership cards, etc.) developed by the company, under the company’s trademark or brand, and which are signed with the company’s Pass ID.  A “Pass ID” means the combination of an Apple-issued certificate and Push Application ID that is used to sign the company’s Passes and/or communicate with the APN.

The Licensee may only use the Pass ID for purposes of digitally signing Passes and/or for purposes of using the APN service with Passes.  The Licensee is limited to distributing Passes only to its employees for internal purposes.  Passes may only operate and be displayed in Passbook, which is Apple’s designated container area for the Pass, or through Passbook on the lock screen of an iOS Product.  Within the Passes, the Licensee must state its name and address, and the contact information to which any employee questions, complaints, or claims with respect to its Passes should be directed.  Apple reserves the right to review and approve or reject any Pass that the company intends to distribute for use by its employees.

  • Twitter

If the Licensee’s Internal Apps access the Twitter service through the Twitter API, such access is subject to Twitter’s terms of service (http://dev.twitter.com).

  • Address Book

If the Licensee’s Internal Apps access data from an employee’s Address Book through the Address Book API, then the Licensee must notify and obtain consent from the user before his or her Address Book data is accessed or used by the Internal App.

To be Continued…

In the third and final part of this three-part post, I will address the terms governing app deployment, as well as the unique requirements related to Apple’s Pre-release Software that may be made available under the Program.  Stay tuned!

DiOS Mio! Apple’s License for Internal Apps (Part 1 of 3)

The purpose of this three-part post is to provide an overview of the Apple iOS Developer Enterprise Program (the “Program”) from a legal perspective.  These posts should provide guidance to business-unit directors and their software developers as they prepare to distribute in-house, mobile applications on Apple-branded products running the iOS to their employees.  In this Part, I will highlight the general legal obligations and restrictions related to Apple’s iOS Developer Program Enterprise License Agreement (the “License”).  This part will focus only on the License as it relates to the use of the Apple Software.  In future posts, I will discuss how the License governs the subsequently developed apps and their deployment.

Ed g2s
Ed g2s

Overview: Apple’s iOS Developer Enterprise Program

The Program provides companies with tools to develop, test, and distribute proprietary, in-house iOS apps to employees and, under very limited circumstances, customers.  These “Internal Apps” are software programs developed for specific use with an iOS Product (e.g., iPhone or iPad) for internal deployment to, and use by, the company’s employees.  As a general rule, the Program is not intended for the creation of other apps that may be used, distributed, or otherwise made available to other companies, distributors, resellers, or members of the general public.

General Program Terms: The Apple Software

Before a company can begin developing Internal Apps using the Apple Software, it will have to accept the terms of the License. As defined by the license, “Apple Software” includes the Apple iOS, Provisioning Profiles, and the all-important Software Development Kit (“SDK”, i.e., the documentation, software, applications, sample code, simulator, tools, libraries, APIs, etc.).  The company (the “Licensee”) must be sure that the person accepting the License terms has the right and authority to enter into the License on behalf of his/her company.  For companies with multiple subsidiaries and affiliates, it is important to note that the License is both non-sublicensable and non-transferable.  Once the License is entered into, Apple grants the Licensee the right to (1) use Apple Software for developing and testing Internal Apps; and, (2) deploy their Internal Apps for the Licensee’s internal purposes.

While Apple grants a rather broad License for a nominal fee of $299, they at the same time, understandably, limit their liability.  Pursuant to the License, Apple is not obligated to provide any maintenance, technical, or other support for the Apple Software.  Of course, evidence suggests that Apple will continue (although not required) to provide software updates and patches.  Nevertheless, the Apple Software is provided “as is” and is not subject to a warranty of any kind.  As a result, Apple is not responsible for any costs or other losses the Licensee may incur as a result of its Internal App development, use of the Apple Software, or participation in the Program.

Who can use the Apple Software? 

The Apple Software may only be used by the Licensee’s Authorized Developers.  To be an “Authorized Developer”, the developer must: (1) be an employee or authorized contractor of the Licensee; (2) have a valid registered Apple Developer account with Apple; and, (3) have a “need to know” or “need to use” the Apple Software in order to develop and test Internal Apps.

How can the Apple Software be used?

Under the License, a company may use the Apple Software under the following circumstances:

1)      To install a reasonable number of copies of the Apple Software on Apple-branded computers owned or controlled by the Licensee, to be used internally by Authorized Developers for developing or testing Internal Apps.

2)      To make and distribute a reasonable number of copies of Apple’s documentation to Authorized Developers for the sole purpose of developing or testing Internal Apps.

3)      To install one copy of the iOS on each Authorized Test Devices, up to the number of Authorized Test Devices that the Licensee has acquired licenses for, to be used for developing and testing Internal Apps. “Authorized Test Devices” are iOS Products owned or controlled by the Licensee that have been designated for testing and development purposes under the Program and specifically registered with Apple for that purpose.

4)      To distribute Provisioning Profiles to the Licensee’s employees for the purpose of developing and testing Internal Apps.

5)      To distribute Provisioning Profiles to the Licensee’s employees in conjunction with the deployment of the Internal Apps on Deployment Devices for employees’ internal use. “Deployment Devices” collectively means Authorized Test Devices and other iOS Products owned or controlled by the Licensee.

In exchange for these rights, the Licensee must make a number of representations.  The following are those representations that really should be communicated to the company’s project team while developing and deploying Internal Apps.

  • The Licensee must monitor and be responsible for its employees’ use of the Apple Software, Authorized Test Devices, and other Deployment Devices.
  • The Licensee must monitor and be responsible for use of the Internal Apps by its employees.
  • The Licensee’s Internal Apps must not violate, misappropriate, or infringe any Apple or third-party intellectual property rights.
  • The Licensee must indemnify Apple for any claim against Apple arising from its breach of the License, infringement of a third-party’s intellectual property, or use of the Apple Software.

In addition to these reps, the Licensee must adhere to a number of restrictions over its use of the Apple Software.  First, the Licensee may not install, use or, run the SDK on any non-Apple-branded computer.  Second, the Licensee may not install, use, or run the iOS and Provisioning Profiles on or in connection with devices other than Deployment Devices.  Lastly, the License does not allow the Licensee to use Apple’s trademarks or logos.  If the Licensee wishes to make reference to any Apple products or otherwise use Apple’s trademarks, then it must comply with Apple’s published guidelines for such use.

A Quick Note on Intellectual Property

Under the License, Apple of course retains ownership in all Apple Software.  The Licensee, on the other hand, retains all ownership and interest in the Internal Apps it develops using the Apple Software.  Even though the Licensee retains all ownership and interest in its Internal Apps, Apple will not treat them as confidential.  Apple expressly disclaims any confidentiality obligations or use restrictions with respect to information that a Licensee provides in connection with the Program, including its Internal Apps.  As such, Apple may use and disclose any such information on an unrestricted basis without notifying the Licensee.

To be Continued…

Part 2 will continue by describing the terms under the License that govern the apps developed and built on the Apple Software.  Finally, in Part 3, the terms governing app deployment will be addressed, as well as the unique requirements related to Apple’s Pre-release Software.

The APPS Act: “Mobile Data as the Oil of the 21st Century”?

Last month, Georgia Congressman Hank Johnson introduced the bipartisan Application Privacy, Protection and Security (APPS) Act of 2013. The bill’s objective is “to provide for greater transparency in and user control over the treatment of data collected by mobile applications and to enhance the security of such data.” If enacted, the APPS Act would require mobile app developers to maintain privacy policies, obtain consent from consumers before collecting data, and securely maintain the data they collect. Here’s Rep. Johnson as he introduced the bill, calling for a common sense approach to meeting the challenges associated with data privacy on mobile devices:

Interestingly, the bill itself was a product of a crowdsourcing effort, of sorts. About a year ago, Rep. Johnson launched AppRights, an online forum for interested parties to build mobile privacy legislation at a grass roots level. According to Rep. Johnson, “the overwhelming majority of participants who helped build the legislation – more than 80 percent – confirmed that Congress should protect consumers’ privacy on mobile devices […] [and] wanted simple controls over privacy on devices, security to prevent data breaches, and notice and information about data collection on the device.” Rep. Johnson even has a Facebook page specific to this proposed legislation; however, at the time of this posting there appears to be only 45 “Likes”, which may be indicative of the actual response to his crowdsourcing initiative.

Putting the efficacy of crowdsourcing for federal law aside, the proposed APPS Act is largely consistent with the Federal Trade Commission’s (FTC) recent Staff Report and initiatives by States, such as the California Attorney General’s Recommendation Memo. If passed, here are the major impacts to mobile app developers and users:

1. Creates two important definitions:

  • De-identified Data” is a term used in the Act and defined to mean data that can be used to identify or infer information about a particular person or their mobile device. This definition is important because the Act largely governs mobile apps that collect Personal Data, which by definition does not include De-identified Data.
  • “Personal Data” (hereinafter “PD”) is used throughout the Act and the bulk of the Act’s provisions rely heavily on this term. So, wouldn’t it be nice if there were a clear and understandable definition of PD in the Act? Yes, but no such luck. Other than to say that PD does not include De-identified Data, the Act punts to the FTC to define this term by regulation.

2. Notice – Where a mobile app collects PD of a user, the app developer would first have to provide its users with a notice containing the terms by which the developer collects, uses, stores, and shares such PD of the user. While the Act would look to the FTC to prescribe the form and manner of such notices, the content of the notice would have to include:

  • The categories of PD that will be collected;
  • The categories of purposes for which the PD will be used;
  • The categories of third parties with which the PD will be shared; and,
  • A data retention policy that governs the length for which the PD will be stored and the terms and conditions applicable to storage, including a description of the rights of the user to withdraw consent and the process by which the user may exercise such rights.

3. Consent – Where a mobile app collects PD of a user, the app developer would first have to obtain the user’s consent to the notice. Interestingly, the statute uses the term “consent” as opposed to “express consent”, which may mean users could be found to impliedly consent to the app developer’s notice.

4. Post-consent Opt-out – This provision would require the mobile app developer to honor a user’s request to prohibit any further collection of PD by the developer. The Act would go an additional step and require the developer, after receiving a user’s opt-out request, to either delete that user’s PD or refrain from using or sharing that user’s PD. Interestingly, the decision to delete the PD or refrain from using/sharing the PD would be vested in the user, and not the developer.

5. Data Security – The app developer would have to implement “reasonable and appropriate measures” to protect against “unauthorized access” to any PD or De-identified Data that the app collects from the user. This provision appears to have very little bite to it, unless the FTC was to expand on it through regulation. Clearly, the APP Act wants no part of the unwelcoming waters that is cybersecurity law.

6. Enforcement – The Act would charge the FTC as the primary regulatory agency for purposes of enforcement and promulgation of regulations under section 18(a)(1)(B) of the FTC Act, which prohibits unfair or deceptive acts or practices. However, the Act provides States’ attorneys general or agencies with the right to bring a federal civil action when they believe the residents of their state are adversely affected by an app developer in violation of the Act.

7. Safe Harbor – App developers would be able to escape liability under the Act if the developer had implemented a “code of conduct for consumer data privacy.” To fit within the safe harbor provision, the code of conduct would have to be (i) developed through the NTIA’s multi-stakeholder process, and (ii) comply with the yet-to-be-promulgated FTC regulations.

That’s it in a nutshell. It should be interesting to see how this bill progresses through Committee, if at all. The good folks at Govtrack are giving it a snowball’s chance in hell of getting passed; but, hey, you never know. So, stay tuned! Better yet, “Like it” on Facebook! Rep. Johnson needs all the support he can get.

BYOD & Corporate Data: It’s Time to Formalize this Party

Employees across the US are increasingly using their own cell phones and other mobile devices for work purposes, in addition to personal or non-work purposes.  This trend has been dubbed Bring Your Own Device (“BYOD”) and according to a recent Cisco survey, 90% of Americans use their smartphones for work.  And, depending on the level of the employee, or the “distro” lists to which that employee is a member, there may be a significant risk that such a device contains vulnerable, confidential business information.

The BYOD trend is probably here to stay. Employees prefer their personal devices over unfamiliar employer-sourced devices.  According to an InfoWorld article, internal helpdesk support calls drop from an average of 4.5 per user per year to 2.5 when employees use their own devices.  Employers, at the same time, save money by not having to provide the devices or procure the underlying data and service plans.  Clearly, companies and their employees alike are capitalizing on the benefits of BYOD.  Here’s a great picture, courtesy of Logicalis, that depicts some interesting trends within the BYOD landscape:

Logicalis graphic.

But, at the same time, the risks associated with a BYOD program cannot be ignored.  One such risk is to corporate information security.  If a company does not have a strategy for managing a BYOD rollout, then corporate email, calendars, financial data, proprietary data, trade secrets, third-party data subject to non-disclosure agreements, and on and on, can all be vulnerable to loss or misappropriation.  And, as some reports would seem to indicate, this risk has largely gone unmitigated: some 40% of employees who use their personal smartphone for work purposes don’t even have a password to lock/unlock their device.

As dismal as the statistic above would seem to indicate, US IT departments are leading the way in terms of managing BYOD.  According to Ovum Research, of the 20-countries they surveyed, US employees are the most likely to have signed a BYOD policy at work.  And while that is certainly an accomplishment, the fact is that 70% of US employees using their own devices at work have not signed any such corporate policy governing BYOD.  The time has come to develop industry standards and best practices related to BYOD programs.  Luckily, there are many in the IT and IS field that are far ahead of their counterparts in legal and HR.  I’ll lean on one such expert at the IT Manager Daily.  As described in a recent post, BYOD programs call for three critical components:

  1. A software application for managing the devices connecting to the network;
  2. A written policy outlining the responsibilities of both the employer and employees; and,
  3. An agreement that employees sign, acknowledging that they have read and understand the policy.

While the enterprise mobility management software (#1 above) is absolutely indispensable to a successful BYOD implementation, I’d like to focus on a few elements that a BYOD policy should address.

First, the BYOD policy should address three related areas of federal employment law; namely, discrimination, labor standards, and labor relations.  As Keneth Vanko recently posted,

“First, the BYOD policy should ensure that the device is not used in a manner that could lead to discrimination or harassment suits. Second, the employer can’t inadvertently run afoul of the Fair Labor Standards Act. Specifically, non-exempt employees should not be permitted to use the device during non-working hours for work purposes. Third, with the National Labor Relations Board cracking down on the use of social media policies, a comprehensive BYOD should specifically provide that the policy does not preclude employees from discussing the terms of their employment, or anything else that can be described as concerted activity under the NLRA.”

Second, the BYOD policy should address security directly and specifically as it relates to the unique ways in which we all use mobile devices.  For example, a comprehensive policy should address at a minimum:

  • Company’s unilateral right to wipe a lost/stolen device of all company confidential information
  • Company’s unilateral right to wipe a device of all company confidential information upon employee’s termination or resignation
  • Company’s control of certain platform-specific mechanisms, such as:
    • Password for logging in
    • Mimimum standards for password strength
    • Disablement after repeated failed logins
    • Self-locking after idle

Third, the BYOD policy should address how provisions of the policy will be enforced.  Beyond the conventional managerial reprimands and HR-type repercussions, the policy should describe IT-type terms or limitations of use.  For example, consider including a provision that states if certain unauthorized use is made of the device or certain prohibited content is accessed, then access to corporate data (such as email or calendars) will be blocked until such time the device is returned to a conforming state.  Taking the concept one step further, consider swiping all corporate data from the device for repeated failure to comply with the terms of use contained within the policy.

Lastly, consider whether the policy addresses prohibited uses of the device independent of whether such use is related to business or personal activities or whether such use is made “on” or “off the clock”.  For example, it may be prudent to create a bright-line rule relative to certain uses such as storing or transmitting: illicit materials, proprietary information belonging to another company, material that harasses other employees, or materials related to an employee’s outside business activities.  Ultimately, such a mechanism (as many of the mechanisms described above) must be considered in light of a company’s IT constraints.  Depending on the capabilities of the chosen enterprise mobility management software, enforcing a BYOD policy may be a challenge; however, as more enterprise software companies push the BYOD envelope even further, I imagine that BYOD security and mobility management will simply be another COTS module that corporate IT teams integrate with their existing systems.

No matter how a company decides to articulate its specific BYOD policy, it must, at the end of the day, be well communicated and easy for employees to follow.  A concerted effort from multiple stakeholders representing IT, Legal, HR, Finance, Communications, and Procurement, should lead to a BYOD implementation that keeps employees happy and corporate data safe.