Placed announces Placed Affiliate, a new way for app developers to monetize their apps

Placed logoMobile app location analytics provider Placed today announced Placed Affiliate, a new way for app developers to monetize their app by providing location data to Placed for market research purposes.

“It’s a new monetization channel for app developers,” says David Shim, founder and CEO of Placed. “No one is doing this today.”

Essentially, mobile app developers get paid by Placed for allowing the company to gather location data from its users who opted-in on Placed collecting such data for its own market research. On top of Placed Affiliate, the Seattle-headquartered company currently offers a free service providing location-based data for mobile app developers called Placed Analytics. Placed also offers a product dubbed Placed Panels, which is a free stand-alone mobile app and survey tool for iOS and Android — called the Panel App in the app stores — that allows businesses to track and measure location-based data from opted-in users, who are rewarded with gift cards or entries into a prize drawing for completing surveys from businesses.

“Placed Affiliate is going to let us acquire and measure more data across a larger universe of devices,” Shim told Inside Mobile Apps.Placed Affiliate

After a mobile app developer signs up for the Placed Affiliate service, they are provided with the Affiliate SDK for integration into their app. Placed wants to make sure it covers all its bases when it comes to a user’s privacy. If a mobile app developer wants to use Placed Affiliate, they must first make sure a user enables location permissions, and second, when a user opens the app, a prompt will inform the user that the app works with Placed for market research on location data. A user can simply select “yes” or “no” if he or she wants or doesn’t want to send location data to Placed. Shim emphasizes that Placed is collecting only location data and nothing else.

“We’re going above and beyond what the legislation has been talking about,” he says.

App developers receive money if Placed can gather location data from users in a 7 day or 30 day period. Shim adds that Placed Affiliate provides incremental monetization. If an app already has monetization hooks through ads, in-app purchases, subscriptions or other means, he recommends app developers keep those and add Placed Affiliate on top of those monetization strategies.

Placed, which already launched a pilot for Placed Affiliate last month, is now allowing any mobile app developer to sign up for the service here.

Back in March 2012, Placed received $3.4 million in Series A funding from the Madrona Venture Group.

Guest Post: 3 reasons to have a privacy policy for your app

Docracy logoEditor’s note: Today’s guest post comes from Veronica Picciafuoco, director of content for Docracy, a free repository of open source legal documents. The Federal Trade Commission (FTC) recently released a report, which outlined recommendations (not laws, yet) for mobile platforms and mobile app developers across the country to better inform its users what personal data is being collected and how the data is being used. Picciafuoco explains three reasons why app developers should have a privacy policy that outlines data collection.

1. The FTC thinks you should

In the U.S., a privacy policy isn’t mandatory requirement. But things are changing for mobile apps. The FTC issued a long report this month titled Mobile Privacy Disclosures. This document lays out a long list of recommendations for both platforms and app developers. Simply put, the FTC thinks every mobile app should have a readable, accessible privacy policy to explain users what data are collected, how, and why.

Here’s what the FTC thinks developers should do:

  • Have a privacy policy and make sure it’s easily accessible through the app stores

According to a June 2012 study, only 28 percent of paid apps and 48 percent of free apps available in the Apple App Store include a privacy policy or link to a privacy policy on the app promotion page. If you are on the “dark side”, it’s time to draft a solid privacy policy and make sure it’s accessible from your app, and not just from the privacy link when you submit the app to the various stores. If your app asks users to login via Facebook to find friends, the login screen is a prominent spot to place the policy link, so every user has the chance to check it.

  • Provide just-in-time disclosures and obtain affirmative express consent before collecting and sharing sensitive information (to the extent the platforms haven’t already provided such disclosures and obtained such consent)

As a user, you surely have met the pop-up notification that asks permission for push notifications. That’s an example of “just-in-time disclosure” provided by the platform itself. The FTC knows that few people read privacy policies, and wants you to notify your users about important privacy disclosures in the moment it occurs. For example, if your app wants to access the user’s address book to find other friends already playing the game, a pop-up is the best way to tell them in details what information are being collected and why.

  • Improve coordination and communication with ad networks and other third parties, such as analytics companies, that provide services for apps so the app developers can provide accurate disclosures to consumers

This is referring to external libraries, SDK and other third-party code that app developers often integrate in the app to facilitate advertising or analytics. The FTC is trying to tell you: it’s ok, but do it responsibly. Check public repositories for bugs, apply some due diligence on the reputation of the companies behind the code you are embedding. In short: use some common sense here, as you’re ultimately responsible for major loss of data from your app, even if due to third-party code.

  • Consider participating in self-regulatory programs, trade associations and industry organizations, which can provide guidance on how to make uniform, short-form privacy disclosures

The FTC is suggesting shortcuts to make your privacy policy up to industry standards. There are many trade associations in this space, including App Development Alliance (ADA), Future of Privacy Forum (FPF), Mobile Marketing Association (MMA), International Game Developers Association (IGDA), Entertainment Software Association (ESA) and many others. I personally oversee a crowdsourcing effort to open source a standard mobile privacy policy.

2. You can be fined you if you don’t follow or update your privacy policy

The FTC issued Path a whopping $800,000 fine for violations of their own privacy policy. Path said it wasn’t collecting certain information when, in fact, it was. While it’s normal for an app to ask permission to access third-party information on your phone, like address book info, what data you collect (and what do you do with it) is crucial. If you cater to minors, for example, you’re subject to COPPA, a federal law that says you must obtain “verifiable parent consent” if children under 13 use your app. Since Path collected birth dates, they knew for a fact they had kids using the app, and never did much about it. Result: $800,000 to the FTC. If you know that you have kids on your website, call your lawyer and find out how to comply with COPPA. If you don’t really know, make sure users represent they’re over 13.

3. You users will trust you more if you do, and your platform, too

recent survey found that 57 percent of all app users have either uninstalled an app over concerns about having to share their personal information, or declined to install an app in the first place for similar reasons. Instagram is said to have lost something like six million users after the their controversial Terms of Service change: people are starting to care about the legal implications of the apps they use. You can get away from the FTC, but there are crowdsourced policing tools in place now (TOS;DRPrivacyChoice, etc.) and it only takes one vocal user to spread a bad rumor. There’s also a positive side: good early behavior can help establish a level of trust with your user base that has positive effects on retention, and may even give you a competitive advantage.

Conclusion: get a privacy policy: it’s not that hard

There are pretty compelling reasons to have a good privacy policy for your mobile applications. It’s not something that only big publisher can afford. You can start with a free online template or a free privacy policy assembler and have a lawyer review it for a small fixed fee.

Looking at what the competition is doing can also help you figure out what kind of disclosures go in a policy. The important thing, particularly with mobile apps, is to make sure the policy stays true at every update. Every time add or fix something, think if it had an impact on your privacy statements, and edit them if necessary. Added a new analytics script? It should go in there. If you adopt a “privacy by design” approach from the beginning, this process will become automatic and naturally integrated in product development, keeping your legal risks low.

FTC recommends new privacy guidelines for mobile app platforms and developers

The Federal Trade Commission today released a new report, which outlines recommendations for mobile platforms and mobile app developers across the country to better inform its users what personal data is being collected and how the data is being used. The report comes less than a month after the California Attorney General’s office released its own privacy guidelines for mobile app developers in the state.FTC logo

FTC Chairman Jon Leibowitz, who yesterday announced his resignation, said in a statement, “the mobile world is expanding and innovating at breathtaking speed, allowing consumers to do things that would have been hard to imagine only a few years ago. These best practices will help to safeguard consumer privacy and build trust in the mobile marketplace, ensuring that the market can continue to thrive.”

The FTC, the federal agency that oversees business practices, stated that mobile devices “facilitate unprecedented amounts of data collection” because users, for the most part, have their mobile device on and with them at most times. In an effort to improve mobile privacy disclosures, the FTC recommended platforms and developers provide privacy data disclosures to consumers before allowing an app to access sensitive content like geolocation and for other personal data such as photos, contacts or calendar entries.

The FTC also recommended that platforms consider implementing a version of Do Not Track (DNT), the privacy mechanism that allows users to prevent tracking by ad networks or other third parties. Multiple desktop web browsers already support DNT including Firefox, Internet Explorer, Chrome and Safari. Mozilla’s Firefox mobile browser has the DNT mechanism and Apple’s Safari has a “limited ad tracking” slider for iOS, but despite Mozilla’s and Apple’s DNT support on mobile, the privacy mechanism is not as standard on mobile as it is on desktops.

