Facebook Messenger is not the privacy threat you should be concerned about

Many people are focused on the permissions they give Facebook when they install Facebook Messenger and are concerned that they are giving Facebook excessive access to their devices. This isn’t necessarily the case and this growing panic may be more a function of how Android permissions have to be obtained than a real privacy threat which many have read into those permissions.

Facebook _Messenger_iOS_6_RGB smallI found myself listening to a discussion on 94.7 this morning about Facebook Messenger. The breakfast team was talking about these permissions that have attracted so much attention as if installing Messenger instantly compromises users and leaves them exposed to all sorts of privacy invasions when microphones and cameras turn on at someone else’s behest.

The panic level rose a few more notches when the breakfast team received a call from an anonymous listener who told the team that part of his work involves remotely accessing people’s devices (presumably part of lawful investigations) and exploiting these sorts of permissions. It wouldn’t be unreasonable to draw the conclusion that giving Facebook these permissions to access your phone’s microphone, camera and other features somehow makes all of those features available to anyone wishing to exploit that level of access and spy on you.

Fortunately it isn’t as simple as that. Leaving aside the risk that Facebook, itself, grants access to your devices to 3rd parties without your knowledge or that its apps have vulnerabilities which are not patched and are exploited by unscrupulous 3rd parties, Facebook isn’t the threat. I spoke to Liron Segev, an IT Consultant and one of the first people I think about when I need some help with the technical aspects of IT security. He explained that the threats to consumers come from various sources and that poor security awareness on consumers’ part is a contributing factor.

To begin with, it is possible for a 3rd party developer to introduce apps to app stores that appear to have a particular functionality but, below the surface, these apps will scan installed apps on your device, attempt to impersonate or even supplant those apps and exploit the access permissions you gave to the legitimate app. These trojan apps would then take advantage of the sorts of permissions you grant Facebook Messenger to access your device microphone, camera and other features. Avoiding this risk largely comes down to only installing apps you trust and how well the app marketplace is regulated and protected from this sort of malware. More and more security experts recommend installing anti-virus software on your mobile devices to help protect you from these sorts of attacks.

A hidden threat few people outside the security industry are aware of comes from the mobile networks we use every day. Mobile networks have the technical ability to gather data from our devices and even remotely install applications without us being aware of this in order to use that data and access to our devices’ features for a variety of reasons ranging from network performance management to remote surveillance and law enforcement. On the one hand, there are good reasons for networks and governments to have the capability to monitor criminal threats (for example, the somewhat misunderstood capability Google has to monitor Gmail for child porn using an existing database of problematic images). We live in a world where the bad people use advanced encryption and digital tools to plan and conceal their activities. On the other hand, there is also scope for governments and companies to use these capabilities to spy on citizens, infringe their rights and exploit their personal information for profit. As I mentioned in my htxt.africa article “Much ado about Facebook Messenger privacy settings, but is it nothing?” –

Whether you use Messenger should be informed by the extent to which you trust Facebook, not by the very explicit and informative permissions Facebook seeks from you in order to use Messenger. If anything, Facebook is just proving that it has come to a long overdue realisation that there is no benefit in deceiving users.

It is possible that Facebook may turn on your phone’s camera and microphone while you are getting dressed in the morning but highly unlikely. What is more likely is that Facebook requires those permissions to enable Messenger to do what you want and expect it to do. That said, you can’t be complacent and install every app on your device that seems amusing. Take the time to satisfy yourself that the app is from a credible source and look into anti-malware software for your devices. As for mobile networks and governments, there is little you can do except reconsider your device choices if you are concerned about this. Segev pointed out that Blackberry devices are still secure options and Blackberry 10.x is a flexible option even if it isn’t popular media’s darling.

Facebook may use your image in its ads, if you let it

Facebook’s Statement of Rights and Responsibilities is Facebook’s terms of use and it governs a number of aspects of your Facebook use. Clause 10 has a set of clauses which privacy conscious users should be aware of and consider carefully:

About Advertisements and Other Commercial Content Served or Enhanced by Facebook

