Архив метки: SDK

Конкурс разработчиков приложений для платформы 2net

Qualcomm Life, "дочка" Qualcomm, объявляет о доступности пакета средств разработки приложений (SDK) для платформы 2net.
Конкурс разработчиков приложений для платформы 2net

YogiPlay Debuts “YogiMeter,” An Educator-Based Rating System For Children’s Learning Apps

yogiplay_logo_rgb

YogiPlay, a Menlo Park-based company from husband-and-wife team Cedric and Michal Selling, is attempting to tackle the critical problem of surfacing appropriate, trusted, and carefully vetted educational apps for children. The company recently raised $1 million in VC funding from DN Capital and Richmond Park Partners, in order to develop a system for rating apps for kids, specifically targeting the ages 2 through 8. Today, YogiPlay is announcing the results of those efforts with YogiMeter, its new app rating system designed to help parents find learning apps for children that have been vetted by a team of educational experts.

The Sellins are both Stanford-trained engineers, with Cedric hailing from Aruba Wireless and Michal an early Google employee. But they’re also parents who grew frustrated with how difficult it was to find quality learning apps for children. Cedric says they were inspired to start the company after watching their two-year old daughter interacting with mobile apps, and realized what powerful learning tools they could be.

In June, the company hired Dr. Jim Gray, who previously served as the Director of Learning at LeapFrog, where he was in charge of all curricula for the last seven or so years. At YogiPlay, he led the development of the YogiMeter system, which has been designed to assess the engagement levels and educational qualities of mobile apps.

“It’s using the same principles I’ve been using all along from my knowledge of child development and interactive media,” he says of YogiMeter. “I’ve structured in a way with some very specific ways to look at how and why kids would be engaged, and if they’re engaged, how and why they might learn.” He also vetted this rubric with other colleagues not associated with YogiPlay to get their feedback and input.

While there are a few startups working to rank and review mobile apps, like KinderTown, for instance (which also vets apps with educators), Dr. Gray says that he believes the YogiMeter system uses a more developmental approach with techniques common to those familiar in child development and education. “The others are not as rigorous, research-based, structured and consistent,” he says describing YogiMeter’s competition.

The system he developed ranks and analyzes apps in two main areas — engagement and educational quality. For determining an app’s engagement, it looks at things like user interactions, user experience, intrinsically motivated engagement, extrinsically motivated engagement and socially motivated engagement. And to analyze the app’s ability to teach, it looks at whether the app will actually engage the child in learning, as it proposes to do, and whether that learning is deep, authentic, personalized, differentiated, and whether or not parents can track the child’s progress throughout. On that last front, it should be noted that YogiPlay also offers mobile developers an SDK which allows them to integrate parental communication tools within their iOS or Android app. Less than twenty developers on iOS and Android are now using this SDK in their apps today.

The YogiMeter rankings will soon be featured visually in the company’s online parent-facing app discovery center and personalized dashboard as well as within its standalone mobile apps, all of which are undergoing massive redesigns right now.  (Hence, no screenshots are appropriate here). YogiPlay’s mobile app is available on Android currently, but has been held up in Apple’s approval queue for around three months. However, since the apps are HTML5-based, it seems that even if it was rejected from iOS, the company could easily make it accessible on mobile devices.

To date, YogiPlay has rated over 600 apps with YogiMeter, and is adding new apps to the system daily. The company has also seen some 45,000 parents register on the site, providing their email and their child’s age and other details. Although parents can’t see the YogiMeter rating just yet on YogiPlay.com, all the apps have now been vetted through the system.


YogiPlay Debuts “YogiMeter,” An Educator-Based Rating System For Children’s Learning Apps

Building Smarter Apps

iPhone App Store Icon Wall

A new breed of mobile applications is coming. These new apps will not only “sense” the world around you, using the smartphone’s sensors like the compass, GPS, and accelerometer – they’ll also be able to combine that data with a history of your actions to intelligently determine your likes, interests and favorites. This understanding of the world, or “ambient discovery” if you will, could then be piped into any app to make it smarter, whether it’s a social app for finding friends, a Siri-like personal assistant, a fitness app, a mobile game, or anything else.