At the end of 2012, the FTC strengthened its more than a decade-old child online privacy laws, in particular, the Children’s Online Privacy Protection Act (COPPA). The new laws require child-directed websites and online services to obtain parental consent before collecting children’s personal information like geolocation data or photos before sending the data off to third-party companies. Although, the updated rules explicitly exempt app “platforms” such as the Apple App Store and Google Play from complying with COPPA since the app stores only offer “public access” to kids’ apps, as opposed to targeting kids directly and exclusively.

How changes to Facebook’s app auth process affect developers

Along with other new privacy controls, Facebook today announced changes to the apps permissions process, which separates read and write permissions into different dialogs. The new flow gives users more control, but adds an extra step that could have an effect on acceptance rate and change the type of access users grant apps.

Today’s changes do not affect how users install games on Facebook.com, but will apply to mobile apps and other sites using Facebook login. Now that apps will request read and write permissions separately, users have the option to log into an application and receive a personalized experience using their name, friend list and other aspects of their profile, but they can reject the app’s request to publish activity on their behalf.

Previously, users accepted these permissions in one step, which led some users to unknowingly authorize an app to post to their wall. When users better understand what an app can do, they are less likely to be taken by surprise and end up marking an app as spam. They will also be more likely to add more apps in the future. Without feeling like they have control over what they share, users might be hesitant to add any third-party apps. That said, the two-step process could also lead to lower install rates or lead fewer people to allow apps to share their activity.

In some cases, the app auth process may involve three steps. That’s because Facebook also distinguishes “manage” permissions from read and write. If an app wants to manage a user’s ads, events, notifications or other products, it will have to request this in a third dialog.

Some aspects developers will appreciate are how the new dialogs are smaller and more lightweight, which is less likely to turn off users, and how some permissions have been combined. For example, apps used to have to request separate permissions for “publish_stream,” “publish_actions” and “publish_checkins.” Now an app can simply ask if it can publish to Facebook or not. “Basic info” has also been renamed to “public profile and friend list” to be more descriptive and transparent to users.

Facebook says all mobile and non-game web apps will be converted to the new auth flow automatically. No changes are required to a developer’s code.

Here’s a look at how the read and write permissions dialogs appear on different platforms:

Images from Facebook.

This article originally appeared on our sister site, Inside Facebook.

AntiSec releases 1M+ UDIDs it claims are from FBI hack

A hacker group named AntiSec has released 1,000,001 iPhone Unique Device Identifiers (UDIDs) it claims it stole from an FBI tracking project that contains more than 12 million of the numbers — some of which are said to be linked to personal information including full name, cell number, address and zipcode.

UDIDs are 40-digit long, unique alphanumeric codes that are assigned to every iOS device. They are used to track users as they move from app to app, to target advertising and measure campaign conversions. Unlike other advertising tracking mechanisms, they can’t be cleared, blocked, removed or opted out of, and are easy to link to personal information such as a user’s contact book.

Security concerns like these that have pushed Apple to move away from UDIDs, although the movement to replace them has lost much of its momentum due to a lack of suitable replacements. For its part, AntiSec had the following to say about UDID tracking:

“We think it’s the right moment to release this knowing that Apple is looking for alternatives for those UDID currently and since a while blocked axx [sic] to it, but well, in this case it’s too late for those concerned owners on the list. we always thought it was a really bad idea. that hardware coded IDs for devices concept should be erradicated [sic] from any device on the market in the future.”

According to the group’s anonymous statement on Pastebin.com, the data was released  in order to draw attention to the FBI’s project. Although most of the user info has been removed, AntiSec left enough for users to determine if their devices were among those being tracked. For those users who do not wish to download the entire list of UDIDs in order to see if their device is among those being tracked, The Next Web has created a custom search tool related to the breach.

Location analytics service Placed is now tracking up to 20 million locations a day

Mobile app location analytics provider Placed is now measuring up to 20 million pieces of user-generated location data a day through its free service, Placed Analytics.

Backed with $3.4 million in Series A funding from the Madrona Venture Group, the Seattle-based company is looking to break into the analytics market by providing developers location-based information that can tell them where, and how their mobile app are being used. Since launching its free open beta in June, Placed has already signed up several hundred developers, and their apps are now sending anywhere from 17 to 20 million locations back to the company every single day.

CEO and founder David Shim describes Placed as similar to the services provided by Flurry or Google Analytics, but for the outside world. While other mobile analytics services can show a developer what city a user is in, Placed can developers know what specific neighborhood a user is in and what kind of businesses they’re close to. Placed can even differentiate between three levels of movement: stationary, walking and in transit.

Although the information might seem excessive at first, it opens up many new possibilities to optimize an app for how it is actually used, explains Shim. “A developer can see what situations his app is used, so he can know not to rely on precise controls if the application is mostly used while walking,” says Shim. Developers can also track their location analytics month-over-month to determine trends and emerging usage patterns.

The service works by using GPS data and Placed’s own 300 million location meta-place database. For businesses that are located next to one another, Placed references time-based information to determine which business a user is more likely to be interacting with. For example, Shim says, if there is a McDonald’s and toy store located side-by-side, Placed can determine which business a user is more likely to be visiting based on how popular those locations are during the day. Placed also has home and work models to tell if users are actually out and about, or if they just happen to live or work in densely populated urban areas.

Of course, all this detail also raises concerns around privacy, something Shim tells us the Placed team has put a considerable amount of thought into. First, the service only tracks location when an app using Placed has received location permission from a user. Second, Placed doesn’t provide what Shim calls “individual level data” to developers — that means the most a developer can learn from Placed is that a user is in an area that measures 150 by 150 meters. “It’s all about aggregation,” says Shim. “You can’t see a random device ID and this is the places that they went to. That’s specifically for privacy reasons. That’s also why we’re not going into the ad targeting business.”

What Shim means by ad targeting business is GeoFence advertising — ads that are pushed to consumers when they enter a pre-defined area or pass near a specific business. The eventual monetization goal for Placed isn’t to serve location-based advertising, but to help developers understand the broader location landscape around their apps, something that will make location-based advertising more effective in the long term.

“If an application doesn’t have enough inventory of people actually going by 7-11, then you can sell [GeoFenced 7-11 ads] for a high CPM but they will have a very low value at the end of the day,” Shim explains. “The other obvious thing from an advertising perspective is you can start to understand what inventory is available. Imagine going to McDonald’s and saying ‘people who use my app are four times more likely to be nearby a McDonald’s then any other app out there, so you should really advertise.’ Alternatively you can say the same to Burger King, so they can get in front of those people before they step into a McDonalds.”

 

What Apple’s UDID phase out means to the iOS ecosystem

Apple is beginning to issue blanket rejections for apps that use Unique Device IDs (UDIDs) to track and identify users. Although the move is an answer to some of the privacy concerns around how iOS apps share user data, the lack of a clear alternative will have far-reaching impacts on how developers, analytics companies and advertising networks function and do business with one another.

UDIDs are 40-digit long, unique alphanumeric codes assigned to every iOS device. They’re used to track users from app to app, see what apps they’ve installed and how often they’re being opened, target advertising and measure the conversion rate and ROI of campaigns. Unlike other advertising tracking mechanisms, they can’t be cleared, blocked, removed or opted out of.

Apple has been trying to steer developers clear of UDIDS since the release of iOS 5.0 last August. At the time, the company depreciated access to UDIDs, telling developers to instead create their own identification systems. Depreciation in and of itself doesn’t necessarily mean much — there are still depreciated features from before iOS 5.0 in active use — so last month Apple raised the issue again, reaching out to developers to get the ball rolling on the transition away from UDIDs.

Even though the writing was on the wall for UDIDs, Apple’s move to reject apps that call on them was “an unpleasant surprise,” in the words of Michael Oiknine, CEO of mobile analytics company Apsalar.

Although the move doesn’t affect apps already in the app store, developers wishing to push updates or new apps will now need to ensure that both their apps and any third-party SDKs aren’t calling on UDIDs.

