dotgnu-general
[Top][All Lists]
Advanced

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

Re: [DotGNU]login service slamming


From: Barry Fitzgerald
Subject: Re: [DotGNU]login service slamming
Date: Sun, 29 Jul 2001 13:50:59 -0400

Ron Burk wrote:
> 
> >The only thing that I want to ensure is that they can't use our own work
> >(outside of the spec) against us.  All specs should be open for
> >anything.  All code, however, is a creation that should be held closely
> >to the intentions of the original author.
> 
> What about all data? How about if Microsoft modifies their
> Passport SDK, so that Passport-enabled servers now
> also suck the personal data out of any end-users
> who happen to be using dotGNU-based single
> logon products and put it into the Passport database?
> Since they control the browser, it's conceivable that they
> could create a completely transparent form of "slamming",
> in which people who thought they were using a dotGNU
> single logon system have been silently converted to Passport,
> and now their data resides on centralized Microsoft
> servers in addition to the original database location
> that the end user selected. (I'm thinking only of the
> proposal being developed at address@hidden, for
> which I see no technical difficulties to implementing such
> slamming -- nor can I see any strictly technical
> barriers that could be erected to stop it.)
> 
> "all specs should be open for anything" would seem to
> indicate that such slamming is perfectly acceptable,
> in which case, the dotGNU specification may be a convenient
> way for Microsoft to acquire new Passport users and
> little threat to them (since they have no compunction
> to make their specs open, and can prevent any slamming
> in the opposite direction).
> 
> Is slamming important to try to prevent? I'm not sure that
> AT&T feels "validated" when their customers get
> slammed over to MCI :-). I bet they would feel even
> less so if a proprietary spec eliminated the possibility
> that slamming would ever occur in the reverse direction.
> 
> Ron Burk
> HighTechInfo.com, www.hightechinfo.com
> 


If the auth system is built correctly, then there should be no problem. 
I haven't had the time lately to get heavily involved in the "quick and
dirty" implementations that people are trying to leverage, but there are
several GAPING problems with what you just stated.

First, and foremost, the user needs a way of controlling where his/her
information goes.  If the default is "always open" then we have a MAJOR
problem and - in that case - does someone want to remind me as to why
we're doing this?  If people want "always open" schemes where
information is transparently given to any entity that requests it, then
we're done for anyway.

Second, relying on the browser API's for the solution is wrong.  For a
"quick and dirty" implementation to get in the door, we may need to do
it.  However, never lose fact of the sight that what MS is doing is to
change the ENTIRE application architecture landscape.  The browser's
interface with, for lack of a better term, the webservices - is
ultimately limited to the short term.  *IF* .Net takes off, focusing on
a browser specific strategy will sink dotGNU as we will not be able to
move quickly into an application compatibility phase.  It also opens up
points where using another proprietary API could cause us problems (such
as the slamming situation).  Finally, if we focus on the browser plugins
and .Net doesn't take off, then our work may be finished and worthless
because it won't generalize to other situations.  This is where the
platform is so valuable.

Third, arguing that we should proprietize or otherwise restrict the spec
will cause us major problems down the line - at no benefit whatsoever. 
What you've said is akin to saying "If people never see the source code,
then they can't crack systems because they can't find holes."  It's not
the case at all.  If we focus on leveraging our political goals through
obfuscation of information, then we have already lost this battle. 
Slamming is an action.  If Microsoft doesn't have access to the spec,
they would figure it out some other way.  Our spec will be transparent
through our source code anyway, so closing the spec is useless. 
Limiting behavior based on the spec is precisely what I hate about where
Microsoft is going.  It would be an interesting end-run to try that
tactic against them, but I think that if Microsoft is willing to Slam
consumers, they're willing to try to find a way around our licensed
spec.

Fourth, isn't slamming essentially illegal?  I think that Microsoft
doing something like this would - at worst for them be illegal, at best
a PR nightmare.  I just happen to think that we have other channels of
fighting this rather than violating our own ethical consistency.

        -Barry


reply via email to

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