161–170 of 174 posts
"Secure business apps" Right, on a device with a closed source baseband. On a platform where the vendor has shown to install new apps without getting active consent from the user (Google Play Games, Hangouts, Google Now, Play Kiosk) to name a few.
Downvote all the way you like. Or start defining "secure".
Earlier quoted context omitted.
That's obfuscation, which is just an arms race; it's not security in any measurable sense. It's fundamentally equivalent to the DRM problem. And there are no open-source libraries and not a lot of public documentation about how to defeat this sort of thing, so very few people who engage in this work have a good understanding of exactly how robust it is (and, anecdotally, most people tend to overestimate their product…
Which brings a good point: if you have root (and presumably you can even write a different kernel), how do you make sure the TPM can verify what's actually running on the processor when you can just fake it? Or better yet, if you have full blown root, what's preventing you from just kinda LD_PRELOAD some code for that process and steal the decrypted data before it gets to the legitimate application? Or take a screens…
On a PC architecture, the TPM is wired up to the CPU and other parts of the system, such that (for so-called "static root of trust") it gets initialized with a hash of the BIOS at bootup. The legitimate BIOS then adds in a hash of the boot sector, which adds in a hash of the kernel, which adds in a hash of anything the kernel thinks is worth verifying. Only if the final value of this TPM register (called a "PCR") matches up will the TPM allow a stored private key to be unlocked ("unsealed") and used.
Alternatively, for so-called "dynamic root of trust", there's a processor instruction that both clears all processor state (interrupts, paging, etc.) and a particular TPM PCR, and loads in a block of code. If the code is different, the key won't unseal. If someone is intercepting that processor instruction, the PCR won't get initialized correctly, and the key still won't unseal.
So it's mostly up to the kernel to verify everything that could possibly be relevant. (If you're thinking this is a hard engineering task, yes, that's one reason why this isn't in wide deployment, despite the technology all existing.) For instance, it might verify an entire read-only root filesystem, and then set things up so that on the work container or VM, nothing else can be installed, no additional executables or libraries or LD_PRELOADs get loaded, debuggers don't work, etc. In the personal-use container/VM, it can still run a normal OS.
Earlier quoted context omitted.
That transitivity itself is an issue. Why cannot the installed apps request the permissions they need individually?
Unless i am mistaken, Amazon can't give premissions to another app install. The user has to leave the "unknown source" option checked as each APK installed goes through the same rigamarole. Play gets around this by being bundled as a system app initially. And if you have a rooted device you can potentially promote the amazon store to the same status, and so forgo the "unknown sources" switch.
Earlier quoted context omitted.
More importantly, if you ask me: iOS allows you to install an app, and deny it permission to something. Eg. I can deny the Facebook app access to my contact list, and the app still works. With Android, you grant an app access to everything it asks for, or you aren't allowed to install it. This seems obviously inferior to me.
With Ap Ops since 4.3 you can twiddle them individually.
Earlier quoted context omitted.
Four years of android user. Just switch to iphone6 2 month ago. Almost every app requests too many permissions. Almost every app starts a background process to receive notifications. which are very bad.
iOS apps do not (can not) "start a background process to receive notifications". Notifications are globally handled by the OS over a single dedicated optimized connection. And then dispatched to the individual applications.
I love the name "Google Play for Work."
Even the icon is a stylized version of the mark found on the appropriate button.
Earlier quoted context omitted.
I worked on Windows Live Mobile for Windows Mobile. Thankfully it was renamed.
Could be worse. I still remember when Microsoft maintained both "Windows Messenger" and "MSN Messenger" as separate apps with separate update schedules and version numbers even though it was the same product. That was confusing.
Earlier quoted context omitted.
Blackberry was ahead of the curve on many things, they just sat on those advantages and never really responded to the changing market.
I don't mean to beat on Blackberry but I too thought of Blackberry when reading this. I had a different approach though. This was the sort of approach that Blackberry optimized to lock out any competition from the enterprise. Apple/iPhone was just soooo good that eventually IT departments had to capitulate and work with BYO devices. Things like the US government were the last to cave so you Obama had a blackberry for…
Didn't many accountants sneak their private AppleII into the office to run Visicalc rather than having to deal with the mainframe and its admins?