I wonder how google driver can know what PC I'm syncing from such that they can block it. That sounds like it may not be true that an admin of the drive folder can block syncing to a PC.
(BTW even if you have a strong password you better also be using encrypted disk's because I'll just pull the drive and slave it to a Linux or even windows box and mount it to extract all the data I like.) Also, google doesn't "own" the configuration or the binary load that goes on that stick device. From an IT security point of view its yet another untrusted usb dongle. Who are you asking to fix what here? And how could it be enforced? You have an entire root of trust discussion you need to work through to get anywhere on this topic. AFAIK all those stick devices are basically rooted hacker toys. If you are worried about security I would not be using them anywhere with a real google account. Even if I compiled the code myself (because alone I can't test it enough to be confident WRT its security) This isn't something that can be fixed on the client side IMO. --mark On Sun, Jan 6, 2013 at 5:21 PM, chicken <[email protected]> wrote: > > Hi Mark > > Indeed you can extend this concern to laptops however two things..... > One is Google apps chanel allows the administrator to stop local drive > sync to pc or mac. There is no ability to block android devices. This > is the reason why it's so troubling or put another way the reason > Google can justify not giving control to administrators over mobile > devices ability to sync drive. Two.. Most enterprises will have their > pcs including laptops joined to a ms server domain requiring the > windows device to have a complex password. Yes hackable but not easy/ > fast. > > I've had someone more technical than me look at the stick software. He > thinks the issue is the configuration file has the lock screen > attribute set to '0'. My amateur solution to Google would be that the > device policy checks that the lock screen setting is set to 1 > otherwise it will not allow any syncing. > > If Google can't do this then they need to give app administrators the > power to stop all devices (not just pc and mac) which from syncing > drive. > > Toby > > > . On Jan 6, 6:05 pm, mark gross <[email protected]> wrote: > > Well, you can extend this FUD storm to any hackable / unlocked device > > including laptops. What you are really asking for is a new type of > google > > account that is only accessible from devices google or some configured CA > > like entity trusts. Not an unreasonable ask. Tricky to implement. Not > > just an Android problem. > > > > IMO this is a bigger discussion than just android. If I steal someone's > > personal laptop I can do the same things to the victim. > > > > However; for the android domain, perhaps a policy engine on the google > back > > end that works with enterprise clients via widevine cirts would be made > to > > work. > > > > --mark > > > > > > > > > > > > > > > > > > > > On Fri, Jan 4, 2013 at 12:29 PM, chicken <[email protected]> wrote: > > > As sent to Android Security... I would very much appreciate the > > > comments from people here..... > > > > > Background > > > In addition to Phones and Tablets, a new set of mini-PC Android > > > devices have come to market. > > > They are the size of USB sticks and have an HDMI port to connect to > > > your TV. > > > They are normally loaded with Android 4.0 or 4.1 Tablet edition > > > Great idea. We want to use in meeting rooms with wireless keyboard/ > > > mouse to allow user access to Gmail and Drive. > > > > > Problem > > > Unlike phones and tablets and devices with touchscreens, these sticks > > > do NOT force a lock screen EVEN if the Google Device Policy App is > > > installed and activated. > > > When activating the Policy App, the device asks for a PIN or Password > > > and the device syncs with Google and checks the PIN or Password > > > entered meets the Apps administrators required security level.. > > > However after the Account is added and data is sync'ed, the device > > > never goes to lock screen. And there is no way to force it to go to > > > lock screen. Even after a restart. > > > So Google and Apps administrators thinks the device is secure but it > > > isnt. > > > If the device is lost then the data is entirely open to be read and to > > > be deleted. > > > > > Urgency > > > If the solution to this was simply not to use this type of device then > > > I could accept the flaw rests solely with the hardware manufacturers > > > However there is nothing a company can do to stop an employee from > > > buying a Stick in good faith and complying with the device policy and > > > then losing the device only to have their entire dataset deleted. > > > The server is saying that the policy is in force. The company is at > > > risk at any time and noone knows who has secure access. > > > We have gone 100% Google Apps and allowed users to buy phones and > > > tablets because we trust that the Device Policy protect us from data > > > theft. > > > If someone with high level access lost their stick and their Drive was > > > deleted, it would be a total disaster for most us and all similar > > > Google Cloud businesses. > > > > > Conclusion > > > In short - there can be no situation ever where a Device Policy can be > > > circumvented. > > > If the Policy which has been activated and validated requires a PIN or > > > Password, then the device must enforce this. > > > I think the issue is to do with these devices being non-touchscreen. > > > There is nothing to 'swipe to unlock'. > > > Android should not be able to be installed on devices without the > > > ability to enforce lock screen policies. > > > > > Two devices I have tested are Minix Neo G4 and Rikomagic MK802IIIs > > > > > Neither of the manufacturers are able to help with this and the > > > retailers suggest putting this on forums. > > > > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Android Security Discussions" group. > > > To post to this group, send email to > > > [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group at > > >http://groups.google.com/group/android-security-discuss?hl=en. > > > > -- > > create interesting things. > > -- > You received this message because you are subscribed to the Google Groups > "Android Security Discussions" group. > To post to this group, send email to > [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/android-security-discuss?hl=en. > > -- create interesting things. -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