“We’re waiting to see how it falls out,” explains Lei Zhang, the US general manager of Chukong (PunchBox and CocoaChina). The company runs its own advertising service and developed Fishing Joy, one of the most popular games in China. “I think the first hit will be analytics companies and developers that depend on analytics, which is everyone. We’re using Flurry right now and Flurry uses UDIDs to track users. Our next submission to Apple is going to be problematic. We can remove advertisement SDKs, but analytics is something we live by. Right now we’re holding off on new submissions and updates.”

Oiknine echos Zhang’s sentiments that the real challenge for the ecosystem will be going forward.

“When you’re using Apsalar data from one app to another there’s no problem. Where it becomes a drawback for vendors like Apsalar and advertising networks is that everyone will come with their own user IDs,” he explains. “If I want to work with an advertising partner to leverage that data for retargeting I need to have a bilateral relationship so we know how to correlate their IDs to our IDs. It directly affects advertising and indirectly affects developers because they won’t have a way to determine the ROI on their advertising dollars.”  For its part, Apsalar is rolling out a new SDK next week that will use Apsalar IDs rather than UDIDs.

There are some alternatives to UDIDs. Among those proposed have been CFUUIDs (core foundation universally unique identifier), unique identifiers developers generate themselves, the so-far-sporadically adopted open source alternative OpenUDID and the Media Access Control (MAC) address of a device’s Wi-Fi interface. Unfortunately, the most promising of the three — MAC addresses — are also most open to the kinds of privacy complaints that have caused Apple to phase out UDIDs. Like UDIDs, they’re tied to a specific device and can be used to track a user’s location. Its also very hard to change or spoof a MAC address.

“The MAC address is as loaded as UDIDs. It’s also owned by Apple, and its a hardware address and for all practical matters its exactly the same as UDID,” says Oiknine. “My feeling is that if developers start using the MAC address, it will work for a while, but at some point we should expect Apple to crack down on the MAC address as well.”

According to Oiknine, what iOS needs is a universal system with a clear way for consumers to opt-out, similar to how Cookies work online. He predicts whatever the new system will be, it will be the companies that track user data, and not Apple that will lead the way.

“We need to find an opt-out mechanism and Apple doesn’t want to get involved in that.”

Apple steps up outreach to developers over moving away from UDIDs

In the wake of a media outcry over giving developers too much access to users’ address books, Apple looks like it is stepping up efforts to close other privacy loopholes too.

We’ve been hearing from developers today that Apple has been reaching out to some of the larger companies on its platform in the last few weeks. Apple has been asking them to move away from using UDIDs or unique device identifiers, a couple developers have confirmed to me.

UDIDs can be used like cookies to track consumers as they move from app to app. Advertising networks can use the data collected through this tracking to target consumers with ads based on their browsing habits. The difference with UDIDs is that they can’t be cleared in the way that cookies can be deleted.

An investigation from The Wall Street Journal last year found that developers were sharing UDIDs with third-party ad networks and other service providers — a potential privacy risk especially if a UDID is tied with a person’s name. Not too long after, Apple said it would deprecate UDIDs and asked developers to start creating unique identifiers that work specifically with their apps.

However, deprecating any feature is a process can take months — if not more than a year — as Apple has to give developers time to change their code base. When Apple originally announced the change in August, there were still deprecated features from iOS 3.0 that were still in use.

With what we’re hearing this morning, however, it seems like Apple wants the developer community to move faster. Developers have been telling us that Apple has reached out to them asking them to move away from UDIDs if they’re still using them in their apps or any third-party libraries.

To replace UDIDs, Apple has some functions here that can create unique identifiers from a string or from a set of raw bytes. Some developers had told us they’re replacing the UDID with the MAC Address, or Media Access Control address, an identifier that’s assigned to networked devices like smartphones or laptops. But that carries most of the same privacy risks that UDIDs do.

The address books fiasco finally comes to an end as Apple says it will make developers ask for permission first

Apple says it will require developers to ask for permission first before they access a user’s address book.

It’s the culmination of a very strange weeklong media blowout that started when a Singapore-based developer discovered that Path was uploading personal contact information from users’ address books without their knowledge. Path apologized and said it would delete all of the user data it had collected this way. That spiraled into a discussion in The New York Times about whether Silicon Valley entrepreneurs have become too cavalier about privacy, by pushing the envelope first and then asking for forgiveness later.

