Difference between revisions of "Privacy issues"

From Project VRM
Jump to navigation Jump to search
m (Reverted edits by Hiphopalemi (Talk) to last version by Joe.andrieu)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Burada tartışma için olası bir VRM gizlilik modeli, [dayalı http://www-306.ibm.com/software/data/db2/eas/anonymous/ Beraber IBM'de çalışan mevcut araçları's]
+
Here’s a possible VRM privacy model for discussion, based on [http://www-306.ibm.com/software/data/db2/eas/anonymous/ existing tools that I work with at IBM]
  
+
 
Gerçek dünyadan bir örnek olarak, hücre geçiş planlıyorum-telefon taşıyıcıları Şubat ayında bu yıl, ve ben de yeni bir cep telefonu gerekir. Bu durumda, hangi anonim merkezi bir veritabanı (bir Web sitesi üzerinden saklayabilir verecek bir VRM sistemi / Web servisi veya yerel P2P istemci bir tür içine benim lüzum girebilirsiniz.).
+
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.).
  
Gelince nasıl bilgi depolamak ve ihtiyaçlarını belirlemek .... Cep telefonu tespit edebilmek için nasılsa biz var tabi. Ben UPC kodları veya başka bir kimlik, ürün sunulan ana listeden tercüme kullanılabilir varsayalım. Cep telefonu planı girişi biraz daha belirsiz olduğunu. Değil nasıl bir tespit olacaktır, ihtiyacı olan bir müşteri formu dayalı başka emin .... Dakikada, aile planı, kapsamı, vb gerekli .... (Ben artık bu küçük parçası ... ..:) atlayacakları
+
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…..:)
  
Sonra ihtiyaçları kaydedilir, bunlar tek yönlü karma ile (şu anda) [http://en.wikipedia.org/wiki/SHA-1 SHA-1] algoritma kullanarak anonim olacaktır. Özgün durumuna hala içinde özgün veriler, ama sadece onu oluşturan kişiye ulaşılabilir. Diğer müşterilerin herhangi bir veri ama kendi göremiyorum.
+
After the needs are recorded, they would be anonymized via a one-way hash (we currently use the [http://en.wikipedia.org/wiki/SHA-1 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.
  
Karma girişleri ayrı ayrı ve Bayiler tarafından sorgulamak için saklanır. Bayiler paylaşılan bir karma anahtarı almak için kayıt gerekir. Bu anahtar sağlayacak eşsiz, paylaşılan kodları üzerinden sorgu müşteri ihtiyaçlarına satıcılar, ancak sağladığı ürünler sadece.
+
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.
  
Satıcılarının müşteri veri göremiyorum. Benzersiz bir ortak kimliği ile sundukları üzerinde sahip ürünleri ile Onlar sadece sorgu verileri. VRM sistemi bir eşleşme bulunursa müşteri değil, Satıcı bildirir.
+
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.
  
VRM sistemi isteğe bağlı olarak, istatistiksel amaçlar için (ürünler satılan hits karşılaştırarak, örneğin), fakat bu ikili hit / hayır isabet değeri olurdu tüm satıcı olduğu bir eşleşme bulunursa satıcı uyarabilir. Kadar bir ürün veya hizmeti satın almayı müşteri anonim kalır.
+
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.
  
Müşterilerin bir maç anonim bir Web sayfası veya Web Hizmeti için belirli bir ürün için bir teklif ile bunların Aradığınız yönlendirilmiş olacağını bulunursa bildirilir. Eğer bu satıcı ile ürün takip etmek istiyorsanız daha sonra o kadar müşteriye (sonraki seviyeye) ilişki almak karar.
+
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).
  
Eğer size, tüm Web Servis tabanlı, araç toplam inşa edilebilir ve o zaman ihtiyacı kaydedilen iade edilir sunar karşılaştırın. Daha da ileri giderek araçları ürün ve hizmet değerlendirmeleri bağlamak için, inşa edilebileceğini ve işlemi tamamlamak kez bir karar yapılır.
+
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.  
  
Benim gerçek dünyadan bir örnek olarak, bir cep telefonu ve hizmet seçenekleri online anonim için, alışveriş olur ve bir veya daha fazla ürünleri I, hoş çok Şimdi ne aynı şekilde ilgileniyorum karar. Daha sonra VRM sistemde cep telefonu tercihleri ve hizmet ihtiyaçlarını kayıt olur. Benim lüzum karma olacak ve Bayiler için erişilebilir karma değerlere ekledi merkezi ya da P2P tarzı merkeziyetçi sistemi (yoluyla). Kayıtlı cep telefonu satıcıları bir ben ne zaman ihtiyaç kaydedilen girilen karma veri (UPCs veya diğer değer) aynı benzersiz kimliklerini kullanarak sorgulayabilir. Eğer bir eşleşme's, ben bir teklif haberdar olacağını Satıcı VRM sistemi. Aynı zamanda, cep telefonu servis sağlayıcı B planı paylaşılan kimlikleri ile veya planın parametreleri ile ihtiyaçları, planım sorgu ve beni bir cep telefonu sağlayıcı ile birlikte bir cep telefonu ve cep telefonu servis listesi sunuyoruz.
+
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.
  
Ben anonim Bu teklifleri gözden geçireceğini ve benim için en iyi karar. Bir kez bir kararı var, VRM sistemi veya doğrudan () üzerinden satın devam satıcısına başvurun olur. Satın satıcı ile ilk doğrudan olmayan anonim temas olacaktı.
+
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.
  
Bir kez karar ve ulaşılır bir satın alma yapılmış, ben VRM sisteminden ve artık benim ihtiyaçların kaydını kaldırmak istiyorsunuz belirli ürün veya hizmet için teklif alırsınız.
+
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.
  
Daha fazla düşünce gerekenler, daha fazla tartışma:
+
Things that need more thought, more discussion:
Bu model sadece birden çok satıcı varsayarak çalıştığını aynı satmak için, biraz kolayca ürün veya hizmet tespit çalışıyoruz. Belirsiz öğeler için kolayca bu model içine (video servis sağlayıcıları, tatil seyahat, yemek, diğer hizmetler), daha fazla düşünce tabi ... uymaz
+
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…
[http://www.sexalemi.org sikis izle]
 
[http://www.pornositeleri.net porno izle]
 
[http://www.sexalemi.org sex izle]
 
[http://www.sexalemi.org sikisi]
 
[http://www.cinsel.name sikis izle]
 
[http://www.cinsel.name.tr sikisi]
 
[http://www.hiphopalemi.net hiphop]
 
[http://www.kelebekchat.net kelebek sohbet]
 
[http://www.kelebeksohbet.org kelebek sohbet]
 
[http://www.chatsohbet.org sohbet sohbet]
 
[http://www.siberchat.net sohbet]
 
[http://www.pornositeleri.net porno]
 
[http://www.pornositeleri.org porno izle]
 
[http://www.pornositeleri.org porno siteleri]
 
[http://www.sexpormok.net sex]
 
[http://www.mynetsohbet.net mynet sohbet]
 
[http://www.hiphopalemi.net sohbet]
 
[http://www.hiphopalemi.net rap]
 
[http://www.kelebekchat.net kelebek]
 
[http://www.gaychat.gen.tr sohbet gay]
 
[http://www.sempatim.net sevişme]
 

Latest revision as of 17: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…