This, at least, is the promise from the Palo Alto-based startup, Alohar Mobile, which recently introduced new SDKs for mobile app developers interested in experimenting with the possibilities of smarter apps.

Alohar Mobile (newly emerged from stealth mode), was founded by a former Platform Architect of Google’s Location Server Platform, Sam Liang. You may know him as the guy who put the “blue dot” location service in tens of thousands of mobile apps, including the default Map app on iPhone and Android, as well as in the Facebook check-in, Foursquare and Yelp. He also architected Google Latitude.

Liang started the company with Stanford alumni, Larry Wang and Alvin Lau, and they’ve now raised $2 million in funding from notable angel investors, including David Cheriton, the first investor in Google, Fortinet founder and CEO Ken Xie, and Tim Draper of Draper Fisher Jurvetson.

As for what, exactly, Alohar is providing – that’s a bit more complicated. It’s not just developing a smarter Siri, although that description is sure to catch more readers’ attention than something like “mobile development platform,” for example. While a smarter Siri-like app could be the product of Alohar’s work, it is not the work itself.

Lau describes the technology as an “ambient sensing platform.”

Um, say what?

“We’ve developed technology that sits on a smartphone that analyzes data coming from all the different sensors on your phone – for example, GPS and Wi-Fi – but a lot of companies do that, that’s nothing special. But we also gather data from the accelerometer, the compass, the gyroscope,” explains Lau. “It helps us to determine a person’s exact location.”

What that means is that apps using Alohar’s technology can precisely determine where someone is because of the way data is combined. For example, an app relying on GPS alone may know that you’re somewhere near a Starbucks, but can’t really tell if you’re there or in an adjacent store. Alohar-enabled apps, however, could detect things like the rate at which you’re moving (60 MPH? You’re probably driving down the road past a Starbucks), the direction you’re headed (moving towards the building slowly? You’re probably walking into the Starbucks), the network you’re connected to (ATTWIFI? You’re probably inside the Starbucks), and even time of day (8:30 AM? You’re probably at the Starbucks on the ground level of that skyscraper, not the nightclub on the top floor).

None of the data is used in isolation, but is instead parsed by advanced algorithms to make sense of your actions and movements. The algorithms give the app higher or lower probabilities to different types of places.

These algorithms can also take into account what you’ve done in the past and use that to help weight the data appropriately. For example, if you’ve visited that Starbucks several times over the past couple of weeks, but have never visited the bagel shop next door, the algorithm knows that you’re probably at the Starbucks.

Alohar’s technology has been packaged into a SDK for mobile developers, which allows them to create new apps or enhance existing ones. They’ve also released a sample app into the App Store called PlaceMe, which is an interesting product on its own. The app tracks and records your movements, producing a virtual trail you could later pull up online. A bit creepy, perhaps, but the company says it would be handy for Alzheimer’s patients to have installed.

But while PlaceMe is a fun experiment, the focus for the company is more so on the tech behind it. Some mobile app makers are already working on integrations, but Alohar can’t reveal who just yet, only give general descriptions. “Developers who are using [the SDK] are in the categories of dating, fitness and health apps that want to track your exercise and make recommendations, and shopping apps that make suggestions based on your location and your likes and favorites,” says Lau.

He also mentioned some check-in apps were experimenting with auto-checkins and the reduced battery consumption the tech enables. Plus, two of these twelve “ambient location” startups that were hot during this year’s SXSW have begun to implement the technology, too.

But it’s still early days for Alohar. The Android SDK came out in March and the iOS version arrived just this month. Both are in beta. So far, around 65 developers are evaluating or integrating the technology, Lau says.

And yet, almost any app that uses location services could benefit from the more precise targeting the tech offers, assuming everything works as advertised. More than that, the tech could enable a whole new kind of experience for developers to build on top of – one where users don’t have to do so much manual labor to explain to apps where they are and what they’re doing and what they want to do.

It’s yet another step towards engineering the serendipitous discovery of the world around us, via our mobile devices. It’s the underpinnings that could breathe intelligence into our apps, which could then make them, at best, more useful, more engaging, and ultimately, more loved…or, at worst, more creepy, more intrusive, more stalker-ish.