That then escalated into a tangentially related discussion of the flaws in tech media as Path investors rushed to defend the company. Yesterday evening, both VentureBeat and the Verge returned to the core issue by looking at other apps like Foursquare and Twitter that were also sending address book information to their servers. This morning, House Energy & Commerce Committee Chairman Henry Waxman and Commerce Manufacturing and Trade Subcommittee Chair G.K. Butterfield sent a letter to Apple asking the company to explain the situation.

Apple finally responded today in an interview with AllThingsD, saying that it would change its policy around address book access:

“Apps that collect or transmit a user’s contact data without their prior permission are in violation of our guidelines*,” Apple spokesman Tom Neumayr told AllThingsD. “We’re working to make this even better for our customers, and as we have done with location services, any app wishing to access contact data will require explicit user approval in a future software release.”

The way this entire story played out was pretty odd. Developers have long had access to address books on iOS and if they do store data, it’s usually to suggest friends when new users come on board. While the intentions are usually harmless, it is true that a malicious developer could do much worse with this data access.

However, hashing has been a fairly well-known tactic to preserve user privacy while making it easy to suggest friendships. Beluga, the group messaging startup Facebook acquired last year, hashed contact lists. To hash a contact, the developer assigns a unique code to each name and stores that instead of the original information. When it scans an address book and finds other names that produce the same hash code, the app can recommend a friend connection. It seems Path, whose chief executive was one of the key early Facebook employees that built out the company’s platform, was merely careless in not hashing contact information.

There have been many privacy flaws in the design of the iOS platform over the years, including the use of UDIDs. The address books issue has existed for years, and yet it was only until one tiny blog post from a single developer emerged, that a firestorm finally ensnared Congress and Apple.

Strange times, indeed.

Here’s the House committee letter to Apple:

Mr. Tim Cook
Chief Executive Officer, Apple Inc.
1 Infinite Loop
Cupertino, CA 95014

Dear Mr. Cook:
Last week, independent iOS app developer Arun Thampi blogged about his discovery that the social networking app “Path” was accessing and collecting the contents of his iPhone address book without ever having asked for his consent.[1] The information taken without his permission — or that of the individual contacts who own that information — included full names, phone numbers, and email addresses.[2] Following media coverage of Mr. Thampi’s discovery, Path’s Co-Founder and CEO Dave Morin quickly apologized, promised to delete from Path’s servers all data it had taken from its users’ address books, and announced the release of a new version of Path that would prompt users to opt in to sharing their address book contacts.[3]

This incident raises questions about whether Apple’s iOS app developer policies and practices may fall short when it comes to protecting the information of iPhone users and their contacts.
The data management section of your iOS developer website states: “iOS has a comprehensive collection of tools and frameworks for storing, accessing, and sharing data. … iOS apps even have access to a device’s global data such as contacts in the Address Book, and photos in the Photo Library.”[4] The app store review guidelines section states: “We review every app on the App Store based on a set of technical, content, and design criteria. This review criteria is now available to you in the App Store Review Guidelines.”[5] This same section indicates that the guidelines are available only to registered members of the iOS Developer Program.[6] However, tech blogs following the Path controversy indicate that the iOS App Guidelines require apps to get a user’s permission before “transmit[ting] data about a user”.[7]

In spite of this guidance, claims have been made that “there’s a quiet understanding among many iOS app developers that it is acceptable to send a user’s entire address book, without their permission, to remote servers and then store it for future reference. It’s common practice, and many companies likely have your address book stored in their database.”[8] One blogger claims to have conducted a survey of developers of popular iOS apps and found that 13 of 15 had a “contacts database with millions of records” — with one claiming to have a database containing “Mark Zuckerberg’s cell phone number, Larry Ellison’s home phone number and Bill Gates’ cell phone number.”[9]

The fact that the previous version of Path was able to gain approval for distribution through the Apple iTunes Store despite taking the contents of users’ address books without their permission suggests that there could be some truth to these claims. To more fully understand and assess these claims, we are requesting that you respond to the following questions:

