<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
* We could use the "favorite" flag, or a new backup flag, to signify<br>
which jobjects the user would like to back up, and we can try to<br>
accomodate them. We probably still need a per-user quota.<div><br>
...<br>
</div><br>
<br>
* Encryption/privacy probably isn't desirable here -- we're dealing with<br>
objects that the user has chosen to have backed up. Also, this would<br>
provide a good way for kids to turn in homework to their teachers: the<br>
teacher passes around a USB key, and as each child inserts the key,<br>
their homework gets automatically copied over to a directory named<br>
after them if it's marked favorite.</blockquote><div><br>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.<br>
<br>We are not short on room for flags. I propose 3 of them would work here: "shared", "favorite", and "unbacked-up".<br><br>-"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.<br>
-"favorite" flag exists, it just means "try to fit me into the backup even if I am big".<br>-"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.<br>
<br>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.<br><br><br></div></div><br>