Friday, March 14, 2014

Application Analytics: Security and Privacy for All

In my previous post, I tried to illustrate the distinction between required capabilities and desired capabilities – and how, with application analytics, this distinction is particularly tricky since true requirements are more likely to come from the users of apps versus the developers of apps (the latter being the app analytics customer and the former – app end users – are often completely out of reach from the analytics solution provider).

I also posited that the most common areas where end user requirements drive important app analytics requirements fall into performance, quality, security, and privacy domains.

In this post, I’m going to drill down into security and privacy a bit. Let’s break out the application analytics supply chain into four parts; Telemetry creation, ingestion, processing, and publication.
  • Telemetry creation (where the app itself or an external agent actually creates the raw telemetry)
  • Ingestion (the steps required to bundle, transport, and deliver the raw data for processing)
  • Processing (parsing, indexing, computing, aggregating, storage, etc. required to transform raw telemetry into publish-ready data) 
  • Publication (the selection, transformation, formatting, and delivery of targeted data to a specific user or external system)

Figure 1: Application Analytics Supply Chain: the dicey part is that application telemetry is typically collected in the context of the “App User’s” world subject to their expectations for privacy, security, etc. and then must be delivered across a great divide into the “App Analytics” user’s world. Application analytics solutions must enforce whatever "app user" policies are required during app usage, then navigate the ingestion process that typically bridges the two worlds, and finally help maintain whatever data governance obligations app users (or their legislatures) require. 

PreEmptive Analytics

To make this “real” and for illustration purposes – here’s a summary of the features offered within PreEmptive Analytics that target these security and privacy challenges. 

Telemetry Creation

Application instrumentation

Activation: No “accidental” or “inadvertent” application monitoring. Application instrumentation is typically accomplished through post-compile injection. The default setting is “off.” In other words, injection must be manually activated avoiding “accidental” application instrumentation. 

Configuration: No data, other than what is explicitly requested by development, is ever transmitted. Once “activated,” each individual data component must then be explicitly identified for data capture. This is true for either the injection pattern or when using the PreEmptive Analytics API directly inside an app’s code. 


Definition: PreEmptive Analytics “opt-in” requires a Boolean “True” value to be set before any data monitoring functionality is initiated (which is prior to transmission). The default value of this setting is “False” and must be explicitly reset by the application at the start of every application session. There are, in fact, two opt-in settings. The first covers general usage and the second covers exception monitoring.
  • Application usage: opt-in covers session, feature and system data previously identified by development prior to deployment. 
  • Exception monitoring: opt-in covers unhandled, caught and thrown exception data previously identified by development prior to deployment. 

Privacy Policy

PreEmptive Analytics permits development to encode a link to the company’s own privacy policy that can be communicated to an end-user prior (or during) a request for an informed consent to opt-in. 


Data transmission

SSL Encryption: by default, all data transmitted from an application to an endpoint is first encrypted before transmission. This can only be overridden by development prior to the release of the application. 

Content Management

Runtime data collected for management and analysis is owned by the development organization. PreEmptive Solutions has no access and no rights to reuse runtime data – either in part or in aggregate.
  • On-premises: Endpoints that are “on-premises” or “client-managed” are completely under the development organization’s control. 
  • Managed service: Data managed by endpoints owned by PreEmptive Solutions are managed solely for our clients’ benefit. There is no other access or use authorized or permitted. 


In addition to PreEmptive component localized authentication, application, identity, and role-based frameworks are respected and enforced, e.g. you cannot provision a TFS project of PreEmptive Analytics without (at least) Admin privileges for that TFS project.

Application security (bonus)

In addition to the thorough, “end-to-end,” approach to information security and privacy, PreEmptive Solutions also provides technology and associated controls to minimize the risk of application reverse engineering or tampering that may lead to the disclosure of application vulnerabilities that can be exploited or the tampering (modification) of applications to alter behavior (to introduce exploitable vulnerabilities where none had previously existed). These include: 

Preventative controls

Obfuscation: prevents reverse engineering and recompilation. 

Detective controls

Tamper detection and defense: provides real-time defense and alert notification when application tampering (modification post-compile) has been detected.

Taken as a whole, PreEmptive Analytics is designed to provide a complete and comprehensive application analytics security and privacy solution – built to encode and enforce the wide variety (and ever-evolving) application and information security and privacy policies, mandates and controls.

As application analytics evolves beyond tracking marketing funnels on the internet, the entire application analytics pipeline will (must) be governed by the same security and privacy policies as the applications they are monitoring and the business and operational content that your organization is managing.

Thursday, March 13, 2014

Application Analytics: fulfilling your every desire

We need to take care in how we use the term “requirement” in development. Development requirements are really carefully crafted descriptions (distillations) of the “behaviors we care about.” They get assigned priorities and scheduled and (typically) only a small number of requirements are actually implemented in any given app release.

Ddevelopment requirements are usually NOT required

Here’s my beef - development requirements are usually NOT required – they are, in fact, desired. …development’s goal is to fulfill desires – but desires are emotional and so we try to use requirements in their place (requirements are for the most part concrete and objectively measured). …of course, we can nail “requirements” and still build the wrong thing and fail – so development cannot escape their true lot in life - to build the most desirable apps possible – and app analytics suppliers are no different – we are subject to the same laws as every other development niche (it’s just that our users are all app stakeholders of some sort with their own users that are not our users).

A silent killer of application analytics implementations

…and herein lies a silent killer of application analytics implementations (and what sets this specialty apart from other analytics categories); app stakeholders care more about app user satisfaction than the app users themselves.

Think about it, if an app user doesn’t like an app, they just stop using it (or go with a competitor). …but when users drop your app, you’re out of a job. So – before an app analytics provider can even think about fulfilling their users’ desires – they must first ensure (and prove) that they “do no harm” to this murky, extended user community once removed; and this is a genuine “requirement” in the truest sense of the word.

Why is this a “silent killer” that exclusively stalks application analytics implementations? Because application instrumentation (the generator of raw telemetry – step one of any app analytics implementation) must either run inside a client’s application (or inside the same runtime “looking in”) – application instrumentation can never be a part FROM runtime applications – it is unavoidably a part OF each runtime application. …and, application user desires are not the desires of application analytics users.

…so, as the great Stevie Wonder has written in Songs in the Key of Life (As), “…make sure when you say you're in it but not of it You're not helping to make this earth a place sometimes called Hell.”

It is a true requirement that app analytics instrumentation cannot, in any way, impact an app user’s satisfaction. If (and only if) this requirement is satisfied, will an app analytics solution be given the opportunity to fulfill its users’ desires (desires like “show me feature usage” or “send me exceptions”).

How can instrumentation fail? Lots of ways sadly – but the most common revolve around performance, stability, security, and privacy at runtime (recall that the expectations that must be met are those of the app user – NOT the app stakeholder).

Stay tuned – I’ll be posting my suggestions on how to distinguish what you may require from what you may desire.