Transmitting screen shots for legal records

[George Toft]

Hi Vic,

Did I say "log in"?  I said "Authenticate" which is a cumbersome practice in
itself.

To your points in general - the process for data retrieval are already in place
and
working.  If the form was mailed in, it would be imaged and the CSR could
retrieve it.
We need the same capability for the web, and The Business thinks they can take a
snap-
shot of the screen and use that instead of the imaged document.  

<Paranoia>
I have some reservations about Big Corporation taking a snapshot of my screen. 
How 
can I be sure they are not sending back other screenshots?  What if the
screenshot
they capture has my banking information or perhaps evidence of a crime?  Our
CSR's
are not trained to handle that (I don't think they are).  I can see it now, Big
Corporation captures something implicating the member of a crime, the CSR blows
the 
whistle, Big Corporation turns over the evidence to the cops, and ends up
getting 
sued for illegal search and seizure, pain and suffering, invasion of privacy -
the
list goes on.
</Paranoia>

I just think this is really bad.

George


Victor Odhner wrote:
> 
> Hi, George.
> 
> You have two things to accomplish:  (1) make the
> account's history available to the CS Reps to
> facilitate anything they need to do in support of
> the account; and (2) save enough information to make
> it clear the company knows its own procedures, and
> can demonstrate the historical accuracy and honesty
> of the transaction.
> 
> I got kinda carried away (see below) and laid out
> a suggestion that should satisfy both of the above.
> 
> The screen snap does not prove anything.  It's all
> the data, the logs, and the procedures surrounding
> the interaction that really tell the story.
> 
> In lieu of saving a document "image", create a "report"
> image that the CSRs would see instead.  The members
> would not have seen this exact report, but the report
> would identify and isolate just what the members DID
> see, plus related information:
> 
> * All statements that were presented for agreement,
>   with variable data filled in as it would have
>   appeared on the form.  NOTE: This requires
>   a DOCUMENTED REVIEW PROCEDURE for the form itself,
>   to ensure that no text will be truncated or obscured
>   in the user's browser screen due to field size, frame
>   size, overlaying of text by graphics, inappropriate
>   background/foreground colors, the member's
>   (or browser's) refusal to run scripts or Java, etc.
>   The best safeguard against this is to generate nice
>   clean, simple HTML with sharply contrasting colors
>   and no fancy stuff; and to document with EACH update
>   of the agreement form that these standards were
>   adhered to.
> 
> * The server's local date and time when the agreement
>   was received, plus the user's account information
>   and IP address.  This is specifically for correlation
>   with the site's server logs, which of course are also
>   being archived, in case an auditor ever wants to
>   trace a specific sign-up session.
> 
> * The full URL and other information that would correlate
>   with the design and contents of the screen that the
>   member saw.  This should include some sort of version
>   coding, so you wouldn't have to make inferences about
>   when the transactions took place vs. when a particular
>   wording of the agreement was cut into production.  Each
>   time the company changes the format or contents of the
>   agreement form, they will also (1) change the version
>   code and (2) save a snapshot of a sample screen.
>   If they can document this procedure, then it lends
>   credence to what the signing member saw, and it gives
>   the kind of transparency that is convincing in the
>   face of challenges.
> 
> In addition:  The form that the user posts back
> to your server should contain that same version
> info as a data field, and the code processing that
> form should CHECK the version against what had been
> sent out in that session.  This would close the loop,
> so there would be no question as to what version of
> the form the member was looking at.  It would go both
> ways as a hidden field, but the validation is to
> confirm that a "sign-up" will not be accepted except
> in response to the intended agreement form.
> 
> Saving the server's logs allows any investigation
> to confirm the timing and progress of the user's
> session, including when they logged in, what
> IP address they were coming from, and how long
> it was between having the agreement form presented
> to them and their having posted back the signed
> agreement.
> 
> Similar procedural consistency must also be
> demonstrable for the member's log-in process, in
> order to help confirm and support the identity of
> the signing member.  Just saying that you require
> a member log-in doesn't cut it:  you need to be
> able to demonstrate that a respectable authentication
> system was in effect for that specific historical
> session.
> 
> IANAL, but I think this is the kind of logging and
> procedural documentation that serious auditors would
> look for in establishing good faith and an absence
> of any deceptive practices.  You probably should
> review it with an auditor as well as with law-yuhs.
> 
> Have fun.  (As you can see, I miss working!)
> 
> Vic
> 
> http://members.cox.net/vodhner/
> ________________________________________________
> See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail doesn't post to the list quickly and you use Netscape to write mail.
> 
> PLUG-discuss mailing list  -  PLUG-discuss@lists.plug.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss