OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Re: [xml-dev] The Rule of Least Power - does it miss the point?

[ Lists Home | Date Index | Thread Index ]


On Thu, 2006-03-09 at 20:43, Bullard, Claude L (Len) wrote:
> >Ok.  I have to give up on this one, because I'm lost.  I hadn't been
> >exposed to the terminology you were using relating to cybernetics, but
> >from the point of view that you just stated, yeah:  multiple viewpoints
> >across the same data is a good thing. 
> 
> No it isn't.  That's the point. Do you really want your Social Security 
> Number on a clipboard?  It depends on the operations over the clipboard, 
> roles, permissions, rights, persistence, access by location by whom (police officers 
> have to weld or chain car PCs to the body of their cruisers), and so on.

Again, we're back to context.  If it is in a totally unstructured way
with no security model, then "no" is correct.  If this access has been
previously been granted via some sort of security protocol, then I still
say "yes", because you have authorized access to the data under a given
set of conditions.  These scenarios are exactly what the EU data
protection legislation is about.  The person is in control of the data,
not the entity holding it.  Of course, this is totally different in the
US.

> We use subjective communications to attain objective goals.  Then measure 
> and iterate.  The fact of measurement being subjective and the choice 
> of goals being subjective makes it all feel... well.... unreal.  Then 
> you get the phone call from a credit agency, realize your identity 
> was stolen and now you have to spend X numbers of days and resources 
> fixing that mess because the time of access to discovery was long 
> and that is how the system was designed:  subjectively.

I haven't had my identity stolen, but I have had my credit card number
nicked and used to buy about $500 worth of stuff.  Yes, it's a royal
pain.  But in your example and related definition, who is playing what
role?  Is the observer the credit agency, you, or both?

> >I take your earlier comment about the context for what the original
> >start for the thread was:  the web and only the web.  
> 
> And that means only apply the principle to the web, but then you'll 
> have hard time figuring out what is 'on the web' and what is 'off 
> the web' and you have a world of marketeers, well-known experts, 
> and laudable heros telling you to be always connected and always 
> on the web because you alwasy want to be Googlable, right?

It depends on your goals and your ability to state your intentions of
access rights to the data you make available.  Obviously, making
information available means you accept certain risks associated with
it.  Depending on who you are or what you do, that's a choice you need
to make.  However, you need to know the implications of your decision. 
I'm sure that someday, these posts will come back to haunt me, but it's
my choice to post them (hopefully, I'll be smarter by then, though... :)

That being said, you always release data under a security model (null
being a valid security model, if not a particularly desirable one).  If
you don't want to deal with the consequences of the available model(s),
don't release the data.

> See the circular nature of that?  Your objectives are subject to 
> their objectives.  You want free gmail whether it is reliable or 
> not.  They want to mine your mail and sell your thoughts in
> their attention economy.  Wouldn't it be a bit cheaper to buy 
> another $99 USB external hard drive?  Objectively speaking that is?

I don't use gmail because I don't trust google, and I don't want the
ads.  So, I'd buy the external HDD.  Some of this goes back to Fromm's
sheep references in "To Have or To Be".  It's still about the choices
you make as an individual, and yes, if I understand your definition
correctly, those are subjective.

> <aside>be aware that attention is both directed 
> and misdirected:  the first is real magic, the second is stage 
> magic.  Fools and their money/identity/love... </aside>
> 
> >Fair enough, but from a few other things going on over the last few days, it's really
> >driven home that in several cases, we need a lot less zeal and a bit
> >more critical thinking & actual understanding of how people solve
> >problems.  A lot of people don't articulate the why, only the how, and
> >that makes it difficult when it comes time to change it later. 
> 
> Alright.  If you have a choice between a QBE-data base GUI that automates 
> the rule checking (think business rules), vs a mashup GUI that is loosely 
> coupled to services of different quality and can mostly validate that 
> you entered a syntactically valid URN, SSN and Zip Code, vs a screen 
> form that is identical to your tax form in appearance but otherwise 
> just ships the data you enter unvalidated to an accountant, 
> which do you prefer to do your taxes?
> 
> How matters.  How long matters.  How much matters.  Why is a given.
> 
> It doesn't always work that way.  Sometimes why matters a lot but 
> only if you have problems with intensions and now we are back to 
> subjective systems.  You do want to know why, but you may not 
> have to care.

I was coming from a more design-based direction, because both the how
and the what are very important when you need to
extend/understand/replace a system.  What I was saying is that in
software architecture, you generally get the how, but you often don't
get the rationale that led to the particular solution.  That's what is
so important about IEEE 1471, because you're supposed to capture that
stuff too.

Probably being a bit thick here, but I'm not 100% sure I follow your
example.  In it, of course how matters, and the why seems self evident: 
you want to get your taxes done.  However, regardless of the way the
data gets into the system, the access control model should still apply. 
Validation, presentation and transmission should all follow these
rules.  If they don't, you should know.  If you don't know or have
doubts, don't use it--just walk away.

> >"It is far better to be explicit and wrong than to be vague."
> 
> You will be just as broke.

This really was in relation to the description of a system, not about
identity theft, but it could well apply to privacy policies.  If it's
vague, you've no idea to what extent you're exposed, so you should
assume the worst.  If it's explicit and proves to be wrong, you at least
know where you stand in relation to what you thought you had.

> >Back to lobotomizing some architectural principles in the name of
> >backward compatibility... *sigh*
> 
> Yes, but you'll have lots of money and desirable things follow that around.

Well, let's just hope that I can convince TPTB to do the right thing and
it doesn't get that far.  I've been fighting this all day.  However,
regardless of how it goes, I don't think it'll fall into the "lots of
money" category except in how much it will cost to fix later vs. now.

I would also agree from your follow-on reference that legitimacy is a
key concept.  However, I don't have the same background on this, so
according to http://www.starlab.vub.ac.be/staff/ademoor/publ.html, I've
got some catch-up reading to do.  Of course, I'm not really sure this
will happen in time to be relevant to the discussion at hand...

Bottom line is no, I don't want unfettered access to my data, or for it
to be aggregated for anything I didn't authorize.  However, in the
current state of the web, anything you publish is done on the assumption
that exactly this sort of unfettered access can happen, and, as you say,
is desired.  It still all boils down to access control on the data, what
data is made available and in what legal framework does that use occur.

BTW, having nothing to do with the above:  for the vast majority of the
things I do, I use vim (with line numbers, ex commands & comment/line
formatting, but without bracket matching, color syntax highlighting or
about 10,000 other things it can do)... ;)

ast
-- 
Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at
InfoSeCon 2006.  For more information, see www.infosecon.org.

***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS