Agreeing to Terms and Conditions
Have you ever created a form with a checkbox on it which says something to the effect of "I agree to the terms and conditions"?
What did it do in the database? Did it just store a value of "1" in a field called "Agreed" or something like that?
For the second time now I've created such a form and was tempted not to store anything at all in the backend. What point can it prove anyway. Can a value of "1" or "Yes" in a field really stand up in court and act as a digital signature?
Surely the fact that they must have ticked it to get the form to submit (assuming there's checking to make sure it's ticked) means they must have agreed. It all seems like a bit of a grey area to me. Anybody know how this should work to make it a legit, legally-binding agreement?
Skip to the 
You can subscribe to an individual
Theoretically, if you're creating a signature document for each user and sign the document using their credentials when they save it, you've got a digital signature that is legally binding. In reality, I've never seen this challenged in court, so I don't have direct knowledge of whether it would be sufficient.
Here, we have something like this when we log into the computer. I know of a contractor that was fired because of looking at inappropriate material and it was questioned by the contract house if he was notified. But the terms and use agreement at the login screen was used to justify the dismissal.
I would guess it would be up to the company though if they tried to push something. Like Tim I've never heard of it being used but I guess if you used a cookie that required a variable to be set to "1" or something in order to view the site it would stand up if need be.
my thoughts...:)
"Surely the fact that they must have ticked it to get the form to submit (assuming there's checking to make sure it's ticked) means they must have agreed."
No, not necessarily.
"Anybody know how this should work to make it a legit, legally-binding agreement?"
Store the value. Reason being, that it could be challenged in court that they hacked the site to bypass the need for a ticked box. No matter how good you are at web security there is nothing like having a little extra protection to stop them wriggling out of it.
I only come to this as a side of designing and running a large e-commerce website that has a need for a legally binding contract, via-a-vis, the acceptance and use of credit cards for sales. And also from a purely subjective view point of hacking websites.
As Tim says, there is nothing like having a proper digital signature, however in the web world, such a thing doesn't really exist. Having user tick a box (or at least do something) to say they have complied, and seeing said value stored somewhere at least goes a long way to ensure that they have complied. Likewise you should also store as much extra information as possible... and not the information they have filled in. Log their IP address, browser agent strings, and virtually everything that they are sending across the connection to your box. Log it, store it, keep it safe. In cases where Joe User complains that it wasn't them that filled in the forms you can provide the necessary data to go to their ISP and say "Yes it was you". (The voice of Experience)
At one time, I asked my attorney about this. I found her answer fascinating.
She's a well respected partner at a prestigious firm, and she heads their intellectual property practice (or did at that time).
She said that with both web based click-through agreements, and even local software installations, there was a sort of "general agreement" that these things should be binding and should hold up, however she wasn't aware at that time of any case law on it. In essence, it had never been tested at all.
This was several years ago now, so who knows what's changed since then. I just found it interesting that this aspect of software development we spend so much time on may have no meaning at all.
Several years ago, I worked for a drug research company, in which digital signatures were a big topic for debate.
The FDA in the US was debating on whether or not to accept, as legally binding, an electronic signature. At that time, the FDA were just starting to get into the realm of forcing new drug applications to be sent in electronic format. (in 2001 or so).
In the end, the company I was at used the out of the box Domino digital signatures to sign documents and presumed that for them it was enough. However, it was not via the browser, it used the Notes private key/public key signature.
I'm not sure, as I have left that company, what was deemed legally binding by the FDA, but I'm sure that they must have something now. I believe in world health regulators, that if you can meet the FDA standards for legality, you will meet most other standards. If you google "fda 21 cfr part 11", it will have a lot of information on electronic signatures.
But that might be overkill.
Thanks for the topic, Jake, and thank you, Pamela, for the tip. I have a feeling as the global economy continues to writhe, we're going to hear of more people trying to wiggle out of website T&Cs to try to cheat out on monies owed or otherwise game the system.
SUMMARY
No, we don't use the check box.
THE WHOLE STORY, ILLUSTRATED
Here's a picture of the way I do it on this IEEE RFIC subcommittee paper submission system.
This is how it looks before it is signed.
http://screencast.com/t/9paISHODp
Here's how it looks after it is signed in the affirmative.
http://screencast.com/t/BYDELZSne
If you click on "I Decline" then you get this dialog:
http://screencast.com/t/0tryM2tpW
We've been using this for about five years after a huge fiasco requiring pages being removed from I-don't-know-how-many hundreds of printed digest before they were distributed.
However, this hasn't been tested in court as far as I know.
Peace,
Rob:-]
My non-legal opinion... I agree with Dragon about storing as much as possible.
My business opinion...
I would store the "1" value along with the date/time of submission as will as the version number of the Ts&Cs agreed to. Odds are the Ts&Cs will change and you'll want a record of who agreed to which version.
Having too much information just takes up storage, having too little... who knows.
-smak
I think the issue for the developer is could stand up and court and say you are confident the person clicked "I agree".
I have an app with an "I agree" box. I store the date/time, IP Address, and user name in a seperate DB. If it's binding is up for the business owners to worry about.
I mirror the same acconts of the person with the lawyer friend -- all I've heard is that the whole business of "click here if you agree" and "by purchasing this you agree to this EULA" is very shaky legal ground, at best, and has never been challenged properly anyways.
For instance -- how do you know that the user you "recorded" actually clicked the checkbox? How do you know it wasn't their child, or even their cat? :P
I know that from SOX/ICS controls in business software that it pretty much comes down to this:
- you are required to store the action (in this case, signing the agreement)
- you are required to store the date/time stamp of that action
- you are required to store the name of the biological person agreeing (thus not some functional account or anonymous id)
- sometimes you need to store the above for a minimum of x years
- you need to carefully consider who can access this data, and again they must be legal persons, not system entities.
SOX/ICS does not care how you store all these things, you just need to store it. even paper is fine.
The terms and conditions example is of course different from SOX, but then again, I think it is generally a set of practices that you see above.
In short, yes, definitely make the effort to store this, along with all the details and keep it safe.
@Ferdy,
"- sometimes you need to store the above for a minimum of x years"
Yup. UK Data Protection Law states 7 years.
Which brings the next question... how many databases have you got that are 7 years old? I have 1... my mail file.
@Pamela,
Part 11 went into effect in 1997 and covers electronic records and esigs. At is core, the reg is about attribution and record control; if a record can't be shown to be secure and/or audit-trailed to demonstrate it's edit history, then the record is no good. If you can deny attribution to a signature, then the eSig is invalid. You can use pretty much any system design you want as long as the records and eSigs are robust enough that the FDA can haul you into court.
We opted for a home built eSig system that explicitly meets all the Part 1
...sorry, hit the <submit> button by accident.
...meet all of the Part 11 requirements and the intent as expressed in the preamble.
For FDA regulated companies a checkbox, by itself, means nothing. An statement of intent combined with a valid eSig does have meaning.
I would think that the use of a checkbox or something more significant would be based on the situation/application. If you definitely want to hold someone accountable for a decision, a robust eSig would be required. Of course, IANAL and could be wrong.
I guess it depends on whether the page can be accessed without going through the proper navigation route. Sometimes badly designed applications ( obviously not yours ! ) allow people to go straight to a page if they are sent the url i.e. bypassing the terms
Recording the acceptance of the terms menas that you would not have to prove that there is no bypass mechanism by which the person could have accessed the record directly
Thanks All. Some interesting points there. I think I'll go with the "data dump" idea and store as much information about the user at that moment as possible.
That said, I'm intrigued by the "eSig" idea. What exactly does that involve?
Part 11 requires a number of things to be considered valid. I'll deal with the two bits that caused me the most trouble. If an eSig isn't biometric, it must use at least two elements. Generally these are some kind of ID plus a password. In a perfect world, we'd just log the user off before a doc save and force them to re-authenticate and bingo, two part eSig.
The OTHER thing Part 11 requires is that the system respond to attempted forgery/guessing. I believe there are some API hooks that tie into the login system that could be used for this, but I'm not an API guy. The logoff/reauthenticate to save fails this requirement. A user can guess passwords till the cows come home and Notes will just take the input and do nothing. (side note - this is a client app)
Soooo....
In my case, I use the user's login name as the id and an eSig password. The user creates an esig document in a separate db. The data is hashed so I can't see the password. Reader fields assure nobody but the user and the admins can see the eSig password records. Passwords expire one year after creation; users are pinged to change them, and you have to enter the old values to update to new. The admins have the ability to set this to a bypass state so user's who have forgotten their passwords are able to reset them.
When an eSig is required the user must enter their sig Password. If they miss 3 times, their sig doc is locked so they can't sign anything anywhere and the admins are notified.
There are a few more features but that should give you an idea what I do and it has, so far, passed several FDA and customer audits (we are a contract device design\build firm).
So why not use the built in Notes digital sig? The FDA sees a signature as an act taken with forethought by the user. When I looked at the digital sigs I didn't see any way to apply it only on demand. There were also issues with the need for multiple sigs and the whole 'detect forgery' thing. One could probably make a case for digital sigs but, at the time, I just didn't see any way to make the design compliant with Part 11.
Hope that helps. If you need more details, let me know. I'll monitor this thread for a couple of days and you can always reach me at my home email.
Doug
http://www.ohesso.com/essays/essay006.htm
Doug,
the http password is stored in the nab in hash format. Did you consider copying this to your seperate database to avoid the step of the user having to register a second password ?
Not tried it but it could work
Sean
@Sean,
Hadn't thought about that.
On the other hand, most users don't have an http password since 99.999% of everything we do is via the client (we use Exchange for mail so we have no need for webmail and almost all our apps are consumed inside the firewall).
On the other hand, my eSig db contains password expiration and notification code as well as code to require the user to enter the old id/password values in order to change them and a separate log of 'transgression events'. And flagging to lock the user out of signing anything if they do the 'three strikes and you're out' and code to unlock locked esigs. And reader fields so nobody gets to see any person's document except the person (probably overkill with author fields and all).
On the other hand, an interesting idea. Now that we've used the system for a number of years and found that we have N E V E R had an instance of someone trying to forge a sig, some of the metal plating built into the original design seems like it might not be needed so switching things around to an easier to manage system might be worth looking at. I'll have to noodle this one around a bit.
Thanks for the idea.