Archive for the 'Apps' Category

European guidance on mobile apps and privacy

The Article 29 Working Party (the “A29WP”), a grouping of representatives from the various European data protection regulators, recently issued an opinion on apps on smart devices.

There are two constants with the A29WP’s opinions:

  • Firstly, although often presented as such, they are not an authorative statement of the law. They simply set out the collective (sometimes aspirational) interpretation of the European data protection directive.
  • Secondly, the opinions set out a far stricter interpretation of the directive than that usually taken by the UK’s Information Commissioner’s Office (ICO). This reflects the fact that the ICO usually takes a more business friendly/pragmatic approach to interpreting the law than some of its European counterparts.

That said, the latest opinion provides some useful guidance for app developers, and builds on previous guidance from California’s attorney general and the GSMA, which I summarised in this blog post last year.

The guidance also follows on from the so-called Cookie Law, which (contrary to popular opinion) also applies to mobile apps.

Why do mobile apps raise privacy concerns?
As I noted in that blogpost, there are a number of reasons for the current privacy deficiencies with mobile apps:

  • The market is immature, with many apps developed by individuals or small companies not familiar with privacy laws, but whose products have become hugely popular.
  • The distribution model is fragmented and apps frequently incorporate third party services (for example, mapping providers) into their functionality. SDKs and OS developer rules impose strict controls on developers, yet they don’t provide the necessary tools to ensure that developers adopt privacy by design.
  • The mobile app market has developed at the same time as a vast expansion in the data created by devices, such as geolocation data.
  • Many app developers are located outside the EU and are therefore unfamiliar with European privacy rules, despite the fact that they are selling their apps to users in the EU.

A29WP’s recommendations
The opinion imposes a number of requirements on app developers. These include:

  • App developers must understand their obligations as data controllers when they process data from and about users.
  • Freely given, specific and informed consent must be sought before an app is stalled.
  • Granular consent must be obtained for each specific category of data that the app will access.
  • The user must be provided with well-defined details of the purposes for which data will be processed before the app is installed. General purposes such as “product innovation” or “market research” are, in the A29WP’s opinion, not sufficient.
  • The purposes for which data is processed must not be changed without obtaining new consent from the user.
  • Users must be provided with a readable, understandable and easily accessibile privacy policy, which includes
  • Allow users to revoke their consent and uninstall the app and delte data where appropriate.
  • Incorporate data minimisation and privacy by design/default.

Part of the problem with these requirements is that some of them are impossible to achieve in practice as they are dependant upon the design of the app store and OS ecosystem. For example, the way in which most smart device operating systems install apps means that there is no opportunity in the app purchase system to notify users about data use and obtain consent. This could be set out in the app licence terms of use, but given the low profile given to such licence terms in the app store purchase process, this wouldn’t meet the A29WP’s own recommmendations on obtaining consent.

This is presumably why the opinion also sets out a number of requirements on app stores and OS and device manufacturers, even though there appears to be little base in law for such requirements (the neither party is a data controller in relation to data primarily processed by the app/the app developer).

These requirements, for example, oblige app stores to check that app developers have incorporated appropriate consent mechanisms, and obligations on OS manufacturers to build additional controls into their OS APIs to facilitate consent to access data on the device.

The practical approach
In my view, given these technical limitations, it is more pragmatic to recommend that app developers design apps so that the privacy policy is displayed, and consent obtained, when the app is first opened, and that no data is captured until this takes place. This way, app developers can be sure that they do not inadvertently collect data without consent.

The opinion also skims over one of the other big issues with mobile apps – the use of third party services. In many cases, I suspect that app developers simply aren’t aware of which party is responsible for data protection compliance. Where third party services are utilised (for example, mapping or geolocation), there will often be multiple data controllers. However, the app developer is the party that controls the primary interface with those third parties and therefore needs to flag the terms on which such third parties will use the data collected.

Given the opacity of the policies provided by many third party service providers (and the lack of clear guidance from regulators when the revised cookie law came into force), working this out is often difficult.

You can read the A29WP’s opinion in full by following this link (PDF). If you are an app developer and would like to discuss how your app collects data, and what you can do to ensure that it complies with EU data protection law, please get in touch.

Martin Sloan

Will the proposed EU directive on web accessibility lead to confusion and hinder innovation?

Following on from my blogpost last month on the European Commission’s draft directive on the accessibility of public sector websites, I have an article in the forthcoming edition of C&L Magazine, the journal for the Society of Computers and the Law.

Under the proposed directive, new EU-wide rules will be introduced setting out specific requirements in relation to the accessibility of certain websites operated by public sector organisations. In the article, I analyse the impact of the proposed directive on public authorities.

If implemented as it currently stands, the directive raises a number of concerns:

  • Firstly, organisations are presumed to comply with the new law if they achieve Level AA conformance with the W3C‘s Web Content Accessibility Guidelines 2.0 (WCAG). The problem with WCAG is that whilst they provide a good starting point for accessible design, they are only one part of the wider accessibility jigsaw. Indeed, legislating in a manner that requires compliance with a fixed set of technical guidelines is concerning, because WCAG (and therefore the law) will inevitably fail to keep up with evolving technologies for delivering online services (for example, mobile or rich media).
  • This approach could have been mitigated by allowing organisations to deviate from WCAG compliance, if they can justify why this is an appropriate thing to do (as the UK Equality Act provides), but the draft directive does not provide such flexibility.
  • Finally, and perhaps more concerningly, the directive does not explain how it is intended to interact with pre-existing national laws that apply to the accessibility of services provided over the web, where a breach is based on actual discrimination taking place. This creates the very real risk that a public authority could comply with the requirements of the directive, whilst simulateously being in breach of its obligations under the Equality Act (or vice versa).

Whilst the directive may help achieve the Commission’s primary stated aim of removing barriers in the market for the provision of web development services in the EU (by ensuring that public sector organisations are obliged to set standardised technical criteria for accessibility), the directive is a fairly blunt instrument. I remain unconvinced that the directive will have such a positive impact upon the accessibility of websites to users with disabilities.

A far better approach would be to look at adopting the guidance contained in the British Standards Institute’s British standard on commissioning accessible websites.

You can read the article in full on the SCL website.

Martin Sloan

IPR infringement and mobile apps – why Apple provides an online reporting tool

Last week’s iOS Dev Weekly email contained an item on the online facility provided by Apple to allow you to report alleged IPR infringement issues with apps on the App Store:

…If you are having copyright or trademark issues [or in fact any other IPR] with your app Apple now have a dedicated App Store process for dealing with this. What I found interesting about the description of this is that it states that it will put you directly in contact with the provider of the disputed app. Surprising.

From Apple’s perspective, this actually makes a lot of sense. Here’s why.

Pretty much anyone can publish an app for distribution by Apple through the App Store. However, whilst Apple does do some quality control on apps that are submitted, it doesn’t have the resources (or time) to carry out an indepth analysis of whether the submitted app infringes any third party IPR. It simply isn’t cost effective for Apple to do so, given the global nature of the App Store – researching whether a particular app infringed third party copyright, patents or trade marks in various countries around the world would cost many, many, thousands of dollars.

This means that there is a very real risk that apps available for sale on the App Store might infringe a third party’s IPR – whether through deliberate infringement, unintended copying, being unaware of a pre-existing patent (whether in the same territory or abroad) or simply the sale of an app by, say, a British registered trade mark holder in a country where the trade mark in question is already owned by someone else.

The dispute process
When an IPR infringement claim does come to light, for the reasons given above it is not practical for Apple to investigate it. It just isn’t worth its while as there’s no financial benefit to Apple from doing so, and Apple is unlikely to have the information required to respond to the complaint. So, instead, it makes much more sense for Apple to provide a facility for complainers to submit a claim straight to the person or organisation that submitted the allegedly infringing app so that the two parties can sort out the dispute directly.

In the meantime, in my experience Apple will suspend (or threaten to suspend) the allegedly infringing app. This keeps Apple in the clear in terms of any alleged infringement by Apple (remember, Apple is simply an agent (or Commissionaire) – it doesn’t licence/sublicence non-Apple apps to end users) and its obligations under the DMCA, as it has taken action as soon as it became aware of the issue, and puts the onus on the recipient of the infringement claim to sort it out so that it can get its app back on the market.

Of course this approach isn’t without its problems – particularly for those on the receiving end of an infringement claim, as the online reporting tool is open to vexatious and frivolous claims, with the onus on the recipient to then demonstrate to Apple that there isn’t an issue. But for aggrieved rights holders it provides an effective way of raising IPR infringement issues directly with the alleged infringer.

Be prepared
It also emphasises the importance of thinking about your IPR before you launch your app.

Are you comfortable that your chosen brand won’t infringe that of a third party? Have you thought about who owns IPR in foreign jurisdictions before you launch an app globally? Are you sure that any third party code utilised in your app is properly licensed? Have your developers assigned across ownership of any code they create? Have you taken steps to register any regiserable IPR that you create?

To learn more about protecting your IPR, download our free guide.

PS It’s not just Apple. A quick check reveals similar facilities on Google Play for copyright infringement and trade mark infringment (although on the latter it appears that Google will actually carry out some investigation itself).

Does the move to app stores inhibit software development and competition?

Microsoft today confirmed its launch hardware partners for its new touch screen/ARM based version of Windows, Windows RT (is this a subliminal advertising campaign by Microsoft to encourage people to promote Windows on Twitter?).

At the end of the BBC News article linked to above, a comment is made about the fact that Microsoft has locked down software distribution on the platform. As pioneered by Apple on the iOS platform, apps for Windows RT may only be distributed through a Microsoft controlled app store, in return for which Microsoft will take the now standard 30% commission.

The article includes a comment from a couple of games industry executives, who label the decision a “catastrophe”, “not awesome” and a “wrongheaded approach”.

So does this mean that games and app developers will turn away from the new platform?

The games industry and app stores
Last week, I was at Edinburgh Interactive one of the UK’s major video games industry conferences.

What struck me was how many of the speakers (from both large and small developers) are focussing their development efforts on the iOS and Android platforms. There was very little discussion in the sessions about the development of games for consoles and PCs. It was all about iPads, iPhones, Android and promoting your product on the app stores. And the future sounded pretty bright.

Indeed, a large amount of discussion on the first day looked at the move to so-called “freemium” products, where the app is free to download and the developer then makes its cash from selling in in-app content (such as additional levels, power-ups etc) or in-app advertising.

So it seems that not everyone agrees with the view of the larger games companies – or if they do then they are prepared to accept the commercial model in order to access the new platforms.

Indeed, for smaller indies, the app stores operated by Google and Apple offer an easy way to market. You can self-publish, without the need for a traditional middle-man to publish your game, and don’t need to fund expensive promotions in bricks and mortar stores – instead using social media and word of mouth to promote your app. This reduces the risk to the developer and fosters the development of innovative new products.

The 30% margin is high (particuarly given that it also now often includes a share of revenue from in-app purchases), but given the sales platform provided (and the fact that the app store will handle all payment processing), for many developers the cost is worth it.

In reality, I suspect the comments quoted above reflect commercial concerns over the fact that the publisher’s margin for Windows products is now under attack. They can no longer sell games to consumers direct from its own website – it is a return to the pre-internet days where a distributor and a bricks and mortar retailer also took a cut.

Competition law
What will be interesting is whether any of the competition authorities look at the cast iron control the operating system providers have over the sale of content on their platforms, and whether this constitutes an abuse of a dominant position. Unlike the Android platform (where there are multiple app stores), it looks like Microsoft will follow Apple and others in that its app store will be the only way to sell content on the platform. In the absence of any competing app store, the 30% margin cannot be challenged. This could be viewed as anti-competitive.

What do you think? Does the app store model put you off developing for iOS, Android and Windows RT? Or are you prepared to work with the new model to access new markets?

New guidance on cookies that are exempt from consent requirements

The Article 29 Working Party, a grouping of representatives from the various national privacy regulators in Europe, today published an opinion on the “essential cookies” exemption under the cookie law.

Opinions of the Article 29 Working Party have no legal effect, but do represent the joint thinking of the national regulators and in turn can often influence the future direction of European data protection law, and may assist organisations currently grappling with the cookie law.