Our goal is to deliver ads and commercial content that are valuable to our users and advertisers. In order to help us do that, you agree to the following:

  1. You can use your privacy settings to limit how your name and profile picture may be associated with commercial, sponsored, or related content (such as a brand you like) served or enhanced by us. You give us permission to use your name and profile picture in connection with that content, subject to the limits you place.
  2. We do not give your content or information to advertisers without your consent.
  3. You understand that we may not always identify paid services and communications as such.

What this means is that Facebook may use your likeness in its ads or share your personal information with advertisers unless you adjust your privacy settings to restrict this. Going further, Facebook “may not always identify paid services and communications as such” so you may find your likeness being used in an ad without being warned that this could happen. The privacy settings page where you can find these settings expands on this:

Facebook Adverts - Privacy

If this is something that concerns you then you should head over to this privacy settings page and carefully select the privacy settings that you are most comfortable with and you should do it right away. If you don’t adjust your settings Facebook will regard you as having agreed to it using your personal information in its ads or to passing your personal information along to its advertisers. You have 2 options: sharing your personal information in an advertising context with your friends or not at all. The rationale is, at least in part, to take advantage of Facebook’s powerful word-of-mouth model to market products and services to your friends through apparently personal endorsements.

Did your iPhone ask for permission to give away your address book?

Instapaper’s creator, Marco Arment, made a good point on his blog about permissions and your phone’s address book in the wake of the Path privacy controversy. It probably came as something of a surprise to many users that their iPhones are habitually handing over their address books to a variety of social services we use daily without as much as a prompt requesting permission to do so.

The popular Path app was caught uploading and permanently storing people’s entire address books on Path’s servers. People were upset, but what’s scarier is the bigger issue: apparently, this is a very common practice among popular apps.

Mobile applications are becoming more and more popular as more people start using smartphones instead of feature phones. These apps are increasingly social and that means that users are often prompted or otherwise given an opportunity to share their social graph with these apps and their underlying services. Users’ social graphs may take the form of Facebook or Twitter connections (in which cases users are probably familiar with the more secure OAuth-based authentication processes to give 3rd party apps and services access to their profile information) or address books stored on the devices concerned.

Dave Morin

Path partially addressed concerns about how it uploaded users’ address books through the social app in a blog post titled “We are sorry.“. The post was a terrific reputation management exercise and diffused much of the anger directed at Path. That said, the general practice of uploading address books remains in place for the most part (although you can imagine that reputation conscious developers will probably alert users to this practice in their apps going forward). What hasn’t really been addressed is the permissions set at a device level which makes this possible. As Arment points out –

When implementing these features, I felt like iOS had given me far too much access to Address Book without forcing a user prompt. It felt a bit dirty. Even though I was only accessing the data when a customer explicitly asked me to, I wanted to look at only what I needed to and get out of there as quickly as possible. I never even considered storing the data server-side or looking at more than I needed to.

This, apparently, is not a common implementation courtesy.

We can’t prevent services with poor judgment or low ethical standards from doing creepy things with the data once it’s sent to them. We can’t even realistically use App Review to only permit access to the Address Book fields (email, name, phone, etc.) that are justifiable for any given app to access, because there are too many gray areas.

One of the problems with allowing your address book to be uploaded is that you lose whatever control you may have had over that data once it leaves your device. In contrast, when users authorise Facebook or Twitter to grant access to their contacts to 3rd party services, they notionally retain the ability to revoke that permission and deny the 3rd party service further access to that data. With address book uploads, its pretty much as the saying goes: you can’t unscramble the egg.

As Arment proposes, one solution is that device manufacturers or smartphone OS developers build device or OS-level permissions into address book APIs such that users are clearly prompted for permission to upload or otherwise grant access to their address books when apps request it. Another option is that users should be more circumspect about granting this sort of access to their address books to 3rd party apps and services. Users frequently have a combination of sensitive and generally available personal information on their devices and simply granting access to their address books can prove to be problematic not just to those users but to the people who have entrusted their personal information to those users, sometimes with specific purposes in mind which exclude being shared with the popular social app of the day.

Update: Ars Technica has a related post titled “Developers say Apple needs to overhaul iOS user information security” about this issue which is worth reading.


Image credit: Dave Morin by Joi Ito, licensed CC BY 2.0

