Talk:Privacy issues

From Project VRM
Revision as of 03:56, 4 January 2007 by Whitneymcn (talk | contribs) (Noting possible concerns about hash comparison approach)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

The hashing approach, while it brings some interesting benefits, makes me a bit nervous on a couple of fronts. My main concern is the limitations that it seems to impose on the RFP: as Bbenz notes, because hashing requires that both seeker vendor hash the exact same string it works well for something like a specific product code, but far less well for more abstract requests.

Taking the examples from the taxonomy page, hashing might manage a request for a Blackberry 7130c relatively easily, but requesting a cell phone based on features (must have bluetooth and EDGE support), or price (must cost $250 or less) becomes non-trivial very quickly...the data dictionary required just for cell phones would be pretty hairy. Hashing also makes RFP-offer matching absolutely binary: either a vendor has an exact match for the RFP or not, no possibility of a vendor offering a good deal on something very close to, but not exactly, what is defined in the RFP. [This "all or nothing" model may be desirable for some; in my head, though, VRM allows vendors some latitude in what they offer, with a combination of seeker-side offer evaluation and a reputation system combatting the potential for abuse.]

I also worry about the increased importance of a third-party authority that I think I see coming from this model. If we're hashing, there needs to be a single, authoritative source defining the language and grammar of every term that can be used in an RFP; returning to the taxonomy examples, until that source provides or confirms the definitive way to say "I want a cell phone that costs less than $50 and is AIM-capable," it's effectively impossible to make that request. The central authority becomes absolutely critical to the VRM process, which scares me a bit.

[Note: I'll happily agree that defining a data format for RFPs/offers that is structured enough to be easily parseable but open enough to allow making all (or most) of the necessary kinds of statements isn't all that much more appealing an option. I just think that it's a much more forgiving approach for when the inevitable typos/errors creep in, and that it would require less maintenance and overhead.]

Looking forward to hearing what others think... --whitneymcn 02:56, 4 January 2007 (EST)