OpenSAML dependency on Velocity breaks application

[Tom van den Berge]

Hi,

I'm using the OpenSAML library to use single-sign-on in my web application. I noticed that OpenSAML has a dependency on Apache Velocity, and is initializing it when calling DefaultBootstrap.bootstrap(). 

The problem is that my web application also uses Velocity, and that Velocity is initialized in a static way; that is, it can be initialized only once per VM. The result is that OpenSAML "hijacks" Velocity, and the initialization performed by my web application is ignored, which effectively breaks my application! In other words, it looks like OpenSAML can't be used in applications that use Velocity.

I way quite surprised to learn that OpenSAML is using Velocity; for the purpose I'm using OpenSAML (generating AuthRequest and verifying Assertions), I can't really think of a reason to use Velocity. Maybe it is used by a specific part of the library that I don't use? Then, it would be highly recommended to make the dependency on Velocity optional. I don't think that is possible now?

Is there a way to use or configure OpenSAML in such a way that it doesn't conflict with my own Velocity configuration?

Many thanks,

Tom

--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

OpenSAML uses velocity for things like generating the body for the
SAML 1 and 2 POST bindings.  So, if all you're not using the binding
layer you don't need it.

To get rid of it, dump the dependency and create your own boostrap
class.  It's quite likely there are other things you can leave out too
(e.g., XACML support).

On Fri, Apr 27, 2012 at 04:05, Tom van den Berge
<[hidden email]> wrote:

> Hi,
>
> I'm using the OpenSAML library to use single-sign-on in my web application.
> I noticed that OpenSAML has a dependency on Apache Velocity, and is
> initializing it when calling DefaultBootstrap.bootstrap().
>
> The problem is that my web application also uses Velocity, and that Velocity
> is initialized in a static way; that is, it can be initialized only once per
> VM. The result is that OpenSAML "hijacks" Velocity, and the initialization
> performed by my web application is ignored, which effectively breaks my
> application! In other words, it looks like OpenSAML can't be used in
> applications that use Velocity.
>
> I way quite surprised to learn that OpenSAML is using Velocity; for the
> purpose I'm using OpenSAML (generating AuthRequest and verifying
> Assertions), I can't really think of a reason to use Velocity. Maybe it is
> used by a specific part of the library that I don't use? Then, it would be
> highly recommended to make the dependency on Velocity optional. I don't
> think that is possible now?
>
> Is there a way to use or configure OpenSAML in such a way that it doesn't
> conflict with my own Velocity configuration?
>
>
> Many thanks,
>
> Tom
>
> --
> To unsubscribe from this list send an email to
> [hidden email]

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

Thanks, that works. 

I think it would be far better to have this optional in OpenSAML itself though. Duplicating code is a major sin ;)

Tom

On Fri, Apr 27, 2012 at 11:47 AM, Chad La Joie <[hidden email]> wrote:

OpenSAML uses velocity for things like generating the body for the
SAML 1 and 2 POST bindings.  So, if all you're not using the binding
layer you don't need it.

To get rid of it, dump the dependency and create your own boostrap
class.  It's quite likely there are other things you can leave out too
(e.g., XACML support).

On Fri, Apr 27, 2012 at 04:05, Tom van den Berge
<[hidden email]> wrote:
> Hi,
>
> I'm using the OpenSAML library to use single-sign-on in my web application.
> I noticed that OpenSAML has a dependency on Apache Velocity, and is
> initializing it when calling DefaultBootstrap.bootstrap().
>
> The problem is that my web application also uses Velocity, and that Velocity
> is initialized in a static way; that is, it can be initialized only once per
> VM. The result is that OpenSAML "hijacks" Velocity, and the initialization
> performed by my web application is ignored, which effectively breaks my
> application! In other words, it looks like OpenSAML can't be used in
> applications that use Velocity.
>
> I way quite surprised to learn that OpenSAML is using Velocity; for the
> purpose I'm using OpenSAML (generating AuthRequest and verifying
> Assertions), I can't really think of a reason to use Velocity. Maybe it is
> used by a specific part of the library that I don't use? Then, it would be
> highly recommended to make the dependency on Velocity optional. I don't
> think that is possible now?
>
> Is there a way to use or configure OpenSAML in such a way that it doesn't
> conflict with my own Velocity configuration?
>
>
> Many thanks,
>
> Tom
>

> --
> To unsubscribe from this list send an email to
> [hidden email]



--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[Brent Putman]

On 4/27/12 7:25 AM, Tom van den Berge wrote:
>
> I think it would be far better to have this optional in OpenSAML
> itself though. Duplicating code is a major sin ;)
>

Note that you don't have to literally copy/duplicate code to do this.
You can just extend the DefaultBootstrap class and override the
initializeVelocity() method to be a no-op.  Then invoke that bootstrap
subclass instead of ours.

That said, I agree that it's not optimal for us to initialize Velocity
like that.  We probably can't fix this for v2, since we aren't planning
on anything but patch releases for that going forward.  But if you'd
like to file a Jira issue against v3, we can examine whether we can
rework how we use Velocity to avoid the static init.  It would actually
be more crucial to fix it there, because the custom bootstrap workaround
won't be there in v3, the library init there is very different.

Thanks,
Brent



--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

Hi Brent,

Unfortunately overriding initializeVelocity doesn't work since it is a static method, so the only option seems to be to override bootstrap() and leave out the initializeVelocity() method. Sadly, this also means that the static String[] xmlToolingsConfigs must be copied.

I fully agree that initially, this is a Velocity problem, since it seems that it can only be initializes in a static way. However the same is true for OpenSAML, although there is a relatively simple workaround for it.

Thanks,

Tom

On Fri, Apr 27, 2012 at 9:02 PM, Brent Putman <[hidden email]> wrote:

On 4/27/12 7:25 AM, Tom van den Berge wrote:
>
> I think it would be far better to have this optional in OpenSAML
> itself though. Duplicating code is a major sin ;)
>

Note that you don't have to literally copy/duplicate code to do this.
You can just extend the DefaultBootstrap class and override the
initializeVelocity() method to be a no-op.  Then invoke that bootstrap
subclass instead of ours.

That said, I agree that it's not optimal for us to initialize Velocity
like that.  We probably can't fix this for v2, since we aren't planning
on anything but patch releases for that going forward.  But if you'd
like to file a Jira issue against v3, we can examine whether we can
rework how we use Velocity to avoid the static init.  It would actually
be more crucial to fix it there, because the custom bootstrap workaround
won't be there in v3, the library init there is very different.

Thanks,
Brent

--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

Hi,

After doing some research, I found that there is a way to use multiple instances of Velocity. It's actually pretty simple. It is explained here: http://velocity.apache.org/engine/releases/velocity-1.7/developer-guide.html#separate

I couldn't find an easy way to set up a jira account to log this issue, so I hope that one of you can log this issue for v3.

Regards,

Tom

On Tue, May 1, 2012 at 12:00 PM, Tom van den Berge <[hidden email]> wrote:

Hi Brent,

Unfortunately overriding initializeVelocity doesn't work since it is a static method, so the only option seems to be to override bootstrap() and leave out the initializeVelocity() method. Sadly, this also means that the static String[] xmlToolingsConfigs must be copied.

I fully agree that initially, this is a Velocity problem, since it seems that it can only be initializes in a static way. However the same is true for OpenSAML, although there is a relatively simple workaround for it.

Thanks,

Tom

On Fri, Apr 27, 2012 at 9:02 PM, Brent Putman <[hidden email]> wrote:

On 4/27/12 7:25 AM, Tom van den Berge wrote:
>
> I think it would be far better to have this optional in OpenSAML
> itself though. Duplicating code is a major sin ;)
>

Note that you don't have to literally copy/duplicate code to do this.
You can just extend the DefaultBootstrap class and override the
initializeVelocity() method to be a no-op.  Then invoke that bootstrap
subclass instead of ours.