Facebook wants to expose your phone number and address

Facebook took a controversial step over the weekend that has privacy advocates concerned, again. The social network is now making users’ mobile phone numbers and addresses accessible to applications as distinct categories of personal information. Alternatively, as Jeff Bowen‘s blog post on the Facebook Developer blog put it:

We are now making a user’s address and mobile phone number accessible as part of the User Graph object. Because this is sensitive information, we have created the new user_address and user_mobile_phone permissions. These permissions must be explicitly granted to your application by the user via our standard permissions dialogs.

Facebook received a fair amount of criticism about this move and, earlier today, announced, also on the Facebook Developer blog, that it would suspend this new functionality while it works to address users’ concerns:

Over the weekend, we got some useful feedback that we could make people more clearly aware of when they are granting access to this data. We agree, and we are making changes to help ensure you only share this information when you intend to do so. We’ll be working to launch these updates as soon as possible, and will be temporarily disabling this feature until those changes are ready. We look forward to re-enabling this improved feature in the next few weeks.

That said, these additional fields are likely to still be exposed to applications in some form or another once Facebook finds its way through this privacy minefield.

Why the concern?

Essentially Facebook proposed adding your mobile phone number and address fields to the categories of personal information developers could access if you granted the appropriate permissions to their applications. If you have been using Facebook for an appreciable period of time, you have probably encountered the Facebook permissions dialogue box along the lines of the one above. This is the mechanism by which applications secure your permission as a Facebook user to access your personal information contained in your Facebook profile.

These permissions tend to include access to your Wall, your friends’ lists, your name and profile photo. Where you give an application permission to access your personal information it is often used to give you a certain experience. For example, granting CNN access to your Facebook profile using Facebook Connect or the Open Graph API functionality gives CNN the ability to show you which of your friends read and recommended an article and publishes your comments about an article on your Wall. This functionality has some social value as friends’ recommendations may be relevant to you and highlight something you may not have discovered on your own. The challenges have been whether users are sufficiently educated about how using this functionality affects their privacy and whether they have adequate tools to do this.

ReadWriteWeb published a post yesterday titled “Facebook & Identity: The Continued Push Toward Becoming Your One True Login” (the title itself nicely summarizes why Facebook is doing this in the first place) which explores objections to Facebook’s plans and these objections largely focus on a perennial theme in Facebook privacy complaints: the degree to which users have meaningful control over their personal information.

Lack of granular control over profile information

One of the problems is how Facebook gives users the option to grant access to their profile information. The permissions are typically all or nothing and users are faced with a stark choice: agree to share their profile information and gain access to the application or refuse and lose out on the experience the application promises. Elias Bizannes summarized the issue quite nicely for RRW when he said the following:

“Something bugs me about the Facebook connect privacy options,” said Bizannes. “When you connect, you see what permissions you have to give, but you don’t have an option there to deny individual permissions.”

Facebook’s response to this criticism is that applications should only request the information they require at a bare minimum to do what they propose to do. Giving users the opportunity to pick and choose which categories of personal information to grant access to would mean that these applications would be hobbled and would not be able to fulfill their purpose. In the event an application mis-uses profile information or asks for more information than it requires, users have the option of revoking the application’s permissions. Its not clear to me whether revoking an application’s permissions would remove all traces of a users’ profile information from the developer’s control (I’m not familiar with how the profile information is passed to developers using the API) or whether the developer will still be left with the profile information passed along when permission was granted to the application.

One of the big problems is that abuses of this level of access to users’ profile information have occurred. These are worrying because of the detailed picture Facebook has of its users which makes Facebook extremely attractive to advertisers. Facebook knows who your friends are, where you live, what your interests are, where you spend your time and so on. This information gives advertisers the ability to target their ads pretty accurately and with a greater likelihood of a positive response. The dangers of giving developers access to such valuable stores of personal information was demonstrated by a company called Rapleaf last year.

Centralized identity

Chris Saad, a co-founder of the Data Portability Project, took issue with Facebook’s approach to identity, namely that it intends placing itself at the centre of your online experience with your Facebook profile as your core identity:

