Subscribe:

Ads 468x60px

Labels

Cell Phones : [ Galaxy Nexus™ (Sprint) ]










  • Samsung Galaxy Nexus











  • Samsung Galaxy Nexus











  • Samsung Galaxy Nexus










Android™ 4.0, Ice Cream Sandwich for unlimited potential and more control

Cell Phones : [ Samsung Repp™ (Generic CDMA) Android Smartphone ]





Customize with Android™ 2.3, Gingerbread and a full range of Google™ services

Cell Phones : [ Samsung Transfix™ (Cricket) Android Smartphone ]





Android™ 2.3, Gingerbread + 800 MHz processor

Automatically Stop Your Music When You Sleep

music-off-logo

If you’re a music fan—and let’s be honest, we all are—you surely have fallen asleep with headphones in your ears at some point. Most music apps don’t have an auto shutoff feature, and this means that your music will keep playing all night. This isn’t ideal, as you probably won’t get a full night’s sleep with the noise, and your battery will drain faster than without anything playing.


Luckily, Simple Sleep Timer by XDA Senior Member crazyfool_1 can lower your music volume, or even shut down your music player app, after a predefined amount of time. In other words, you can set the app to kill your music player after one minute or an hour.


This application supports most popular music players like PowerAmp, Google Music, or Spotify; so you shouldn’t worry about music player compatibility. Simple Sleep Timer works with all Android versions, ICS or later. It’s currently in its initial release, so there may be some bugs, but they should be ironed out really soon.


You can grab that simple, but useful application from the original thread. If you have a habit of going to sleep with headphones in, this app is a must-have.


Snapchat: A Lesson in How NOT to do Security

Snapchat logo

Here at XDA, we focus on bringing you news about what developers are up to on the forums or significant changes in the mobile industry. Today though, I bring an analysis of some recent news about goings-on in the security world in relation to a particular mobile application you may or not have heard of: Snapchat.


Snapchat is best described as a gimmick application, widely used by teens to send each other photos and short videos, which “self destruct” after viewing, preventing copies being made, etc. Before the security world tries to spear me on a stick and roast me, allow me to point out that Snapchat is an entirely flawed application. It’s not possible to achieve what they are trying to do, as they are trusting a device you control (your phone) to prevent you from copying data they send to it. As such, Snapchat has been broken. Many. Times. Over. On iPhone, and Android, and even via HTTP interception.


Four months ago, a group of security researchers, known as Gibson Security, identified a flaw in the Snapchat server API (the interface through which the Snapchat application communicates with the server), from the feature allowing users to find other users based on their mobile phone number. As the intention was for the application to upload a user’s contact list in order to find friends using the service, the API permitted a rapid rate of phone number queries. This allowed anyone to rapidly query the Snapchat service with phone numbers, asking if those numbers were in use by any user of the service, and if so, the associated username of that user.


Gibson Security found the original flaw in July 2013 and disclosed the issue to Snapchat. Four months later, and no response from Snapchat. They even tried applying for one of the jobs they were advertising! (source) On December 24th, Gibson Security released full documentation of the Snapchat API. The Snapchat API, while not documented, is not in any way hidden from a competent user, as the Snapchat application simple sends requests to the Snapchat servers using a particular format. Unfortunately though, Snapchat seem to be great believers of “security through obscurity,” sending unfounded takedown requests against people working to understand their API. That shows Snapchat has something to hide. After all, reliable, robust, and professional services make their API available freely and openly for people to use.


What followed was Snapchat’s somewhat lackluster statement on the matter, which amounted to saying “they were right, but we don’t think it’s a big deal, so we won’t really do anything about it, short of hiding behind some words about API query limits”. As anyone competent in security can tell you, putting some limits on this API is a short-term stop-gap fix (if done correctly), but isn’t a proper solution. The proper solution is to redesign this functionality to prevent attackers from gaining any information about users by guessing at simply phone numbers. A shame Snapchat’s team probably have never even seen the word “security”, let alone used the word with any meaning.


They also make some really rather bold statements, such as:



“We are grateful for the assistance of professionals who practice responsible disclosure and we’ve generally worked well with those who have contacted us.”



