Windows, Windows Phone, App Studio, Privacy Policies, Certification and legal responsibilities

At some point, probably in the not too distant future, the privacy of app data is going to become a seriously important issue. Some country or another is going to suddenly clamp down hard or a developer who should have known better is going to do something silly and end up getting taken to court and made an example of.

Why am I saying this?
Because I've been thinking about privacy policies and how they are referred to in apps created with App Studio.


In case you are developing apps and didn't realise it, you almost certainly need a privacy policy for your app.

If your app connects over the internet you definitely (supposedly?*) need one for it to be certified in the store.

App policies for Windows Phone 2.8.1

If your app has the technical ability to transmit data to you or a third party, you must maintain a privacy policy. This can be hosted within or directly linked from the app. The privacy policy must be accessible from your app at any time. App capability declarations that make your app network-capable include: internetClient, internetClientServer, privateNetworkClientServer, and ID_CAP_NETWORKING. Your privacy policy must inform users of the personal information accessed or transmitted by your app and how that information is used, stored, secured and disclosed, and describe the controls that users have over the use and sharing of their information, how they may access their information, and it must comply with applicable laws and regulations.

App certification requirements for the Windows Store

4.1.1 Your app must have a privacy statement if it is network-capable
If your app has the technical ability to transmit data to you or a third party, you must maintain a privacy policy. You must provide access to your privacy policy in the Description page of your app, as well as in the app’s settings as displayed in the Windows Settings charm.
App capability declarations that make your app network-capable include: internetClient, internetClientServer and privateNetworkClientServer.
Your privacy policy must inform users of the personal information accessed or transmitted by your app and how that information is used, stored, secured and disclosed, and describe the controls that users have over the use and sharing of their information, how they may access their information, and it must comply with applicable laws and regulations.

* I say "supposedly" because this isn't checked or enforced.

In that the store's have a space for the developer to enter the required privacy policy link then would it not be reasonable that when an app is submitted the URL becomes mandatory for apps which have a networking capability? (The store can easily detect his capability when an app is submitted.)

Is this a widespread issue?
Yes. Take a publisher. For the sake of an example let's look at "Microsoft Corporation". Take a look at their apps in the Windows Phone Store. For some you'll see they're breaking their own requirements and not including the required privacy policy link.

With App Studio apps (where I started this explorations) it's even worse.
For many such apps that make it into the store you'll find no privacy policy whatsoever. In the app bar there's also a "privacy" option but tapping it does nothing as they haven't added a link.

For a few apps you'll be directed to http://appstudio.windows.com/en-us/home/appprivacyterms
I'm not a lawyer (obviously) but this seems inadequate and overly vague. It doesn't even (IMHO) meet the store certification requirements for a privacy policy. At best it just defers any responsibility from any privacy related issues from Microsoft and onto the developer. It doesn't help the developer know what they should be declaring or even help them create an app without broken links in it's menu.


The app studio agreement also highlights the developers responsibility regarding the need for a privacy policy in two places:


II.1.a.3:

The Application must comply with the applicable laws of each jurisdiction into which you choose to make the Application available, including (i) export control laws; (ii) data protection, privacy, and other laws and regulations relating to collection and use of user information by your Application; (iii) telecommunications laws; and (iv) content ratings regulations. 

II.2.c:

Terms of Use and Privacy Policy. If you distribute an Application that enables access to and use of Internet-based or mobile services or otherwise collects and/or transmits user information to you or a third party, you are responsible for informing Development Partners and Application Recipients of your terms of use and privacy policy. At a minimum, you must maintain a privacy policy that (i) complies with applicable laws and regulations, (ii) informs users of the information collected by your Application and how that information is used, stored, secured, and disclosed, and (iii) describes the controls that users have over the use and sharing of their information and how they may access their information.

If you're publishing an app (including or maybe especially if it's created via App Studio) you need to consider what should be in your privacy policy.



Also though, don't you think Microsoft could and should be doing more to help developers? Most of whom are individuals who don't have the resources or knowledge to do a sufficient job in this area on their own.
It would also be nice to see the store enforcing its own policies - or at least helping flag to developers where they need to provide something, Especially when this can be done in an automated way.



I'm not a lawyer - this isn't legal advice. (It's advice to seek legal advice.)
You may (probably) need actual, bona fide legal advice for your app (business).
Seek it from someone suitably qualified. Not just some random blog! ;)

Comparing WP7 stats: AdDuplex and Microsoft

