Talk:Correlating Bitfrost and threats: Difference between revisions

From OLPC
Jump to navigation Jump to search
Line 17: Line 17:
So, you need central backup. And therefore you need encryption. As the bitfrost spec points out, secure passwords are impossible for young kids. So, what would help deter abuse of authority? Keys can't just be kept on the server. Stashing with one buddy seems insecure against loss, treason, or coercion. The most secure answer I can think of would be to stash N key fragments, of which only M are needed, at random with other laptops in the same batch. (n=4 m=2 would be plenty). The randomness would mean that a restore-from-lost-laptop would involve a broadcast message to the WHOLE BATCH (and this would cause some non-annoying UI effect), thus a stealthy data theft would be impossible. (It would also eliminate the "Yucky, I don't want to be THEIR buddy" ostracizing factor).
So, you need central backup. And therefore you need encryption. As the bitfrost spec points out, secure passwords are impossible for young kids. So, what would help deter abuse of authority? Keys can't just be kept on the server. Stashing with one buddy seems insecure against loss, treason, or coercion. The most secure answer I can think of would be to stash N key fragments, of which only M are needed, at random with other laptops in the same batch. (n=4 m=2 would be plenty). The randomness would mean that a restore-from-lost-laptop would involve a broadcast message to the WHOLE BATCH (and this would cause some non-annoying UI effect), thus a stealthy data theft would be impossible. (It would also eliminate the "Yucky, I don't want to be THEIR buddy" ostracizing factor).


Another factor not considered by Bitfrost: activity privacy. In the current model, all laptops publish their currently active application and collaboration, all the time. This lack of privacy has positive and negative aspects, but on the whole I think a limited exception should be possible. For one possible example, one should be able to "go offline" without turning off the computer. The laptop would still forward mesh packets, but apart from that would not appear on the "neighborhood" or "world" view; no network tasks, aside from transparent backup and restore, would be possible. A teacher could still notice the virtual "absence" of a student intent on their screen, but safe at home you wouldn't have the whole town able to see what you were up to. (Gossip is a serious social problem in a small town.) [[User:Homunq|Homunq]] 01:31, 30 July 2007 (EDT)
Another factor not considered by Bitfrost: activity privacy. In the current model, all laptops publish their currently active application and collaboration, all the time. This lack of privacy has positive and negative aspects, but on the whole I think a limited exception should be possible. For one possible example, one should be able to "go offline" without turning off the computer. The laptop would still forward mesh packets, but apart from that would not appear on the "neighborhood" or "world" view; no network tasks, aside from transparent backup and restore, would be possible. A teacher could still notice the virtual "absence" of a student intent on their screen, but safe at home you wouldn't have the whole town able to see what you were up to. (Gossip is a serious social problem in a small town.) This would still keep a social/practical reason to be public (which is beneficial), but open at least the possibility of privacy. [[User:Homunq|Homunq]] 01:31, 30 July 2007 (EDT)

Revision as of 05:35, 30 July 2007

I agree with most of this article.

Assume officals are self serving, and governments will use any central repository to coerce the users. Because of this, theft protection and user control must be fully placed at the 'school level'. There can be no means for a government or master key holder to exert control. This control, for example, could simply be threats of shutting down the OLPC population used by an ethnic group unless a that group submits to a demand, such as placing one of its leaders into government custody.

Secondly, ownership transfer should be a very simple process handled exclusively at the school level. I don't know why such extreme mesures are needed for positive identification of the owner. This is an educational appliance - not a CIA computer!!! Why does the user even have to identify himself to the computer? Windows95 was good enough and demanded no login.

If the user loses the OLPC, who cares?? This assumes that unknown machines can't participate in any school mesh, so they becomes quite useless. If the machine reappears on the original mesh where it was lost, the administrator could disable it, until its user is identified.

An OLPC denied mesh access is not much of a theft target. Recall, it is not a CIA machine with tons of valuable documents!! A stolen OLPC wont help terrorists much without net access, and it is much less functional to a different child without the mesh. Social stigmas will undoubtedly be enough to minimize theft from one kid to give to another, as the value of the asset is diminished greatly without mesh access or a learning program in place.

Lets not keep applying western complexity appropriate for western security risks and sensitivities to a little bitty child's educational tool. The V-tech 'laptops' found at Walmart have a much more effective security model - none!

I like your outlook

...however, there is one central recommendation which in not feasible: foregoing backup. As comments in the document already point out, 1GB per child, for programs and data, is just not enough.

So, you need central backup. And therefore you need encryption. As the bitfrost spec points out, secure passwords are impossible for young kids. So, what would help deter abuse of authority? Keys can't just be kept on the server. Stashing with one buddy seems insecure against loss, treason, or coercion. The most secure answer I can think of would be to stash N key fragments, of which only M are needed, at random with other laptops in the same batch. (n=4 m=2 would be plenty). The randomness would mean that a restore-from-lost-laptop would involve a broadcast message to the WHOLE BATCH (and this would cause some non-annoying UI effect), thus a stealthy data theft would be impossible. (It would also eliminate the "Yucky, I don't want to be THEIR buddy" ostracizing factor).

Another factor not considered by Bitfrost: activity privacy. In the current model, all laptops publish their currently active application and collaboration, all the time. This lack of privacy has positive and negative aspects, but on the whole I think a limited exception should be possible. For one possible example, one should be able to "go offline" without turning off the computer. The laptop would still forward mesh packets, but apart from that would not appear on the "neighborhood" or "world" view; no network tasks, aside from transparent backup and restore, would be possible. A teacher could still notice the virtual "absence" of a student intent on their screen, but safe at home you wouldn't have the whole town able to see what you were up to. (Gossip is a serious social problem in a small town.) This would still keep a social/practical reason to be public (which is beneficial), but open at least the possibility of privacy. Homunq 01:31, 30 July 2007 (EDT)