Jobs (was Re: Chilling Effects paper at USENIX UPSEC)
On Fri, Apr 11, 2008 at 6:16 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: ...OLPC is hiring again, which means that hopefully soon we will only be underappreciated, not quite so much overworked. We're more than doubling our devel team, hiring QA folk (finally!), and I'm excited. If y'all have high quality candidates, send them our way! --scott -- ( http://cscott.net/ ) I see five jobs listed at http://laptop.org/en/jobs.shtml. It sounds like you have heard of others. Any chance of a Doc Lead to organize hardware and software manuals, training materials, and textbooks? or some paid Volunteer Coordinators? -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Jobs (was Re: Chilling Effects paper at USENIX UPSEC)
Weren't you just posting bitter rantings how OLPC was all lost yesterday? On Sat, Apr 12, 2008 at 1:20 AM, Edward Cherlin [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 6:16 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: ...OLPC is hiring again, which means that hopefully soon we will only be underappreciated, not quite so much overworked. We're more than doubling our devel team, hiring QA folk (finally!), and I'm excited. If y'all have high quality candidates, send them our way! --scott -- ( http://cscott.net/ ) I see five jobs listed at http://laptop.org/en/jobs.shtml. It sounds like you have heard of others. Any chance of a Doc Lead to organize hardware and software manuals, training materials, and textbooks? or some paid Volunteer Coordinators? -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Jobs (was Re: Chilling Effects paper at USENIX UPSEC)
Sorry, that was meant to be a reply not reply to all. mea culpa On Sat, Apr 12, 2008 at 6:47 AM, Charles Merriam [EMAIL PROTECTED] wrote: Weren't you just posting bitter rantings how OLPC was all lost yesterday? On Sat, Apr 12, 2008 at 1:20 AM, Edward Cherlin [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 6:16 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: ...OLPC is hiring again, which means that hopefully soon we will only be underappreciated, not quite so much overworked. We're more than doubling our devel team, hiring QA folk (finally!), and I'm excited. If y'all have high quality candidates, send them our way! --scott -- ( http://cscott.net/ ) I see five jobs listed at http://laptop.org/en/jobs.shtml. It sounds like you have heard of others. Any chance of a Doc Lead to organize hardware and software manuals, training materials, and textbooks? or some paid Volunteer Coordinators? -- Edward Cherlin End Poverty at a Profit by teaching children business http://www.EarthTreasury.org/ The best way to predict the future is to invent it.--Alan Kay ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX UPSEC
On Thu, Apr 10, 2008 at 3:08 AM, John Gilmore [EMAIL PROTECTED] wrote: 4. It is unfortunate that a respected conference did not do a better job at vetting this paper. I don't know who wrote the response that you are replying to, John, but I for one welcome both the paper and broader discussion of our security plans implementations in general. We can't be so sensitive about things! I have given generously of my time to OLPC by following the project for some three years now; testing B1, B2, B4, and MP machines; supporting G1G1 users; recruiting and paying others to contribute; researching SD card protocols; contributing to discussions by email, phone, and IM; and filing dozens of bug reports. OLPC has seldom graciously addressed my concerns on fundamental design issues, such as BitFrost, activation, developer keys, GPL compliance, game keys, or anything else. When I wasn't ignored, I was criticized for attacking OLPC, or for failing to write up my concerns as a properly tested source code patch. It has been hard -- indeed, impossible -- for me to gin up the requisite perseverence to actually implement anything for OLPC, except small patches to SimCity. (Making those patches turned up numerous bugs, which I reported, which are still largely being ignored.) First: Thank you! It's hard to say what OLPC feels about things, but I for one certainly appreciate all you've done for the project. (If you get a chance, could you post a pointer to the bugs you referenced? Or should I just search trac for [EMAIL PROTECTED] It's true that SimCity is not high on our priority list right now, but I know that our trac triage has not lacking recently and your bugs tend to deserve close attention.) The BitFrost spec was so clearly a personal hobbyhorse of Ivan that questioning its basic assumptions was heresy, grudgingly tolerated due to my reputation, but otherwise ignored. I decided very early on that it wasn't worth wasting my time and making people mad by criticizing BitFrost in detail, partly because I expected it to fall flat on its face. The parts that were worth focusing on were the pervasive DRM (maybe now that Ivan's gone, I can go back to using the right name for crypto that disables the owner's control). And I was ignored and vilified on *that* until I escalated the DRM issue to Richard Stallman over OLPC's ongoing non-compliance with GPLv3 (and also pointed out non-compliance with GPLv2, which is ongoing). Mako's been your liason on these issues -- I didn't know that we were still deficient. Please follow up, either to me or to Mako. OLPC staff are overworked and underappreciated. Working in the glare of publicity has not made their jobs easier. But giving OLPC an opportunity to address your concerns is pretty much a null concept. OLPC barely has the opportunity to address its own opportunities. This is true, but OLPC is hiring again, which means that hopefully soon we will only be underappreciated, not quite so much overworked. We're more than doubling our devel team, hiring QA folk (finally!), and I'm excited. If y'all have high quality candidates, send them our way! --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX UPSEC
4. It is unfortunate that a respected conference did not do a better job at vetting this paper. The conference is a small USENIX workshop (Usability, Psychology and Security). USENIX workshops generally involve fewer than 100 participants, more timely work, and less pre-publication peer review. BitFrost (and criticism of the design, the spec, and the implementation of BitFrost) are directly on-point for this workshop. The paper appears in a short papers session, along with papers on RFID and authentication via electronic pets. 1. The BitFrost Specification is documentation, not detailed implementation. The author does not read code. Indeed, the paper would've been better if they had also been able to review the implementation, but based on the paper deadline and what they had available (a prototype XO from B3 or earlier), most of BitFrost was not implemented in what they had access to. 2. BitFrost does not promise anonymity to school children. This is a valid criticism of a social scheme such as give one laptop to every child, and as pointed out by the authors, a scheme being rolled out in some very violent, repressive countries like Nigeria. It would have been nice if the criticisms had been delivered directly to OLPC, instead of broadcast in a public forum, ... Almost every OLPC forum, including olpc-security, is a public forum. If the enemies of OLPC aren't reading its open mailing lists, they aren't very competent enemies. It's actually more likely that they would notice OLPC criticisms in OLPC forums, rather than at a small USENIX workshop. Indeed, it's the discussion of the paper here that has probably tipped off OLPC's enemies. Shh!!! I believe that the prevailing ethos in the white hat security community is to report newly-discovered vulnerabilities first to the company in question, thus giving them some amount of time to develop a patch before the public announcement. The authors didn't identify any buffer overflows or similar issues. The things they identified were wrong at the fundamental design level, and are not trivially patchable. Luckily, some of them were design goals that never got implemented, like signing everything with the child's private key. Thus, many of the BitFrost mistakes which they point out, are not actual problems in the current shipping XO. The authors appear to be academics, however, so they would get little credit for having contributed to OLPC security by privately contacting OLPC and giving us an opportunity to address their concerns. Ahem. I have given generously of my time to OLPC by following the project for some three years now; testing B1, B2, B4, and MP machines; supporting G1G1 users; recruiting and paying others to contribute; researching SD card protocols; contributing to discussions by email, phone, and IM; and filing dozens of bug reports. OLPC has seldom graciously addressed my concerns on fundamental design issues, such as BitFrost, activation, developer keys, GPL compliance, game keys, or anything else. When I wasn't ignored, I was criticized for attacking OLPC, or for failing to write up my concerns as a properly tested source code patch. It has been hard -- indeed, impossible -- for me to gin up the requisite perseverence to actually implement anything for OLPC, except small patches to SimCity. (Making those patches turned up numerous bugs, which I reported, which are still largely being ignored.) The BitFrost spec was so clearly a personal hobbyhorse of Ivan that questioning its basic assumptions was heresy, grudgingly tolerated due to my reputation, but otherwise ignored. I decided very early on that it wasn't worth wasting my time and making people mad by criticizing BitFrost in detail, partly because I expected it to fall flat on its face. The parts that were worth focusing on were the pervasive DRM (maybe now that Ivan's gone, I can go back to using the right name for crypto that disables the owner's control). And I was ignored and vilified on *that* until I escalated the DRM issue to Richard Stallman over OLPC's ongoing non-compliance with GPLv3 (and also pointed out non-compliance with GPLv2, which is ongoing). OLPC staff are overworked and underappreciated. Working in the glare of publicity has not made their jobs easier. But giving OLPC an opportunity to address your concerns is pretty much a null concept. OLPC barely has the opportunity to address its own opportunities. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX UPSEC
The most represive school systems we have been talking to have been the ones in the U.S.They even claim that they have a legal obligation to break internet access on the laptop everywhere but the school, to ensure compliance with the law. I personally configured the server to not log IP addresses on HTTP requests, but that will only be used in developing countries. You can bet that most school systems running their own cache/filter/proxy WILL log this info. Forget BitFrost, these kids are being betrayed by basic networking mechanisms (such as persistent MAC and IP addresses.) wad 2. BitFrost does not promise anonymity to school children. This is a valid criticism of a social scheme such as give one laptop to every child, and as pointed out by the authors, a scheme being rolled out in some very violent, repressive countries like Nigeria. It would have been nice if the criticisms had been delivered directly to OLPC, instead of broadcast in a public forum, ... Almost every OLPC forum, including olpc-security, is a public forum. If the enemies of OLPC aren't reading its open mailing lists, they aren't very competent enemies. It's actually more likely that they would notice OLPC criticisms in OLPC forums, rather than at a small USENIX workshop. Indeed, it's the discussion of the paper here that has probably tipped off OLPC's enemies. Shh!!! I believe that the prevailing ethos in the white hat security community is to report newly-discovered vulnerabilities first to the company in question, thus giving them some amount of time to develop a patch before the public announcement. The authors didn't identify any buffer overflows or similar issues. The things they identified were wrong at the fundamental design level, and are not trivially patchable. Luckily, some of them were design goals that never got implemented, like signing everything with the child's private key. Thus, many of the BitFrost mistakes which they point out, are not actual problems in the current shipping XO. The authors appear to be academics, however, so they would get little credit for having contributed to OLPC security by privately contacting OLPC and giving us an opportunity to address their concerns. Ahem. I have given generously of my time to OLPC by following the project for some three years now; testing B1, B2, B4, and MP machines; supporting G1G1 users; recruiting and paying others to contribute; researching SD card protocols; contributing to discussions by email, phone, and IM; and filing dozens of bug reports. OLPC has seldom graciously addressed my concerns on fundamental design issues, such as BitFrost, activation, developer keys, GPL compliance, game keys, or anything else. When I wasn't ignored, I was criticized for attacking OLPC, or for failing to write up my concerns as a properly tested source code patch. It has been hard -- indeed, impossible -- for me to gin up the requisite perseverence to actually implement anything for OLPC, except small patches to SimCity. (Making those patches turned up numerous bugs, which I reported, which are still largely being ignored.) The BitFrost spec was so clearly a personal hobbyhorse of Ivan that questioning its basic assumptions was heresy, grudgingly tolerated due to my reputation, but otherwise ignored. I decided very early on that it wasn't worth wasting my time and making people mad by criticizing BitFrost in detail, partly because I expected it to fall flat on its face. The parts that were worth focusing on were the pervasive DRM (maybe now that Ivan's gone, I can go back to using the right name for crypto that disables the owner's control). And I was ignored and vilified on *that* until I escalated the DRM issue to Richard Stallman over OLPC's ongoing non-compliance with GPLv3 (and also pointed out non-compliance with GPLv2, which is ongoing). OLPC staff are overworked and underappreciated. Working in the glare of publicity has not made their jobs easier. But giving OLPC an opportunity to address your concerns is pretty much a null concept. OLPC barely has the opportunity to address its own opportunities. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
Having received a lot of publicity, the OLPC project is a great candidate for criticism, sometimes constructive, other times done in the absence of other serious academic research. Potentially weak security models in windows is no news, but in OLPC... Now this is worth taking a shot at! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
On Wed, Apr 9, 2008 at 6:21 AM, Mitch Bradley [EMAIL PROTECTED] wrote: It would have been nice if the criticisms had been delivered directly to OLPC, instead of broadcast in a public forum, where enemies of OLPC can cite and expand on them as evidence that OLPC is hopelessly screwed up, so you should buy our competing product instead. If you get my drift. I would be very happy if this kind of criticisms were broadcast in a public forum like the olpc-hosted mailing lists. If people already involved in the project had to go hunting in the blogs for criticism, no code would get written! Is my opinion that one of the things that the project needs badly is criticism. We are just doing too many new things for not being wrong in some of them. But looks like people can be just friends or foes. Sad. Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
I'm a bit slow, being a bugbear of very little brain. I read the paper, and it seems to summarize as: 1. The BitFrost Specification is documentation, not detailed implementation. The author does not read code. 2. BitFrost does not promise anonymity. 3. BitFrost does not cover how to secure the Country Key Store. 4. If used as a specification, and all packets are signed and the Country's Key Store is compromised, then bad things can happen. It seems like OLPC F. should issue an immediate (preemptive) response saying: 1. BitFrost is an open-source implementation. The BitFrost Specification is a high level document and not an engineering specification. Engineers can read the implementation source code. 2. BitFrost does not promise anonymity to school children. [If factcheck says HTTP packets are not generally signed then add] However, it does not enable the pervasive montoring the author suggests. 3. BitFrost does not specify general security measures for the country wide servers. 4. It is unfortunate that a respected conference did not do a better job at vetting this paper. Below is my blow-by-blow. If no one else writes a Wiki page on it by next week, I may do it. Charles Merriam. Concerns seem to be: 2.2 - BitFrost has poor documentation and is not on standards track. Could someone let me know if *all* the BitFrost implementation is opensource? 2.3 - ECC Keypair does not specify keysize Anyone shed light on this? 2.3 - Long lived photograph/name/laptop pairing is made. Um, yes. Author questions, but does not support reasoning for question, this linkage. Also, is this Photograph transmitted as the P in her tuple? Or is P a crypto P? If the photo is not transmitted, then her assertion of being linkable falls down. I hate it reviews let an article publish without checking all the terms. The author incorrectly lumps this under Compromising Privacy. The Compromising Privacy under Bitfrost 7.2, 8.16, 9.2 addresses stealing documents from a user; anonymity is not part of the BitFrost specification or goals. The author also starts a poor researcher's tool here: It's not said why this happens, but if it is because of X then it is wrong. 2.4 - Keys/User This appears to summarize as BitFrost doesn't tell you how to protect your country's key store. 2.5 Bitfrost does not specify anonymous communication. If done like X, you can't get anonymous communication. 2.6 Is it true that calling home for an XO does not include the local School Server? If it does include the local School Server, the author's assertion of remote villages bricking until Internet Access is restored is incorrect. Also points out that an authority could turn off a child's laptop at will. (part of the spec.) 2.7 Spec doesn't cover some bios implementation details. 3.1 The lack of anonymity makes this a bad tool for overthrowing corrupt regimes. 3.2 If author is correct about how packets are signed and an oppressive government monitors all traffic and overtly punishes children for saying anti-government things online, then it could hurt the child's esteeem. Again, would someone in the code answer if all HTTP packets are signed? 3.3 If government monitors all communication, children may be surprised that things said within their school are monitored. 4.0 Conclusions Finds BitFrost doesn't support anonymity, and believes it to be in the spec. Brings up spec addresses user space programs, not the implementing operating system. Footnotes, etc: Didn't check to see if shipping version have a led on the camera. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
Charles, An attempt to answer some of your questions: Could someone let me know if *all* the BitFrost implementation is opensource? yes Long lived photograph/name/laptop pairing is made. In current implementations, there is no photograph, so any discussion of the implementation details is speculative. Is it true that calling home for an XO does not include the local School Server? It need not include the local School Server as currently implemented, but active kill is not implemented (and may never be). Again, would someone in the code answer if all HTTP packets are signed? I don't believe so. Didn't check to see if shipping version have a led on the camera. The LEDs for the microphone and camera are on all mass production laptops. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
Charles Merriam [EMAIL PROTECTED] writes: I read the paper, and it seems to summarize as: 1. The BitFrost Specification is documentation, not detailed implementation. The author does not read code. [...] It seems like OLPC F. should issue an immediate (preemptive) response saying: 1. BitFrost is an open-source implementation. The BitFrost Specification is a high level document and not an engineering specification. Engineers can read the implementation source code. [...] As shown on the Bitfrost status wiki page though, there is not that much implementation yet to critique, so the paper's authors are perhaps justified in looking at just the plans. - FChE ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
On 09.04.2008 05:50, Jaya Kumar wrote: On Tue, Apr 8, 2008 at 8:38 PM, Joshua N Pritikin [EMAIL PROTECTED] wrote: On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote: A paper called Freezing More Than Bits: Chilling Effects of the OLPC XO Security Model will be presented next Monday at USENIX UPSEC'08 [1]. The author has kindly posted the paper at [2], which I discovered after Google took me to her weblog [3]. This paper is depressing. Why didn't the authors step up and contribute instead of criticizing from the citadel? This paper is dead on arrival. No, the paper is dead-on. I think your reaction is dismissive rather than addressing the author's criticism. Forgive me if I'm wrong, I'm no expert, but it looks to me like the paper makes specific technical criticisms and seems quite detailed. I think it would be more positive and productive to respond to the technical statements made in the paper rather than to be dismissive and ignore what looks to some of us like valuable feedback. Some of the criticisms in the paper have been mentioned on the security@ list over a year ago. The reactions were twofold: Some were ridiculed, others were ignored. It seems this academic paper was the only way to get meaningful responses. Then again, most of the comments about the paper were either flames or otherwise dismissive instead of disproving any of the claims made in the paper. Anybody who has not completely read both the bitfrost spec and the USENIX paper should shut up now. I have read the Bitfrost spec and was one of the first persons to comment on it directly after it was published. That's why I dismiss most of the comments on this list about the USENIX paper - it is too obvious that commenters did not read and understand the Bitfrost spec. Oh, and by the way, http://wiki.laptop.org/go/OLPC_Bitfrost states We welcome feedback on this document, preferably to the public OLPC security mailing list http://mailman.laptop.org/mailman/listinfo/security. There is NO point in contacting any Bitfrost author privately to point out flaws - it would go squarely against published official OLPC policy. Regards, Carl-Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
I'm not a security expert and won't even BEGIN to comment on that aspect. My only comment is that one true measure of success is the prominence of your detractors. SO rather then getting noses out of joint, I'd suggest taking it as a compliment and true measure of success that the project was deemed worthy of such academic scrutiny and approach the subject, authors, and potential solutions with that mindset. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote: A paper called Freezing More Than Bits: Chilling Effects of the OLPC XO Security Model will be presented next Monday at USENIX UPSEC'08 [1]. The author has kindly posted the paper at [2], which I discovered after Google took me to her weblog [3]. This paper is depressing. Why didn't the authors step up and contribute instead of criticizing from the citadel? This paper is dead on arrival. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
On Tue, Apr 8, 2008 at 8:38 PM, Joshua N Pritikin [EMAIL PROTECTED] wrote: On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote: A paper called Freezing More Than Bits: Chilling Effects of the OLPC XO Security Model will be presented next Monday at USENIX UPSEC'08 [1]. The author has kindly posted the paper at [2], which I discovered after Google took me to her weblog [3]. This paper is depressing. Why didn't the authors step up and contribute instead of criticizing from the citadel? This paper is dead on arrival. I think your reaction is dismissive rather than addressing the author's criticism. Forgive me if I'm wrong, I'm no expert, but it looks to me like the paper makes specific technical criticisms and seems quite detailed. I think it would be more positive and productive to respond to the technical statements made in the paper rather than to be dismissive and ignore what looks to some of us like valuable feedback. Regards, jaya ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
It would have been nice if the criticisms had been delivered directly to OLPC, instead of broadcast in a public forum, where enemies of OLPC can cite and expand on them as evidence that OLPC is hopelessly screwed up, so you should buy our competing product instead. If you get my drift. I believe that the prevailing ethos in the white hat security community is to report newly-discovered vulnerabilities first to the company in question, thus giving them some amount of time to develop a patch before the public announcement. The authors appear to be academics, however, so they would get little credit for having contributed to OLPC security by privately contacting OLPC and giving us an opportunity to address their concerns. Publishing is the coin of the realm in academic circles. Jaya Kumar wrote: On Tue, Apr 8, 2008 at 8:38 PM, Joshua N Pritikin [EMAIL PROTECTED] wrote: On Tue, Apr 08, 2008 at 10:24:34PM -0400, Benjamin M. Schwartz wrote: A paper called Freezing More Than Bits: Chilling Effects of the OLPC XO Security Model will be presented next Monday at USENIX UPSEC'08 [1]. The author has kindly posted the paper at [2], which I discovered after Google took me to her weblog [3]. This paper is depressing. Why didn't the authors step up and contribute instead of criticizing from the citadel? This paper is dead on arrival. I think your reaction is dismissive rather than addressing the author's criticism. Forgive me if I'm wrong, I'm no expert, but it looks to me like the paper makes specific technical criticisms and seems quite detailed. I think it would be more positive and productive to respond to the technical statements made in the paper rather than to be dismissive and ignore what looks to some of us like valuable feedback. Regards, jaya ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Chilling Effects paper at USENIX
Moved the top post down. On Tue, Apr 8, 2008 at 9:21 PM, Mitch Bradley [EMAIL PROTECTED] wrote: It would have been nice if the criticisms had been delivered directly to OLPC, instead of broadcast in a public forum, where enemies of OLPC can cite and expand on them as evidence that OLPC is hopelessly screwed up, so you should buy our competing product instead. If you get my drift. In the free and open source community, people generally post their technical opinions and criticisms in the open. If they're wrong, then we can say it, while moving forward, or if they're right, then we can fix it, and move forward. I believe that the prevailing ethos in the white hat security community is to report newly-discovered vulnerabilities first to the company in question, thus giving them some amount of time to develop a patch before the public announcement. If the paper provided an exploit or specifically identified a vulnerability then they should have sent it to you guys first. Did they identify a specific vulnerability or exploit? The authors appear to be academics, however, so they would get little credit for having contributed to OLPC security by privately contacting OLPC and giving us an opportunity to address their concerns. Publishing is the coin of the realm in academic circles. Agreed. Are any of their concerns valid? Thanks, jaya ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
