>>> Well, I'm going to disagree. If I understand the reason  
>>> correctly,  the application is impossible to get to because it  
>>> offers nothing but  a GUI, and frankly, if you don't want a GUI  
>>> what are you doing on OSX? Use Darwin or Linux.

I'm in OS X because it's the best.  I'm using lynx (or some other command line 
app) because I'm in a remote location and don't have access to the GUI.  I 
frequently use curl, wget, axel, rsync, scp, etc to download files to my home 
computer while I'm not at home.  This is incredibly useful as I'm able to start 
a large download while at work and have it ready to use when I arrive home.  OS 
X is after all based on BSD and as expected can be used without a GUI.


>I was afraid it would be taken poorly - sorry, but that's that the  
>"PEACE" was for. I'm not worried about the user experience - of  
>course, if the user chooses GUI or CLI, it's their choice. But - the  
>point was (and excuse me if I mangle this a bit) that the developers  
>don't believe that a CLI-based interface is nearly as secure as a GUI- 
>based one, it would compromise the basic tenants of LS.

I can understand this thinking, but forgive me if I don't believe it.  I fully 
understand that by opening LS to the command line it allows a rogue application 
to make changes to the LS configuration in the background and without the user 
being any wiser.  This is why OS X, as a BSD based system, supports user 
privileges.  LS must be authenticated before changes may be made.  Likewise the 
proposed command line app would be authenticated before changes are made.  
Granted the rogue app could toss up an authentication dialog in an attempt to 
trick the user, but this is why LS should not install the command line app 
unless the user specifically a) authorizes the installation and b) authorizes 
LS to accept changes from the command line.  Both of these authentications 
would initially occur in the GUI (in the PrefPane or during installation).  
This level of security, along with some heavy disclaimers, should be enough to 
deter those who don't know what they're doing, warn those who !
do, and free those who are stupid.


>I support that decision because the rules aren't hard to add in the  
>GUI, and frankly I don't want LS diminished one iota because some  
>users just refuse to use the GUI. It's virtually never the GUI but  
>rather the terminal you have to watch.

They aren't hard to add in the GUI, unfortunately they are impossible to add in 
the terminal.  Yes the terminal is far easier to cause damage from, but that's 
why it's the terminal.  Anyone who doesn't understand that has already gone too 
far.  With the terminal comes great power and responsibility.  This of course 
comes off as diminishing those users that aren't comfortable enough to have 
that power, but they are of course also the users who will not install the 
command line app.


> I don't believe for one minute  
>that because someone uses a terminal, their requests are more serious  
>or more valid than the GUI users, or the developers for that matter.

Unfortunately it seems that the reverse is true and the requests of the 
terminal users are less important.


>If you thought me rude, please excuse me if my point was brusquely  
>made, but I support the developers in their choice and I certainly  
>don't want my app weakened because of Terminal laziness.

As said this is not an issue of Terminal laziness.  There are many valid 
reasons why the GUI is simply unavailable and a command line interface is very 
valuable indeed.  I have almost complete control over my home machine while I 
am away due to the Terminal.  LS control would be a valuable addition.


>> Sometimes you can't have a remote desktop, and you're really happy  
>> to be able to work within a shell. If you prefer to have on osX  
>> nothing more than windows can offer you, it's your choice. As osX  
>> have powerfull CLI capabilities, i'm just asking to have software  
>> use it.

Agree completely.

As a final note, I'll correlate LS with the MacOS X Firewall.  The firewall is 
simply an interface into ipfw.  Back when Microsoft Office would check the LAN 
for duplicate copies, it was found that this was a security hazard by the way, 
I would disable the requested ports used by Office in order to run Entourage on 
one computer and Word on another.  Without disabling these ports Office was 
less useful.  It would be very simple for Office to authenticate as root (with 
a GUI dialog) and modify ipfw to re-allow these ports.  It is up to the user to 
be intelligent enough to not allow or correct this behavior.  Note that Office 
never actually performed these tricks, though it would be quite possible.

Any application that deliberately tricks the user in the manner described above 
is the kind that would spend the time to reverse engineer the LS security 
checks.

A command line interface DOES provide additional means of compromised security. 
 There are however plenty of ways to ensure that security is not actually 
comprised and that any user who might access these more risky actions is 
educated enough to know what they are doing.

If every application stooped to the lowest common denominator of user, I 
suspect that LS would not even exist.  Just because Mac OS X is a GUI intensive 
platform doesn't mean LS should neglect the other half of the available 
interface.

I hope you'll reconsider, but I also recognize that at worst the lack of a 
command line interface is an annoyance measured in the amount of time required 
to regain physical access to a machine.  

Thanks for listening.

Peace :)

--                                                 --
arno  s  hautala         /-\           [EMAIL PROTECTED]
--                                                 --
_______________________________________________
Littlesnitch-talk mailing list
[email protected]
http://at.obdev.at/mailman/listinfo/littlesnitch-talk

Reply via email to