[e-lang] Microsoft's laws of identity

[Mark Miller]

Andy Dwelly wrote:
> It's a bit tricky to be precise but I'll try and describe the situation. 
> The planned product is a commercial one and it allows a collaborating 
> group of people manipulate a collection of shared data structures that 
> represent documents. These documents can be converted to Word/OpenOffice 
> etc for viewing elsewhere. In short I could describe it as document 
> management.

Hi Andy,

Where are these shared data structures? The main choices I see are 1) a shared 
server, or 2) only within the applications run by the individual users. If #2, 
then you have the additional problem of how Bob can access data hosted by 
Alice when Alice isn't running her app. Possible answers include a) Each user, 
such as Alice, is assumed to always be running a background server serving the 
data she hosts, or b) the data is in a shared filesystem accessible (somehow) 
to Bob.

 From what you say below, I assume we're in scenario #1.


> It's groupware, but the data is not fully available to everyone so there 
> needs to be a way of controlling who can see what, and who can change 
> what. The normal choice would be to build in some version of 
> groups/accounts into the application, or possibly just pick up on the 
> underlying OS version of this. However, the unthinking use of ACLs leads 
> to various problems that would make our system less usable. As I said, 
> my choice has been to use a capability model instead. I believe this 
> leads to a variety of positive outcomes as far as usability is concerned 
> and I'm anxious to try it.

Very good!



> The level of security I'm after is essentially enforced at the 
> application level. Its my intention that for the sort of user that 
> interacts via the standard client, they should be able to exert some 
> security controls on their collegues - equally equipped. It's clear that 
> for anyone who is capable of changing either the clients or servers, or 
> illegally accessing data  the server despite its OS level security, or 
> even physically accessing the server if it's a Windows style OS, this 
> system is wide open. For this particular version we don't care.


Always good to know what problem you're solving and which you're not. No need 
to apologize. I applaud your focus on usability!



> Why would it cost more to properly implement security ?  I'm assuming if 
> I was to do this in E, I would actually get most of this for free. Well, 
> I'm the only one in the development team who has any idea about E, and 
> in fact I'm the only one in the development team who has ever done any 
> functional programming. My colleagues would need to be convinced and 
> then taught which takes time and resources. 

This education cost is real. That's why I've spent so much time encouraging 
the insights from E to be adopted into other suitable existing language platforms.



> Secondly, we are using a 
> bunch of prebuilt UI components. The cost of these conventional widgets 
> is small compared with the cost of reimplementing them in E but I think 
> that this would be necessary as well to preserve the security.

Are you using AWT/Swing or SWT? Our approach to widgets has been to try to 
tame the widgets provided by an existing library. Taming AWT/Swing was too 
hard (in the absence of funding needed to mount a large scale effort). As far 
as we can tell, we've tamed SWT, but our SWT taming hasn't gone through the 
kind of security review to which our Swing taming was.

In any case, given the problems you are and are not trying to solve, I agree 
that widget taming is probably irrelevant.


  Finally
> there is the matter of scale, we are looking at around 100k lines of 
> code in java. Less in E I'll warrant, but its not clear to me that an 
> application of this scale has ever been built in E, is this right ?

The total number of lines of E code in the E distribution is 40k, so yes. 
Electric Communities Habitats was written in Original-E, and I'd guess it was 
over 100k, but I no longer have any way to measure it.

Another possibility is mixing E and Java. Write the bulk of the apps in Java. 
Write the security, client/server protocol, and/or control layers in E. So 
long as the bulk of your Java code is singly threaded (a good idea anyway), 
Java and E interoperate quite well.


> This is not intended as a rant against E, which in fact I'm rather taken 
> with; but these are practical problems that software architects face at 
> the moment who might consider using E. The best I can do is start to 
> experiment with some of the underlying concepts in the hope that at some 
> point in the future I'll be able to say - 'lets do this one in E, it 
> will save us a lot of time and money'.

Thanks you! By that point in the future, I hope to have E in good enough shape 
for it to be a good choice. For your current situation, your decision seems 
quite sensible.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM