[
Lists Home |
Date Index |
Thread Index
]
In the context of the principle of least power as it applies to
security I think this quote from the Structure of Authority is
appropriate:
"Common programming practice grants excess authority for the sake of
functionality; programming principles require least authority for the
sake of security."
http://www.erights.org/talks/no-sep/
The obvious connection is to the authority that a programming language
has, what objects is it allowed to manipulate.
Cheers,
Bryan Rasmussen
On 2/17/06, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
> The main problem is how do we define power in this context.
>
> Last night I was struck by the thought that the dynamic typing is more
> power argument does not fit this context in that I am familiar with
> this argument as meaning that power = increase in productivity. I'm
> not sure if the people arguing typing here are taking that point but
> at any rate that is the only context that I am familiar with dynamic
> typing leads to an increase of programming language power.
>
> And obviously it is absurd to argue that one should use the less
> powerful solution because the less powerful solution is less
> productive. The principle of least power is not arguing for a slowing
> down of internet time! I realise I may be misinterpreting the dynamic
> typing leads to greater power argument, but power = increase in
> productivity is the only context in which I've ever seen the argument
> before.
>
> I think there is also a real problem with the principle in that it has
> been observed before that languages over time tend to grow in power.
> It is a natural tendency to make a language more powerful in each
> stage of its development, if your principle of what makes a language
> good is going up against a natural tendency of language development I
> worry about the ultimate survival of the principle.
>
> Of course, since we haven't decided exactly what power means in this
> context can we actually decide that languages grow in power in the way
> that the word must be used in this context?
>
> CSS is an example of a language with clearly defined powers, and their
> gradual overstepping.
>
> CSS with the power of setting values of styling on elements is CSS
> with the least power necessary for achieving its goal.
>
> However, in order to make various things work in Internet Explorer, it
> was allowed to put script code into the css, via dynamic properties -
> http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/overview/recalc.asp
>
> Increasing the language in power but decreasing the ability to analyse
> the stylesheet, and maybe opening the css engine up for security
> holes.
>
> Another increase in power of CSS, the ability to place text into the
> document via content:
>
> This makes analysis of the various components of a web application
> more difficult to analyse because now we have the possibility of
> putting content into what the user sees from several places.
>
> Increases in power generally occur when the original problem domain is
> expanded or crossed. I believe that the examples of CSS I've given
> here basically comply to the usage of the term power as set forth in
> the principle of least power.
>
>
>
>
>
>
>
>
>
>
> On 2/16/06, Bullard, Claude L (Len) <len.bullard@intergraph.com> wrote:
> > That is my take too. As in 'wisdom of crowds' what one
> > asks, 'crowds of what?', the principle isn't applicable
> > without knowing the task because it is 'least power
> > adequate to the job at hand'. As Jeliffe said, otherwise
> > one is a troll.
> >
> > AJAX is probably applicable to lots of jobs only because
> > there are objects around to do the heavy lifting. The
> > fact of xmlhttp and loading up a bigChunk of XML, well
> > that is how markup was supposed to work from before the
> > web and was talked about while everyone else was arguing
> > for 'thin clients', 'HTML is holy' and 'separate formatting
> > from presentation'. Load balancing IS holy. The client
> > gets thicker by task, the separations of formatting from
> > presentation IS about reuse, and so on. It isn't that the
> > ideas aren't right, they are only right sometimes and
> > even then, they may start becoming wrong if practice and
> > application take another direction. It's like driving
> > in the left lane in right lane countries.
> >
> > So when I see these principles, I have some scepticism
> > until 'crowds of junkyard dog experts' chew on them. If
> > they stand up to that (for example, "Dare to do less" was
> > debated but it stands up to abuse and is a sound principle),
> > they are probably good to go.
> >
> > len
> >
> >
> > From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
> >
> > On 2/16/06, Bullard, Claude L (Len) <len.bullard@intergraph.com> wrote:
> > > I hate to see web architectural principles in the same
> > > light as pop psychology. So if there really is a
> > > deeper and clarifying principle here, one wants to be
> > > able to express it in simple terms that the marketing
> > > department can't screw up.
> >
> > Don't think there is any deep clarifying principle here. Even if
> > there was, it's not one that couldn't be screwed up....
> >
> > I recall the first time I encountered the Mandelbrot set: the
> > algorithm looked pretty simple so I coded it up in a high level
> > language I was using at the time. It had good floating point
> > libraries and I figured things would work fine. The resulting program
> > was probably about 200 lines of code and took like 30 minutes to
> > produce a very low resolution plot. So next I turned to C. Now I got
> > it down to maybe 100 lines of code and I got a better resolution graph
> > in a couple of minutes but still nothing like the images that I
> > wanted. Finally, I turned to 370 Assembler. I had direct access to
> > the floating point registers so I could pull a couple of numerical
> > manipulation tricks and I finally got something that ran in seconds
> > and produced the results I wanted with probably about 40 lines of
> > code. (All of these essentially fed the same graphics library).
> >
> > Could I base any development principles on this? Absolutely not, the
> > result was completely specific to the problem at hand and I think it
> > always will be. IT seems to me that finding the "least powerful" way
> > to implement an algorithm, system or whatever requires as much
> > analysis, modelling and experimentation as any other approach to
> > matching requirements to implementation, if not more and is not
> > something that can be generalized or encapsulated in a couple of pithy
> > sound bites worth of "wisdom"..
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://www.oasis-open.org/mlmanage/index.php>
> >
> >
>
|
