Hi rprosser-ga,
Thank you for your question. I am a Web Developer myself, and have
built many Web applications on the ASP (Application Service Provider)
model. I would like to offer my advice in finding a solution to your
situation.
I believe that your question can be answered in two parts :
(1) Whether or not these application services that you provide can be
securely made available to the client as an online account without
requiring installation on the client's machine, thereby freeing you
from the requirement for such a capability from your Web hosting
provider.
(2) Whether or not search engines "blacklist" IP addresses or URLs,
and their criteria for this blacklisting.
+=====================================================================================+
In answer to part (1), the answer is, yes! You do not need this
"specialized" Web hosting provider that will enable software
installations because you can run these ASP.NET and PHP programs as
services for your users, and all the aspects involved - secure account
login and online application services - are handled as part of your
application. To give you an example, think of Monster.com. As a job
seeker, the application service here is "to enable you to build a
resume, to have that resume available to recruiters, and to search for
jobs and apply online". All you need is to register, and log in with
your user name and password. This is just one example of an
application service, there are many such online services, you could
even offer a graphics editing program online, or a spreadsheet, or a
fax answering service, for example.
The magic behind account-based online application services is made
possible by the use of "session variables". Here is a definition of
the concept of "session" :
+----
session - a searchWebServices definition
http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci541649,00.html
"In telecommunication, a session is a series of interactions between
two communication end points that occur during the span of a single
connection. Typically, one end point requests a connection with
another specified end point and if that end point replies agreeing to
the connection, the end points take turns exchanging commands and data
("talking to each other"). The session begins when the connection is
established at both ends and terminates when the connection is ended."
+----
In the case of your online application, a session would begin with a
user logging in successfully, and end when the user logs out, or there
is no response from the user for more than X amount of time, also know
as the session timeout. All interactions during this session would be
"remembered" by the server using session variables. More permanent
data would be stored on the application's database. There can be more
than one session at a time, therefore there can be more than one
online user at a time. In this manner you can have multiple users
using the same application running off the Web host, but each one is a
unique instance (session), even though theoretically the software was
only "installed" once (on the Web host server). There is no need for
the user to install the application software on their computer, and
they can run the application online by logging in and establishing a
session.
Here are some script samples of user management using session
variables. The basic idea is that you would protect the "members only"
pages with a line of code that checks to see whether a client is
logged in, and if not, then prompt them for the login info. The
application service you are offering would run within this protected
area, and thus lock out other users :
+----
DevScripts - ASP.NET User Management Scripts, ASP.NET User Management
Code Snippets, ASP_NET User Management Code Samples
http://www.devscripts.com/category.php?stId=179
+----
DevScripts - PHP User Authentication Scripts, PHP User Authentication
Code Snippets, PHP User Authentication Code Samples
http://www.devscripts.com/category.php?stId=252
+----
Programmers Heaven - ASP - ASP.NET Zone - Sourcecode Articles : User
Management
http://www.programmersheaven.com/zone26/articles/article39.htm
+----
Simple ASP.Net Login
http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=561&lngWId=10
+----
Creating a Secure PHP Login Script : PHP
http://martin.f2o.org/php/login
+----
If you've never built session-based, account-based online applications
before, don't worry, it's not as complicated as it sounds. Try the
simpler scripts first and experiment with logging in / logging out.
You might like to also visit the following website, an excellent
resource for securing your Web applications :
+----
The Open Web Application Security Project
http://www.owasp.org/
"The Open Web Application Security Project (OWASP) is an Open Source
community project staffed entirely by volunteers from across the
world. The project is developing software tools and knowledge based
documentation that helps people secure web applications and web
services. Much of the work is driven by discussions on the Web
Application Security list at SecurityFocus.com. All software and
documentation is released under the GNU public licenses."
+----
Also, with regard to the "Pay and Go" aspect, these days it is very
easy to integrate with an online payment processing provider, such as
PayPal (www.paypal.com) which offers their Integrated Payment
Notification (IPN) service. This would be integrated with your
application, and your Web hosting provider would not be required to
set up anything (you as the developer build it). Visit PayPal for
technical documentation on how to do this. They have PHP and ASP
scripts ready to go. I have built such a "Pay and Go" service using
PayPal's Subscriptions. There are also other e-commerce providers, and
you can view the listing here :
://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&q=related:www.2checkout.com/
+=====================================================================================+
Now on to part (2) - unique IPs/URLs and the issue of "blacklisting".
In a nutshell, this is a non-issue if you are merely offering
application services online that do not involve Web page building. The
issue of blacklisting (or greylisting, where a site is ranked poorly)
only applies to Websites that try to trick (spam) search engines. Here
is a definition :
+----
Optimisation - Search engine spam
http://www.4everweb.com/search_engine_spam.htm
"A search engine spammer is generally a person who is using unfair
techniques in order to better their own or a clients website within
the search results. The spammer is generally aware that the content
that they are promoting is less useful to the end user than they would
like. Because of this, they try to use methods that will make the
website appear above more relevant websites in the search engine
listings."
+----
If your online application does not result in new Web pages being
added to the Internet and made available for indexing by search
engines, then you don't have to worry about this. For instance, if you
are offering that online graphics editing program or spreadsheet, then
this is a non-issue.
Let's look at the factors that would cause a site to be blacklisted or
poorly ranked. Among them are mirroring, doorway pages, keyword
disguising, constant site submission (re-registering), and most
importantly, reciprocal links. Probably the most important measure of
a site's popularity (or lack thereof) can be determined using Google's
PageRank algorithm. Since Google is renowned as THE number 1 search
engine, lots of other websites refer to it to determine a site's
popularity. In other words, get popular on Google and you get popular
elsewhere. Get ranked poorly on Google and you'll probably be ranked
poorly elsewhere too.
Here is an excerpt from a good online article :
+----
Pagerank Explained. Google's PageRank and how to make the most of it
http://www.webworkshop.net/pagerank.html
[begin excerpt]
What is PageRank?
PageRank is a numeric value that represents how important a page is on
the web. Google figures that when one page links to another page, it
is effectively casting a vote for the other page. The more votes that
are cast for a page, the more important the page must be. Also, the
importance of the page that is casting the vote determines how
important the vote itself is. Google calculates a page's importance
from the votes cast for it. How important each vote is is taken into
account when a page's PageRank is calculated.
PageRank is Google's way of deciding a page's importance. It matters
because it is one of the factors that determines a page's ranking in
the search results. It isn't the only factor that Google uses to rank
pages, but it is an important one.
From here on in, we'll occassionally refer to PageRank as "PR".
Notes:
Not all links are counted by Google. For instance, they filter out
links from known link farms. Some links can cause a site to be
penalized by Google. They rightly figure that a site cannot control
which sites link to it, but it can control which sites it links to it.
For this reason, links into a site cannot harm the site, but links
from a site can be harmful if they link to penalized sites. So be
careful which sites you link to. If a site has PR0, it is usually a
penalty, and it would be unwise to link to it.
[end excerpt]
+----
Continuing with this logic, if your application allows users to
publish dynamic pages (say for instance
www.yoursite.com/UserXPublicArea/pages.htm) and a particular user does
all the "wrong" things, then it MAY count toward the "penalization" of
your site (www.yoursite.com) as a whole. I say MAY because Google's
PageRank also looks at individual pages and subdirectory structures,
not just sites as complete units, and therefore a site like
"www.yoursite.com/UserXPublicArea" may be ranked differently from
"www.yoursite.com" .
A quick way to determine the PageRank of a page is to have Google
Toolbar installed as a browser add-in ( http://toolbar.google.com/ )
and to visit the Web page. The PageRank will be displayed on the
Google Toolbar.
Let's do a case study. ZyWorld is a Web page builder application
service provider (www.zyworld.com). Here are the PageRanks of several
of their member sites :
http://www.zyworld.com/crayfordgreyhoundtrack/ (PageRank of 5/10)
http://www.zyworld.com/ExeterSouthernhay/Home.htm (PageRank of 4/10)
http://www.zyworld.com/sschiller/Home.htm (PageRank of 4/10)
http://www.zyworld.com/quickguides/home.htm (PageRank of 3/10)
http://www.zyworld.com (PageRank of 5/10)
http://www.zy.com (PageRank of 6/10)
Zy.com appears on Google's first page for the search term "free
webpage OR 'web page' builder". Notice in this case how two different
domains are used, zy.com and zyworld.com. One is used for the "front
face" of the provider, the other is used to house the member pages,
and they have their own respective rankings.
In conclusion, we can say that since Google ranks individual pages
accordingly, this should not be a big issue for you, but if you still
want to make sure that your "corporate" site is not "tainted" by "bad"
member pages, you can always use two separate domain names. We can
apply this generalization to all the other search engines out there
too, having used Google as our standard.
Also, it depends on what other functions your application service
performs. Will your application run a program or script that
participates in spamming activities, if so, then yes, this will be a
concern for a common (shared) IP address. For example, if your
application has a mailer that sends out mass emails via SMTP, and if
your clients misuse this, you will soon find your SMTP server
blacklisted. It all boils down to the type of functionality you have
available, and I believe that all this can be addressed by good
application design.
+=====================================================================================+
I hope this has been a helpful answer! I have tried my best to
understand your question, but if you feel that there are areas that
still need clarification or further research, please do not hesitate
to post a Request For Clarification and I will be glad to assist. You
have my committment to the solution you are looking for. Thank you for
using Google Answers.
Regards,
kyrie26-ga
+----
Google search terms :
asp.net login script
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=asp%2Enet+login+script+
asp.net "login script" OR "login scripts"
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=asp%2Enet+%22login+script%22+OR+%22login+scripts%22
asp.net user login
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=asp%2Enet+user+login
php "user management" OR login script OR scripts
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=php+%22user+management%22+OR+login+script+OR+scripts
search engine blacklist OR blacklisting
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=search+engine+blacklist+OR+blacklisting
google pagerank
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=google+pagerank
free webpage OR "web page" builder
://www.google.com/search?sourceid=navclient&ie=UTF-8&oe=UTF-8&q=free+webpage+OR+%22web+page%22+builder
+---- |
Clarification of Answer by
kyrie26-ga
on
30 Apr 2003 14:14 PDT
Hello again Richard,
Thanks for the article you provided. I was unable to get in through
your link because I don't have a subscription, but found the same
article through another link via Google News, at
http://www.nytimes.com/2003/04/29/technology/29SPAM.html?ex=1052280000&en=edd6db2e3c97b37c&ei=5062&partner=GOOGLE
.
I did an analysis of this article, and it is consistent with my
current knowledge and my posted answer to your question. I understand
your fears on this issue, and I wish to allay your fears, armed with
the objective truth.
Oh, before we get to that, I would like to suggest that you use the
"Request For Clarification" feature instead of posting your responses
on the Comments section, because I get notified instantly and will be
able to respond to you much quicker.
First of all, here is a related article :
Internet Week Spam Spam Leads To High Costs For ISPs April 28, 2003
http://www.internetwk.com/breakingNews/showArticle.jhtml?articleID=9400084
Let's take a look at what happened in the US Moneywerx incident. The
way Internet service works is like a big tree. The government owns the
tree trunk. The main ISPs own the main branches. The smaller ISPs own
the smaller branches, and so on, until have small ISPs and resellers
in the picture. What happened was that someone "downstream" from US
Moneywerx, in this case NetGlobalMarketing, was accused of spamming,
and the ISP "upstream", Server Beach, decided to pull the plug on US
Moneywerx.
Now, whenever we talk about Internet services, we need to make a
distinction between email, Web, FTP, Telnet, and many other services
that make up the whole package. In this case, even though it was only
email (spam) that was involved, Server Beach pulled the plug on ALL
services including Web, which is why the 89 websites operated by US
Moneywerx were shut down.
Another important distinction to make : there are two possible
scenarios at work here :
1) NetGlobalMarketing purchased Internet services from US Moneywerx
which enabled them to run their own SMTP (email) server, which they
subsequently abused.
2) NetGlobalMarketing purchased a Web hosting account from US
Moneywerx, which includes a server-side application programming
language, which has automated email sending capability (Sendmail,
CFMAIL, etc.) via SMTP. They created a Web application that can send
out mass mail and either used this themselves, or made it available to
their Web account users, which was subsequently abused.
Now continuing on this thought, let's take a quick jump to your
question on why there is "a gap in the market". The reason is simple
enough. You have to own a branch to be able to give out the smaller
branches. You cannot give out branchlets off a branch that you don't
own. Therefore you can only assign "sub-IPs" to your customers,
clients or users, but not random "independent" IPs. Therefore you are
still responsible for anything that happens downstream.
Here's another jump, and another important distinction : whenever we
talk about software, we need to differentiate between :
1) Web-based software, which requires no installation, and runs on a
remote server, therefore using the remote server's IP address for any
network-related interactions. User accounts are managed using database
and session variables.
2) Desktop applications, which are installed on the user's computer,
and use the IP address of the user's ISP connection (e.g. AOL) to go
online on that computer.
Putting it all together, your role here would be similar to that of US
Moneywerx, hence your concern. Let's look at the above two scenarios
again :
1) Are you a reseller of Internet services (email, Web, FTP, etc.) who
will be providing your clients with their own SMTP (email) servers? I
don't think so, this doesn't apply to you.
2) Are you an Application Service Provider who provides a service to
your clients through a Web Application? If so, will you enable
server-side outgoing email capability? Here is an example - a user
logs on to his account on your website. They enter a whole bunch of
recipient email addresses on a web form, and compose the email, then
send it. Your application, on your server, then sends out this email.
This is possible BECAUSE YOU BUILT IT THAT WAY. If you do this, then
yes, as I mentioned before, it could get abused, and your server's IP
address could get blacklisted. Again, I maintain my stand, IT ALL
DEPENDS ON WHAT YOU MAKE AVAILABLE as part of your application
service.
Once, again, my answer remains the same! If you are concerned about
being blacklisted because of other "peer-level" users (i.e. NOT your
clients but rather, other customers of your ISP), then that is an
unavoidable risk. But if you are concerned about being blacklisted
because of your "downline", then that is a controllable risk - it all
depends on what kind of application service you are offering. You can
build your application so that there is ZERO RISK. To give you an
extreme example, a simple website that does not do anything except
serve up pure HTML. Such a website poses no risk because your users
can only view Web pages and nothing more. Now let's spice things up
with a server-side application. Now they can play games online. Or
submit their resume online. Or chat online. All still ZERO RISK. But
wait... now you're letting them send email online. Through your
server, your IP address. That's getting a little risky. Open it up and
let them send mass email! There you go! That's when all the problems
arise.
Here's another solution, if you're still intent on selling your users
applications that are truly "independent". You would build Desktop
Applications that they can download and install themselves. Whatever
network interactions these applications make, would be through the
client's own Internet connection, unrelated to your Web server. This
is not the same as a Web application, you would not be using PHP or
ASP.NET, but rather a desktop application programming language such as
Java or C++. But, in answer to your question, there is no such ISP
that will do the "installation and registration" part for you, because
it is simple enough for you to program your own e-commerce site where
you would make the software available for downloading only after the
customer has registered and paid, and logged in securely. Of course
that is another topic in itself.
However, I still maintain that Web Applications are the way to go, and
whatever risk you have to face is dependent on how you built your
application.
A very good example at hand is the Google Answers service. It is a Web
Application, and I, as a registered Researcher, am a user who logs
into my user account every time I answer a question. Notice that no
matter what I do, I cannot "cause spam" in the context that we are
talking about. Sure, if I decide to post low quality answers, that may
be considered "spamming" and cause me to lose my Researcher status,
but I cannot cause Google to be blacklisted due to my actions.
As a seasoned Web Developer I stand by my answer. However I would also
like to open this question up to the other Researchers if they would
like to add their opinions.
Thanks, and don't hesitate to Request For Clarification if still
needed! Have a great day.
Regards,
kyrie26-ga
|