The law
Under the revised law, the requirements in relation to consent do not apply to cookies that:

  • are used for the sole purpose of carrying out the transmission of a communication over an electronic communications network; or
  • are strictly necessary in order for the provider of an information society service [essentially a website] explicitly requested by the subscriber or user to provide the service.
  • As readers will know from previous Techblog posts, neither the UK implementing regulations or the original directive give much further guidance on what falls within the “strictly necessary” category.

    Accordingly, the Working Party has published its opinion on what it thinks the law is. In addition to listing examples of cookies that are or are not essential (and therefore exempt from the consent requirement), the guidance also analyses factors such as whether the cookie is first and third party, and whether it is as session cookie or persistent. The opinion notes that fact a cookie is third party or persistent is not necessarily fatal to it being “essential” – for example, it may be appropriate for a cookie to persist for a reasonable period of time following the user leaving the website.

    Cookies that are essential
    The opinion lists the following types of cookies as potentially being exempt:

    • user input cookies – cookies used to keep track of a user’s input. For example, the completion of a multi-page form, or a shopping basket on an e-commerce website.
    • authentication cookies – cookies used to identify a use once he has logged in to a website. But cookies used to “remember me” to avoid the need to log in for future visits are not considered “essential.”
    • user-centric security cookies – for example cookies used to detect the number of failed log-ins to a service specifically requested by a user.
    • multimedia player session cookies – cookies used to store technical information (for example network speed, quality and buffering) needed to play video or audio content requested by the user. This might include Flash cookies.
    • load balancing session cookies used to manage server load balancing. This would fall within the first bullet above (the transmission of a communication).
    • UI customisation cookies – cookies used to remember preferences specifically set by a user (for example, language or display preferences set using a button or tick box) and not linked to other data such as the user’s username. The guidance is slightly contradictory here, but it appears to suggest that if the customisation applies longer than the session then he opinion states that consent is required, but this could be done by including a “uses cookies” message next to the button or tick box.
    • social media content sharing cookies – cookies used by social media plug-ins to identify users that are logged in to social media networks and which are used to enable them to share content using that social media network. These cookies should only persist for so long as the user is logged in or “close his browser” (it’s not clear how this equates with a user that asks the social media network to “remember me”), and the exemption will not apply where that cookie is dropped onto the device of a user who is not logged in.

    In each of these cases, the exemption is dependant upon cookie not persisting for longer than necessary and the cookie not also being used for other purposes.

    Cookies that are not essential
    The opinion also lists a number of cookies that, in the eyes of the Article 29 Working Party, are not essential:

    • social plug-in tracking cookies – cookies used to track the activity of logged in users of social networks (for example, for the purposes of targeted advertising, or analytics etc).
    • third party advertising – unsurprisingly, cookies used for third party advertising (that is, advertising served by a domain outside the website in question) are not considered essential. The Working Party is lobbying to ensure that all such cookies are included in the W3C.
    • first party analytics – the opinion confirms the Working Party’s view that first party Analytics cookies (for example, those used for Google Analytics) are not essential and therefore require consent.

    As I noted at the outset of this blog, the Working Party’s opinions have no legal standing, but some of the types of cookies listed as falling within the exemption, and the comments on assessing whether or not a cookie is likely to fall within the exemption should give web site operators some assistance when determining how to implement the changes necessary for their websites. As with the ICO’s recent updated guidance, it’s just a shame that this guidance wasn’t available in the run up to 26 May.

    Mobile apps, accessibility and the Equality Act

    The One Voice for Accessible ICT Coalition has published a report warning that elderly and disabled users are at risk of digital exclusion if mobile apps are not developed with accessibility in mind. The One Voice for Accessible ICT Coalition’s members include accessibility charity Abilitynet, BT, the UK technology trade association Intellect, Lloyds Banking Group and City University London.

    The findings of the report are not surprising, and are reminiscent of similar warnings many years ago when web 1.0 was taking off, and traditional websites contained many accessibility problems. However, given the exponential growth in the use of smartphones (particularly as a low cost alternative to getting online) and the increasing reliance upon delivering services online, the warning is perhaps even more concerning this time around.

    Seven steps to accessibility
    To help mitigate these potential problems, the Coalition advocates that app developers follow their Seven Steps to Accessibility.

    The seven steps are largely common sense, but should help organisations to ensure that accessibility of their apps is factored in at an early stage, particularly when combined with guidance such as BS8878.

    What does the law say?
    The relevant law here is the Equality Act 2010, which obliges service providers not to discriminate against people with disabilities by reason of their disability. It also contains (more limited) obligations not discriminate on the grounds of age.

    The obligations include a duty not to indirectly discriminate against people on the grounds of age or disability, a duty not to discriminate on the terms of service, and an obligation to make reasonable adjustments. You can read more about these duties in this blogpost.

    These duties have interesting implications for evolving areas such as mobile apps, where accessibility technologies and standards are still immature, and are often dependant upon the hardware and software accessibility features built in to the mobile device by the device manufacturer.

    What if a service provider offers a service through a conventional website, which is accessible to all users, but wishes to provide a better mobile solution using a bespoke mobile app? Does the Equality Act work in such a way as to hinder innovation for the wider world by preventing a service provider from launching a mobile app if that app is not accessible to users with disabilities?

    This is something that Jonathan Hassell and I chewed over on World Usability Day last year. Ultimately, each case will depend on its facts but the answer to the question is, I think, no.

    Proportionate means to acheive a legitimate aim
    The duty not to indirectly discriminate against disabled or elderly users applies where:

    A person (A) discriminates against another (B) if A applies to B a provision, criterion or practice which is discriminatory in relation to a relevant protected characteristic of B’s

    However the duty is only infringed where the service provider cannot show that the provision, criterion or practice is “a proportionate means of achieving a legitimate aim”.

    In this case, the service provider’s aim is to improve the ways in which its customers can access its services on the move and when using mobile devices (the “legitimate aim”), and provided that the service provider has given reasonable congniscance to any accessibility measures that are available when designing the mobile app, it is likely that its actions are proportionate.

    This is particularly so where the app is only made available on certain platforms, and where elderly or disabled users can already access the service through other channels such as the conventional website or by telephone.

    So the fact that an app cannot be made accessible to a specific group of users should not stop the service provider from making it available to the wider public.

    Reasonable adjustments
    Whilst an initial mobile app may not be accessible to disabled users, service providers do have a duty, under the reasonable adjustments obligation, to continue to review the means through which they provide services and consider whether any adjustments can be made which will improve the accessibility to users with disablities (this obligation does not apply to potential age discrimination).

    This is an evolving duty, and so requires service providers to take advantage of new technologies and techniques – for example, new hardware or operating system features, and new W3C standards.

    As with conventional websites, service providers should therefore ensure that accessibility improvements are continually reviewed as further versions of the app are developed.

    Apps and privacy – who is responsible?

    California’s attorney general last week announced a new rule, seemingingly agreed with the major apps vendors (Apple, Google/Android, RIM, Windows, HP and Amazon), requiring mobile apps to have in place clearly displayed privacy policies.

    Of course, for those of us in Europe, this is nothing new; European data protection laws have required this for years.

    However, to date many app providers have paid little attention to privacy rules.

    I think this is down to a number of factors:

    • Apps are generally sold through app stores operated by Apple, Google and Microsoft etc – but these companies only act as agents in the sale. When you buy an app, you are buying a licence from the company that made the app – not Apple/Google etc (unless it is one of their own apps). The app store providers are not responsible for that app or how it is used. They just provide the app store infrastructure and provide payment processing services;
    • The app store environment has made it very easy for anyone to create and sell apps – a genuine cottage industry, where a niche app can suddenly become very successful. But many small start-ups will launch an app without properly considering legal and regulatory requirements;
    • App stores tend to operate on a global basis. This means that most app providers are unlikely to be aware of local law requirements in many of the countries in which their app is sold. Use of Apple’s App Store in the UK may be subject to UK specific terms and conditions, but the licence governing the user’s use of the app will often still be subject to US law, with little attention paid to local laws.

    In relation to this last point, data protection law is a good example. There is currently some debate as to whether or not cookies deployed by websites hosted outside the EEA are subject to EU data protection rules. The position with apps is analogous with apps sold by providers outside the EEA. As part of the proposed reform of EU data protection law, the European Commission is pushing to make clear that EU data protection laws will apply to all websites and apps used by users in Europe – even where the website or app provider is located outside the EEA.

    As I note above, app store providers are not generally responsible at law for ensuring that apps on their platform comply with data privacy rules. It is the provider of the app itself. However, it seems that recent incidents (for example tracking of geolocation data and uploading of address books) has led the Californian Attorney General to go after the people best placed to force app providers to improve the privacy of their apps. We can assume that following this undertaking privacy settings will now form part of the app approval process.

    So what should I do if I am designing an app?
    First of all, you should have in place a privacy policy, which sets out what information your app collects, what is done with that information, why it is collected, and who it is disclosed to.

    However, it’s not enough to simply provide a privacy policy.

    • The privacy policy needs to be written in a way that is clear and transparent.
    • Particular consideration needs to be given to sharing of data with third parties and ensuring that the third party’s privacy policy is incorporated and accepted – for example, an app that overlays data on a Google Maps interface.
    • The user’s informed consent needs to be obtained. The privacy policy cannot be hidden deep in the app. Some revised rules on obtaining consent were issued last year.
    • In particular, if the app collects/uses geolocation data then you need to consider how consent is obtained from the user.

    Do you need to collect the data in the first place?
    In her speech announcing the new rules, the Californian Attorney General said that the new rules do not change what a mobile app can or cannot do, but instead simply require the app to be upfront about what it is doing.

    This may be the case under Californian privacy law, but one of the key principles of European data protection legislation is that the data collected is not excessive, and that the processing is fair and lawful. This means that you need to consider whether the data that you are collecting and the processing that you are carrying out is reasonable – do you need to track a user’s location or upload his address book just because you can? You can’t simply rely upon a user’s consent.

    Privacy by design
    Finally, app developers should bear in mind forthcoming changes in EU data protection laws.

    Under the proposed EU regulation, the requirement for privacy by design/privacy by default will be formalised. Under this concept, data controllers should design their systems (such as apps and websites) so that privacy is considered from the outset and the default setting is that the minimum amount of data is collected from the user, unless he agrees otherwise. If privacy by design is considered from the outset, then many potential privacy issues can be avoided.

    You can find some more top tips for app developers (covering other legal issues as well as privacy) by following this link.

    PS I’m pleased to see that the GSMA have just endorsed my recommendations that app designers take heed of the Commission’s privacy by design initiative, with the launch of new app privacy guidelines for apps developed by GSMA members. The guidance is well worth reading if you are involved in app development.

    Techblogger article in Computing magazine on DP and geolocation services

    I have an article in last month’s edition of Computing magazine. The article looks at the recent Article 29 Working Party opinion on data protection and geolocation services. Geolocation services are services that utilise the geolocation data (mobile phone triagulation, GPS, wifi hotspot) on a mobile device.

    The article is important reading if you are involved in developing apps or other web-based services that utilise geolocation data. Whilst the Article 29 Working Party’s opinions are not binding law, the opinions do reflect the thinking of the various national data protection regulators, and are also likely to feed into the forthcoming revamp of the data protection directive.

    As with a number of other opinions issued by the Article 29 Working Party recently, this opinion focusses heavily on the issue of consent. In particular, it proposes a number of onerous (some might say impractical) obligations upon service providers in relation to obtaining express consent. These go against the UK Information Commissioner’s current guidance on privacy policies which generally takes the view the obvious use does not require to be expressly highlighted.

    I think there are also a number of flawed assumptions in how geolocation data is used.

    For me, the key thing to take from the opinion is that the Article 29 Working Party doesn’t really understand how geolocation services work. It is therefore critical that those in the industry take part in the consultation on the revised data protection directive to ensure that the new laws are pragmatic and fit for purpose.

    You can read my article here.

    Article in B2B Marketing magazine on legal issues and apps development

    I have an article in this month’s B2B Marketing magazine. The article looks at some of the legal issues to bear in mind when developing apps for platforms such as iOS, Android, and Blackberry.

    Although the aticle appears in a publication that deals with business to business marketing (the clue is in the title!), many of the issues highlighted are equally applicable to B2C (ie consumer) apps.

    Here are some of my top tips:

    • know the rules of the platform – Apple in particular has extensive rules that you need to adhere to when developing for iOS.
    • decide what you want the app to do – is an app genuinely the best way to deliver your idea, or would you be better creating a mobile optimised version of a website? Has it been done before? Can it be easily copied?
    • Make sure you own/are properly licensed to use the IP in your app – there is no presumption that you will own the copyright in code developed for you. Also, make sure that third party IP is properly licensed (and on wide enough terms to avoid future problems further down the line – if your third party licence specifically references the iPhone then it won’t allow you to distribute the same app on the iPad).
    • Make sure you think about brand protection (ie trade marks) – and remember that the app market is generally global. A number of apps have had to rebrand because their brand infringes the rights of a third party in another country where the app is available. So think about your brand before you launch it – the more distinctive the better.
    • Think about your charging model – remember that Apple and Google take a 30% cut of revenue in return for hosting the app stores and processing payments, and they are also now demanding a cut of in-app purchases. You might even want to make the app free – some of the highest grossing iOS apps are free and make money purely through in app advertising.
    • Think about data protection – are you collecting personal data/utilising geolocation functions on the device (eg mobile phone triangulation/GPS/wifi data)?
    • Apps are licensed directly to the end user – Apple etc just acts as an agent in the sale. Do you want to use its standard EULA, or should you have specific licence terms that better reflect your app?

    New rules on the use of cookies and apps

    The UK Information Commissioner’s Office (ICO) has published some much-needed guidance for website operators on compliance with recently published amendments to the e-privacy regulations governing the use of cookies and apps.

    Background
    Cookies are commonly used to help websites deliver a better user experience, for example by identifying the user and therefore providing a more personalised experience, for example by remembering the user’s settings, avoiding the need to log-in to a website, remembering the contents of a shopping basket, or providing more intuitive results in search engines. However, by their very nature, cookies invariably involve the collection of data from and about the user.

    In November 2009, a new EC directive was passed, requiring member states to implement a number of new rules in relation to telecoms and privacy. The rules, which the directive requires be implemented by 25 May 2011, include new rules in relation to seeking consent from users in relation to the use cookies and similar technologies that store or allow access to information stored on a user’s device, for example apps installed on smartphones and other mobile devices that circumvent the need for a conventional web browser.

    Following a period of consultation, the UK government finally published the amending regulations in late April, which will come into effect on 26 May 2011.

    What do the new regulations say?
    Under the old, 2003, regulations, website operators were simply required to provide users with information about the use of cookies and give the user the opportunity to “refuse the storage of or access to that information.” Under the 2009 directive, as implemented, this has changed. The law now requires that a user:

    (a) is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information [ie the cookie]; and
    (b) has given his or her consent.

    The effect of new limb (b) is that users now need to give prior consent to the use of cookies.

    Ok, so what does that mean?
    Historically, website operators have generally sought to comply with the 2003 regulations by putting information on cookies in their privacy policies and allowing users to use browser controls to opt out.

    Whilst new regulation 3A expressly contemplates that the consent may be capable of being signified “by a [user] who amends or sets controls on the internet browser”, the UK government’s opinion that current cookie controls in web browsers are not sufficient to meet the new test for limb (b) above as they do not have the necessary level of sophistication to distinguish between different types of cookies. The UK government is working with browser manufacturers, presumably as part of a pan-European approach, to to discuss how cookie controls can be modified.

    In order to help website operators comply with the new rules, the UK ICO has recently published a guidance note.

    Here are the key points.

    Exceptions to the rule
    Consent is not required when a cookie is “strictly necessary for the provision of an information society service requested by the subscriber or user” – the ICO gives this a narrow interpretation (the example given is for an online shopping basket), that specifically excludes cookies that simply make a website more attractive or easier to use. It’s not clear how this might apply to apps.

    Audit and review
    The ICO recommends a three stage approach:

    • audit whether cookies are needed, and how they are currently used
    • assess how intrusive its use is; and
    • decide on the best solution for obtaining consent.

    Methods of obtaining consent
    Acknowledging that current browser controls are not sufficient, the ICO suggests a number of methods for satisfying the consent test:

    • using a pop-up window or similar technique when the user first logs on to a website or installs an app;
    • using terms and conditions by obtaining, positive, up front acceptance from the user to terms and conditions that clearly set out how cookies are used before the cookie is deployed;
    • settings-led consent for cookies that remember a user’s settings;
    • feature-led consent by asking for consent at the point at which a feature/function is first utilised by the user
    • functional uses (for analytic cookies) by displaying a prominent/highlighted message notifying the user and providing a link to more information and how to make a choice (although its not clear how the ICO invisages that the user rejects this particulr type of cookie)
    • third party cookies – although the ICO rather unhelpfully says here that it is complex and “everyone has a part to play” in working out a solution here.

    Further details on each of these approaches are discussed in more detail in the ICO’s guidance note.

    So how long do I have to comply with the new rules?
    As noted above, the new regulations come into force on 26 May, but the ICO acknowledges that there needs to be a phased approach to implementation, and therefore that in the event of a complaint the important thing is that the organisation can show that it is taking steps to comply with the new rules. However, it is not clear for how long this grace period will apply.

    The ICO has said that it will issue further guidance in due course, so watch this space or follow @ICOnews on Twitter.

    Updated 25/05/11 – the ICO has today announced that website operators will have a period of one year to make the necessary changes to their websites.


    Twitter: @BrodiesTechBlog feed

    August 2017
    M T W T F S S
    « May    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  

    %d bloggers like this: