dotgnu-auth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Auth]Freport Update


From: David Sugar
Subject: Re: [Auth]Freport Update
Date: Fri, 15 Mar 2002 09:28:40 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20020107

In the end any identity service requires some degree of trust to exist, and IDsec assumes this, whether it's trust of oneself by locally hosting identity, or trust of others. That trust can and is abused is certainly the imperfect situation, but it is still possible to have trusted third parties, and as such, IDsec permits these (and anyone else) to provide identity.

Consider this, the FSF holds copyright on many free software packages exclusivily. They could, on their own, at any time, choose to change these packages to a proprietary license and have the full support of the law in doing so. Yet, they are trusted. That UCITA could exist does not mitigate the possibilities that third parties can exist which can enjoy and do deserve similar levels of trust as profile providers. All IDsec says is that anyone can provide this function openly, that a free and open market in identity services can exist, and certainly some of them that do will not be trustworthy.

In the end it is impossible to enforce social behavior thru engineering, nor would it be desirable to do so. In this sense, the paradox is as great as that of those corporations that use free software while activily promoting it's destruction. We do not have free software licenses that say anyone but "company X" can use this software, as this is not freedom, nor can we say how any third party hosted software may or may not be abused in this regard.

Could there be a better solution than IDsec? Certainly. In the end, IDsec not only depends on the trust of those that host profiles, but also on the knowledge of those that use it. These represent challenges, but are not insoluable problems. At least what flaws exist in IDsec can at this point be understood and where needed users can be educated. While not ideal, I don't think the solution that is offered in IDsec is nessisarly all that bad or fataly flawed. However, I do not think we should stop looking at other ideas either.
David

John wrote:

David - You're still hung up on the Services colluding. I'm not
concerned about the services. I'm concerned about the Manager. I pointed
out why the first party hosting scenario is less than reliable and
practically forces the traveling Owner to the reliable third-party
scenario, which is has a hole that allows the collection of transaction
meta-data. Thus I'm heartened that you say in-situ:

David Sugar wrote:

I do not say IDsec is perfect, but it is a reasonable effort and what
flaws exist can be understood and mitigated, especially by locally
hosting profiles.  The primary question is can profile providers be
trusted?  But since anyone can become one, it is quite possible for
trustworthy (and untrustworthy) ones to exist.


and disenheartened by this non-extension:

As I pointed out in my reply, in a UCITA state that trustworthiness can
evaporate with the flip of some bits at no notice to yourself. Remember,
every well-written commercial TOS contains an agreement as to which State and Country terms of the TOS are to be adjudicated. Once you click
you're bound; if the company happens to be governed under UCITA - it
doesn't matter where *you* are only where "they" are. In a UCITA state
he who is trustworthy today in not collecting transactional meta-data is
not necessarily trustworthy tomorrow.

ID-Sec doesn't "prevent the possible abuses of Passport" (one of the
original requirements); but instead allows more corporate entities to
abuse customers in the same way. Colloquially, ID-Sec gives the data
Owner a choice of bloodsuckers to marry. The only way to prevent cloning
the passport collection is to prevent transactional metadata from being
collected at all. (See my other response for how transactional meta-data
can be abused)

Close the barn door. As was originally positted: offer an alternative
that is private on every level. If the aim of DotGNU is to foster our
moral choices (in such manner as the GPL fosters our moral choices),
then opening the barn door wide for even one potential entity to abuse
is a very bad idea. Better to chose a design that backs what we felt
were moral choices in the beginning, than grab the first thing that
comes along and give it the imprimateur of "our way" simply out of
convenience. Build paranoia into our solution from the start as we
originally planned, assume that everyone is dishonest and will try to
benefit from dishonesty.

A piece of paper is a flimsy protection for privacy.

As I said before, I only believe that people should be informed, and if
Hans can show me that the transactional metadata cannot be collected
under his current design *in any sane usage scenario*, then I will
renounce my objection: and probably apologize.
John Le'Brecage
_______________________________________________
Auth mailing list
address@hidden
http://subscribe.dotgnu.org/mailman/listinfo/auth






reply via email to

[Prev in Thread] Current Thread [Next in Thread]