Mozy documentation is also available in:
| Members | Liked |
|---|---|
| username_issues | 2432 |
| Owyn | 613 |
| Wayward | 204 |
| Invisiblade | 151 |
| KCj | 142 |
I have a couple of suggestions on the mobile app... I'm a DroidX user. ![]()
1. I am using the mobile app with the PIN feature. I feel securing an individual mobile device for use with my Mozy account should have more checks/balances - not just any mobile device that knows the username/password - approved devices only.
2. When I close the mobile app, I would like immediate PIN lock on the app. Currently, I can back out of the App and then go back in without the need for a PIN. There seems to be a timeout which does eventually require the PIN again, but I feel it should be immediately after the App exit.
3. I did a test restore to check how that worked.... When I selected the file, I noticed that the file actually downloaded to my SD card before I could do anything with it. I feel that the phone's storage should not be in the equation... I think that one should be able to restore straight to the client machine/server and the ability to email it without the need to download the file first. Downloading the file first causes delays and one has to remember to remove the file from the phone's storage to ensure file security.
Thanks all, please comment with your thoughts on these two issues. ![]()
KyleG
Solved! Go to Solution.
06-24-2011 10:25 AM
Hey, Kyle:
Thanks for your input on our mobile app. I'm the product manager for the mobile app, so feedback like yours is really valuable to me for planning our roadmap. I'll provide responses to your three items by citing each one before responding.
1. I am using the mobile app with the PIN feature. I feel securing an individual mobile device for use with my Mozy account should have more checks/balances - not just any mobile device that knows the username/password - approved devices only.
I definitely agree. In fact, we're currently working on a general "Device Management" feature that would become part of your general account management settings. The first iteration aims to show you the devices that have authenticated to your account, and provide you control to remotely expire your login on a given device. Once we roll this out, I can see a lot of value in providing a an account option to "Allow only devices that I have pre-authorized," or something similar. I have already been considering something similar for MozyPro to give administrators control so that only IT-approved devices can be added. Your suggestion would extend this capacity on a limited scale to MozyHome.
2. When I close the mobile app, I would like immediate PIN lock on the app. Currently, I can back out of the App and then go back in without the need for a PIN. There seems to be a timeout which does eventually require the PIN again, but I feel it should be immediately after the App exit.
The behavior on Android right now is that the PIN prompt will come up if again if you lock the screen, so the time-out that you sense is there is dependent on the screen-lock time-out for your device. Knowing that, would you still see this as a must-have improvement?
3. I did a test restore to check how that worked.... When I selected the file, I noticed that the file actually downloaded to my SD card before I could do anything with it. I feel that the phone's storage should not be in the equation... I think that one should be able to restore straight to the client machine/server and the ability to email it without the need to download the file first. Downloading the file first causes delays and one has to remember to remove the file from the phone's storage to ensure file security.
There's another angle to this in addition to using local device storage--bandwidth. The workflow you cite--download file, then attach to email--consumes bandwidth for both the download and the upload. We see it as sub-optimal. At present, it's necessary only because we have yet to implement a link-based sharing service. In the longer term, we plan to add more sophisticated cloud-based sharing to supplement attaching to an email. That would allow you to send an email containing a link to a file instead of attaching the actual file, along with alleviating the device storage concerns you mention.
I look forward to your response regarding these responses,
Ted
06-24-2011 04:05 PM
Hi Ted,
Thank you for responses, truly appreciated....
1. Good to know that this was considered previously and is currently being ironed-out. It will be a welcome improvement.
2. I didn't notice that the PIN lock was associated with the screen lock, but I checked and sure enough, it is! I think the current design is acceptable, but I'll wager that others would like the immediate lock.
3. Like #1, glad it's on the to-do list. The remote restore ability is a biggie for IT admins on the road and do not have their laptop handy - because hey - its a mobile app. The link-based system you mentioned seems like the way to go! Would the link require a Mozy login to access? In my situation, most files I restore are to users that do not have a Mozy account; they are simply members of my network. They have proper rights to my network, but not to the Mozy portal. That may be tricky for you all, not sure how you plan to approach that, unless you add Active Directory Integration defaulting everyone to Read Only rights?
06-24-2011 10:46 PM
KyleG:
Good to know that #2 hits the good-enough mark for you.
You asked one question about link-based shares that I can address: "Would the link require a Mozy login to access?" Under our current plan, it would not. Our philosophy on this is essentially that having to sign up would create a potential barrier for the recipient. We don't want recipients to feel like they have to sign up with Mozy to get the shared data. After all, only subscribers could create shares, and we feel they should have the option to share however they need without Mozy inserting any impediments.
That said, we're just beginning to explore the whole domain of sharing, and our plans are largely theoretical at this time.
--T
06-27-2011 09:06 AM