Good point. It looks like I'll be just implementing this for myself but I'd appreciate input from the list.
You could always have two attribute. One that indicates general obfuscation (replaces each character with '#') and one where you can specify the number of dummy characters to use (for salary case). Also, general obfuscation method could only replace alpha numeric characters (would ignore characters such as ',' and '-'.) That way the social security number would still have '-' in it (which would be desirable IMO). On Wed, 19 Jan 2005 09:56:22 -0600, Nail, Evan Burke <[EMAIL PROTECTED]> wrote: > I've worked on a small HR system and we ran into this type of problem. On > demos yes, but mostly on tracking down data related issues we would often > need the production employee data in test without the sensitive information. > We ended up incorporating some data manipulation methods when copying the db > down to our test environment. Kind of like data obfuscation. Much more > complexity was generally needed that just performing a char replace at > display time. I can't think of all the examples but a couple would be.. > > For example ( not that this is what you are doing of course) but assume your > demoing a list of employees salaries and you display John Smith and Jane > Doe's salaries as #,###.## and ###,###.## Even though you can't see the > amount the difference is obvious. Now John jumps across the conference table > during the demo and smacks Jane..there's a lawsuit..your demo is ruined. > > Plus we had lots of search items on SS# . Displaying the SS# is perfect for > your scenario because of it's uniformity, but we had lots of search fields > that used the SS# so even typing that in during a search demo would cause > issues if it wasn't switched to some set of random numbers. We wrote some > stuff that generated the ss# and other keys and was able to propagate them to > keep all the PK, FK relationships with the new fake data. > > Anyway, not that these are your issues, but just a few things to think about. > It's more work of course, but I'd advise a demo database with scrubbed data. > > bn > > > -----Original Message----- > From: Sean Schofield [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 18, 2005 4:36 PM > To: MyFaces Discussion > Subject: Re: Idea for new "privacy" feature > > I am leaning towards that conclusion. We'll leave this thread up here > and see what others think. There isn't really any harm in including > it in MyFaces. It would be another attribute that you could add to a > tag and a few custom renderers. Not a big deal really. > > On the other hand, if this is really something only I care about. Why > subject anyone else to it ;-) > > On Tue, 18 Jan 2005 14:31:58 -0800, Travis Reeder > <[EMAIL PROTECTED]> wrote: > > I think you should just create your own custom components to add this, > > definitely not something that should be in MyFaces. > > > > Travis > > > > > > Sean Schofield wrote: > > That's a bit difficult in my case. I have a perfectly functioning > system > > already with real data. Suppose I don't want to add fake data > to my > > production system. Also, the data is in a lot of different > tables with > > foreign keys, etc. Finally some of the data tables are > not under our control > > - we just read from them. > > On Tue, 18 Jan 2005 16:16:41 -0600, Heath > > Borders > <[EMAIL PROTECTED]> wrote: > > > You can't just create dummy data? > > On Tue, 18 Jan 2005 17:13:38 -0500, Sean > > Schofield > <[EMAIL PROTECTED]> wrote: > > > What do you think about this idea ... > > Our current application at work uses > > very sensitive data. I've often > wanted to show the application to other > > clients but I don't want any > of this data to be shown. > > Maybe we could > > modify the ext tags to provide a "private" attribute > (true/false.) Then > > supply some custom renderers that could render a > private version of the > > data. > > So for example "Sean Schofield" could become "#### #########". > > Would > > this be useful for anyone else besides myself? I'm thinking it > could also be > > used to generate screen shots for user guides. > > Thoughts? > > sean > > -- > -Heath > > Borders-Wing > [EMAIL PROTECTED] > > > -- > Travis Reeder > Ecommstats Web Analytics > www.ecommstats.com > > > ********************************************************************** > This e-mail is the property of Enron Corp. and/or its relevant affiliate and > may contain confidential and privileged material for the sole use of the > intended recipient (s). Any review, use, distribution or disclosure by others > is strictly prohibited. If you are not the intended recipient (or authorized > to receive for the recipient), please contact the sender or reply to Enron > Corp. at [EMAIL PROTECTED] and delete all copies of the message. This e-mail > (and any attachments hereto) are not intended to be an offer (or an > acceptance) and do not create or evidence a binding and enforceable contract > between Enron Corp. (or any of its affiliates) and the intended recipient or > any other party, and may not be relied on by anyone as the basis of a > contract by estoppel or otherwise. Thank you. > ********************************************************************** > >
