No More Jargon


The coalescence of thoughts with regards to technical subject matters in the areas of software design and computer languages.

Twitter:

    Wednesday, November 15, 2006

    Adversarial System Design

    So, very, very often, I see people characterizing the need for member and function privacy as a way of keeping people out and preventing them from mucking with your stuff.

    How messed up is that? You're a fool if you let untrusted users run code in your system without putting massive, massive restrictions on them. See _why's Sandbox efforts.

    When you're designing a system or library, the purpose of restricting access to elements of an object is not like putting up a "KEEP OUT" sign, but more along the lines of, "Here are the controls to drive the car. Really, please, don't unscrew the spark plugs." But if a competent mechanic needs to do something to the car, he doesn't feel compelled to not go touchy touchy. Someone else that's happy to just drive the car so he can carry around his precision telescopes won't touch the spark plugs.

    Why design with an adversarial mindset? You're not helping the mechanics, and the astronomers probably weren't going to touch the spark plugs in the first place.

    No comments:

    About Me

    My photo
    Truly a Simple Minded Fool