There's an important distinction between the implementation of multiple accounts on the Mac vs multiple accounts on tablets like the Nexus 7. Whereas desktop operating systems allow multiple applications to run truly concurrently, most applications for Android or iOS only run when visible. When you go to the home screen, lock the screen, or switch to another application, the current application saves its state, pauses, and ceases to consume CPU cycles; at this point, the application is ready to be killed at any time by the OS to free up memory. Therefore, the overhead of multiple user profiles on a tablet should be quite low. As you can see here (http://youtu.be/Ra27gat-u_Y?t=3m), switching users is pretty quick on a Nexus 7, and should be even faster on the beefier hardware of the iPad. A multiuser implementation for iOS could actually be simpler than Android's current implementation since iOS does not have to deal with third-party background services.
I think this is basically how Android's implementation works.
That assumes Apple would do it the same way and that Android's way is secure. Is there any evidence that the user data on each account is not accessible from another account?
I don't think it's impossible but that video doesn't show something that looks like something Apple would release. That said, I'm all for it since it doesn't impede my usability in any way.
That assumes Apple would do it the same way and that Android's way is secure. Is there any evidence that the user data on each account is not accessible from another account?
From the same Arstechnica article that I ninja-edited into my previous post:
"Users also can't share data directly with one another; if you want to transfer a picture to another user's account, you'll have to e-mail it to them or share it through some other third-party service. Even if you plug the device into a PC or Mac, you can only view the media files of the tablet's current user. Switching users with the tablet connected to a computer will unmount the tablet and then remount it to give you access to the other user's files. This is a little annoying from a usability perspective, though from a security perspective it's definitely a nice touch."
The security architecture is quite similar to that of OS X or any other unix-like system, and is a solved problem. Each user has his own UID. User-specific application data are stored in each user's home directory, which is kept private using standard unix access controls.
"As an app developer, there’s nothing different you need to do in order for your app to work properly with multiple users on a single device. Regardless of how many users may exist on a device, the data your app saves for a given user is kept separate from the data your app saves for other users. The system keeps track of which user data belongs to the user process in which your app is running and provides your app access to only that user’s data and does not allow access to other users’ data." (http://developer.android.com/about/versions/android-4.2.html)
From the same Arstechnica article that I ninja-edited into my previous post:
"Users also can't share data directly with one another; if you want to transfer a picture to another user's account, you'll have to e-mail it to them or share it through some other third-party service. Even if you plug the device into a PC or Mac, you can only view the media files of the tablet's current user. Switching users with the tablet connected to a computer will unmount the tablet and then remount it to give you access to the other user's files. This is a little annoying from a usability perspective, though from a security perspective it's definitely a nice touch."
I agree it's a nice touch but it's still proof of actual security. From the video it doesn't appear the same level of user space is being built up and torn down every time the device is locked and unlocked. To me that means the accounts are loaded at login and then held in RAM with some services running. They could cut some corners on security to speed it up and have it use less power. In either case it's likely insecure or using too much power to keep an entire family worth of accounts running at launch. And we still haven't addressed how having more than 2 account loaded at once or if you a family's worth of Touch ID accounts that need to be matched.
I agree it's a nice touch but it's still proof of actual security. From the video it doesn't appear the same level of user space is being built up and torn down every time the device is locked and unlocked. To me that means the accounts are loaded at login and then held in RAM with some services running. They could cut some corners on security to speed it up and have it use less power. In either case it's likely insecure or using too much power to keep an entire family worth of accounts running at launch. And we still haven't addressed how having more than 2 account loaded at once or if you a family's worth of Touch ID accounts that need to be matched.
What's wrong with holding accounts in RAM? Unix was designed from the outset to support multiple users running concurrently on the same machine. Could you give some examples of security risks?
What's wrong with holding accounts in RAM? Unix was designed from the outset to support multiple users running concurrently on the same machine. Could you give some examples of security risks?
1) Can reduce performance, especially since iOS doesn't use a swap partition.
2) Can use more power, which is especially troubling on a device you don't want to plug in frequently.
3) As for security risks what exactly are you looking for? Aren't risks to the security of your device and personal data without your permission enough of an issue that it should be considered?
1) Can reduce performance, especially since iOS doesn't use a swap partition.
2) Can use more power, which is especially troubling on a device you don't want to plug in frequently.
3) As for security risks what exactly are you looking for? Aren't risks to the security of your device and personal data without your permission enough of an issue that it should be considered?
Of course security risks should be considered, but my point was that this problem was solved long ago by Dennis Ritchie and Ken Thompson. Unix was designed specifically for this use case.
I interpreted your comment about holding accounts in RAM as a ding against security, when it was actually about resource utilisation. Ars shared your concerns when multiuser first came out for android. Here are their findings:
"A brand-new user account with no e-mails, apps, or other configured settings takes up just 12.78MB on our Nexus 7 tablet, though this will quickly increase as other users start to download stuff. Other users' background services also take up a small amount of RAM—though your mileage may vary, we observed usage between 20 and 60 megabytes on our Nexus 7—a fraction of the 1GB or 2GB of RAM in most shipping Android tablets today." (http://arstechnica.com/gadgets/2012/11/hands-on-multiple-users-lock-screen-widgets-round-out-android-4-2/)
Keep in mind that the part about background services is Android-specific; iOS doesn't allow third-party background services.
Of course security risks should be considered, but my point was that this problem was solved long ago by Dennis Richie and Ken Thompson.
I interpreted your comment about holding accounts in RAM as a ding against security, when it was actually about resource utilisation. Ars shared your concerns when multiuser first came out for android. Here are their findings:
"A brand-new user account with no e-mails, apps, or other configured settings takes up just 12.78MB on our Nexus 7 tablet, though this will quickly increase as other users start to download stuff. Other users' background services also take up a small amount of RAM—though your mileage may vary, we observed usage between 20 and 60 megabytes on our Nexus 7—a fraction of the 1GB or 2GB of RAM in most shipping Android tablets today." (http://arstechnica.com/gadgets/2012/11/hands-on-multiple-users-lock-screen-widgets-round-out-android-4-2/)
1) My comments were about the feasibility or creating hardened, unique user accounts within iOS that would be secure, not affect performance, or longevity of use. I have seen no testing on Android that proves that is a reasonable assumption.
2) That's a lot of RAM for still doing nothing. What about the many apps each user has suspended? How much power is that using? How much of a performance hit is it? Where are is the charts showing a variety of scenarios?
3) Again, what if we're talking about a family of 5 and each are playing Kingdom Rush. That's 309MB for the game? How many times is it loaded into RAM? Five times or just once? If 5 times how is that not affecting the device negatively? If only once then how are the user's credentials loaded into the game each time the user logs in when this isn't a part of how iOS apps work? Where are the YouTube videos proving how this is so seamless, perfect and wonderful on Android?
1) My comments were about the feasibility or creating hardened, unique user accounts within iOS that would be secure, not affect performance, or longevity of use. I have seen no testing on Android that proves that is a reasonable assumption.
2) That's a lot of RAM for still doing nothing. What about the many apps each user has suspended? How much power is that using? How much of a performance hit is it? Where are is the charts showing a variety of scenarios?
3) Again, what if we're talking about a family of 5 and each are playing Kingdom Rush. That's 309MB for the game? How many times is it loaded into RAM? Five times or just once? If 5 times how is that not affecting the device negatively? If only once then how are the user's credentials loaded into the game each time the user logs in when this isn't a part of how iOS apps work? Where are the YouTube videos proving how this is so seamless, perfect and wonderful on Android?
1) If you are looking for extensive testing, I cannot provide you with the answers. All my responses have been based on publicly available information for Android as well as general knowledge of how unix works. So far, there is no reason a priori why Android's implementation shouldn't work. It should be trivial for someone to verify whether it does indeed work (anyone here have a nexus 7?).
2) Have you heard the saying that unused RAM is wasted RAM? It probably takes more power to wake up permanent storage and relaunch an app completely than to keep suspended apps in memory so that they can be recalled instantly. Again, you are correct to demand hard numbers, but I cannot help you there.
3) It would only be logical for each user to have his own instance of Kingdom Rush. This is the only possibility given how the unix privilege system works. My instance of Kingdom Rush would not able to write to your private storage. The fact that each instance requires several hundred MB of RAM merely means that when another user fires up Kingdom Rush, my suspended instance will probably be booted from memory. The user experience should be no different from what you already experience now if you try to juggle several memory-heavy apps on an iPad; when memory runs low, the system starts removing apps from memory.
1) If you are looking for extensive testing, I cannot provide you with the answers. All my responses have been based on publicly available information for Android as well as general knowledge of how unix works. It should be trivial for someone to verify whether Android's implementation does indeed work well (anyone here have a nexus 7?). If it does work, then there should be no technical barrier for iOS to implement a similar system.
2) Have you heard the saying that unused RAM is wasted RAM? It probably takes more power to wake up permanent storage and relaunch an app completely than to keep suspended apps in memory so that they can be recalled instantly. Again, you are correct to demand hard numbers, but I cannot help you there.
3) It would only be logical for each user to have his own instance of Kingdom Rush. The fact that each instance requires several hundred MB of RAM merely means that when another user fires up Kingdom Rush, your instance will probably be booted from memory. You would face a similar situation if you try to juggle several memory-heavy apps on the iPad; when memory runs low, the system starts removing apps from memory.
1) All my experience with *nix systems with GUIs have secure user accounts taking much too long to log in and logout than what would be reasonable on a phone or tablet.
2) I use my RAM and I am trying to support a large family of user accounts on my devices.
3) So if each user has their own set of apps (which isn't the way it works on desktop OSes) then you using a lot more storage. And what about videos and music? Those at least are stored within a user account.
4) If the device is dumping things from memory frequently because it doesn't have enough to support a family worth of users which then have to be loaded again as a different user takes over you issues I've been talking about. This isn't a good user experience.
5) The only way I can user profiles being added to iOS are in the Apple TV so that when a particular user picks up the remote control it senses (perhaps via a form of Touch ID) that the user is a particular family member and then changes the Apple TV UI to match their settings, favourites, history, and recorded videos. These settings typically aren't private as the DVR is still mostly a community device for a family and it gets rid of the clunky nature of this community device, which an iDevice typically isn't.
1) All my experience with *nix systems with GUIs have secure user accounts taking much too long to log in and logout than what would be reasonable on a phone or tablet.
2) I use my RAM and I am trying to support a large family of user accounts on my devices.
3) So if each user has their own set of apps (which isn't the way it works on desktop OSes) then you using a lot more storage. And what about videos and music? Those at least are stored within a user account.
4) If the device is dumping things from memory frequently because it doesn't have enough to support a family worth of users which then have to be loaded again as a different user takes over you issues I've been talking about. This isn't a good user experience.
5) The only way I can user profiles being added to iOS are in the Apple TV so that when a particular user picks up the remote control it senses (perhaps via a form of Touch ID) that the user is a particular family member and then changes the Apple TV UI to match their settings, favourites, history, and recorded videos. These settings typically aren't private as the DVR is still mostly a community device for a family and it gets rid of the clunky nature of this community device, which an iDevice typically isn't.
1) I don't think multiuser is to blame. Desktop environments are much more complex than what you would find on a tablet or smartphone. Logging into a single user on a desktop already takes much longer than on a tablet.
2) I agree that multi-user environments benefit from more RAM. Maybe the 1GB on the iPad is on the low side, but it's not inconceivable that this number will go up soon. 2GB or 3GB ought to be quite generous for two users with average workloads, such as internet browsing or emailing. No one is suggesting that a tablet should support five users running heavy games simultaneously.
3) I should have been more clear. There is a central application storage area which holds one copy of each application binary, similar to the /Applications folder in OS X. What the user sees however is something analogous to the OS X dock, which contains links to the main applications folder. If you install Facebook and another user then "installs" facebook, the system merely creates a link to that other user's application launcher. There is only one copy of the application binary. User-specific data is stored in the user's home directory just like in OS X. Music and videos would presumably not be shared between users (although one might use a checksumming system like what Dropbox uses to avoid storing multiple copies of the same file), and this could be a problem if four or five users each want to store multiple HD movies on the same iPad. But again, no one is suggesting that tablets handle these rather extreme use cases.
4) See my response to 2). That said, would you be really be passing your iPad from one user to another on a short time scale? Back when people used to share a single computer among the whole family, were people constantly kicking each other off? Macs have long had a full-blown multiuser OS even though it wasn't that long ago that they had only 2GB of RAM; further, swapping was far slower than reloading an application in modern tablets. Did the multiuser capability of OS X detract from the user experience back then?
1) [@]d4NjvRzf[/@], I was just reading about the [URL=http://daringfireball.net/linked/2014/03/18/whatsapp-security]WhatsApp security issue[/URL]. If all app data is saved to the general file system — not a secure home directory — then why wouldn't another user be able to access those files for various users since it's all stored on the same SD card? I'm simply not seeing this robust, secure system that you seem to be eluding to exist on Android.
2) The time frame is irrelevant for Apple. If I pick up an iDevice I want my apps to be ready for me. I don't want to wait 20 seconds every time I run certain apps because it had to be dropped from RAM because the previous user had to run their own set of apps. This hurts the user experience, not helps it.
1) @d4NjvRzf, I was just reading about the WhatsApp security issue. If all app data is saved to the general file system — not a secure home directory — then why wouldn't another user be able to access those files for various users since it's all stored on the same SD card? I'm simply not seeing this robust, secure system that you seem to be eluding to exist on Android.
2) The time frame is irrelevant for Apple. If I pick up an iDevice I want my apps to be ready for me. I don't want to wait 20 seconds every time I run certain apps because it had to be dropped from RAM because the previous user had to run their own set of apps. This hurts the user experience, not helps it.
1) Google's documentation (http://developer.android.com/guide/topics/data/data-storage.html) explains this in detail, but the gist of it is the following. Apps on Android have two options for storage. Every app has a private sandboxed storage area that only they can access, just like on iOS. The docs refer to this as "Internal Storage", and this is where apps are supposed to store all data that's not intended to be accessed by other apps. Where Android differs from iOS is that Android also provides a common public storage area (misleading called "External Storage") that all apps can read and write to provided that they declare the appropriate permissions at install time. This public storage area would be appropriate for files that are likely to be accessed by more than one app, such as videos or files downloaded from the internet. Whatsapp made a mistake by storing its private files in public storage instead of in its sandbox.
In the context of multiple users, Google states that in its specifications that "Each user must have their own isolated primary external storage, and must not have access to the primary external storage of other users." (http://source.android.com/devices/tech/storage/) Note that "primary external storage" refers to the public storage area on internal memory, while "secondary" storage refers to actual SD cards. I guess "external" here means external to apps.
One can perhaps understand this system better by looking at how OS X implements sandboxing in post-Snow Leopard releases, since the overall designs are quite similar. Every sandboxed app has its own "container" in your Library Directory that is accessible by only that app. If an app declares the appropriate "entitlements" (the direct analog of Android permissions), it can read and write to your home directory as well as certain other public directories. Under no circumstances however can an app launched by you access the home directory of another user. (https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW6)
2) One would only experience a delay when switching to another user. If you merely lock your screen, you should not encounter a delay the next time you unlock your screen unless someone else has used the tablet in the intervening period. As you can see from the Nexus 7 video above, it takes more like two seconds to switch to a different user, not twenty. If you find that too long, well, no one is going to force you to enable multiuser on your tablet.
The SD card has always been used as "External storage", which means that apps treat it as public storage. There is no real security content in the changes described in the link, as apps with the appropriate permissions can still read anything on the SD card. It's not clear to me what is Google's long-term plan for SD cards. Apps have always had secure areas for storing sensitive data, and it was dumb of Whatsapp to store its databases in the open.
Comments
That assumes Apple would do it the same way and that Android's way is secure. Is there any evidence that the user data on each account is not accessible from another account?
I don't think it's impossible but that video doesn't show something that looks like something Apple would release. That said, I'm all for it since it doesn't impede my usability in any way.
That assumes Apple would do it the same way and that Android's way is secure. Is there any evidence that the user data on each account is not accessible from another account?
From the same Arstechnica article that I ninja-edited into my previous post:
"Users also can't share data directly with one another; if you want to transfer a picture to another user's account, you'll have to e-mail it to them or share it through some other third-party service. Even if you plug the device into a PC or Mac, you can only view the media files of the tablet's current user. Switching users with the tablet connected to a computer will unmount the tablet and then remount it to give you access to the other user's files. This is a little annoying from a usability perspective, though from a security perspective it's definitely a nice touch."
The security architecture is quite similar to that of OS X or any other unix-like system, and is a solved problem. Each user has his own UID. User-specific application data are stored in each user's home directory, which is kept private using standard unix access controls.
"As an app developer, there’s nothing different you need to do in order for your app to work properly with multiple users on a single device. Regardless of how many users may exist on a device, the data your app saves for a given user is kept separate from the data your app saves for other users. The system keeps track of which user data belongs to the user process in which your app is running and provides your app access to only that user’s data and does not allow access to other users’ data." (http://developer.android.com/about/versions/android-4.2.html)
I agree it's a nice touch but it's still proof of actual security. From the video it doesn't appear the same level of user space is being built up and torn down every time the device is locked and unlocked. To me that means the accounts are loaded at login and then held in RAM with some services running. They could cut some corners on security to speed it up and have it use less power. In either case it's likely insecure or using too much power to keep an entire family worth of accounts running at launch. And we still haven't addressed how having more than 2 account loaded at once or if you a family's worth of Touch ID accounts that need to be matched.
I agree it's a nice touch but it's still proof of actual security. From the video it doesn't appear the same level of user space is being built up and torn down every time the device is locked and unlocked. To me that means the accounts are loaded at login and then held in RAM with some services running. They could cut some corners on security to speed it up and have it use less power. In either case it's likely insecure or using too much power to keep an entire family worth of accounts running at launch. And we still haven't addressed how having more than 2 account loaded at once or if you a family's worth of Touch ID accounts that need to be matched.
What's wrong with holding accounts in RAM? Unix was designed from the outset to support multiple users running concurrently on the same machine. Could you give some examples of security risks?
1) Can reduce performance, especially since iOS doesn't use a swap partition.
2) Can use more power, which is especially troubling on a device you don't want to plug in frequently.
3) As for security risks what exactly are you looking for? Aren't risks to the security of your device and personal data without your permission enough of an issue that it should be considered?
1) Can reduce performance, especially since iOS doesn't use a swap partition.
2) Can use more power, which is especially troubling on a device you don't want to plug in frequently.
3) As for security risks what exactly are you looking for? Aren't risks to the security of your device and personal data without your permission enough of an issue that it should be considered?
Of course security risks should be considered, but my point was that this problem was solved long ago by Dennis Ritchie and Ken Thompson. Unix was designed specifically for this use case.
I interpreted your comment about holding accounts in RAM as a ding against security, when it was actually about resource utilisation. Ars shared your concerns when multiuser first came out for android. Here are their findings:
"A brand-new user account with no e-mails, apps, or other configured settings takes up just 12.78MB on our Nexus 7 tablet, though this will quickly increase as other users start to download stuff. Other users' background services also take up a small amount of RAM—though your mileage may vary, we observed usage between 20 and 60 megabytes on our Nexus 7—a fraction of the 1GB or 2GB of RAM in most shipping Android tablets today." (http://arstechnica.com/gadgets/2012/11/hands-on-multiple-users-lock-screen-widgets-round-out-android-4-2/)
Keep in mind that the part about background services is Android-specific; iOS doesn't allow third-party background services.
1) My comments were about the feasibility or creating hardened, unique user accounts within iOS that would be secure, not affect performance, or longevity of use. I have seen no testing on Android that proves that is a reasonable assumption.
2) That's a lot of RAM for still doing nothing. What about the many apps each user has suspended? How much power is that using? How much of a performance hit is it? Where are is the charts showing a variety of scenarios?
3) Again, what if we're talking about a family of 5 and each are playing Kingdom Rush. That's 309MB for the game? How many times is it loaded into RAM? Five times or just once? If 5 times how is that not affecting the device negatively? If only once then how are the user's credentials loaded into the game each time the user logs in when this isn't a part of how iOS apps work? Where are the YouTube videos proving how this is so seamless, perfect and wonderful on Android?
1) My comments were about the feasibility or creating hardened, unique user accounts within iOS that would be secure, not affect performance, or longevity of use. I have seen no testing on Android that proves that is a reasonable assumption.
2) That's a lot of RAM for still doing nothing. What about the many apps each user has suspended? How much power is that using? How much of a performance hit is it? Where are is the charts showing a variety of scenarios?
3) Again, what if we're talking about a family of 5 and each are playing Kingdom Rush. That's 309MB for the game? How many times is it loaded into RAM? Five times or just once? If 5 times how is that not affecting the device negatively? If only once then how are the user's credentials loaded into the game each time the user logs in when this isn't a part of how iOS apps work? Where are the YouTube videos proving how this is so seamless, perfect and wonderful on Android?
1) If you are looking for extensive testing, I cannot provide you with the answers. All my responses have been based on publicly available information for Android as well as general knowledge of how unix works. So far, there is no reason a priori why Android's implementation shouldn't work. It should be trivial for someone to verify whether it does indeed work (anyone here have a nexus 7?).
2) Have you heard the saying that unused RAM is wasted RAM? It probably takes more power to wake up permanent storage and relaunch an app completely than to keep suspended apps in memory so that they can be recalled instantly. Again, you are correct to demand hard numbers, but I cannot help you there.
3) It would only be logical for each user to have his own instance of Kingdom Rush. This is the only possibility given how the unix privilege system works. My instance of Kingdom Rush would not able to write to your private storage. The fact that each instance requires several hundred MB of RAM merely means that when another user fires up Kingdom Rush, my suspended instance will probably be booted from memory. The user experience should be no different from what you already experience now if you try to juggle several memory-heavy apps on an iPad; when memory runs low, the system starts removing apps from memory.
1) All my experience with *nix systems with GUIs have secure user accounts taking much too long to log in and logout than what would be reasonable on a phone or tablet.
2) I use my RAM and I am trying to support a large family of user accounts on my devices.
3) So if each user has their own set of apps (which isn't the way it works on desktop OSes) then you using a lot more storage. And what about videos and music? Those at least are stored within a user account.
4) If the device is dumping things from memory frequently because it doesn't have enough to support a family worth of users which then have to be loaded again as a different user takes over you issues I've been talking about. This isn't a good user experience.
5) The only way I can user profiles being added to iOS are in the Apple TV so that when a particular user picks up the remote control it senses (perhaps via a form of Touch ID) that the user is a particular family member and then changes the Apple TV UI to match their settings, favourites, history, and recorded videos. These settings typically aren't private as the DVR is still mostly a community device for a family and it gets rid of the clunky nature of this community device, which an iDevice typically isn't.
1) All my experience with *nix systems with GUIs have secure user accounts taking much too long to log in and logout than what would be reasonable on a phone or tablet.
2) I use my RAM and I am trying to support a large family of user accounts on my devices.
3) So if each user has their own set of apps (which isn't the way it works on desktop OSes) then you using a lot more storage. And what about videos and music? Those at least are stored within a user account.
4) If the device is dumping things from memory frequently because it doesn't have enough to support a family worth of users which then have to be loaded again as a different user takes over you issues I've been talking about. This isn't a good user experience.
5) The only way I can user profiles being added to iOS are in the Apple TV so that when a particular user picks up the remote control it senses (perhaps via a form of Touch ID) that the user is a particular family member and then changes the Apple TV UI to match their settings, favourites, history, and recorded videos. These settings typically aren't private as the DVR is still mostly a community device for a family and it gets rid of the clunky nature of this community device, which an iDevice typically isn't.
1) I don't think multiuser is to blame. Desktop environments are much more complex than what you would find on a tablet or smartphone. Logging into a single user on a desktop already takes much longer than on a tablet.
2) I agree that multi-user environments benefit from more RAM. Maybe the 1GB on the iPad is on the low side, but it's not inconceivable that this number will go up soon. 2GB or 3GB ought to be quite generous for two users with average workloads, such as internet browsing or emailing. No one is suggesting that a tablet should support five users running heavy games simultaneously.
3) I should have been more clear. There is a central application storage area which holds one copy of each application binary, similar to the /Applications folder in OS X. What the user sees however is something analogous to the OS X dock, which contains links to the main applications folder. If you install Facebook and another user then "installs" facebook, the system merely creates a link to that other user's application launcher. There is only one copy of the application binary. User-specific data is stored in the user's home directory just like in OS X. Music and videos would presumably not be shared between users (although one might use a checksumming system like what Dropbox uses to avoid storing multiple copies of the same file), and this could be a problem if four or five users each want to store multiple HD movies on the same iPad. But again, no one is suggesting that tablets handle these rather extreme use cases.
4) See my response to 2). That said, would you be really be passing your iPad from one user to another on a short time scale? Back when people used to share a single computer among the whole family, were people constantly kicking each other off? Macs have long had a full-blown multiuser OS even though it wasn't that long ago that they had only 2GB of RAM; further, swapping was far slower than reloading an application in modern tablets. Did the multiuser capability of OS X detract from the user experience back then?
2) The time frame is irrelevant for Apple. If I pick up an iDevice I want my apps to be ready for me. I don't want to wait 20 seconds every time I run certain apps because it had to be dropped from RAM because the previous user had to run their own set of apps. This hurts the user experience, not helps it.
1) @d4NjvRzf, I was just reading about the WhatsApp security issue. If all app data is saved to the general file system — not a secure home directory — then why wouldn't another user be able to access those files for various users since it's all stored on the same SD card? I'm simply not seeing this robust, secure system that you seem to be eluding to exist on Android.
2) The time frame is irrelevant for Apple. If I pick up an iDevice I want my apps to be ready for me. I don't want to wait 20 seconds every time I run certain apps because it had to be dropped from RAM because the previous user had to run their own set of apps. This hurts the user experience, not helps it.
1) Google's documentation (http://developer.android.com/guide/topics/data/data-storage.html) explains this in detail, but the gist of it is the following. Apps on Android have two options for storage. Every app has a private sandboxed storage area that only they can access, just like on iOS. The docs refer to this as "Internal Storage", and this is where apps are supposed to store all data that's not intended to be accessed by other apps. Where Android differs from iOS is that Android also provides a common public storage area (misleading called "External Storage") that all apps can read and write to provided that they declare the appropriate permissions at install time. This public storage area would be appropriate for files that are likely to be accessed by more than one app, such as videos or files downloaded from the internet. Whatsapp made a mistake by storing its private files in public storage instead of in its sandbox.
In the context of multiple users, Google states that in its specifications that "Each user must have their own isolated primary external storage, and must not have access to the primary external storage of other users." (http://source.android.com/devices/tech/storage/) Note that "primary external storage" refers to the public storage area on internal memory, while "secondary" storage refers to actual SD cards. I guess "external" here means external to apps.
One can perhaps understand this system better by looking at how OS X implements sandboxing in post-Snow Leopard releases, since the overall designs are quite similar. Every sandboxed app has its own "container" in your Library Directory that is accessible by only that app. If an app declares the appropriate "entitlements" (the direct analog of Android permissions), it can read and write to your home directory as well as certain other public directories. Under no circumstances however can an app launched by you access the home directory of another user. (https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW6)
2) One would only experience a delay when switching to another user. If you merely lock your screen, you should not encounter a delay the next time you unlock your screen unless someone else has used the tablet in the intervening period. As you can see from the Nexus 7 video above, it takes more like two seconds to switch to a different user, not twenty. If you find that too long, well, no one is going to force you to enable multiuser on your tablet.
[LIST]
[*] http://www.androidcentral.com/kitkat-sdcard-changes
[/LIST]
@d4NjvRzf, it looks like you need 4.4 for the improved security, which account for less than 3% of Google Play devices.
The SD card has always been used as "External storage", which means that apps treat it as public storage. There is no real security content in the changes described in the link, as apps with the appropriate permissions can still read anything on the SD card. It's not clear to me what is Google's long-term plan for SD cards. Apps have always had secure areas for storing sensitive data, and it was dumb of Whatsapp to store its databases in the open.