Last month, both Microsoft and AdDuplex released statistics which include figures for Windows Phone 7.X usage.
As a number of developers and companies are starting to think more about how long they continue to support WP7.x devices (I've spoken with a few recently) I thought it was worth looking at this subject in a bit of detail and to consider why the figures from Microsoft and AdDuplex are so different.

Let's start by looking at those figures.

Microsoft claim that "Windows Phone devices running OS 7.x represent less than 5% of all downloads."

AdDuplex (on slide 6) say Windows Phone 7 has a 15.2% share of the OS market.

"15.2" and "less than 5" are quite different. One is more than 3 times the other.
So why could this be?

The answer of course is that I'm not comparing like with like.

Microsoft are reporting that 5% of downloads come from WP7 devices.
AdDuplex are reporting that 15% of app usage is done on WP7 devices.


Downloads and usage are very different.

• An app is (typically) only downloaded once per user but (hopefully) will be used many times.
• Due to the nature of the apps that AdDuplex collects data from (ones that show adverts) this may skew the results in favour of devices used over longer periods of time. (Which is a factor that makes showing ads a more viable monetization strategy.)
• There is an anecdotally supported and widely held opinion that people download more apps when their devices are new. Given that anyone with a WP7 device has likely had it for more than a year I'm surprised it's still this high. (Maybe the second hand market and hand-me-down scenarios are meaning many people are still getting devices that are new to them.)

So, should you still support WP7 devices?
Let's look at some scenarios:

If you're building a new app that needs WP8 specific features then you obviously can't.

If  you're building a new app that doesn't need WP8 specific features then it comes down to considering whether the opportunity to have your app available to 1 in 20 more people is worth the effort (of development, maintenance, support, etc.).

If you have a WP7 app that you're considering dropping support for then it will come down to the potential costs and impact of any potential future problems or issues anyone using the app may have.

If you have a WP7 app that you're considering removing from the store then it will come down to whether you actively want to stop 1 in 20 people potentially downloading the app. Note that this will also prevent people from uninstalling and then reinstalling the app. I know some people use this a documented solution to some issues and so may be an issue.

If you have a WP7 app that you're considering disabling then it will come down to the potential costs and impact of stopping some people from using the app. Hopefully you've got analytics in your app to tell you this. If you haven't then AdDuplex's figure of 15% is very close to numbers I've seen for apps that have been around for about 3 years.

Of course this isn't a complete list (technical issues and commercial pressures can also have an impact) but hopefully this covers the majority of scenarios.

SVG to XAML conversion

Notes for my reference as I only do this every now and again and have to look it up every time.

[Updated]
Ignore the below.
Inkscape can export to XAML!
- thanks @AwesomeDevsigner


--------  Ignore the below, it's far more complicated than it need be --------

1. Open .svg in Inkscape
2. Save as .pdf
3. Change file extension to .ai
4. Import in Blend
   OR
   Import into Expression Design (Adobe Illustrator-PDF compatible)
5. [If in Expression Blend] Export as XAML

Why I've become an AdDuplex Advocate

Starting this week, I'm now a Developer Advocate for AdDuplex.

What does this mean?
It means you may now find me talking more about AdDuplex and I am available to help if you have any questions or technical issues.

Who or what is AdDuplex?

"AdDuplex is a cross-promotion network specifically targeted at Windows 8 and Windows Phone apps and games. It empowers developers to promote apps for free by helping each other."

You simply register and add a control to your app. The control in your app shows ads for other apps and in return the other apps show ads for your app. A few paid ads are also displayed to fund the service.

Why am I doing this?
Firstly because I believe that AdDuplex is a great service and has the potential to benefit lots of developers.
Also, because AdDuplex solves two important problems.

1. Many developers struggle with knowing where and how to promote their apps. AdDuplex provides a very simple way to help developers do this.
2. Most advertisers can't guarantee 100% fill rate. AdDuplex can. If you've got an app that you're monetising with adverts then there will be times that your ad provider doesn't have an advertfor you to display. So what happens then? Without a fallback you'll end up with unused ad space. If you use AdDuplex as a backup (AdRotator could help here) for when your other provider doesn't have anything to show then rather than completely wasting an advertising opportunity you are using it to help promote your app.

What can I do for you?
If you aren't already registered and using AdDuplex then please get in touch (@mrlacey or via 'matt [at] catchyagency [dot] com') and I'll send you a promo code to use when you register. This will give your apps extra exposure for the next six months!

If you have already registered please get in touch and tell me about the apps you've published that include the control. I'll have promotional opportunities for you in the coming weeks and the sooner you get in touch the more promotion I'll be able to give your apps.

What about other things I do?
None of that will change or stop because of this.
I'm still doing contract development work.
I'll still be organising Windows Apps London.

Book Review: Designing Mobile Payment Experiences - Skip Allums

Cross-posted from http://windowsapps.london/2014/10/13/book-review-designing-mobile-payment-experiences-skip-allums/

Back in the late nineties I worked on a system that produced store gift cards/vouchers. Fast forward to 2008-9 and I was working on mobile payments, NFC payments, stored value cards on mobiles and even custom software for chip and pin terminals. More recently I've worked with a number of banks and money transfer services to build them mobile apps. (There are more than a couple of screenshots in the book that look VERY familiar!)
All in all it's fair to say I have an interest and background in working with mobile payment solutions.
When I first heard about this book I became very interested. Mobile payment and money transfer is an area which I expect to grow considerably in the next few years and the recent announcements by Apple, with the iPhone 6, will only help fuel interest in this area and speed up growth.

The book is relatively short at just 7 chapters and a little over 200 pages but it's packed with useful information.

The first chapter starts the book by providing some background on the history of money and how and why it is used. It provides the perfect grounding for the rest of the book.

The second chapter introduces the three payment types covered in the book: NFC; Cloud : and Closed loop. The description of each of these is intermingled with a few UX notes dotted about. I think it would have been nicer to have made the UX points stand out more. As I am familiar with the payment options and their pros and cons I would have liked to see the UX tips stand out more form the text so I didn't risk skipping over them as I skimmed a paragraph about a subject I am already familiar with.

The third chapter is the first to provide some easy take-aways for the reader. It analyses the strengths and weaknesses of the design, payments, feedback and security aspects of popular mobile payment solutions available today in the US. Namely Google Wallet, ISIS, PayPal, LevelUp, Starbucks and GoWallet.

The fourth chapter is about building trust into mobile payments. It was while reading this chapter that I realized I had been reading this book with my "developers hat" on, rather than one of a designer. I think of myself as a developer who wants to understand design. I also hope that more developers take an interest in design and how it impacts what they are developing. Anyway, this chapter diverged from what I was expecting and had a strong focus on the psychology of the consumer (or person using the app). I found it really useful to have this focus and the idea of designing for the most common security concerns people have with mobile payments was explored in depth in the rest of the chapter.

The fifth chapter is about actually designing successful payment interactions. The chapter is full of useful advice if creating an interaction using NFC, Bar or QR codes, or geolocation. It even made me smile as I remembered back to building an app that displayed barcodes on an iPhone and testing it in actual supermarkets. I'm sure with the information from this chapter I could revisit many past applications and create improvements. My only criticism would be that it would be nice to touch upon iBeacons or similar when also focusing on geolocation as that would, I suspect, address some of the issues of a geolocation approach. (e.g. getting the wrong neighboring store.)

Chapter six feels somewhat of a mish-mash of topics. This is probably due to the nature of the chapter being about additional services that can be provided with a payment experience to bring a richer and more valuable user engagement. Depending on the original app or services purpose is will affect what additional services are appropriate. This chapter provides guidance on: managing finances; rewarding loyalty; offers and coupons; and travel.

The final chapter looks to the future. As Apple has such an influence in the mobile space (especially in the US - the market this book focuses on) it is right that there is talk about what Apple may do. (This includes consideration for iBeacons-as noted earlier.) Then there's speculation on what may come from MCX (the Merchant Customer Exchange) and Facebook. The chapter concludes with a look at wearable devices and bio-metrics and how they may be part of payment experiences in the future. As it's still early days for these technologies the book provides no specific guidance in using them though.


All in all a useful book. If you are, or are likely to be working with mobile payment with regard to mobile devices and apps then I recommend you buy and read this book.


There is also a website by the author that contains additional content (via a blog) and a collection of mobile wallet & payment UI design patterns: http://mobilepaymentux.com/



Disclaimer: The copy of this book was supplied for review as part of the O'Reilly User Group/Community program.

Is your mobile app as secure as you think? #NDCLondon

This December, NDC is returning to London and I'm speaking along with some fantastic other speakers.

I'll be talking about mobile security:

News stories of security vulnerabilities in mobile apps are becoming more common and their impact risks affecting more and more business and consumers. It doesn't have to be this way.
There are solutions to all the common security issues in mobile but sometimes we need to be made aware of what the issues are and how they can be prevented.
That's what I'll show in this talk.
I'll draw on more than twelve years personal experience building apps for a wide variety of industries and the accumulated knowledge of the OWASP Mobile Security Project.
We'll look at some examples of the common security mistakes apps on iOS, Android and Windows have made and then show practical examples of how to address the issues.
You'll leave this session wanting to review the security of your mobile apps but armed with the knowledge to make improvements and fix some security holes.

The conference runs for 3 days with 2 days of workshops beforehand.

If you order your ticket before Oct 15th you can also benefit from early bird pricing.

I attended the conference last year and it was great. I'm expecting that this year things will be even better!

See you there.