– Please describe all iOS App Guidelines that concern criteria related to the privacy and security of data that will be accessed or transmitted by an app.
– Please describe how you determine whether an app meets those criteria.
– What data do you consider to be “data about a user” that is subject to the requirement that the app obtain the user’s consent before it is transmitted?
– To the extent not addressed in the response to question 2, please describe how you determine whether an app will transmit “data about a user” and whether the consent requirement has been met.
– How many iOS apps in the U.S. iTunes Store transmit “data about a user”?
– Do you consider the contents of the address book to be “data about a user”?
– Do you consider the contents of the address book to be data of the contact? If not, please explain why not. Please explain how you protect the privacy and security interests of that contact in his or her information.
– How many iOS apps in the U.S. iTunes Store transmit information from the address book? How many of those ask for the user’s consent before transmitting their contacts’ information?
– You have built into your devices the ability to turn off in one place the transmission of location information entirely or on an app-by-app basis. Please explain why you have not done the same for address book information.

Please provide the information requested no later than February 29, 2012. If you have any questions regarding this request, you can contact Felipe Mendoza with the Energy and Commerce Committee Staff at 202-226-3400.

Sincerely,
Henry A. Waxman, Ranking Member
G.K. Butterfield, Ranking Member
Subcommittee on Commerce, Manufacturing, and Trade

Despite Google’s “Bouncer,” malware is still a threat on Android

In a bid to make downloading Android apps safer for consumers, Google has added an automatic scanning service to Android Market to find potentially malicious apps.

It’s an important move as Google does not review apps before appear in the store unlike Apple. Because the barrier to entry is so low, that sometimes means consumers unwittingly install malware on their phones.

The program, codenamed Bouncer, scans apps after they have been uploaded to the market, meaning developers still won’t have to go through an approval process to get their apps listed.

According to a blog post from Hiroshi Lockheimer, Google’s vice president of engineering for Android, Bouncer scans both new and existing applications for known malware, spyware, trojans and for behaviors that could indicate hidden malicious behavior. Google also analyzes new developer accounts to ensure that repeat offenders are prevented from uploading malicious apps.

Google revealed that Bouncer has been scanning the Android market for some time, reporting that “between the first and second halves of 2011, we saw a 40 percent decrease in the number of potentially-malicious downloads from Android Market.”

However, while Google is reporting downloads of malicious apps are decreasing, third-party analysts have found the amount of malware in the Android market is increasing as the platform’s larger reach makes it a more enticing target for unscrupulous developers. in November, the Juniper Global Threat Center reported it had seen a 472 percent increase in Android malware samples since July 2011 and in December Lookout reported it had found more than 1000 infected apps in the Android market — double the amount it detected in six months ago.

In January, AhnLab researcher JungSin Lee pegged Android as the OS under the most threat from malware due to its lack of a proactive screening policy. While Bouncer helps to address these concerns, the Android market has still had some recent, high-profile security incidents.

In November, a number of fake apps pretending to be popular games such as Angry Birds and Tiny Wings were removed from the store after customers complained they had bought the apps and they did not work. A month later Google had to remove 22 more apps from the Android market for SMS fraud.

Fighting malware can be like running faster just to stay in the same place. If Google adds one security measure, hackers eventually find another loophole. But Google is familiar with this dynamic, as it has had to battle search spam and black hat SEO (search engine optimization) for more than a decade.

There are currently more than 400,000 apps on the Android market.

Get the latest news in your inbox
interested in advertising with inside mobile apps?

Social Media Jobs
of the Day

Social Media Manager

The Culinary Institute of America
Poughkeepsie, NY

PR & Social Media Account Director

Manifest New York
New York, NY

Assistant Social Media Editor

Salon Media Group, Inc
New York, NY

Part-time Social Media Manager

Michelson on Medicine
New York, NY

Featured Company

Join leading companies like this one and recruit from the nation's top media job seekers on the Mediabistro Job Board. Every job post comes with our satisfaction guarantee. Learn More
 

Our Sponsors

Mediabistro A division of Prometheus Global Media home | site map | advertising/sponsorships | careers | contact us | help courses | browse jobs | freelancers | content | member benefits | reprints & permissions terms of use | privacy policy Copyright © 2014 Mediabistro Inc. call (212) 389-2000 or email us