Detect Visitor's Town and Country

[Victor]

Reverse DNS gets you whatever is entered in the in-addr.arpa reverse
domain for the zone. It may be an indicator of location, it may not.

Now, how do you get my country and town when I dial into a Canadian
ISP from here in the US?

Like I wrote, I get the location of the Canadian ISP connection (duh), which
is exactly what I was telling you when I wrote that you get "the user's
internet connection to the ISP". Do you need me to explain that more fully
to you?

 

[Victor]

Victor wrote on 12 apr 2005 in microsoft.public.inetserver.asp.general:

Victor wrote on 11 apr 2005 in
microsoft.public.inetserver.asp.general:


Victor wrote on 11 apr 2005 in
[..]
Victor wrote on 11 apr 2005 in

This is for a password security system, to prevent re-use of
passwords issued to corporate accounts. So, asking the user
kinda defeats the security, don't you think?

You seem to have a strange sense of security,
trusting a virtual component like that.

you seemd to be pretty narrow minded, thinking that I don't have
other methods of security.


Narrow minded??

Yes, because you are looking at the problem from a very narrow minded
perspective. Like all components, and all programming, there needs to
be error-checking in case the component doesn't provide the required
functionality.

Do you understand the concept of error-checking?

You are both insulting and bringning in new unmentioned points that have
nothing to do with your OQ.

Well, you kind of prove my point with the above post. You are more concerned
with an extremely narrow-minded examination of the language I use (troll
mentality?) than taking a broad-minded view of looking at what exactly is
the problem and how can it be solved in a FLEXIBLE and ADAPTABLE programming
environment.

You were asking about localisation by IP, which we answered.
Then you said you you wanted it for security, which we answered.
Then you said I was narrow minded,
because I did not know that you would not depend on that security, which
I answered. Now you say we should not warn you because we schould know
you would depend on error checking anyway, which concwept I would have
to know, but that you did not introduce before.

Exactly my point - you are taking an extremely narrow minded view of the
details, and ignoring the philosphy of the problem.

Let me explain error-checking to you - you take a component (like the one
discussed) and you ask yourself

1. Under what circumstances will this component perform as expected
This takes into account the component performing as documented, and also
user compliance with the component's intended functionality in the system.
2. Under what circumstances will the component NOT perform as expected
This takes into account the component NOT performing as documented
(including malfunctioning or being unavailable), and also the user's
behavior that is NOT compliant with the component's functionality in the
system (including user error and user deliberately defeating the intended
functiionality of the component).

These are the basic assumptions I make when error checking. Of course, on
the one extreme there is no error checking, on the other extreme you are
error checking for statistically insignificant errors. A good programmer
finds that happy median in the middle. It's a zen thing.

YOU are making the assumption that, for this component to be useful based
upon a narrow interpretation of what I wrote, that there is no error
checking, and that this is the ONLY method of security and that the
component must always provide the user's location consistantly and that its
INTENDED purpose is never defeated by the user.

*I* make the assumption that both #1 and #2 must be addressed, and that this
is inherent in the use of any component. You, on the other hand, make as
narrow-minded an interpretation of what I've written as you can so that you
can feel better about yourself as a programmer.

You better not be my programmer.

You would never be a member of one of my programming teams. You are not
concerend with end-result.

I have had enough of this.

That much is clear.

 

[Victor]

:

Okay, so now your security relies on an ISP entering information into
a PTR record that you can refer to, then possibly adapt in some other

No, I'm saying that ONE aspect of my security uses this. My security does
not RELY on this.

 

[Victor]

I find this discussion amusing, since my desktop would be an abomination

Isn't that a line from a Dilbert cartoon? "The unspeakable abominations from
my desktop..."

 

[Jeff Cochran]

:

No, I'm saying that ONE aspect of my security uses this. My security does
not RELY on this.

I'm still puzzling how it could even be a part of a security test,
since it is so highly inaccurate and depends on information you can't
guarantee is correct. Let's say I edit my PTR records to point to the
town you expect the person I'm impersonating to be from, does that
improve my chances of bypassing your security?

I equate this with a security guard at a bank. Since many bank
employees wear white shirts, is there any realistic reason the guard
should use a white shirt as an indicator of access level? There will
likely be non-employees wearing white shirts, there may be employees
wearing colored shirts and there is nothing to prevent the bank robber
from wearing a white shirt.

Jeff

 

[Jeff Cochran]

Like I wrote, I get the location of the Canadian ISP connection (duh), which
is exactly what I was telling you when I wrote that you get "the user's
internet connection to the ISP". Do you need me to explain that more fully
to you?

I understand you, and your explanation. What I don't understand is
how the Canadian ISP location I dialed into equates in any way to
identifying me or my security access, since I only dialed the Canadian
number because my US ISP was busy for two hours straight.

Jeff

 

[Aaron [SQL Server MVP]]

Do you need me to explain that more fully to you?

Hard to explain anything from a killfile. *plonk*

 

[Victor]

I understand you, and your explanation. What I don't understand is
how the Canadian ISP location I dialed into equates in any way to
identifying me or my security access, since I only dialed the Canadian
number because my US ISP was busy for two hours straight.

For the situation you mention above... hmmm... O.K., I guess I'll have to
handle it by tracking some users with a persistent cookie.

in pseudoCode,

' So, when the user logs in the very first time,
IF GeoBytesLocation <> "undefined", and other security stuff is valid,
THEN set persistant cookie and record browser ID
END IF

'On subsequent login,

IF the GeoBytesLocation is within xxx miles, and other security stuff is
valid,
THEN it's O.K., and set cookie
Log them in
ELSE 'it's outside of xxx miles
check if it's been X hours since login 'maybe they're travelling?
check if "Proxy Network" '(AOL, MSN, etc)
check for cookie
do other non-geographic security stuff
make decision if it's O.K.
END IF

This is going to depend upon other stuff as well, since some users delete
all their cookies on a regular basis.

 

[Victor]

I'm still puzzling how it could even be a part of a security test,
since it is so highly inaccurate and depends on information you can't
guarantee is correct. Let's say I edit my PTR records to point to the
town you expect the person I'm impersonating to be from, does that
improve my chances of bypassing your security?

I equate this with a security guard at a bank. Since many bank
employees wear white shirts, is there any realistic reason the guard
should use a white shirt as an indicator of access level? There will
likely be non-employees wearing white shirts, there may be employees
wearing colored shirts and there is nothing to prevent the bank robber
from wearing a white shirt.

These are good questions. From what I can see from GeoBytes, there's a
variable that gives you a percent of certainty of the location. For example,
if I access using Comcast Cable, or Verizon DSL, it will give me a location
with a certainty of 98%. If I access using AOL, it may give me a certainty
of 20%. An AT&T dialup might give me a certainty of 85% for the dialup
location while also setting one of the proxy bits telling me that could have
dialed up from anywhere in the world to that location.

The real issue for me is properly coding in the LOGIC to take this stuff
into account (by considering the objections I'm reading here).