Live data from Hacker News

Google announces Android for Work

googleforwork.blogspot.com

81–90 of 174 posts

Re: Google announces Android for Work

#81

Earlier quoted context omitted.

Just for the sake of clarity, do you mean that there are more apps that are sandboxed on iOS or that all apps have a higher level of sandboxing on iOS?

More "sandboxed" in the sense that iOS apps start in a small sandbox that gets progressively and opportunistically larger. Instead of demanding all permissions upon installation, they demand them contemporaneously with attempted access to certain resources. The idea is that user consent is more informed. In contrast, Android apps demand all of their permissions up front.

Even beyond that though, if an iOS app requests ALL possible permissions, it doesn't have the same capabilities that an android app does.

Re: Google announces Android for Work

#83
post #9

So we're all going to code, write, etc. on four inch screens? Seriously why hasn't someone made a smart phone that "transforms" into a larger screen form factor when connected to a monitor? I could see Android phones doing this. I could never imagine iOS doing it-- Apple would never cannibalize Mac like that, and iOS is too jailed for anything "real." Of course apps would have to support it. But those that didn't cou…

Sure, tech companies aren't going to start writing code on mobile devices. But there are plenty of enterprise companies where writing, viewing and editing can definitely be done on phones and larger form factors such as tablets.

Re: Google announces Android for Work

#84
post #34

Earlier quoted context omitted.

This is more targeted for people who have an enterprise domain (Google Apps for Work, Blackberry, Citrix, etc.) That said, if you want to create a separate profile for Uber or Line, you can already do so on Android 5.0 and above: https://support.google.com/nexus/answer/2865483?hl=en&ref_to...

Please correct me if I am wrong but I thought this was for sharing your phone with someone else or sharing your phone between two or more Google accounts... I think Facebook Messenger, Line, and the like will still have access to all permissions even if you switch to a different user and install the apps there... That being said, guest mode is really nice on my nexus 5 so my curious friends on iPhone can log in to th…

I think the idea is, you create a dedicated "sandbox" account, install apps in it that you don't trust that want access to calendar, contacts, text messages, etc., and then don't put any real data of those kinds in the account. So, they still have permission to see those things, but they don't see anything when they look.

Note, I have not looked deeply, so maybe it doesn't work like I said. I would not expect multitasking to be very seamless with this method. Also, I know there are some permissions that have "cross-user" abilities, so maybe there is still a way to accidentally allow an app to access your real data.

Re: Google announces Android for Work

#85

Earlier quoted context omitted.

A bus station is a where a bus stops. A train station is where a train stops. So what is the purpose of a workstation? And more importantly, what is the purpose of a PlayStation? ;).

A bus station is also where a bus starts. Ditto for trains and train stations. ;)

But you have to wonder what a bus shelter is for if there are air raid shelters too - to protect you from buses??

Re: Google announces Android for Work

#90
post #37

Earlier quoted context omitted.

If your device is rooted, and by that I mean real rooted (bypassing SELinux), then it can get the encryption keys as at some point the data needs to be decrypted and viewable by you.

Encryption keys can be hidden in a way that is next to impossible to decipher. Superfish level of insecurity doesn't have to be the norm. The downside is that there are no open source libraries that make this possible which is why few people know about it.

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 products by a lot).

The one thing you can do is to put the key in a separate hardware device, and have the hardware refuse to make the key directly available, but only do encryption or decryption operations under certain circumstances (e.g. it's audited what's running on the device). This is definitely doable with a TPM on a standard PC, and there are in fact open-source libraries that will handle this for you.

Post reply on HN