That said, I agree that it's not optimal for us to initialize Velocity
like that.  We probably can't fix this for v2, since we aren't planning
on anything but patch releases for that going forward.  But if you'd
like to file a Jira issue against v3, we can examine whether we can
rework how we use Velocity to avoid the static init.  It would actually
be more crucial to fix it there, because the custom bootstrap workaround
won't be there in v3, the library init there is very different.

Thanks,
Brent

--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

Click the "Log In" link.  Follow directions on screen.

On Tue, May 1, 2012 at 15:21, Tom van den Berge
<[hidden email]> wrote:
> I couldn't find an easy way to set up a jira account to log this issue, so I
> hope that one of you can log this issue for v3.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

I did. It forces me to select some educational organization, or "ProtectNetwork". The latter sends me to some other site where I need to sign up, which I kindly refuse. I hope you understand my reluctance to set an account.

Regards,

Tom

On Tue, May 1, 2012 at 9:27 PM, Chad La Joie <[hidden email]> wrote:

Click the "Log In" link.  Follow directions on screen.

On Tue, May 1, 2012 at 15:21, Tom van den Berge
<[hidden email]> wrote:
> I couldn't find an easy way to set up a jira account to log this issue, so I
> hope that one of you can log this issue for v3.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered

--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[Tom Scavo]

On Tue, May 1, 2012 at 3:42 PM, Tom van den Berge
<[hidden email]> wrote:
> It forces me to select some educational organization, or
> "ProtectNetwork". The latter sends me to some other site where I need to
> sign up, which I kindly refuse. I hope you understand my reluctance to set
> an account.

FWIW, I understand your dilemma. May I ask what you would prefer to
happen when you click the login link?

Thanks,
Tom
--
To unsubscribe from this list send an email to [hidden email]

[Brent Putman]

On 5/1/12 3:21 PM, Tom van den Berge wrote:
> Hi,
>
> After doing some research, I found that there is a way to use multiple
> instances of Velocity. It's actually pretty simple. It is explained
> here: http://velocity.apache.org/engine/releases/velocity-1.7/developer-guide.html#separate
>
>



You know, we actually already use injected instances of VelocityEngine
on the things that use Velocity templates.  We actually don't ever use
what they call there the "singleton model".  So to be honest, I'm not
actually sure why we are doing the global Velocity static init like
that. It might be that newly created VelocityEngine instances just
inherit the properties from the global Velocity singleton if they are
otherwise unspecified, so maybe that is the (not very good) reason.  If
that is the case, we can probably just get rid of the Velocity singleton
init entirely, and just make sure to move those properties into the
Velocity Engine instance that is used in the encoders by, for example,
the Shibboleth IdP.

I'll do some more research to confirm.  If accurate, I believe we might
be able to do that in a patch release, as it involves no interface
additions or changes.

Of course, not to point out the obvious, but I believe your app could
also do the same thing, and avoid being stepped on by the current
behavior of OpenSAML, by using the "separate instance model".  As a
short-term workaround.



>
> Unfortunately overriding initializeVelocity doesn't work since it is a
> static method, so the only option seems to be to override bootstrap()
> and leave out the initializeVelocity() method. Sadly, this also means
> that the static String[] xmlToolingsConfigs must be copied.


Yeah, you're right.  Java static methods can't be overridden.  I
probably knew this at one point and just forgot.  ;-)  I thought we were
doing this in a test bootstrap for our unit tests, but turns out it's
not really inheritance we were doing.  I was misremembering.


--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

On Wed, May 2, 2012 at 12:07 AM, Brent Putman <[hidden email]> wrote:

On 5/1/12 3:21 PM, Tom van den Berge wrote:
> Hi,
>
> After doing some research, I found that there is a way to use multiple
> instances of Velocity. It's actually pretty simple. It is explained
> here: http://velocity.apache.org/engine/releases/velocity-1.7/developer-guide.html#separate
>
>