The problem is that Facebook has architected the whole thing from the beginning to be an exclusive hub and spoke relationship with them rather than a peer to peer relationship on the open web.

When you couple concerns about how much of your profile information developers have access to, the all-or-nothing approach to permissions and a centralized identity used to access an increasing number of social sites or sites with social capability care of the Open Graph API, you begin to appreciate both the value of a Facebook profile to advertisers (with a corresponding benefit to Facebook itself which relies of advertising revenue for a significant share of its income) and the risks to users’ privacy if they don’t fully appreciate that their activities on Facebook and on the broader Web may expose more of their personal information than they may intend.

To aggravate matters, Facebook’s privacy policy has frequently been criticized as being too complex for most users to understand, as are the privacy controls Facebook gives users to help them manage their privacy settings. Of course, changes to Facebook’s privacy policy has historically made managing privacy settings even more complex.

What now?

Fortunately, Facebook has decided to return to the drawing board and rethink how it proposes making users’ phone numbers and addresses available to developers in light of criticism it received over the weekend.

The nature of the profile information in question necessitates that Facebook take great care safeguarding this personal information when giving users the option to make it available to developers. While some people may not be too concerned about their mobile number being passed along to third parties, a person’s home address is particularly sensitive information.

While there may be value in being able to pass along your address and mobile phone number in more controlled circumstances to third party providers (you may want a retailer to know where to ship a purchase to you or get in touch with you to respond to a query); it is essential that this information is protected from abuse by unscrupulous third parties as well as from Facebook’s own tendency to change its privacy practices and expose more personal information than users initially anticipated.

While we can only hope that Facebook acts responsibly, users should also take responsibility for the personal information they make available on their profiles. If you are deeply concerned about Facebook passing along your phone number and home address, remove that information from your profile! I have often recommended that when it comes to personal information that people decide, in advance, which categories of personal information are most sensitive and to never publish that information online. This sensitive personal information may include home addresses, identity numbers, phone numbers, children’s schools and so on. That applies to Facebook as much as it applies to any online platform or service. You should assume that anything you publish online could be compromised and shared without your consent, regardless of Facebook’s best efforts to safeguard your information.

RSS does not mean Reuse Share Sell: taking the Pulse of noncommercial

feed-icon-96x96The Pulse RSS reader caused quite a stir when Steve Jobs demonstrated it during his recent WWDC keynote speech. He talked briefly about Pulse’s merits and as used it as an example of the sorts of applications which are available for the iPad in the iTunes App Store. He probably didn’t count on the New York Times’ lawyers taking issue with the Times’ feed being one of the feeds Pulse ships with by default, particularly considering that Pulse is a paid application. NYT’s lawyers wrote to Apple requesting that Pulse be pulled from the App Store alleging as follows:

The Pulse News Reader app, makes commercial use of the NYTimes.com and Boston.com RSS feeds, in violation of their Terms of Use*. Thus, the use of our content is unlicensed. The app also frames the NYTimes.com and Boston.com websites in violation of their respective Terms of Use.

I note that the app is delivered with the NYTimes.com RSS feed preloaded, which is prominently featured in the screen shots used to sell the app on iTunes.

The full email was republished on Kara Swisher’s blog. The NYT’s terms of service provide as follows:

2. NYTIMES.COM CONTENT

2.1 The contents of the NYTimes.com sites are intended for your personal, noncommercial use. All materials published on NYTimes.com (including, but not limited to news articles, photographs, images, illustrations, audio clips and video clips, also known as the “Content”) are protected by copyright, and owned or controlled by The New York Times Company, NYTimes.com, or the party credited as the provider of the Content. You shall abide by all additional copyright notices, information, or restrictions contained in any Content accessed through the Service.

2.2 The Service and its Contents are protected by copyright pursuant to U.S. and international copyright laws. You may not modify, publish, transmit, participate in the transfer or sale of, reproduce (except as provided in Section 2.3 of these Terms of Service), create new works from, distribute, perform, display, or in any way exploit, any of the Content or the Service (including software) in whole or in part.

