On Wed, Apr 02, 2014 at 05:48:57PM +0200, Alexandre Anzala-Yamajako wrote: > In a world where everybody would only do what they qualified for and know > when to call for help I would agree with you but I think you underestimate > how many well meaning people would consider that sampling the system clock > is "unpredicatble enough". > Listing all the ways you could mess things up is obviously a lost cause but > naming a few bad ideas serves as a good cautionary tale IMO
I always thought that many proscriptive and prohibitive lists lack rationale, and so a few words as to why you should not do X and Y are worthy of inclusion. The risk with this is that the developer thinks, "ah, but these do not apply in my case!". Therefore, you should include a few examples that are so obscure that the developer would not have thought of them (so as to humble them intellectually), and indicate that your lists are not exhaustive, to avoid making them feel so smart that they can ignore your warnings. IMHO. When it comes to security, ignorance and hubris combined seem to be the top risk, and so it helps to demonstrate to the dev that things are not as simple as they seem right off the bat. That is best done by way of seemingly reasonable examples of previous attempts and how they failed. Lead them down a "safe" path and spring the trap on them once, and you have a much better chance of being listened to. -- http://www.subspacefield.org/~travis/ Remediating... LIKE A BOSS
pgpN8e89DWHpr.pgp
Description: PGP signature
_______________________________________________ dsfjdssdfsd mailing list [email protected] https://www.ietf.org/mailman/listinfo/dsfjdssdfsd
