Hi Mark - thanks for your reply. First i should say i am a complete novice on this subject - i appreciate it is annoying when a newbie dives in with a problem and they dont understand the bigger picture.
On your PC pooint - why doesnt the Drive app for Windows require a Device Policy also if the account is part of Apps. No different from a phone? I understand that Google does not own the binary code that gets put on the device. I see your point about it being yet 'another usb' dongle. My thought was that Google Apps device policy can check to see that the device has the ability to lock screen? That is the lock screen attribute is set to 1 rather than 0 (i am probably simplifying but you know what i mean). Maybe there could be a lock and unlock process to activasting a device. Your last point on on sticks is valid for sure. But my worry is that I can only control what I do, not the many people who work at the company. They can buy a stick adn enter their email address/password in and activate the device policy - I agree its a service-side problem not a client side one. (although i think it is a reckless implementation by stick manufacturers to allow people to circumvent device policy from Google which is most like the key platform people will connect to.) Thanks Toby On Jan 7, 3:07 am, mark gross <[email protected]> wrote: > 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.
