Apple is no stranger to the privacy game, as this move is only the latest in a series of policy updates designed to strengthen data access and usage policies across its platforms and devices.

The most significant of these changes was the introduction of App Tracking Transparency in iOS 14.5 in 2021. That update required apps to request end-user permission to track activity across other apps and websites. Opting in allowed developers to use Apple’s IDFA identifier to share activity with third party data brokers and marketing agencies. Opting out should have stopped tracking cold – but like all privacy policies designed to return control to end-users, there was a loophole.

By design, a number of Apple’s APIs that deliver core functionality – known as required reason APIs – also allow developers and marketing partners to track end-user activity even if they’ve specifically opted out of data sharing.

By using a technique called fingerprinting, or data fingerprinting, developers can keep the data flowing – even after end-users had explicitly denied permission for the apps to do so. Apple does not allow fingerprinting regardless of whether or not the user has provided permission to track their activities.

To close the gap, developers who use required reason APIs will have to provide additional information as part of the approval process.

The updated policy guidance – published here on its developer website – confirms that starting this autumn, Apple will email developers if they “upload an app to App Store Connect that uses required reason API without describing the reason in its privacy manifest file.”

The rules get even stricter next year:

“From Spring 2024, apps that don’t describe their use of required reason API in their privacy manifest file won’t be accepted by App Store Connect,” the statement continues.

PREPARE NOW FOR THE INEVITABLE

Apple’s move is a clear signal to developers that the privacy landscape continues to tighten – as it should. It’s also a message to all developers, on any platform, that vendors are increasingly tying privacy compliance to initial approvals, and to ongoing support within their app stores and online marketplaces.

To remain compliant, developers must not only adopt a privacy-first approach to their work, but they must educate themselves on current data stewardship rules and best practice to ensure they set appropriate expectations with stakeholders. Keep the following in mind as you initiate and manage your own development projects:

1. Follow a privacy by design approach. Don’t just tack privacy on at the end of a development project. Rather, build it directly into the architecture from the moment the project has been approved. Proactively identify anticipated risks and build out detailed response frameworks to minimize exposure and maximize business continuity.
2. Conduct a data privacy assessment. Before the first line of code is written, developers and stakeholders must agree on what data will be collected, under what circumstances, how it will be processed, where it will be moved and stored, and who will have access to it. They must also agree on how data will be categorized – for example, by sensitivity and compliance requirements – and how the proposed solution will ensure compliance with applicable legislation. This assessment should form the critical framework for the entire development process.
3. Minimize what you need. Just because you can collect certain types of data doesn’t mean you should. Place limits on the breadth and scope of personally identifiable information (PII) required to meet identified business requirements. Collect and retain only what is absolutely required to meet minimum core functionality – and no more. Ensure that users are able to provide explicit consent for their data to be collected, retained, and processed.
4. Secure what you’ve captured. Use strong end-to-end encryption throughout the data lifecycle, and incorporate secure communication protocols, such as HTTPS, to minimize risks both at-rest and in-transit. Incorporate tighter, role-based access controls when designing database structures and procedures and include authentication details for end-user and administrator roles as part of the documentation process.
5. Conduct regular security audits. Revisit protocols throughout the development process to ensure what was initially proposed is, in fact, supported by the evolving code base. As part of the quality assurance testing process, conduct penetration tests to identify – and resolve – vulnerabilities. Include regularly scheduled audits and reviews in documentation and maintenance procedures and incorporate these protocols into initial and ongoing end-user training.
6. Build in robust authentication. Use two- or multi-factor authentication (2FA or MFA) wherever possible to minimize the potential for unauthorized system access and data leakage. Regularly review chosen protocols to ensure they are developed to the latest, most secure standards.
7. Assess APIs and third-party integrations. Sure, you can build your own super-secure, privacy-aware code – but are you just as confident when incorporating another vendor’s code into your project? Assess all APIs, SDKs, and toolsets to ensure permissions and data accesses are all within project requirements. Only share data that is absolutely necessary, and review vendor performance and reputation to minimize the potential for data exposure.
8. Document your privacy policy. Be obviously transparent about how user data is collected, processed, and used. Get explicit consent from end-users for any and all data required by the proposed system and make privacy tools and documentation easily accessible throughout the final solution.
9. Ensure data is regularly deleted and anonymized. Build into the project plan procedures for periodic data retention and purging. Publish detailed rules for data management, and ensure data is aggregated and anonymized when used for reporting, dashboards, analytics, and research.
10. Become a regulatory expert. You don’t have to live in Europe, California, or the U.S. to fall under the compliance requirements of GDPR, CCPA, or HIPAA, respectively. Data easily crosses borders, and solutions – and their developers – must be aware of the increasingly stringent legal requirements in the jurisdictions where their solutions will be used. 