How developers choose to implement the technology, and the level of control they give to users surrounding that data’s use and storage, could raise a whole new series of questions about data privacy even though Apple, Google, developers and the government, are still figuring out what to do about the concerns we already have now – those that come more basic actions like accessing the address book or storing GPS data.

But with the fast pace of technology, sometimes you have to weigh the good with the bad and choose to move forward or get left behind. Using this scale, the possibilities to develop more intelligent apps – not to mention ones that can reduce battery drains – is a more exciting and promising step than the potential for abuse, real as it may be, from unscrupulous developers or the government (at least in less authoritarian regimes like the U.S.). You may not agree. That’s fine. But sometimes the laws have to catch up with the world, and in the mobile ecosystem, this is clearly going to be the case for years to come.

Below, a demo of how Alohar, doing things like automatically ordering an ambulance for you. “I’ve fallen and I can’t get up?” Yes, your phone will know.

Image credit: Ryan Orr


Building Smarter Apps

Security Hole Spotted In Facebook Android SDK, Long Tail Apps May Still Be Unpatched

facebook-security

Mobile app platform provider Parse is reporting having discovered a major security hole in the Facebook Android SDK. The problem was quickly patched after being reported to Facebook, but that alone may not be enough to secure affected mobile applications, the company says.

The security vulnerability affected all apps using the Facebook Android SDK, including major apps like Foursquare, and there’s no way for end users to know which app developers, outside the big ones, have implemented the fixes needed to secure users’ data. (Except for Foursquare, which we know to be patched – whew!)

Parse, for those unfamiliar, offers a mobile platform that enables developers to add scalable backend services to their applications. One of the tools the company provides makes it easier to add Facebook support to their Android apps. When used, developers can show a Facebook authentication flow to users, allowing users to sign into an app with their Facebook credentials.

To implement the feature, Parse uses Facebook’s Android SDK to get its authorized access token from the social network. This gives app developers the ability to perform common social actions on behalf of the app’s users, like posting to their Facebook Wall, for example, or accessing their Facebook profile data or friend list. Nothing malicious, of course, as the user is in control and can revoke the app’s permissions whenever they want.

Parse engineer David Poll explains via blog post how he spotted the vulnerability.  Android developers often use logcat, a diagnostic log that apps and system processes can write to, he says. This is actually an executable that can run on a developer’s PC and device. Applications can capture its log for debugging purposes, which, when combined with bug or crash reports, can help developers get to the meat of a problem in an app’s code.

Again, nothing odd or malicious.

However, when working on adding Facebook integration to Parse, Poll noticed something strange: a line appeared in the logcat viewer which basically showed the entire access token that had been just granted after logging in, encoded in a URL.

But Poll’s first thought was that the token was only viewable to them, even though they knew that logcat was essentially a public diagnostic bulletin board for Android apps. But to be sure, Poll tested to see if he could discover other apps (like Foursquare) that also use the Facebook SDK to see if they showed the same thing.

And they did.

Next, Poll used an Android app called CatLog (it lets you view logcat files), which let him see the same line of code without first debugging the app.

Uh-oh.

For those that don’t follow the above dev speak, what this all means is that anyone could write a simple app that scraped the output from the Facebook SDK and steal access tokens from the user of the device.

So Poll did that, too.

And yep, his “FacebookThief” proof-of-concept app worked, running in the background, snagging user tokens.

“In less than 20 lines of non-boilerplate code, I could masquerade as any Facebook user that logged into any app on the device that used the Facebook SDK,” explains Poll. “It wouldn’t even be clear that my app was the culprit. If my app posted to a user’s profile using the stolen access token, it would show up as though it came from the application from which it was stolen!”

And why is this bad? Because with the access token, a malicious app developer could then access the Facebook API and pull down personal data for the Facebook user whose token they had grabbed.

Parse was worried about what this meant for their own developer community. “By using an unmodified version of the Facebook SDK with Parse, we were exposing our developers and their apps’ users to the same vulnerability – something with potentially broad repercussions,” says Poll.

As for Facebook’s response to the reported vulnerability – no complaints here. The issue was patched within 24 hours, and Parse quickly updated to use the new SDK with its platform.