2.3 You may download or copy the Content and other downloadable items displayed on the Service for personal use only, provided that you maintain all copyright and other notices contained therein. Copying or storing of any Content for other than personal use is expressly prohibited without prior written permission from The New York Times Rights and Permissions Department, or the copyright holder identified in the copyright notice contained in the Content.

The terms of service clearly restrict use of NYT content to “personal, noncommercial” use and, as the extract from NYT’s lawyer above indicates, NYT was of the view that including the NYT’s feed in the Pulse application was a commercial use of that content, apparently because the NYT believes its content was used to sell Pulse. NYT also objected to Pulse “framing” NYT and Boston Globe content in the application, presumably a reference to how these websites can be displayed in Pulse like a Web browser. In fact, Pulse incorporates a Web browser to display actual Web pages rather than just the published RSS or Atom feeds.

I have been listening to the debate on a recent episode of This Week in Law about the merits of NYT’s lawyer’s contention that Pulse infringed NYT’s terms of service and made use of NYT’s and its affiliate’s content for uses that were not personal and noncommercial. Evan Brown expressed a view early on in the podcast that seemed to mirror the view held by NYT’s lawyer; namely that the terms of service prohibit commercial use of NYT’s content and Pulse’s use of the content was commercial, therefore a violation of the content license the NYT grants to its readers. This, in turn, justified NYT’s call for the application to be pulled. I initially agreed with his view and disagreed with TWIL host Denise Howell‘s arguments that aggregators like Pulse should be regarded as utilities and effectively exempt from any argument that they infringe copyright simply because they display content feeds that the content owner publishes (I believe that summarizes her argument fairly).

I do see Denise’s point and agree that regarding a paid RSS reader as infringing copyright because it displays a feed which may have a noncommercial restriction is as absurd as claiming Google; Mozilla; Apple, Opera or any Web browser developer is liable for copyright infringement because their browsers display content with similar restrictions. On the other hand, I don’t believe that this is what the real issue is. The real issue in this case is whether a paid RSS reader like Pulse is making commercial use of content either by displaying it at all or if it displays the restricted content in its marketing material? The term “noncommercial” has proven to be a particularly tough one to pin down, so much so that Creative Commons commissioned a study on what people generally understand by this term.

On the one hand, Pulse is a paid application and a user’s purchasing decision may be influenced by the appearance of the NYT’s content in the application when it is demonstrated. What if the NYT’s content was not included in the application’s demonstrations? What if a user purchased the application and subsequently added the NYT’s feed to Pulse and consumed that content on a personal and noncommercial basis? Would this use still be tainted by the price charged to use Pulse? NYT’s lawyers would seem to argue this is the case but this argument is increasingly absurd when you consider that the argument necessarily means that Google, Mozilla, Apple and Co. must similarly be on the hook for copyright infringement if people view the NYT website in their browsers.

The central question should be whether the use of the content is permitted by the relevant content provider’s terms of service or content license and not whether the technology used to access that content permits that access, as I understand Howell’s argument to suggest, in part. Assuming I understood this to be one of Howell’s points correctly, the logical implication of her further argument is that it should be legal to pirate and share pirated content because the means exist to make this possible. Rather, the argument should focus on the relevant content license which may have been applied to the content (or, in the absence of a license, the restrictions of copyright law itself).

I see selling content as a clear case of commercial use. On the other hand, enabling a person to view content in a freely available Web browser shouldn’t be regarded as commercial use of the content. The fact that Pulse is a paid application shouldn’t, in itself, make displaying the NYT’s content (either the website itself or its published feeds) commercial but perhaps selling the application with an implication of NYT’s endorsement or, worse, that NYT content is part of the deal could be commercial use of NYT’s content. The answer to this question isn’t clear but the closer Pulse’s developer gets to actually making profit from NYT’s content directly, the clearer it is that his use of NYT’s content is commercial. The developer is probably best served removing NYT content from the application as it ships and to refrain from referring to it or displaying it in the application in his marketing material.

What this furore highlights, though, is that some publishers publish their content under restrictive content licenses which are typically detailed in their terms and conditions. I have advised a couple clients who has assumed that if content is published through a feed they should be free to use that content however they please but this is simply not the case. Irrespective of the technology used to publish the content, content licenses still apply to that content and use of the content should be moderated accordingly.