Privacy issues: Difference between revisions
Hiphopalemi (talk | contribs) No edit summary |
m (Reverted edits by Hiphopalemi (Talk) to last version by Joe.andrieu) |
||
| Line 25: | Line 25: | ||
Things that need more thought, more discussion: | Things that need more thought, more discussion: | ||
This model only works assuming multiple vendors are trying to sell you the same, somewhat easily identified product or service. For vague items that donât easily fit into this model (video service providers, holiday travel, catering, many other services), more thought is needed⦠| This model only works assuming multiple vendors are trying to sell you the same, somewhat easily identified product or service. For vague items that donât easily fit into this model (video service providers, holiday travel, catering, many other services), more thought is needed⦠| ||
Latest revision as of 12:21, 1 December 2009
Hereâs a possible VRM privacy model for discussion, based on existing tools that I work with at IBM
As a real-world example, Iâm planning on switching cell-phone carriers in February this year, and I also need a new cell phone. In this case, I could enter my needs into a VRM system, which would anonymously store them (in a centralized database via a Web site/Web service, or locally to some kind of P2P client.).
As for how to store the info and identify needsâ¦. Somehow we have to be able to identify the cell phone needed. I suppose that UPC codes could be used or some other identifier, translated from a master list of products offered. The cell phone plan entry is a little more nebulous. Not sure how that one would be identified, other than needs based on a customer formâ¦.minutes needed, family plan, coverage, etcâ¦.(Iâll just skip over this little part for nowâ¦..:)
After the needs are recorded, they would be anonymized via a one-way hash (we currently use the SHA-1 algorithm). The original data is still in its original state, but only accessible to the person who created it. Other customers can not see any data but their own.
Hashed entries are stored separately and available for querying by Vendors. Vendors would have to register to receive a shared hash key. That key would allow Vendors to query customer needs, but only for products that they provide, via unique, shared codes.
Vendors can not see customer data. They can only query data with products that they have on offer, via a unique shared ID. The VRM system notifies the customer when a match is found, not the Vendor.
The VRM system could optionally notify the vendor when a match is found, for statistical purposes (comparing hits to products sold, for example), but this binary hit/no hit value is all the vendor would have. The customer remains anonymous until they choose to purchase a product or service.
Customers that are notified when a match is found would be anonymously directed to a Web page or Web Service with an offer for the specific product that they are looking for. It is then up to the customer to decide if they want to pursue the product with that vendor (take the relationship to the next level).
If the offers are all Web Service based, tools could be built to aggregate and compare offers that are returned when needs are recorded. Going even further, the tools could be built to link to product and service reviews, and complete the transaction once a decision is made.
In my real-world example, I would shop for a cell phone and service options online, anonymously, and decide on one or more products that Iâm interested in, pretty much the same way I do now. I would then record my cell phone preferences and service needs in the VRM system. My needs would be hashed and added to the hash values that are accessible to Vendors (via a centralized or P2P-style decentralized system). Registered cell phone vendor A can query the hashed data using the same unique IDs (UPCs or other value) that I entered when I recorded my need. If thereâs a match, I would be notified of an offer from that Vendor by the VRM system. At the same time, Cell phone service provider B could query my plan needs via shared plan IDs or via plan parameters, and offer me a cell phone and cell phone service bundle in conjunction with a cell phone provider.
I would review these offers anonymously and decide which is best for me. Once I have made a decision, I would contact the vendor (via the VRM system, or directly) and proceed with the purchase. The purchase would be my first direct, non-anonymous contact with the vendor.
Once a decision is reached and a purchase has been made, I would remove the record of my needs from the VRM system, and no longer receive offers for that specific product or service.
Things that need more thought, more discussion: This model only works assuming multiple vendors are trying to sell you the same, somewhat easily identified product or service. For vague items that donât easily fit into this model (video service providers, holiday travel, catering, many other services), more thought is neededâ¦