You know, we actually already use injected instances of VelocityEngine
on the things that use Velocity templates.  We actually don't ever use
what they call there the "singleton model".  So to be honest, I'm not
actually sure why we are doing the global Velocity static init like
that.

You are using the singleton model in DefaultBootstrap: "Velocity.init();". Maybe you are using the separate instances model when you are using velocity templates, but not when initializing.

 

It might be that newly created VelocityEngine instances just
inherit the properties from the global Velocity singleton if they are
otherwise unspecified, so maybe that is the (not very good) reason.  If
that is the case, we can probably just get rid of the Velocity singleton
init entirely, and just make sure to move those properties into the
Velocity Engine instance that is used in the encoders by, for example,
the Shibboleth IdP.

 

I'm not sure what you mean with you last phrase, but that's probably because I'm not very familiar with OpenSAML. I would say if OpenSAML needs Velocity, it needs to take care of its own initialization, and obviously not break any application or library that is using OpenSAML. 

I'll do some more research to confirm.  If accurate, I believe we might
be able to do that in a patch release, as it involves no interface
additions or changes.

That would be great! 

Of course, not to point out the obvious, but I believe your app could
also do the same thing, and avoid being stepped on by the current
behavior of OpenSAML, by using the "separate instance model".  As a
short-term workaround.

That would definitely be an option. However, I already chose to overwrite DefaultBoostrap, and leave out the velocity initialization, since I dont' need it.

>
> Unfortunately overriding initializeVelocity doesn't work since it is a
> static method, so the only option seems to be to override bootstrap()
> and leave out the initializeVelocity() method. Sadly, this also means
> that the static String[] xmlToolingsConfigs must be copied.

Yeah, you're right.  Java static methods can't be overridden.  I
probably knew this at one point and just forgot.  ;-)  I thought we were
doing this in a test bootstrap for our unit tests, but turns out it's
not really inheritance we were doing.  I was misremembering.

--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

Normally, when I create an account for Jira for some company, I do exactly that: sign up for "Jira for company X".

I am not aware of the structure of your company, and therefore surprised to be able to choose from a range of educational institutions, or choose a very specific one if mine isn't listed... I think your login/signup procedure makes a number of assumptions that don't apply to me, or at least they are not clear to me.

Regards,

Tom

On Tue, May 1, 2012 at 11:52 PM, Tom Scavo <[hidden email]> wrote:

On Tue, May 1, 2012 at 3:42 PM, Tom van den Berge
<[hidden email]> wrote:
> It forces me to select some educational organization, or
> "ProtectNetwork". The latter sends me to some other site where I need to
> sign up, which I kindly refuse. I hope you understand my reluctance to set
> an account.

FWIW, I understand your dilemma. May I ask what you would prefer to
happen when you click the login link?

Thanks,
Tom

--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[Tom Scavo]

On Wed, May 2, 2012 at 3:38 AM, Tom van den Berge
<[hidden email]> wrote:
> Normally, when I create an account for Jira for some company, I do exactly
> that: sign up for "Jira for company X".

You mean a brand new username/password? So you aren't averse to
creating a new username/password for situations such as this?

> I am not aware of the structure of your company, and therefore surprised to
> be able to choose from a range of educational institutions, or choose a very
> specific one if mine isn't listed... I think your login/signup procedure
> makes a number of assumptions that don't apply to me, or at least they are
> not clear to me.

Understood. So if you had been prompted to log into jira with your
google account (or at least been offered that as an option), what
would have been your reaction?

Thanks,
Tom
--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

On Wed, May 2, 2012 at 12:59 PM, Tom Scavo <[hidden email]> wrote:

On Wed, May 2, 2012 at 3:38 AM, Tom van den Berge
<[hidden email]> wrote:
> Normally, when I create an account for Jira for some company, I do exactly
> that: sign up for "Jira for company X".

