I have no knowledge of an industry standard, but I would record the exact time when the checked POST came in and the IP address that it came from. My natural inclination is to record the time when they downloaded the terms of service document along with when they "accepted", but I suspect that would most often just prove that they had not read the document. You could also check for an instance of identd at their IP and record its response but I doubt such would be useful frequently enough to be worth spending any time to implement it.

There may be other registration data that is worth recording separately. For example, you might have in the user record in the DB such information as "name", "e-mail", "phone", etc. It might be wise to have a "user registration" record in the DB that records some of these values at the time of registration. So updating my personal info updates my user record but my registration record still records key bits about the info I used to originally register. (Note that "normal form" practices probably encourage actually making these just separate fields in one table, if there is a 1-to-1 relationship between the two sets of data, despite my referring to them as separate "records".)

If there are any checks you use to prevent "funny business", then you should also record data about those. For example, if you use a CAPTCHA, then record the string the user entered to prove that they weren't a script. If you check the IP for things like country or against a list of banned IPs, then record something that demonstrates that this check was done (which country the IP appeared to be from or the address of the server used to check for banned IPs or the "last update" date for the DB of banned IPs, etc.). If you check the user agent string, then record it.

Given the current style of using JavaScript for nearly everything including things that gain no real benefit from JavaScript (and that are usually not done quite so well that they don't break some aspects of the UI and very often break my expectations and/or desires regarding the UI), you might be able to record whether they checked the "I agree" box via a mouse click or via keyboard navigation. Okay, now I'm just being too silly. Good luck.

- tye        

In reply to Re: Covering your posterior on "Terms & Conditions" checkboxes (data) by tye
in thread Covering your posterior on "Terms & Conditions" checkboxes by punch_card_don

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.