Portland-based company Grovemade is known for its range of attractive wood accessories designed for the iPad and the iPhone, which it has been producing for several years now. Grovemade recently invited MacRumors to go hands-on with two of its newest products for the iPhone 6 Plus, and we jumped at the chance because Grovemade products have been popular with our readers in the past.
We checked out the Maple and Leather iPhone Case and the matching Maple iPhone Dock. Read on to see what we thought.
Maple & Leather iPhone Case
All of Grovemade’s products are crafted by hand and the company’s attention to detail is evident in both the dock and the Maple & Leather iPhone Case. The base of the iPhone case is made of maple (there’s also an option for a darker walnut) that’s been carved to fit the iPhone 6 Plus.
The phone fits tightly into the maple shell, which has a cutouts for the camera, the mute switch, the headphone port, the speakers, and the Lightning port. There are darker wooden buttons for the volume and the power, which are lined with foam on the inside to activate the volume and power on the iPhone.
At the points where different wood pieces have been joined to create the case, there’s darker wood burned accents, which is aesthetically pleasing, and there’s also some wood burning around each of the ports, for a darker look. A piece of leather wraps around the backside of the shell and covers the front of the phone, and the leather front cover is attached to another thin piece of maple that protects the iPhone’s display.
On the maple attached to the cover, there are three pieces of metal, which adhere to three magnets built into the wooden shell. Inside the case, there are two additional magnets that pop away to allow the leather cover pull back to serve as a stand for the iPhone when in landscape mode. There are three separate stand positions that give slightly different viewing angles, and because of the cover, the phone also stands up by itself in portrait mode.
After announcing the Apple Watch in September of 2014, launch time has finally arrived. Apple in March announced that pre-orders for the Apple Watch will begin on April 10, with an official launch taking place on April 24.
Apple product lines for its iOS devices and Macs are relatively simple, consisting of a few models from which to choose. Picking an Apple Watch is a little more complicated, with the different models, a couple of watch sizes, and multiple band options. The prices start at $349 and go all the way up to $17,000 — a very wide range.
This guide walks you through the considerations you need to make when buying an Apple Watch. If you’re not sure which one to buy, this guide will lead you in the right direction.
More information has been revealed about the hardware specifications for the Surface 3 Docking Station. It’s now available for pre-order alongside the newly-revealed 10.8-inch tablet for $199 with shipments beginning on May 5.
Typically Android security issues fall into a couple of major categories. Firstly, personal information stored insecurely on a phone and secondly, insecure communication to any back end database or web server. And while there are lots of other things that can go wrong, the majority of security problems fall into these two areas. In this article we will look at the various options available to secure personal information in an app, and in the next article we’ll look at network communications.
The best option is to never store a user’s personal information, such as passwords or credit card numbers, on the phone. If getting the user to enter a password each time is not an option then you’re going to have to store the username and password somewhere on the device. There really aren’t a lot of places you can store information on an Android device. The possibilities are to store the information in shared preferences, or in a sqlite database, or in the device’s keystore.
Over the past few years, I have been part of a process that manually audited a couple hundred Android apps. During that time I have seen the same security problems, repeated again and again. And although we do our best to let the developers know about the security issues with their apps, we’ve been a lot more successful at hacking the apps than at getting anyone to fix them. So in an effort to spread the knowledge, let’s look at some real world authentication patterns we’ve seen as developers try to hide password information.
These are ranked in order of difficulty to break.
- Store in cleartext
- Store encrypted using a symmetric key
- Using the Android Keystore
- Store encrypted using asymmetric keys
Using cleartext means there is no protection to a user’s runtime data – assuming the hacker has physical access to the phone, which is a big assumption. But as there are so many phones for sale on eBay and Craigslist you have to assume that your app is going to end up sooner or later on a secondhand device. You can access all the information in an app’s data folders use the
adb backup command and then convert it into a tar format using the Android Backup Extractor or abe.jar. For example:
adb backup com.packagename.android
java -jar abe.jar unpack backup.ab
tar -xvf backup.tar
Using cleartext means there is no protection to a user’s runtime data – assuming the hacker has physical access to the phone.
A slightly better option used by a significant number of apps is to set the android:allowBackup flag to false in AndroidManifest.xml and then put whatever you want in the shared preferences or in into an sqlite database. The idea being that if nobody can back it up then nobody should be able to access the passwords. Unfortunately there’s a big flaw in this argument. Android is a Linux based system so root will have access to any files on the phone. If the phone isn’t properly wiped when it’s resold the new owner is going to have all the time in the world to root the phone and recover whatever dynamic user information is stored in the data folders by changing the permissions on the file and then doing an adb pull, instead of the adb backup command. Here is an example shared preferences file with an exposed password:
<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<boolean name="remember" value="true" />
A much better idea is to encrypt the password before you store it. If you are going to take this approach then don’t store the key in the APK code or anywhere else on the phone. It’s never a good idea to use AES, DES or any other symmetric encryption algorithm if you store the key where it can be easily found. It is a relatively simple process to find the APK and then get a copy off the phone. The command
adb shell pm list packages will get a list of the APK’s on your phone. To find where the APK lives on the phone use the command
adb shell pm path com.packagename.android using your APK name. Then use the following command to get a copy of the APK,
adb pull /data/app/com.packagename.android-1/base.apk making the appropriate changes for the package name and path or apk name where appropriate.
jadx base.apk to decompile the code back into java source code to see if you can find the encryption key in the code. If you are familiar with dex2jar then I suggest switching to jadx. It is an order of magnitude better at decompilation than dex2jar. Lots of apps I audited in the past with dex2jar have only given up their secrets when we starting using jadx.
Developers are a helpful bunch and they often put the encryption keys in easy to find places like com.packagename.android.util.security.
Developers are a helpful bunch and they often put the encryption keys in easy to find places like com.packagename.android.util.security. If that doesn’t work more often than not the code isn’t obfuscated and you can try searching for the class name or phrases like ‘encrypt’ or ‘decrypt’. To decrypt the password cut and paste the decryption code into a java file and give it the password as an argument. Some developers make the encryption key device specific by including device information such as the AndroidID as well as make and model information, but it’s mostly worthless if you can already see how the key is put together in the code. If you are going to use some sort of a recipe to generate the encryption key then obfuscate the code properly so that the ingredients are not easy to find. If possible store some piece of information (or even the entire key) remotely on a server, so not all the information can be found on the phone.
And as your app grows and you add more developers, make sure everyone knows how to encrypt and decrypt login information. In one of the dating apps I audited, I found the password encrypted in the shared preferences and another copy of the password was also stored in cleartext in the app’s sqlite database. Someone either didn’t know the rules or simply forgot to remove old code that stored the password in the database.
If you’re writing a healthcare app and you want to see if it’s HIPAA secure then put your device into airplane mode and if you can still log into the app then it’s probably not compliant with the HIPAA regulations.
The safest option for encrypting passwords is to use asymmetric encryption algorithms such as RSA. Asymmetric means that the key is split into public and private keys where only the private key can decrypt the information. We’re seeing a lot more developers using the Android Keystore to store public and private asymmetric key information.
In the Android Keystore this public – private key exchange takes place on the device and would seem to be HIPAA compliant. We say ‘seem to be’ as once again if you can root the phone you can gain access to the private keys. Nothing is 100% secure and sooner or later someone will find a way to get at the keys, especially if you put everything in the same place. I’ve always had a problem with mechanisms like the Android Keystore because app developer’s are relying on the skills of another developer for security, and there is no physical impediment to get at the keys.
Android Keystore public and private keys are stored in the
/data/misc/keystore/user_0 directory. The private key is stored in a file that has <app_id>_USRCERT_<key_alias>. On a rooted phone you can copy the file to another <app_id_malicious>_USRCERT_<key_alias> and then import it from your malicious app, allowing you to recover the password.
A safer asymmetric encryption option is to store the private key remotely. When the password is first entered, it is sent to the server for storage. It’s also encrypted with the public key and stored in the shared preferences. Every time the password needs to be checked then the public key encrypted password gets sent to the backend server and decrypted by the private key. It is then checked against the password information in the server’s database. A token is then passed to the Android client to allow access to the app. At no time is the password visible on the phone.
In Android this usually means using the Spongy Castle libraries or other alternative such as Google’s Keyczar. Sure there are other security issues that you have to think about like how to ensure that someone isn’t just sending you a publically encrypted key from a different device. But it is a lot easier to add extra ingredients to your asymmetric key recipe to foil these type of attacks when the code is on the server. We’ll return to this in the next article.
In the future Lollipop device encryption may put an end to many of these types of attack, but until Lollipop gains critical mass then options 1, 2 and 3 are not secure approaches. Our original recommendation is to ask the user to enter their password every time they sign in. If that’s not possible then never store the password in cleartext or leave the key in the code or on the device for someone to find. Asymmetric encryption keys using Spongy Castle or Google Keyczar are much better alternatives to consider. In the next article we’ll look at similar options for safeguarding your API keys.
Subscribe to our Android Developer Newsletter
Join our Android Developers newsletter to get all the top developer news, tips & links once a week in your inbox
About the author
Godfrey Nolan is the founder and president of the mobile and web development company RIIS LLC based in Troy, Michigan, and Belfast, Northern Ireland.He has had a healthy obsession with reverse engineering bytecode. See more from him here.
Back when the internet was starting to gain traction, one of the great benefits that came from it was email: a much quicker and easier to manage form of communication than the traditional letter. As technology has improved, email has managed to stick through all of the other changes in communication, including Instant Messaging (IM). Many have come to prefer IM over email, however it doesn’t make much sense to share your IM username (whether it’s Facebook Messenger, Hangouts, Whatsapp, etc) with more professional relationships. This is even despite the fact that after several emails in one thread, the formality that both parties followed in the beginning tends to fade, to more closely match the type of communication that exists in IM.
Not only does this help you find an email containing information you may have forgotten earlier in a thread, but helps make using email easier to do. Does this approach to email actually help?
The design of the app is curious to me. Overall, it looks good, and fits well with the IM theme. However, some of the icons, particularly those you see when swiping to the left over a message, look very pixellated (pictured below). This one place where the design falls makes the app feel not well-done, despite the fact that the app runs fluidly and the rest of the design is great. It gives me mixed feelings.
Other than that, the app looks great, and while it needs some polishing, it’s off to a great start for a brand new app.
The idea of Hop is to pull together your emails into a running thread that looks like an IM client, but still have it run through email. This brings many benefits, the biggest of which allows finding a past email with information you need much easier. You don’t have to scroll all the funky formatting that all the different email clients out there place into their email threads. Hop automatically strips all of that, and places the text of the very last email into a message-like bubbles (pictured below). Also, the app was always faster in retrieving an email before my other email applications, allowing it to really feel like IM.
In terms of making email feel like IM, Hop succeeds really well. However, this method brings two issues from my perspective:
- Since the emails look more like an IM, my instinct is to reply to messages as such. So rather than typing out more formal, professional responses, I feel inclined to respond in a short, informal manner, and even include emoticons. Not only is this unprofessional, but it proves difficult for separating personal conversations with work-related conversations.
- Hop seems to always combine conversations with the same person, despite their being a different “Subject”. While I understand the continuity in providing an IM-like experience, there are times when I’d like to find a different email thread based on the “Subject”.
Hop is a great idea, and will fit well into a generation where immediate results are desired. However, I think the app needs some work and polishing, especially in its design. Also, I don’t think this is the best solution for business application, as the informal feel of conversation and combination of different subjects makes working professionally in the email more difficult.
Google has partnered with ASUS, Haier and Hisense to bring four new budget priced Chromebooks to the market. Prominent among these is the ASUS Chromebook Flip, which is a convertible device that can transform into a tablet or a fully functioning notebook on your call.
The Chromebook Flip comes with a 10.1 inch touchscreen display and can be rotated 360 degrees, hence the name. We must note that this tablet cannot detach itself from the keyboard, but merely flip backwards. But it’s a neat feature to have nevertheless.
ASUS Chromebook C201, the Hisense Chromebook and the Haier Chromebook 11 are pretty basic in their approach and don’t come with the bells and whistles of the Chromebook Flip. But the pricing of these devices make them very attractive propositions.
As for the hardware, all the aforementioned Chromebooks sport 16GB of internal storage with a microSD card slot, 2GB of RAM and a Rockchip 3288 SoC. Other features include a front facing 720p camera and a total of two USB 2.0 ports.
The Chromebook Flip has been priced at $249, while the ASUS Chromebook C201 costs $169. The two Chromebooks from Haier and Hisense have been priced at $149, making them the cheapest of the lot.
Come comment on this article: Google launches four new budget Chromebooks ranging up t $250
Flickr has long had ways to let others use and tweak your photos, but if you want to give up your copyright altogether? You can now do just that. In the wake of Elon Musk releasing SpaceX’s photos to public domain, Flickr has added options for public domain and Creative Commons 0 (“no rights reserved”) licenses. Choose them and others can do whatever they want with your images, free of charge or even credit. If you see your photography as more of a service for the greater good than a closely guarded treasure, you can loosen the restrictions today.
[Image credit: SpaceX, Flickr]
Filed under: Internet
Source: Flickr Blog
According to an unnamed source from Korea, the upcoming LG G4 flagship will come equipped with a Qualcomm Snapdragon 808 SoC, rather than the expected Snapdragon 810. The source also claims that Qualcomm won’t be able to fix the overheating issues that have plagued the chip’s reputation until the second half of this year.
As well as local sources, a recent GFXBench listing for an LG G4 (F500x) also points to a Snapdragon 808 processing package. The database also lists a 5.5-inch QHD display, 3GB of RAM and Android 5.1 on board.
In case you missed the announcement, the 20nm Snapdragon 808 is a hexa-core SoC. It features four low power Cortex-A53 CPU cores pair up with a dual-core high performance Cortex-A57 configuration. The GPU is an Adreno 418 and the memory configuration is paired back to 933MHz dual-channel LPDDR3 rather than LPDDR4 found in the 810.
Apparently, this all comes back to the Snapdragon 810 overheating issue, but there is mixed evidence as to whether this is actually a major problem or not.
After a period of denial, LG eventually conceded that an initial batch of chips had suffered from some problems, but that the issue would not affect the G Flex 2 or G4. While the G Flex 2’s UI may be a little sluggish in places, we didn’t have the same complains about the new HTC One M9, suggesting that LG’s performance problems may have more to do with software than hardware. Some sources state that Qualcomm fixed the issue for production commencing Q1 2015, while others say the fix won’t be applied until Q2.
Above: HTC apparently patched some One M9 overheating issues with an update.
It’s tough to know exactly what to make of the Snapdragon 810’s apparent issues, but LG dropping back to an 808, having earlier used the 810, would be a damning concession. The other possibility is that LG is reserving the Snapdragon 810, or waiting for fixed chips, until it launches its even more high-end device later this year, although that theory may leave the G4 disadvantaged against the competition.
As for performance, six cores, two high-performance and four energy-efficient, would be more than good enough for most tasks, providing that the OS is kept lean, but the loss of two cores would definitely be felt in heavy multi-tasking scenarios. The switch to a mid-range Adreno 418 GPU would result in inferior graphics performance compared with many last generation Snapdragon 805 handsets, which pack an Adreno 420 GPU. This could be particularly concerning for gamers, if the LG G4 retains a QHD display resolution.
Although this rumor may sound negative, switching to a cooler, more energy efficient chip has benefits for battery and product life-spans. If it side-steps rumored throttling issues with the 810, the performance gap may not even be that pronounced either. Of course, this would leave Samsung’s Galaxy S6 in a secure position as the performance leader.
Qualcomm declined to comment on the issue and LG stated that its release plan is subject to the development of Qualcomm chips, which doesn’t tell us very much. With the LG G4 launch date right around the corner, we’ll know soon enough if this latest rumor comes to pass.
Google has just announced a new and affordable way to bring Chrome OS to your television. The Chromebit, which is essentially a Chromebook packed into an HDMI dongle, will turn your TV into a fully-functional computer for a pretty low cost.
The first Chromebit device is manufactured by Asus and actually packs quite the punch. It has a Rockchip 3288 ARM Cortex-A17 processor, 2GB of RAM, a Mali 760 GPU, 16GB of internal storage, one USB port, Bluetooth 4.0 and Wi-Fi 802.11ac. The device is a bit bigger than a Chromecast, but the Chromebit actually swivels around allowing you to hide the device from sticking out of the side of your television. Google says the device will become available sometime later this summer for less than $100 in silver, blue and orange variants. This first generation device is still in testing, so the company couldn’t comment on its battery life quite yet.
The dongle made by Asus is just the first of many that will eventually make their way to market, though. Google says its hoping other manufacturers will jump on board, so we’ll likely see a few more of these devices launch with varying price points and different features sometime in the next few months.
So what do you think? Are you interested in the Chromebit?
Apple and HBO recently inked a deal that will see Apple becoming the exclusive launch partner for HBO’s upcoming “HBO Now” web-based streaming service, and in an interview with CNBC, HBO CEO Richard Plepler explained why the company chose to partner Apple.
According to Plepler, the main reason why HBO opted to team up with Apple was due to the success of its existing cable-based service, HBO GO. 60 percent of HBO GO traffic comes from Apple devices, including the Apple TV, Macs, and the iPhone and the iPad. HBO GO apps have been available on iOS devices since 2011 and the service has been available on the Apple TV since 2013. Plepler also pointed towards the popularity of Apple devices as a deciding factor.
Well, listen. They’re obviously an extraordinary company with a wide range of devices, and those devices are proliferating throughout the consumer base. But also, as we look at HBO GO, which is our streaming service tethered to distributors, we saw about 60 percent usage on Apple devices so it made perfect sense for us to work with Apple introducing HBO Now.
HBO Now differs from HBO GO because it does not require a cable subscription for access. Instead, all of HBO’s content, including TV shows, movies, documentaries, and more, is available to customers for $14.99 per month. Launching in time for the Game of Thrones premiere in April, HBO NOW will be exclusively available on the Apple TV and Apple devices for the first three months of its life.
Once that three month period has expired, HBO will bring the service to other platforms as well. Plepler expects HBO NOW will be popular with millennials, calling it a “millennial missile,” and he doesn’t believe the price, which is higher than other services like Netflix, will turn customers away. “We think we have a premium product,” he said. “We have extraordinary content … and it’s the price of a movie ticket and a bucket of popcorn.”
In addition to partnering with HBO for HBO Now, Apple is also in the middle of negotiations for its own streaming television service, which would provide a select number of cable channels to customers via the web, with no cable subscription necessary. Apple is said to be planning to price the service at $30 to $40 per month for approximately 25 channels, and is partnering with ABC, CBS, Viacom, Fox, Discovery, Disney, and more.
Apple may be planning to launch its new service in June, at this year’s Worldwide Developers Conference, possibly alongside a revamped set-top box.