Given this case indicates the opposite (4 months+ without a response for Gibson security), I refuse to believe this, and implore you to do so as well. In fact, I would love to hear from any security researcher who has had any kind of positive interaction with Snapchat, at any time. I genuinely would, as it would prove that perhaps Snapchat are not lying through their teeth in a moment of self-preservation at this point.


On the 1st of January, a website appeared, offering for download 4.6 million Snapchat users’ phone numbers and associated usernames. While the resulting database had censored the final 2 characters of each phone number, those releasing the data said they would give access to the full, uncensored data, if approached with reasonable requests. That means there are now 4.6 million users of Snapchat with their phone numbers available to the world. While some naive and technically inept news sources report that the files and associated website have been “taken down,” as we all know, nothing is ever fully deleted from the Internet, and the files remain easily accessible for those seeking them. Unfortunately for anyone whose details were in that database, the damage has now been done.


Two to three days later (depending on timezones and the time of the precise release of the data), Snapchat finally raised their heads from the sand to make a somewhat pointless blog post. They did not apologise for the data breach, and nor did they apologise for being naive or mishandling user data. In fact, they didn’t actually apologize for anything. They were rather quick to apportion blame though:



On Christmas Eve, that same group publicly documented our API, making it easier for individuals to abuse our service and violate our Terms of Use”



Unfortunately, Snapchat, after designing a broken and insecure web service and trying to call the API that interfaces with it “private,” is not going to help you here. No serious hacker (who has bad intentions for your users’ data) is going to read your terms of use and say “I won’t hack them then… They asked me nicely not to do it.” Your terms of service should never be a front-line protection. Consider, for instance, that Snapchat states in their terms of service, “you must not view messages intended for other users,” and then simply makes every message publicly visible to everyone. I know it sounds far-fetched and silly, but that perhaps puts into perspective Snapchat’s naive approach to security.


Indeed, Sophos appear to also concur with my thinking here. Ultimately though, if users want to be protected from these kinds of attacks, I have 2 key pieces of advice: Firstly, give out less information. There is no reason for Snapchat to require or ask for your phone number, other than to enhance their user base and get you using Snapchat more. Mobile phone numbers are personal information, and you should really stop handing it out to services (sometimes without your knowledge). Take a look at XPrivacy by XDA Senior Member M66B to control access to this kind of data.


Secondly, and arguably more importantly, companies need to protect your data. I would say they should protect it as much as their own data, though given Evan Spiegel’s (Snapchat founder and CEO) own phone number and username were in the data breach, I suggest they don’t take enough care of their own information either. Users should have the expectation that ANY service being actively marketed and encouraging users is secure, and that this security has been tested through the company employing security experts, or at least getting suitable levels of peer review on their source code. Just think—if Snapchat’s web service was open source, this would have been fixed months ago, if that bug had even got through the scrutiny of the open source community in the first place.


To close, I offer you the following questions:



  1. How incompetent and complacent must a company be to ignore a security advisory of any kind, for 4 months?

  2. Why would a company such as Snapchat, in dire need of security knowledge, ignore a job application from a group of security researchers?

  3. Do Snapchat seriously believe that a malicious attacker (who wouldn’t tell anyone they obtained this information) will avoid taking advantage of their own security weaknesses, just because they ask politely for people not to? (Imagine asking another country nicely to not invade you – it doesn’t work)

  4. What can Snapchat do to regain user trust? Asides from coming and working with the security community (full disclosure, which I am a member of) in an open manner and fixing issues, Snapchat need to apologise to their users, and show humility here. Evan Spiegel is a college student, and he needs to get in people who know about security. And I know plenty of college students who are experts and could have prevented this.


While writing this article, further vulnerabilities have already been found in Snapchat. It appears that the original Snapchat issue is only scraping the surface of issues on their service. I do hope they take this opportunity to get competent security review of all their services and code carried out, so that they can protect their users and ensure their data is properly protected in future.


Skate to Where the Puck Is Going

Businesses implementing Android apps can learn from what Web developers have done to handle browser variations, to handle the similar variations in Android OS versions. In this first post of a three-post series, we will examine what Web developers have done to simplify their development efforts and what the Android analogues are.



SQLCipher for Android, and You!

Full-disk encryption is fine as far as it goes, but it does not go quite as far as you might think in terms of defending your data. If you are considering encryption at the application level, in addition to the device level, SQLCipher for Android makes it easy for you to add AES-256 encryption to your local databases.