So maybe it sounds like this whole story is sort of a non-starter? Security hole gets patched in a day. Nothing to see here, move along?

But it’s not really a story about Facebook security. Facebook handled the situation as professionally as possible.

There’s a greater issue to be examined here about developers using SDKs and apps over-reaching when asking permissions to run.

Facebook (or any SDK maker, really), doesn’t have a way to push updates into developers’ apps. Instead, developers have to be proactive and manually pull down the latest Facebook SDK, incorporate the new version into their apps, and then push out updates through the app store.

Meanwhile, users are unknowingly exposed to security issues simply because they haven’t updated their apps, or worse, because a developer hasn’t yet addressed the issue on their end.

This particular issue happened in February, and Parse was asked to wait to disclose the issue until Facebook could work with major app developers to get app updates pushed out. Foursquare, you’ll be glad to know, is fixed.

However, Poll says ominously, “there are still some major apps out there that display this vulnerability.”

Which ones, we asked?

“I honestly don’t know,” says Poll.  ”We worked with Facebook to make sure that the major apps had fixed this issue before disclosure, and I know Facebook has sent a broad email to all developers with Android apps on their platform asking them to update their Facebook SDKs. I’m not even sure if Facebook has a way of knowing how many apps are still out there with this issue…”

Facebook, however, confirmed that it has reached out to all major app makers to get their code resolved, and it does have ways to tell that which apps are patched or not. But its response is being determined by how serious a problem this issue really is.

Users are only vulnerable if they have a previously installed malicious application on their system that they have granted the “Read Sensitive Log Data” extended permission. Users can protect themselves by downloading the latest version of their applications and uninstalling any untrustworthy apps.  Due to the responsible reporting of this issue to Facebook, no one within the security community has evidence of an application abusing this vulnerability. We have provided a bounty to the team to thank them for their contribution to Facebook Security.

What should Android users do then?

Poll suggests that, for starters, users should update their apps. But also be careful when granting an app permission which it doesn’t need. Applications that request the “Read Sensitive Log Data” permission have the potential to access private data, so only grant that permission to those you trust, he says.

Frankly, while accurate, I worry about these suggestions. On platforms where apps auto-update, great, that part is handled. (Ahem, Apple – listening?). However, asking users to read complicated and confusing dialog boxes and then make judgement calls based on what’s displayed sounds like a recipe for failure.

Really, it’s up to the mobile ecosystem itself to figure out a safer way to manage issues like this on the developer side. For what it’s worth, that’s what Poll says Parse is working on (as, I would imagine, are their competitors). The company tries to future-proof its design by reviewing code for any area where there’s potential for information to be exposed, he says, and it continually adds new features to the SDK to push developers to upgrade.

But at the end of the day, getting a developer to upgrade their SDK still involves a lot of manual outreach, it seems. Meanwhile, Android still need to think for themselves about every app they install by carefully reading the permissions. Depending on where you stand on things, that situation is either better or worse than Apple’s system, where apps just steal your data because users blindly trusted Apple to weed out the bad ones.


Security Hole Spotted In Facebook Android SDK, Long Tail Apps May Still Be Unpatched

Amid UDID Uncertainty, AppRedeem Creates New ID Scheme, Groupon Adopts

UDID-e1292882803383

Six months ago, Apple began making some big changes to its operating system ahead of the release of iOS5. Among them, was the news that it would begin ramping up the deprecation of the UDID — Apple’s go-to identifier that ties users to their specific iOS device. The company remained silent for months, but, as Kim-Mai reported last week, Apple recently began to take action, and is now rejecting apps that attempt to access those identifiers. Naturally, this has the iOS developer community sounding the alarm bells. Even though Apple made its intentions known months ago, since then, there’s been no consensus among developers as to the best replacement. Some have perhaps expected Apple to propose a solution, but the company has remained silent.

Apps that access UDIDs are still making it into the App Store, but developers now have to disclose the fact that they’re using them, and ask users for permission. Because of the mounting privacy concerns (from Congress, etc.), Apple is going to nix UDIDs altogether, but it remains unclear how long that will take. In the meantime, developers are scrambling to find alternatives, and Kim-Mai yesterday laid out some of the options available to those looking to take preemptive action. Of the choices, MoPub thinks the best near-term solution is the open source project, OpenUDID. Crashlytics has proposed another variation, SecureUDID.

