[kwlug-disc] Security arguments

[unsolicited]

Khalid Baheyeldin wrote, On 09/23/2009 10:13 AM:
> 
> 
> On Tue, Sep 22, 2009 at 6:42 PM, Chris Frey <cdfrey at foursquare.net 
> <mailto:cdfrey at foursquare.net>> wrote:
> 
>     On Tue, Sep 22, 2009 at 02:38:04PM -0400, Paul Nijjar wrote:
.
.
.
>     Very good point.  But I don't think that programming well is easy,
>     nor can it be made easy without some unforeseen cost.
> 
>     A better way, in my view, is to make programming badly hard.
> 
>     In other words, it should be impossible, or it should hurt, to make
>     mistakes in programming.  But this sort of mentality isn't something
>     most programmers like.  I think many programmers actively try to
>     escape such constraints.

i.e. They just want to get on with their day.

> What do we have in common here? The human is the weakest link.
> Whether it is the programmer that introduced SQL injections, or the
> amateur web master who installs insecure software, and never updates
> it, or the guy who clicks the attachment that promises a saucy pictures.
> 
> Computers are tools, and if you use the tool to shoot yourself in the foot,
> then there is no way to protect people from that, other than by getting
> educated on them.
.
.
.
>     Both problems are due to lack of attention to detail, and the lack of
>     using the tools we already have to conquer the fundamentals.
> 
> 
> Agreed. Again, humans' fault here.
.
.
.
>     Make programming badly hard.
> 
> 
> I don't think that this should be a goal, not is it effective. Making it 
> very hard, will make it very expensive too because the pool of qualified 
> developers will be less.
> 
> I think that education is the key here to mitigate all this, not making 
> programming hard. Another route is open source, were a pool of people 
> look at the product, not just one or two people who may be not very 
> qualified.
.
.
.
> As a related point: Look at the history of computers and you see 
> attempts at dumbing down the industry that did not work either.
> 
> For example, COBOL was supposed to be a way that managers can write 
> their own reports and bypass pesky developers who never respond in time. 
> It was supposed to be English like just for that. What was the result: 
> managers never learned it, and it was developers who used it for 
> business applications.

	Interesting. ("COBOL was supposed to be a way that managers can write 
their own reports".) I liked Cobol, it's the first language I can 
think of / encountered that enabled data / record structure / integrity.

> The same was proposed for SQL. Rooted in cartesian math, it was given 
> (again) an English like syntax so, you got it, managers can produce 
> their own reports. I can only speculate that it was the query from hell 
> on the production machine that hte manager ran and caused production 
> downtime that made them abandon forever the concept of managers creating 
> and running queries. But the result is that SQL was, like COBOL before 
> it, left for developers.


	Also interesting, and feels accurate - everything started coming out 
(with ODBC?) with an ability to roll your own SQL statements. And 
things just withered under the load. Mind you, I do think the 
accomplishment of a 'standard data' 'mining' language has been a good 
thing. As have local databases, e.g. MySQL, instead of requiring big 
beefy hardware and expensive software. Vs. local text / btrieve 
'databases.'


These comments make me think of the prevalence of Point & Shoot 
digital cameras. Everybody goes click happy. I wonder what the 
percentage of truly good / desired result / well exposed images happen 
these days. Vs. the days of film where every image cost X amount as a 
portion of the film processing and printing costs - I'll bet, even 
with film P&S, the percentage of reasonable images resulting was 
higher than today. I also wonder what percentage of pictures taken 
today actually get printed. And the success percentage of P&S vs. 
SLRs. i.e. The cost of entry of SLRs, or the cost of acquiring 'good' 
programming skills, garnering similar 'quality results'.

How many people self-medicate, do their own wiring, fix their own 
plumbing, change their own oil, only going to the experts after 
they've shot themselves in the foot?

How many people don't 'call before they dig'?

Why? Poor programming or otherwise? Because they can.

And because sysadmins, like regulation, are seen as barriers, not safe 
facilitators. And so, sysadmins, have neither the authority nor the 
tools to keep us safe.

We let children ride bikes on busy roads ...