Hi,
Pedro Silva wrote:
> (take this has a brainstorm, some ideas fit, some don't)
>
Awesome
> What kind of personal data should we manage with an Online Desktop
> profile? Aplication Preferences, Email, Docs ? What about ssh keys, My
> Music/Movies/Pics ?
>
One thing Bryan Clark suggested is that we start trying to dogfood "nuke
my homedir every Monday" - that will mean we need to pretty quickly
solve some of the more developer-oriented stuff such as ssh keys.
I think when possible, it can be nicer to store stuff online via the
online app that edits it - e.g. store photos on Flickr, rather than
store photos in a remote filesystem or something.
However, I think we might want to do just a quick hack that lets us sync
homedir files like .emacs and .ssh.
Key stuff for me to dogfood might include: .emacs, .bashrc, .ssh, GNOME
keyring, evolution/thunderbird accounts, network manager config, and
browser state (history/bookmarks/toolbars). The list isn't really that long.
I would think that a good solution for storing this stuff would 1) have
a whitelist of files it knows make sense to store and 2) allow hooks to
potentially massage the files a bit when storing/restoring. The problem
isn't too unlike Sabayon in a certain way.
> Which steps could be taken to assure privacy and secuity on remote storage
> of an Online Desktop profile?
When we store in an online app like Flickr, we just inherit their
privacy and security.
When we store as "just files," the most secure and private model is that
everyone has a private key (ideally on a "smartcard" hardware USB gizmo)
and we just ship a big encrypted blob to the server.
However, that model has usability problems if it's the only model, i.e.
the private key is not recoverable. It also has the big downside that
you can't have web-based access to stuff.
What Mozy (an online backup thing) does is that it defaults to escrowing
your private key for you and you can get it just with your web account
and password, but if you click "I understand I am doomed if I lose the
key" you can use the private key of your choice.
The encryption thing only works for file data that is private to me, if
we're talking about database data or data that is used across users
("social network" type data) then the privacy and security come down to
the security of the hosting server and its privacy policy / terms of use.
> Which steps could be taken to ensure that copyrighted material doesn't get
> remotely stored on a profile?
Copyrighted is OK, right - I mean, anything I do is copyrighted by
default. Also, copyrights can be very liberal (creative commons, etc.)
The issue is if material is made public in violation of its license.
I think the DMCA safe harbor is what one normally relies on here - if
you have a process to take down stuff you're notified about, then you
aren't in trouble for stuff users do.
> What kind of remote storage would that be, a simple file/folder structure
> of /home/usr, an encrypted .tar.gz file containing /home/user, mount
> /home/user using a nfs/fuse share?
My intuition is that mounting an Internet server as your homedir won't
work well; and most homedirs have a bunch of gunk in them that is "just
a cache" or otherwise doesn't make sense to store in an online profile.
Maybe have a gvfs/fuse mount for "documents" and encourage word
processor type apps to save there, but have it separate from the
homedir, and manage the homedir more via syncing?
> Should there be an offline snapshot of the Online Desktop profile? When
> should it sync, during login/logout? Should it be deleted upon logout?
> Could it have options to keep offline snapshot until next reboot or for x
> days?
For the file-based stuff, sync on login makes sense to me, and then try
to stay in sync during the session periodically?
For database-based stuff, we can have "live change notification" using
the Desktop Data Model that's driving your contacts and so forth in
BigBoard.
> Online Desktop integration could start right on the login screen, read
> GDM. Better yet, think freedesktop.org integration. A user could choose a
> Online Desktop account/service to login to the system.
Absolutely.
Havoc
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