You mean a brand new username/password? So you aren't averse to
creating a new username/password for situations such as this?

Oh sure, not having to set up a new account for this kind situation would be highly appreciated!

 

> I am not aware of the structure of your company, and therefore surprised to
> be able to choose from a range of educational institutions, or choose a very
> specific one if mine isn't listed... I think your login/signup procedure
> makes a number of assumptions that don't apply to me, or at least they are
> not clear to me.

Understood. So if you had been prompted to log into jira with your
google account (or at least been offered that as an option), what
would have been your reaction?

That would be wonderful! As far as I'm concerned, this is how all Jira installations (and the like) worldwide should work. Nobody likes setting up incidental accounts everywhere.

Thanks,

Tom

 

Thanks,
Tom
--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

So your concern has nothing to do with security or privacy, just with
whatever effort is required to fill in the account creation form?

On Wed, May 2, 2012 at 7:14 AM, Tom van den Berge
<[hidden email]> wrote:
>> Understood. So if you had been prompted to log into jira with your
>> google account (or at least been offered that as an option), what
>> would have been your reaction?
>
>
> That would be wonderful! As far as I'm concerned, this is how all Jira
> installations (and the like) worldwide should work. Nobody likes setting up
> incidental accounts everywhere.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

Well, it's not anything to do with the project.  It's just the nature
of federated identity management (whether SAML, OpenID, or whatever
proprietary thing Google and Facebook are using today).

In that environment there are two things that can happen at login
time.  Either you have an account with an identity provider that is
accepted by the application you're attempting to login in to (the list
you see is all the ones we currently accept) or you don't.  If you
don't, then you need to create one.  In our case, ProtectedNetwork
happens to be an identity provider that allows anyone to register a
new account.

On Wed, May 2, 2012 at 3:38 AM, Tom van den Berge
<[hidden email]> wrote:
> I am not aware of the structure of your company, and therefore surprised to
> be able to choose from a range of educational institutions, or choose a very
> specific one if mine isn't listed... I think your login/signup procedure
> makes a number of assumptions that don't apply to me, or at least they are
> not clear to me.


--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

On Wed, May 2, 2012 at 1:43 PM, Chad La Joie <[hidden email]> wrote:

Well, it's not anything to do with the project.  It's just the nature
of federated identity management (whether SAML, OpenID, or whatever
proprietary thing Google and Facebook are using today).

In that environment there are two things that can happen at login
time.  Either you have an account with an identity provider that is
accepted by the application you're attempting to login in to (the list
you see is all the ones we currently accept) or you don't.  If you
don't, then you need to create one.  In our case, ProtectedNetwork
happens to be an identity provider that allows anyone to register a
new account.

The problem for me is in your last phrase. I don't know what or who ProtectedNetwork is. To me, the name already sounds like it's a scam ;)

I wouldn't want a party that I don't know or trust to manage my identity. So to answer your other question of it's matter of effort to fill out a form, or a matter of security/privacy: it's both.

Cheers,

Tom

 

On Wed, May 2, 2012 at 3:38 AM, Tom van den Berge
<[hidden email]> wrote:
> I am not aware of the structure of your company, and therefore surprised to
> be able to choose from a range of educational institutions, or choose a very
> specific one if mine isn't listed... I think your login/signup procedure
> makes a number of assumptions that don't apply to me, or at least they are
> not clear to me.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered

--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

On Wed, May 2, 2012 at 7:54 AM, Tom van den Berge
<[hidden email]> wrote:
> The problem for me is in your last phrase. I don't know what or who
> ProtectedNetwork is. To me, the name already sounds like it's a scam ;)

hehe, I'm sure the folks who run that service would love to hear that.

> I wouldn't want a party that I don't know or trust to manage my identity. So
> to answer your other question of it's matter of effort to fill out a form,
> or a matter of security/privacy: it's both.

Well, at this point, I think you'd be hard pressed to find anyone on
this project who thought Google provided anything like privacy.  But I
understand that some people feel differently.