THE BOTTOM LINE

Apple’s move to force developers to explain why they must use certain APIs and SDKs may elicit some grumbling, but it’s being implemented for good reason.

The age of data free-for-all is thankfully drawing to a close as vendors get serious about tightening the rules, enforcing compliance, and returning the power of data stewardship to end-users.

Devs who proactively comply will reap the rewards – including streamlined app store approvals, higher levels of trust from stakeholders, and reduced support costs over the product lifecycle. The rest of us will have more positive control over our data, and a more secure app experience.

Everybody wins.

—

Connect with us on LinkedIn if you’re wondering about your own data privacy best practices.

The post Apple’s new device fingerprinting rules send clear privacy message to developers first appeared on STEP Software.

Now that the first few heady weeks of Threads’ existence are giving way to the cold, harsh reality of long-term use, we’re beginning to get a better look at what lies underneath. And what we’re seeing – at least from the perspective of end-user privacy – merits additional discussion, because Threads collects significantly more data than competing apps in the microblogging space. While apps like Twitter, Mastodon, Hive Social, and Bluesky all have their own privacy policies, all of them are far less aggressive in their data collection. 

It’s difficult to imagine anyone being surprised that Threads leads the way in aggressive data collection. After all, the new app comes to us from Meta, parent company of Facebook, architect of the Cambridge Analytica scandal that laid bare just how far a social media company might go in the pursuit of its customers’ data.

In a digital economy largely fueled by data culled from billions of devices, apps, browsers, and services, Meta is hardly the only player pushing hard to learn as much as possible about the folks who subscribe to its services. But in a Wired.com comparison of Twitter and its direct competitors, Threads was found to be collecting data from a much broader range of categories – such as third party advertising, developer marketing, analytics, product personalization, and app functionality – than the competition.

In that respect, the scope and breadth of the data collected by Threads echoes that of Facebook. And while Threads falls under the common privacy policy that covers Meta’s other social media platforms, including Facebook, Instagram, and WhatsApp, the new app also has its own supplemental privacy policy.

Among the clauses that apply uniquely to the new app is what happens if you eventually decide to delete it: the close architectural relationship between Threads and Instagram means users who choose to delete their Threads account will also be forced to delete their Instagram account, as well.

For additional details on competitors’ privacy policies, check out the following links:

• Twitter
• Mastodon
• Hive Social
• Post News
• Spill

DEVELOPERS TAKE NOTE

If your business – like ours – involves software development, this issue is critically important. Consider the following best practices to limit your exposure to data-related concerns throughout the software development lifecycle:

1. Implement strong data protection measures. Encrypt critical data at every step of the process, including processing, transmission, and storage. Incorporate secure protocols such as TLS (HTTPS) when developing for the web. Bolster access controls with two-factor authentication (2FA) and/or multi-factor authentication (MFA).
2. Follow Privacy by Design principles throughout the development process. Don’t just tack data privacy on at the end of the project. Consider it right from the outset, then assess and reassess at every major decision point throughout the development process. Instead of casting the widest possible data collection net, minimize data collection and retention by focusing only on what is essential to meet the documented business needs – nothing more – and ensure end-user consent is both explicit and transparent.
3. Sanitize your data inputs. Do not use any user and third-party data that hasn’t been sanitized by your software to avoid SQL injection and/or Cross-Site Scripting (XSS) attacks.
4. Regularly conduct penetration testing and security audits to better identify vulnerabilities and minimize the risks of potential security breaches. Incorporate third-party input into development and maintenance efforts to provide unbiased guidance and rapid resolution of identified weaknesses.
5. Build transparent privacy policies clearly outlining how end-user data is collected, why it is collected, how it is used, who has access to it, and the context within which it is shared. Publish these policies in easily accessible locations, including the app itself, the app store, and your website. Maintain ongoing communication to update stakeholders on future policy updates.
6. Use role-based access controls to limit access to sensitive data only to those individuals who need it for their jobs. Conduct regularly scheduled assessments to review the role matrix and revoke accesses as needs evolve.
7. Ensure data is anonymized, wherever possible, to limit the risk of exposure. Where possible, remove identifiers or replace them with artificial identifiers like tokens to protect individual privacy while maintaining the utility of aggregated data.
8. Implement robust patch management processes to ensure security and feature updates are efficiently deployed to stakeholder devices and systems. Review analytics to measure compliance and adjust processes as needed. Maintain thorough and frequent communications with the end-user community to ensure no one is running outdated – and possibly vulnerable – code.
9. Audit third-party partners to ensure their products and platforms – such as APIs and SDKs – are built to the same security standards as the rest of your own homegrown solutions. Hold partners to the same privacy and data stewardship standards you’ve outlined in your own privacy policies.
10. Train your people. Data privacy is only as effective as the people who are responsible for it. Ensure you and your entire development team have access to regular training to stay current with the latest best practices and privacy regulations. 

THE BOTTOM LINE 

The arrival of Threads is prompting long-overdue discussions around digital privacy and the risks associated with oversharing on social media platforms. This is a healthy process that spotlights developer accountabilities when building software – as well as best practices software development professionals need to follow to minimize the potential for data leakage – and damage to the brand.

If you’re looking for answers in your own privacy journey, give us a call. 

The post Threads privacy policies reveal need for better development best practices first appeared on STEP Software.

The Canadian move echoes similar moves in recent weeks by the U.S. government, the European Union, and at least half of all American states. It falls short of a full-on national ban, however such legislation has been proposed in the U.S. Nevertheless, this marks a serious foreign policy rebuke from Canada to China.

The growing global turbulence around TikTok reinforces the disparity between its populist perception as a non-threatening app, and accusations that it represents a major security threat on a personal, organizational, and national level. If we were talking about any other app, it would be a no-brainer: delete it outright and get on with our lives. But TikTok has become Gen Z’s de facto digital gathering place. Kicking its algorithmically fed habit won’t be as easy as simply quitting the platform, and the ripple effects could have a far-reaching economic impact.

A FIRST AND FINAL WARNING FOR BUSINESSES

While this particular action by the Canadian government targets this one particular app, on federally issued devices, it really serves as a sobering warning to businesses, as well. More bluntly, if this specific app is worrisome to the feds, then it should be worrisome to everyone else, too. 

In fact, organizations whose employees use mobile devices for work – in essence, all of them – are now on notice that their corporate security could be exposed to unnecessary risk simply because workers decided to watch a viral video, or two, or ten, during their break.

In fairness to TikTok, all apps, particularly social media ones, engage in data harvesting to a certain degree. They all ask for certain accesses and permissions – camera, mic, contacts, location information, etc. – upon installation, ostensibly to feed the multibillion-dollar marketing machine that underpins the digital economy. But most users are too focused on getting on with their day to fully read and appreciate what they’re consenting to, or the privacy implications of that consent.

But TikTok presents two unique concerns for businesses. First, it collects far more data than equivalent social media apps. Second, unlike most American-owned social platforms, TikTok is owned by a Chinese company, ByteDance. And as Chinese companies are all required by Chinese law to hand over data if the Chinese government requests it, it presents the very real risk that an employee’s lunchtime video habit could lead directly to corporate data ending up on a Chinese server and accessed by Chinese government officials. From a cybersecurity standpoint, this is terrifying!

This is no longer about delivering targeted ads to sell us stuff we never asked for. It’s about a foreign government with a troubling human rights track record potentially getting its hands on our organizational secrets.

Now, ByteDance rather vehemently denies end-user data is stored in China. Senior leaders have said data from North American users is stored on servers in the U.S. and in Singapore. They further deny they have any deal with the Chinese government, or that they’ve ever been asked to hand over data. They say if they were asked, they would refuse.

But audio recordings leaked from dozens of internal TikTok meetings last year showed employees in China repeatedly accessed data via a number of backdoors built into the platform.

Should organizations, then, trust that their data isn’t being stored and shared within Chinese borders? No. Should they worry that TikTok-using employees are making it possible at all for the data to be shared in the first place? Absolutely.

A LONG OVERDUE CONVERSATION

To be fair, every app represents a potential source of data leakage. While TikTok’s uniquely data-hungry architecture and the geography of its ownership may raise the stakes, the broader issue – where all apps deserve tighter scrutiny – should rank higher on corporate IT’s radar than it currently does.

Organizations that establish well-understood frameworks around appropriate mobile app usage will stay ahead of this fast-evolving threat. Acceptable use policies should clearly define what can and cannot be installed on an organizationally provided device. Similar frameworks should also be implemented for employee-owned devices that are used to access organizational resources.

Apps should be approved based on a simple ROI basis: if the benefit to the business outweighs the risks and related drawbacks of having apps on the device in the first place, then they deserve to be considered in-scope. Similarly, it may turn out that some roles justify certain apps being installed, while others do not. For example, marketing employees responsible for maintaining an organization’s social media presence may have a legitimate reason to use TikTok. But an accountant who just wants to kill time in between meetings would not. 

THE BOTTOM LINE

Whatever the role or the use case, apps that present a clear a present danger to organizational data integrity need to be identified and carefully managed – if not outright banned. Organizations can rein in some app-related risks by dialing back the security settings on end-user devices. It is almost never an all-or-nothing proposition: most apps will continue to work – albeit somewhat less conveniently – even if data tracking and location awareness are deactivated.

It isn’t realistic to expect over a billion people worldwide to suddenly quit TikTok cold turkey. But the rising tide of restrictive new rules being enacted by governments around the world should give pause to business leaders concerned about the pervasive risks of unchecked app use by their employees.

At the very least, it should spark an initial conversation. As a next step, organizations would do well to start tightening their end-user security profiles as they work to educate employees to the risks these seemingly benign apps present.

In fact, there’s nothing benign about them, and the TikTok controversy should serve as a stark reminder to organizations to start taking cybersecurity a lot more seriously than they have been to-date.

Our STEP Software experts work closely every day with clients to identify risk areas within their software estates, then reliably address any gaps. Reach out if you’d like to discuss your own end-user needs.

The post TikTok bans are a long overdue wakeup call for mobile security first appeared on STEP Software.

Using sensors, cameras, and software algorithms, Microsoft’s “Meeting Insight Computing System” (MICS) will collect data on each meeting participant’s body language, expressions, and participation level. MICS will also track how much time attendees spend on activities that are not meeting-related, such as texting or reading email. For remote meeting participants, MICS factors in whether or not they activate their cameras. The system will also take environmental factors into consideration, including the temperature and level of noise in a meeting room. Meeting time is also considered. A hot meeting room, a room with a distracting level of noise, or a meeting running into lunch hour could affect the attendees’ levels of participation.

THE SYSTEM’S STATED PURPOSE ACCORDING TO MICROSOFT’S PATENT FILING

Statements in the application filed by Microsoft with the U. S. Patent Office, available for review at patents.google.com/patent/US10735211B2/en?oq=10735211, provide detailed information about the type of data MICS collects and how MICS uses the information to evaluate the effectiveness of meetings. The application identifies shortcomings of traditional meeting scheduling tools that do not provide any input to the organizer as to whether a meeting is likely to be productive.

Microsoft’s patent application does not provide details regarding the protection of potentially sensitive data that MICS may collect, but the fact that this is not part of the patent application does not mean that they have not considered the issue. The application simply focuses on how MICS will increase the effectiveness of meetings, not on potential issues associated with personal privacy.

THE ARGUMENTS FOR AND AGAINST

Some will assert that employees who do not like being observed and evaluated by an application like MICS can simply quit and take a job elsewhere. After all, aside from evaluating the attendees’ level of interest and participation, how else could technology be used to measure the effectiveness of a meeting?

Others, however, may be concerned that the level of surveillance capabilities to be offered by MICS is excessive and that this is a slippery slope. Should its use become common in the workplace, the negative impact could be significant. An argument can be made that, because each person is different, allowing Microsoft to establish a single set of parameters by which to evaluate all meeting attendees is not appropriate. If, for example, a 25-year-old and a 60-year-old attend a meeting, chances are good that the former will check messages on his or her phone much more often than the latter, potentially indicating that the 25-year-old is distracted and not participating. Will this later be used against the younger employee? What if the younger employee was already familiar with the material being presented and doesn’t necessarily need to pay close attention? Are the algorithms used by MICS sophisticated enough to take these factors into consideration?

CONCLUSION

Despite Microsoft’s assertions in the patent application that the purpose of MICS is to evaluate meetings, not employees, concern over how the employee data could be used is to be expected. Will the information collected be considered in performance evaluations? Could repeated “low participation scores” form the basis for disciplinary actions? If so, are the MICS algorithms “intelligent” enough to take into consideration the natural differences between individuals or is everyone measured based on the same set of parameters created by Microsoft developers?

Technology impacts virtually all aspects of daily life, with data being continuously collected, shared, sold, and stolen. When systems like MICS emerge, they naturally evoke renewed concerns about the erosion of personal privacy and how much data collection is too much.

NOTE: This article includes only a brief summary of the information in Microsoft’s patent application regarding the data MICS would collect and how the information would be evaluated. Readers interested in learning more are encouraged to review the full text of the application, publicly available online.

The post Privacy Concerns: New Technology to Grade Meetings Through Surveillance of Attendees first appeared on STEP Software.