[sugar] Disconnected backups.

[Jameson "Chema" Quinn]

> * We could use the "favorite" flag, or a new backup flag, to signify
>  which jobjects the user would like to back up, and we can try to
>  accomodate them.  We probably still need a per-user quota.
> ...
>
>
> * Encryption/privacy probably isn't desirable here -- we're dealing with
>  objects that the user has chosen to have backed up.  Also, this would
>  provide a good way for kids to turn in homework to their teachers: the
>  teacher passes around a USB key, and as each child inserts the key,
>  their homework gets automatically copied over to a directory named
>  after them if it's marked favorite.


I disagree with the latter statement, I think it is not too hard to do
encryption intelligently. I understand that if you are backing up against
possible loss of hardware, you need to have a backup of the encryption key
itself, and that if you keep the encryption key next to the files it defeats
the purpose. That's a separate issue - at the simplest, you just store the
encryption key on the first backup and only manually thereafter; a more
complicated scheme, for implementing later, would break it into 5 parts of
which any 3 would suffice, and store the same 2 parts on all the backups,
giving the other 3 parts separately to randomly chosen peers over the
mesh... In the simple scheme, you could also password-protect the backup of
the encryption key, as long as you enforced that the password be of a length
that takes a few hours to brute-force on an XO; this would be sufficient
nuisance value to discourage routine or widespread snooping, but still allow
for data recovery in the inevitable case of the kid who loses their XO and
forgets their password.

We are not short on room for flags. I propose 3 of them would work here:
"shared", "favorite", and "unbacked-up".

-"shared" would be set for all files which were shared globally or with a
group. Files shared with other individuals would not be marked. UI for
setting this bit is TBD but for now it would just be set if the activity
instance was shared. Files with the "shared" flag would not be encrypted,
and would be given priority if backup space were limited. This covers the
student half of the turn-it-in use case; the teacher half would be from
Terminal or with some TBD backup-browser activity.
-"favorite" flag exists, it just means "try to fit me into the backup even
if I am big".
-"unbacked-up" is just what it sounds like, it keeps files from landing in
every single backup. They could still be backed up repeatedly as space
allowed; you could even add a last-backed-up-date metadatum to help with
this.

The other thing that could be used to figure out file priority would be
whether there were newer versions of a file in the datastore.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080219/9ae9bf34/attachment.htm