Clarification

Discussion in 'Java' started by Ravi Shankar, Sep 20, 2005.

  1. Ravi Shankar

    Ravi Shankar Guest

    Dear all,

    Assume that I have an application called "Generator", which generates some
    output format, not necessarily XML. The output generated is going to be used
    by the customer for uploading to a server. I cant change any part of the
    application used by the customer, for example I cannot plugin an adapter of
    decrypter etc in the file upload program used by the customer.

    A strange requirement:- how can I make sure that the customer is using the
    output generated from my application only for uploading to the server, but
    the customer is not using for sending to another application or customer is
    not sending as attachment through SMTP, or FTP etc etc ?

    The purpose is that when I sell my Genrator tool, I want the customer to use
    that tool only for the intended purpose of uploading to a server, and not
    for anything else. How can I prevent from happening programmatically? If any
    veterans there had seen such a scenario, please advise, thanks

    Note that I cannot encrypt the output generated and decrypt later when the
    client is uploading, since, I can't control or change any part of the
    application used by the customer, thanks

    Best regards,
    Ravi
     
    Ravi Shankar, Sep 20, 2005
    #1
    1. Advertising

  2. Ravi Shankar

    Chris Uppal Guest

    Ravi Shankar wrote:

    > Assume that I have an application called "Generator", which generates some
    > output format, not necessarily XML.
    > [...]
    > Note that I cannot encrypt the output generated and decrypt later when the
    > client is uploading, since, I can't control or change any part of the
    > application used by the customer, thanks


    Do you mean that you can't control how the customer does the upload, or do you
    mean that the "generator" program itself is not in your control ?

    If the generator program is under your control then why not just generate
    encrypted output (encrypted with a public key) that you will then decrypt on
    your server (using the corresponding private key). Of course, a reasonably
    ingenious customer will still be able to circumvent the restiction.

    If the generator program itself is not under your control then I don't think
    there's any way you can even get close to what you are asking for. You'll just
    have to trust your customers.

    -- chris
     
    Chris Uppal, Sep 20, 2005
    #2
    1. Advertising

  3. One rude way to do this is to allow the clients to run the Generator on
    your server via terminal services. Then lock down the terminal and strip
    it for any means of sending the output anywhere else.

    What kind of app is the Generator? If its a small utility you could wrap
    it in a webservice and allow clients access to the service only. If its
    a full client app i think terminalserver is the best bet i can think of.

    Karl Øie


    Ravi Shankar wrote:

    > Dear all,
    >
    > Assume that I have an application called "Generator", which generates some
    > output format, not necessarily XML. The output generated is going to be used
    > by the customer for uploading to a server. I cant change any part of the
    > application used by the customer, for example I cannot plugin an adapter of
    > decrypter etc in the file upload program used by the customer.
    >
    > A strange requirement:- how can I make sure that the customer is using the
    > output generated from my application only for uploading to the server, but
    > the customer is not using for sending to another application or customer is
    > not sending as attachment through SMTP, or FTP etc etc ?
    >
    > The purpose is that when I sell my Genrator tool, I want the customer to use
    > that tool only for the intended purpose of uploading to a server, and not
    > for anything else. How can I prevent from happening programmatically? If any
    > veterans there had seen such a scenario, please advise, thanks
    >
    > Note that I cannot encrypt the output generated and decrypt later when the
    > client is uploading, since, I can't control or change any part of the
    > application used by the customer, thanks
    >
    > Best regards,
    > Ravi
    >
    >
     
    =?ISO-8859-1?Q?Karl_=D8ie?=, Sep 20, 2005
    #3
  4. Ravi Shankar

    Oliver Wong Guest

    "Ravi Shankar" <> wrote in message
    news:dgp48l$4k9$...
    > Assume that I have an application called "Generator", which generates some
    > output format, not necessarily XML. The output generated is going to be
    > used by the customer for uploading to a server. I cant change any part of
    > the application used by the customer, for example I cannot plugin an
    > adapter of decrypter etc in the file upload program used by the customer.
    >
    > A strange requirement:- how can I make sure that the customer is using the
    > output generated from my application only for uploading to the server, but
    > the customer is not using for sending to another application or customer
    > is not sending as attachment through SMTP, or FTP etc etc ?
    >
    > The purpose is that when I sell my Genrator tool, I want the customer to
    > use that tool only for the intended purpose of uploading to a server, and
    > not for anything else. How can I prevent from happening programmatically?
    > If any veterans there had seen such a scenario, please advise, thanks
    >
    > Note that I cannot encrypt the output generated and decrypt later when the
    > client is uploading, since, I can't control or change any part of the
    > application used by the customer, thanks


    I'm not sure I understand: You CANNOT modify any of the source code of
    Generator, and yet you want to behaviour of Generator to differ from its
    current behaviour?

    - Oliver
     
    Oliver Wong, Sep 20, 2005
    #4
  5. Ravi Shankar

    Roedy Green Guest

    On Tue, 20 Sep 2005 21:53:25 +0800, "Ravi Shankar"
    <> wrote or quoted :

    >The purpose is that when I sell my Genrator tool, I want the customer to use
    >that tool only for the intended purpose of uploading to a server, and not
    >for anything else. How can I prevent from happening programmatically? If any
    >veterans there had seen such a scenario, please advise, thanks


    If the server is not yours, then of course the customer can do
    whatever he wants with the uploaded data.

    Uploaded data may go through a proxy or a router. There is nothing to
    stop such an intermediate beast from taking a copy selectively of
    whatever flows through.

    TCP/IP was designed to make it easy to insert various processes en
    route.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 20, 2005
    #5
  6. Ravi Shankar

    Wibble Guest

    Roedy Green wrote:
    > On Tue, 20 Sep 2005 21:53:25 +0800, "Ravi Shankar"
    > <> wrote or quoted :
    >
    >
    >>The purpose is that when I sell my Genrator tool, I want the customer to use
    >>that tool only for the intended purpose of uploading to a server, and not
    >>for anything else. How can I prevent from happening programmatically? If any
    >>veterans there had seen such a scenario, please advise, thanks

    >
    >
    > If the server is not yours, then of course the customer can do
    > whatever he wants with the uploaded data.
    >
    > Uploaded data may go through a proxy or a router. There is nothing to
    > stop such an intermediate beast from taking a copy selectively of
    > whatever flows through.
    >
    > TCP/IP was designed to make it easy to insert various processes en
    > route.

    It sounds like you may need a legal solution, not a technical one.
     
    Wibble, Sep 21, 2005
    #6
  7. Ravi Shankar

    Ravi Shankar Guest

    HI all,

    Thanks a lot for your answers. Just to clarify, Generator is the application
    I am writing, hence I have full control on that.

    Thanks and regards,
    Ravi

    "Roedy Green" <> wrote in message
    news:...
    > On Tue, 20 Sep 2005 21:53:25 +0800, "Ravi Shankar"
    > <> wrote or quoted :
    >
    >>The purpose is that when I sell my Genrator tool, I want the customer to
    >>use
    >>that tool only for the intended purpose of uploading to a server, and not
    >>for anything else. How can I prevent from happening programmatically? If
    >>any
    >>veterans there had seen such a scenario, please advise, thanks

    >
    > If the server is not yours, then of course the customer can do
    > whatever he wants with the uploaded data.
    >
    > Uploaded data may go through a proxy or a router. There is nothing to
    > stop such an intermediate beast from taking a copy selectively of
    > whatever flows through.
    >
    > TCP/IP was designed to make it easy to insert various processes en
    > route.
    > --
    > Canadian Mind Products, Roedy Green.
    > http://mindprod.com Again taking new Java programming contracts.
     
    Ravi Shankar, Sep 21, 2005
    #7
  8. Ravi Shankar

    Chris Smith Guest

    Ravi Shankar <> wrote:
    > Thanks a lot for your answers. Just to clarify, Generator is the application
    > I am writing, hence I have full control on that.


    So, let's get this straight. Correct me if I'm wrong about this.
    FIRST, the user will run Generator (your code) and create an XML file.
    SECOND, the user will upload that XML file using something other than
    Generator. Is that right?

    Now, do you control the server? If so, then read Chris Uppal's
    response. The answer isn't perfect, but it at least protects you from
    users without the skill or determination to reverse engineer and modify
    the code of the Generator application.

    If you don't control the server, then give up on technical answers. You
    can't generate a file and then indefinitely keep watch over what happens
    with the future of that file. And I'm glad that you can't. If and when
    the insidious "trusted computing" architectures come around, you might
    be able to do this... but I and many others are fighting to be sure that
    day never comes.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Sep 22, 2005
    #8
  9. Ravi Shankar

    Oliver Wong Guest

    "Chris Smith" <> wrote in message
    news:...
    > Ravi Shankar <> wrote:
    >> Thanks a lot for your answers. Just to clarify, Generator is the
    >> application
    >> I am writing, hence I have full control on that.

    >
    > So, let's get this straight. Correct me if I'm wrong about this.
    > FIRST, the user will run Generator (your code) and create an XML file.
    > SECOND, the user will upload that XML file using something other than
    > Generator. Is that right?


    At this point, the OP is already screwed. If the user uploads that XML
    file using something not under the OP's control, then there's nothing to
    stop the user from sending that XML as an e-mail attachment to all his/her
    friends.

    - Oliver
     
    Oliver Wong, Sep 22, 2005
    #9
  10. Ravi Shankar

    Chris Smith Guest

    Oliver Wong <> wrote:
    > > So, let's get this straight. Correct me if I'm wrong about this.
    > > FIRST, the user will run Generator (your code) and create an XML file.
    > > SECOND, the user will upload that XML file using something other than
    > > Generator. Is that right?

    >
    > At this point, the OP is already screwed. If the user uploads that XML
    > file using something not under the OP's control, then there's nothing to
    > stop the user from sending that XML as an e-mail attachment to all his/her
    > friends.


    Yes, I think you're right. If the OP is in charge of the server, then
    the file could be securely encrypted... but that would only prevent the
    file from being read by other people. It could still be shipped around
    without restriction. I missed that requirement in the original.

    (And, of course, the concerns about reverse-engineering the Generator
    app still apply... so the encryption could be circumvented.)

    One option that hasn't been mentioned here is to convert the Generator
    app into a web-based or client-server application with a trusted server.
    This could be made truly secure, if and ONLY if it's sufficient for the
    user to work with certain summary information that isn't security-
    sensitive, while the sensitive information could be associated with the
    document transparently by the server. Instead of "uploading" the file,
    the Generator web app would need an option to securely transmit the
    application to the "true" server (or, if it is the true server, to just
    do whatever needs to be done with the completed document). The
    sensitive data would never be in the hands of the user, so would never
    be at risk.

    Of course, that depends on a certain nature of data such that the
    sensitive information doesn't need to be directly seen by the user, and
    there is a non-sensitive view of the data that's sufficient for all user
    tasks. If that requirement isn't fulfilled, then you absolutely NEED to
    have some trust in the user with access to the data; otherwise, a secure
    is just plain impossible, even theoretically.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Sep 22, 2005
    #10
  11. Ravi Shankar

    Chris Uppal Guest

    Chris Smith wrote:

    > Yes, I think you're right. If the OP is in charge of the server, then
    > the file could be securely encrypted... but that would only prevent the
    > file from being read by other people. It could still be shipped around
    > without restriction.


    I'm finding it very difficult to imagine a scenario where this would be a
    problem (assuming that client-side execution is OK in the first place, of
    course).


    > Of course, that depends on a certain nature of data such that the
    > sensitive information doesn't need to be directly seen by the user, and
    > there is a non-sensitive view of the data that's sufficient for all user
    > tasks.


    But then, I'm also having difficulty imagining a (legitimate) scenario where an
    application running on a client's machine has access to data that the client
    should not, and would not, be able to share as freely as /they/ wish. (Crash
    dumps and similar, perhaps -- they might contain data that neither party would
    wish to see splashed around ?)

    -- chris
     
    Chris Uppal, Sep 23, 2005
    #11
  12. Ravi Shankar

    Ravi Shankar Guest

    Dear Chris,

    You had said it - I have implemented as a web based application. After
    translation, I had designed the third party application as one which will
    call a servlet for the translated file. When calling the servlet, I made
    configuration in web server such that only the calls from a particular IP
    are allowed, otherwise webserver will reject it.

    Webserver will be in DMZ of the company, app server behind a firewall. Calls
    cannot come to app server directly, hence no possibility to call servlet
    directly.

    Solved - Kudos to J2EE :)

    Thanks and regards,
    Ravi
    "Chris Smith" <> wrote in message
    news:...
    > Oliver Wong <> wrote:
    >> > So, let's get this straight. Correct me if I'm wrong about this.
    >> > FIRST, the user will run Generator (your code) and create an XML file.
    >> > SECOND, the user will upload that XML file using something other than
    >> > Generator. Is that right?

    >>
    >> At this point, the OP is already screwed. If the user uploads that
    >> XML
    >> file using something not under the OP's control, then there's nothing to
    >> stop the user from sending that XML as an e-mail attachment to all
    >> his/her
    >> friends.

    >
    > Yes, I think you're right. If the OP is in charge of the server, then
    > the file could be securely encrypted... but that would only prevent the
    > file from being read by other people. It could still be shipped around
    > without restriction. I missed that requirement in the original.
    >
    > (And, of course, the concerns about reverse-engineering the Generator
    > app still apply... so the encryption could be circumvented.)
    >
    > One option that hasn't been mentioned here is to convert the Generator
    > app into a web-based or client-server application with a trusted server.
    > This could be made truly secure, if and ONLY if it's sufficient for the
    > user to work with certain summary information that isn't security-
    > sensitive, while the sensitive information could be associated with the
    > document transparently by the server. Instead of "uploading" the file,
    > the Generator web app would need an option to securely transmit the
    > application to the "true" server (or, if it is the true server, to just
    > do whatever needs to be done with the completed document). The
    > sensitive data would never be in the hands of the user, so would never
    > be at risk.
    >
    > Of course, that depends on a certain nature of data such that the
    > sensitive information doesn't need to be directly seen by the user, and
    > there is a non-sensitive view of the data that's sufficient for all user
    > tasks. If that requirement isn't fulfilled, then you absolutely NEED to
    > have some trust in the user with access to the data; otherwise, a secure
    > is just plain impossible, even theoretically.
    >
    > --
    > www.designacourse.com
    > The Easiest Way To Train Anyone... Anywhere.
    >
    > Chris Smith - Lead Software Developer/Technical Trainer
    > MindIQ Corporation
     
    Ravi Shankar, Sep 23, 2005
    #12
  13. Ravi Shankar

    Oliver Wong Guest

    "Chris Uppal" <-THIS.org> wrote in message
    news:4333d033$0$38045$...
    > Chris Smith wrote:
    >
    >> Yes, I think you're right. If the OP is in charge of the server, then
    >> the file could be securely encrypted... but that would only prevent the
    >> file from being read by other people. It could still be shipped around
    >> without restriction.

    >
    > I'm finding it very difficult to imagine a scenario where this would be a
    > problem (assuming that client-side execution is OK in the first place, of
    > course).
    >
    >
    >> Of course, that depends on a certain nature of data such that the
    >> sensitive information doesn't need to be directly seen by the user, and
    >> there is a non-sensitive view of the data that's sufficient for all user
    >> tasks.

    >
    > But then, I'm also having difficulty imagining a (legitimate) scenario
    > where an
    > application running on a client's machine has access to data that the
    > client
    > should not, and would not, be able to share as freely as /they/ wish.
    > (Crash
    > dumps and similar, perhaps -- they might contain data that neither party
    > would
    > wish to see splashed around ?)


    DRM http://en.wikipedia.org/wiki/Digital_rights_management

    The client is paying $5 per month (or whatever) to listen to the latest
    pop music. But the client is only allowed to listen to the music data using
    your client. The client has no direct access to the music data, and the
    client is not allowed to e-mail a copy of the music data to his/her friends.
    Similarly for music videos, movies, video games, e-books, etc.

    - Oliver
     
    Oliver Wong, Sep 23, 2005
    #13
  14. Ravi Shankar

    Stefan Ram Guest

    "Oliver Wong" <> writes:
    >But the client is only allowed to listen to the music data using your client.


    The first occurence of the word "client" in the above sentence
    has another meaning than the final occurence of the wort
    "client". The first occurence might be replaced by "customer" or so.
     
    Stefan Ram, Sep 23, 2005
    #14
  15. Ravi Shankar

    Oliver Wong Guest

    "Stefan Ram" <-berlin.de> wrote in message
    news:-berlin.de...
    > "Oliver Wong" <> writes:
    >>But the client is only allowed to listen to the music data using your
    >>client.

    >
    > The first occurence of the word "client" in the above sentence
    > has another meaning than the final occurence of the wort
    > "client". The first occurence might be replaced by "customer" or so.


    Yes, sorry for the confusion. Here's the same paragraph with the term
    "Alice" and "your client" used in the proper locations.

    Alice is paying $5 per month (or whatever) to listen to the latest pop
    music. But Alice is only allowed to listen to the music data using your
    client. Alice has no direct access to the music data, and Alice is not
    allowed to e-mail a copy of the music data to her friends. Similarly for
    music videos, movies, video games, e-books, etc.

    - Oliver
     
    Oliver Wong, Sep 23, 2005
    #15
  16. Ravi Shankar

    Chris Smith Guest

    Chris Uppal <-THIS.org> wrote:
    > Chris Smith wrote:
    >
    > > Yes, I think you're right. If the OP is in charge of the server, then
    > > the file could be securely encrypted... but that would only prevent the
    > > file from being read by other people. It could still be shipped around
    > > without restriction.

    >
    > I'm finding it very difficult to imagine a scenario where this would be a
    > problem (assuming that client-side execution is OK in the first place, of
    > course).


    I don't know. But upon re-reading the OP, the requirement was clearly
    stated.

    > > Of course, that depends on a certain nature of data such that the
    > > sensitive information doesn't need to be directly seen by the user, and
    > > there is a non-sensitive view of the data that's sufficient for all user
    > > tasks.

    >
    > But then, I'm also having difficulty imagining a (legitimate) scenario where an
    > application running on a client's machine has access to data that the client
    > should not, and would not, be able to share as freely as /they/ wish. (Crash
    > dumps and similar, perhaps -- they might contain data that neither party would
    > wish to see splashed around ?)


    You're having trouble imagining this in principle? Or you think it's
    poor security to attempt it? I agree with the latter, but the former is
    actually rather simple.

    Let's hypothesize that I'm writing a gambling program. It's almost
    certainly true that there are some bits of information that the user is
    allowed to see, and some bits that the user is not allowed to see.
    Furthermore, there is a fairly complex set of rules and conditions under
    which information is constantly transitioning from secret to known, in
    return for which the user has made certain committed actions.

    Of course, actually implementing this as a client-side application would
    only be reasonable if the degree of security required is lower than the
    effort needed to cheat... which is why practically all gambling web
    sites are web apps, and the remainder are client-server applications.
    You'll never see a gambling site in which you play by downloading and
    playing games completely offline and then uploading the results. That
    doesn't mean the requirement is false; rather, it means that the
    security is lacking.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, Sep 23, 2005
    #16
  17. Ravi Shankar

    Chris Uppal Guest

    Oliver Wong wrote:

    > > [me:]
    > > But then, I'm also having difficulty imagining a (legitimate) scenario
    > > where an
    > > application running on a client's machine has access to data that the
    > > client
    > > should not, and would not, be able to share as freely as /they/ wish.
    > > (Crash
    > > dumps and similar, perhaps -- they might contain data that neither party
    > > would
    > > wish to see splashed around ?)

    >
    > DRM [...]


    Yes that would cover the case as I described it, but not the case that I was
    actually meaning ;-) There there is the additional constraint that the client
    will (or must) upload the data to my server rather than the other way around.

    Still, possibly a variation on that idea is plausible. If I am in the business
    of sellling (say) DRMed music for downlaod by other people (who are in a sense
    customers of both myself and the actual artists). And if my part of the deal
    is two-fold -- I provide a distrubution service for the artists (in return for
    a cut of the sales), /and/ I provide recording/packaging/editing software for
    the musicians to use that I feel is good enough to be be worth real money to an
    artist who was using a different distributer (but am providing it at cur-price
    to my "own" artists); then I would have an incentive to lock the cut-price
    version of my software to my own distribution service.

    -- chris
     
    Chris Uppal, Sep 23, 2005
    #17
  18. Ravi Shankar

    Oliver Wong Guest

    "Chris Uppal" <-THIS.org> wrote in message
    news:433433d7$0$38037$...
    > Still, possibly a variation on that idea is plausible. If I am in the
    > business
    > of sellling (say) DRMed music for downlaod by other people (who are in a
    > sense
    > customers of both myself and the actual artists). And if my part of the
    > deal
    > is two-fold -- I provide a distrubution service for the artists (in return
    > for
    > a cut of the sales), /and/ I provide recording/packaging/editing software
    > for
    > the musicians to use that I feel is good enough to be be worth real money
    > to an
    > artist who was using a different distributer (but am providing it at
    > cur-price
    > to my "own" artists); then I would have an incentive to lock the cut-price
    > version of my software to my own distribution service.


    Yes, although for music it seems not too realistic. Here's the same idea
    applied to videogames:

    Distribute software, not for creating music, but for creating simple
    games. Bundle along assets (e.g. 3D models, 2D sprites, music, sound
    effects, etc.). Almost every kid who has played around with a computer has
    dreamed of making their own computer game. Make their dream a reality by
    giving out this software for free, and letting them design games to be
    uploaded to your centralized server, and you then let others download and
    play the game for a small fee. You take a cut of the fee, and send the rest
    to the person who created the game.

    You'd want to restrict the games created by your software to only be
    playable from your distribution service because of the licensing terms of
    the assets. (i.e. you probably had to hire artists and musicians
    specifically for this project, and you so you don't want to just give away
    their creative artwork for use in games if you're not gonna make a profit
    from those games).

    - Oliver
     
    Oliver Wong, Sep 23, 2005
    #18
  19. Ravi Shankar

    Roedy Green Guest

    On Fri, 23 Sep 2005 15:30:25 GMT, "Oliver Wong" <>
    wrote or quoted :

    > The client is paying $5 per month (or whatever) to listen to the latest
    >pop music. But the client is only allowed to listen to the music data using
    >your client. The client has no direct access to the music data, and the
    >client is not allowed to e-mail a copy of the music data to his/her friends.
    >Similarly for music videos, movies, video games, e-books, etc.


    The key there is to keep changing the client code and its encryption.
    Then hackers have a moving target. see
    http://mindprod.com/jgloss/obfuscator.html for tips on psychological
    warfare against those who would defang your client.

    Never leave plaintext on disk, even in a temporary file. If ram is a
    problem, consider a task that decrypts and leaves behind a chunk
    mildly encrypted e.g. xor with some pseudorandom pattern that you can
    rapidly convert back to plaintext. You would staledate your
    downloads so the freshness date is embedded in them. Your own player
    would refuse to play them after a certain amount of time unless the
    licence were renewed.

    If feasible, require a new key every time the song is played. You
    destroy the file as you go, so it will only work with a new
    yet-unrevealed key.

    At some point the song gets turned to analog. There is no way you can
    stop recording of that signal.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 23, 2005
    #19
  20. Ravi Shankar

    Roedy Green Guest

    On Fri, 23 Sep 2005 18:04:31 GMT, "Oliver Wong" <>
    wrote or quoted :

    > You'd want to restrict the games created by your software to only be
    >playable from your distribution service because of the licensing terms of
    >the assets. (i.e. you probably had to hire artists and musicians
    >specifically for this project, and you so you don't want to just give away
    >their creative artwork for use in games if you're not gonna make a profit
    >from those games).


    that is a much harder problem. First a hacker can totally ignore your
    upload program and go straight for the raw data files.
    He has the code that made them. So he can decipher their format.

    Your main defense is to keep changing the file format and sending out
    compulsory JAWS updates that rearrange the files. Only the latest
    version of the client software is permitted to talk to your server.

    Your legit end users need have no awareness this is happening.

    If hackers get to be a problem, your software can start doing sanity
    checks, verifying the byte code with the server doing random "drug"
    tests. the hackers have counter measures, but if you keep changing
    things just a little bit, you can keep breaking their code and wear
    them down psychologically.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 23, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nikos Mitas
    Replies:
    2
    Views:
    1,066
    Hubble
    Sep 27, 2005
  2. ss

    One Clarification

    ss, Aug 19, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    324
    Kevin Spencer
    Aug 19, 2003
  3. Ken Cox [Microsoft MVP]

    Database Connection clarification

    Ken Cox [Microsoft MVP], Nov 26, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    353
    Jon Booth
    Nov 26, 2003
  4. Alex Agranov

    Tabstrip clarification

    Alex Agranov, Jan 20, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    321
    Alex Agranov
    Jan 20, 2004
  5. Lerp

    Clarification Needed

    Lerp, Aug 17, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    347
    Edd Connolly
    Aug 18, 2004
Loading...

Share This Page