<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Praetorian Update: May 2007</title>
	<atom:link href="http://blog.cocoia.com/2007/05/25/praetorian-update-may-2007/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.cocoia.com/2007/05/25/praetorian-update-may-2007/</link>
	<description>The Cocoia Blog is the website of Sebastiaan de With, a Dutch Icon and Interface designer.</description>
	<pubDate>Fri, 21 Nov 2008 09:35:54 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: sebastiaan</title>
		<link>http://blog.cocoia.com/2007/05/25/praetorian-update-may-2007/#comment-4419</link>
		<dc:creator>sebastiaan</dc:creator>
		<pubDate>Sun, 27 May 2007 08:22:52 +0000</pubDate>
		<guid isPermaLink="false">http://blog.cocoia.com/?p=104#comment-4419</guid>
		<description>I wasn't, at the time of taking the screenshot, able to reverse the title bar color. It is now, however.

The basic idea behind RADIUS is that it does store passwords in cleartext - therefore, most knowledgeable users will be able to read the users file with administrator-level privileges. However, I do not let Praetorian run with admin-level privileges, and I wouldn't have come this far if I would put all sensitive material in a list.
Praetorian uses Core Data. The interface you see here, is the hard work done and the data views (the tableview, the search field, etc.) made with rapid prototyping. I have a special password assistant for the full version that takes all the work out of your hands and works with the regular system-wide 'password assistant' and keychain.

You might also notice the 'clients' section doesn't work and is actually a copy of the 'users' custom view, but that's beside the point. I wanted to illustrate the interface and put it out there.


However, my readers can convince me anything. I -do- have ethical questions not abiding by HIG's. I have my doubts about my own dark tableviews (all previous builds had 'normal' tableviews). The interface also takes a generous slice of the time going into the project, but I don't feel like it's wasteful - if I ever have to dump it and go with unified metal, then ah, we'll just make the assistants pretty ;).

On a side note, my awful English is hopefully something that will be resolved in the beta's and localisations where I will be having a venerable army of grammar nazi's to my disposal (not implying that you are a grammar nazi, but it's come up before in contexts like 'Stop using 'it's' for possesive, for god's sake!').

Thanks a lot for the input based on solely a screenshot. If you want in on testing, just let me know. I appreciate your feedback a lot..</description>
		<content:encoded><![CDATA[<p>I wasn&#8217;t, at the time of taking the screenshot, able to reverse the title bar color. It is now, however.</p>
<p>The basic idea behind RADIUS is that it does store passwords in cleartext - therefore, most knowledgeable users will be able to read the users file with administrator-level privileges. However, I do not let Praetorian run with admin-level privileges, and I wouldn&#8217;t have come this far if I would put all sensitive material in a list.<br />
Praetorian uses Core Data. The interface you see here, is the hard work done and the data views (the tableview, the search field, etc.) made with rapid prototyping. I have a special password assistant for the full version that takes all the work out of your hands and works with the regular system-wide &#8216;password assistant&#8217; and keychain.</p>
<p>You might also notice the &#8216;clients&#8217; section doesn&#8217;t work and is actually a copy of the &#8216;users&#8217; custom view, but that&#8217;s beside the point. I wanted to illustrate the interface and put it out there.</p>
<p>However, my readers can convince me anything. I -do- have ethical questions not abiding by HIG&#8217;s. I have my doubts about my own dark tableviews (all previous builds had &#8216;normal&#8217; tableviews). The interface also takes a generous slice of the time going into the project, but I don&#8217;t feel like it&#8217;s wasteful - if I ever have to dump it and go with unified metal, then ah, we&#8217;ll just make the assistants pretty ;).</p>
<p>On a side note, my awful English is hopefully something that will be resolved in the beta&#8217;s and localisations where I will be having a venerable army of grammar nazi&#8217;s to my disposal (not implying that you are a grammar nazi, but it&#8217;s come up before in contexts like &#8216;Stop using &#8216;it&#8217;s&#8217; for possesive, for god&#8217;s sake!&#8217;).</p>
<p>Thanks a lot for the input based on solely a screenshot. If you want in on testing, just let me know. I appreciate your feedback a lot..</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ahruman</title>
		<link>http://blog.cocoia.com/2007/05/25/praetorian-update-may-2007/#comment-4201</link>
		<dc:creator>Ahruman</dc:creator>
		<pubDate>Fri, 25 May 2007 21:26:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.cocoia.com/?p=104#comment-4201</guid>
		<description>Apart from the obvious blackness of it all – I’m sure I couldn’t convince you, at this point, that white on black is bad and tiring, but black on black in the title bar? – the thing that stands out most to me is actually the non-standard use of full stops at the end of captions. I suspect that users will tend to notice that there’s something odd, but not notice what. Was this a concious decision? (Obviously most of your decisions are very concious and deliberate, but – no offense intended – your English is a bit unpolished, so that could be an oversight. On that general topic, “Guarded” is a bit of a weird choice of words.)

From a functional point of view, the list of visible passwords bugs me. At the very least, seeing passwords should require an admin password to be entered, along the lines of Keychain Access. This at least reduces the chance that someone might walk past and see them.

But really, having user passwords available to the administrator at all is bad and wrong; all the admin needs is to be able to reset the password as necessary. Users tend to reuse passwords, no matter how much you tell them not to, and entrusting admins with access to users’ passwords is thus a clear security problem. I suppose this could be a flaw in the underlying protocol, though.</description>
		<content:encoded><![CDATA[<p>Apart from the obvious blackness of it all – I’m sure I couldn’t convince you, at this point, that white on black is bad and tiring, but black on black in the title bar? – the thing that stands out most to me is actually the non-standard use of full stops at the end of captions. I suspect that users will tend to notice that there’s something odd, but not notice what. Was this a concious decision? (Obviously most of your decisions are very concious and deliberate, but – no offense intended – your English is a bit unpolished, so that could be an oversight. On that general topic, “Guarded” is a bit of a weird choice of words.)</p>
<p>From a functional point of view, the list of visible passwords bugs me. At the very least, seeing passwords should require an admin password to be entered, along the lines of Keychain Access. This at least reduces the chance that someone might walk past and see them.</p>
<p>But really, having user passwords available to the administrator at all is bad and wrong; all the admin needs is to be able to reset the password as necessary. Users tend to reuse passwords, no matter how much you tell them not to, and entrusting admins with access to users’ passwords is thus a clear security problem. I suppose this could be a flaw in the underlying protocol, though.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