Whatever the solution, there’s no question that the UDID issue has big potential ramifications for mobile advertising, as Amit Runchal pointed out. Developers and mobile ad companies unilaterally need to find a workable solution, and yesterday we caught up with Sheffield Nolan, the Co-founder of AppRedeem, whose team has developed its own alternative to UDIDs with what it’s calling the “Organizational Specific Device Identifier” (ODID).

Nolan says that, while Apple is backing off a bit on UDIDs in the short term with opt-in requirements, it’s really just postponing the inevitable. The “universal” part of UDID will end, and a replacement is imperative so that developers can switch before the next scare. The CEO tells us that the AppRedeem, which, for those unfamiliar, is an advertising platform designed to help developers boost engagement and drive new users to their mobile apps, tried a bunch of options, including fingerprinting, but they were found lacking.

Really, any solution predicated on having a global identifier for the device still doesn’t address the real privacy issues, he said, so the team began working on hashing Mac addresses. They did this for about six months, until they realized that, without the ID being bound to an organization, again, users would experience the same privacy concerns inherent to the UDID.

So, the team created ODID as a way to address user privacy issues. Over-simplifying, an ODID is created by appending a hash of the MAC address to an organization’s “secret key” to create the payload, and then applying a hash wrapper to the payload. Furthermore, the ODID is sandboxed within the specific organization that created it, and the device’s Mac address is used as the seed for the ODID.

This is the key: There’s no way to derive the MAC address from an ODID, because the MAC address is only a seed, so Company A, for example, could not determine if Company B’s ODID belonged to Company A’s users — even if they had the “secret key” — while both companies still have what they need to track their own users. What’s more, the ODID does not disappear with a device reset, so individual game developers can track their users even if there’s a reset, which is really what everyone is clamoring for.

Beginning on Thursday, AppRedeem began rolling out an update to its SDK with ODID support, which will be available for all customers by the weekend. The SDK is in plain source code, so everyone can see how it works, and AppRedeem is sharing the steps to create an ODID to AppRedeem’s spec so that users can do it on their own or just use its SDK.

AppRedeem currently has 3.4 million members on its platform, and App Trailers, its iOS app, has been downloaded 1 million times (and is currently seeing 20K downloads a day), the CEO says. The company’s advertisers include Groupon, Zynga, Disney, TinyCo, GameLoft, Priceline, Glu, Addmirred, AOL, and Smule; all in all, Nolan says, over half of the top 100 grossing apps use AppRedeem, which means the startup had good reason to find a solution that works for everyone. Groupon is the first of its advertisers to begin using the startup’s UDID-free SDK, as they were in a rush to realize full compliance with Apple, and wanted to switch as soon possible.

Although the UDID affects mobile advertisers (and mobile ad networks) most acutely, it really touches any iOS developer looking to track usage, downloads, clicks, etc. — all stuff that’s essential to mobile ad rev models. And there are a lot of those. As Amit points out, the UDID debacle really shows that the way Apple deals with its apps isn’t just going to affect individual business models, it has implications for the way an entire industry operates.

Apple likely never intended the UDID to become so vital to the economy they created, but it has. Most companies with iOS apps are scrambling to find a solution, and Nolan says that they’ve been in talks with TinyCo, Zynga, GameLoft, and that the majority of companies he’s talked to, both big and small, are trying to find a workaround. Any mobile business that has as its priorities both consumer privacy and advertisers tracking needs a better alternative to UDID. Nolan says that he hasn’t seen anyone really taking the lead, so the team has pushed to turn ODID into a replacement scheme for UDIDs — in such a way that doesn’t just solve the problem for their own clients, but offers a model for all businesses looking for better privacy tools for their users.

The startup is currently in the process of pushing its SDK live, and is in the process of creating a landing page and docs, which the AppRedeem CEO says should be live on the homepage soon. We’ll include a link when it goes live. AppRedeem homepage here.

What do you think?


Amid UDID Uncertainty, AppRedeem Creates New ID Scheme, Groupon Adopts