If we had had an "open" IdP in the shibboleth.net domain, would that
have made you feel better?

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

[Tom van den Berge]

On Wed, May 2, 2012 at 2:03 PM, Chad La Joie <[hidden email]> wrote:

On Wed, May 2, 2012 at 7:54 AM, Tom van den Berge
<[hidden email]> wrote:
> The problem for me is in your last phrase. I don't know what or who
> ProtectedNetwork is. To me, the name already sounds like it's a scam ;)

hehe, I'm sure the folks who run that service would love to hear that.

My first thought when hearing this name is why do they emphasize that the network is protected? But maybe I'm too cynical...

 

> I wouldn't want a party that I don't know or trust to manage my identity. So
> to answer your other question of it's matter of effort to fill out a form,
> or a matter of security/privacy: it's both.

Well, at this point, I think you'd be hard pressed to find anyone on
this project who thought Google provided anything like privacy.  But I
understand that some people feel differently.

I fully agree. But it would allow me to avoid setting up yet another account. And having a Google account is more secure than having a Google account plus a ProtectNetwork account.

If we had had an "open" IdP in the shibboleth.net domain, would that
have made you feel better?

I'm not sure what you mean with an "open" IdP, but if that means that one would have to register with shibboleth.net, and it is branded as such, that would be fine. I haven't seen a Jira installation not doing it like this, so that is what surprised me on your site. 

What would you do if you wanted to raise an issue on my Jira, and I would let you set up an account with a seemingly unrelated company that you don't know?

Thanks,

Tom

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]

--
To unsubscribe from this list send an email to [hidden email]

[lajoie]

On Wed, May 2, 2012 at 8:28 AM, Tom van den Berge
<[hidden email]> wrote:
> I'm not sure what you mean with an "open" IdP, but if that means that one
> would have to register with shibboleth.net, and it is branded as such, that
> would be fine. I haven't seen a Jira installation not doing it like this, so
> that is what surprised me on your site.

Sorry, by "open" I meant that anyone would be able to create an
account (i.e., not just people in a particular organization).

Right, you don't see this much because Atlassian goes out of their way
to make sure their products can't be integrated with external
authentication systems.  The cynic in me notes that they sell a
separate product to sorta does this and so have a financial incentive
to ensure such integration is difficult in any of their other systems.

> What would you do if you wanted to raise an issue on my Jira, and I would
> let you set up an account with a seemingly unrelated company that you don't
> know?

Well, relationship clearly isn't the issue here.  You said you would
be fine using a Google account and there is no relationship between
them and your Jira.  The crux of the issue is really whether you trust
any given organization with some subset of your data.  I happen to be
okay with Google having a limited subset of my data so I'd be okay
using them for something like this.  If some one said I had to use
Facebook I'd tell them to go to hell because I don't trust that
organization at all.

So, to answer your specific question.  If your directions listed the
people your Jira instance accepted then I'd look for one that wasn't
on my blacklist of organizations (e.g., Facebook) and that didn't ask
for an unacceptable amount of data[1] and I'd use them.  If there was
no IdP left after my little mental filtering process then I wouldn't
create an account.

So, I understand your mental filtering process might exclude
ProtectNetwork.  And from what you said, a seemingly related domain
name and site appearance would be enough to allow a given IdP to make
it through that filtering process.  Which is good info for us.

While we're discussing this then, would it have mattered at all if
ProtectNetwork (or any other randomly selected IdP) had displayed our
logo, service name, and description on their page and stated you were
jumping through these hoops in order to work with our app?



[1] Incidentally, I think many people have a totally irrational view
of what is an acceptable set of data to provide to account bearing
organizations.  Anyone who thinks, for example, that asking for their
name, physical address, phone/fax/mobile number, or email address is
too much data doesn't understand that all that data is public data,
either by law (in the US) or in effect.

--
Chad La Joie
www.itumi.biz
trusted identities, delivered
--
To unsubscribe from this list send an email to [hidden email]