MétaCan
Menu
Retour à la cohorte
Enregistrement W2495850764 · doi:10.4018/978-1-59140-799-7.ch158

Semi-Automated Seeding of Personal Privacy Policies in E-Services

2006· book-chapter· en· W2495850764 sur OpenAlexaff
George Yee, Larry Korba

Notice bibliographique

RevueIGI Global eBooks · 2006
Typebook-chapter
Langueen
DomaineSocial Sciences
ThématiquePrivacy, Security, and Data Protection
Établissements canadiensNational Research Council Canada
Organismes subventionnairesnon disponible
Mots-clésPrivacy policyConsumer privacyBusinessInternet privacyInformation privacyService providerPersonally identifiable informationPrivacy by DesignPrivacy softwareService (business)MarketingComputer securityComputer science

Résumé

récupéré en direct d'OpenAlex

The rapid growth of the Internet has been accompanied by a proliferation of e-services targeting consumers. E-services are available for banking, shopping, learning, government online, and healthcare. However, each of these services requires a consumer’s personally identifiable information (PII) in one form or another. This leads to concerns over privacy. In order for e-services to be successful, privacy must be protected (Ackerman, Cranor, & Reagle, 1999). An effective and flexible way of handling privacy is management via privacy policies. In this approach, a consumer of an e-service has a personal privacy policy that describes what private information the consumer is willing to give up to the e-service, with which parties the provider of the e-service may share the private information, and how long the private information may be kept by the provider. The provider likewise has a provider privacy policy describing similar privacy constraints as in the consumer’s policy, but from the viewpoint of the provider, (i.e., the nature of the private information and the disclosure/retention requirements that are needed by the e-service). Before the consumer engages the e-service, the provider’s privacy policy must match with the consumer’s privacy policy. In this way, the consumer’s privacy is protected, assuming that the provider complies with the consumer’s privacy policy. Note that policy compliance is outside the scope of this work but see Yee and Korba (July, 2004). Initial attempts at conserving consumer privacy for e-services over the last few years have focused on the use of Web site privacy policies that state the privacy rules or preferences of the Web site or service provider. Some of these policies are merely statements in plain English and it is up to the consumer to read it. This has the drawback that very few consumers take the trouble to read it. Even when they do take the time to look at it, online privacy policies have been far too complicated for consumers to understand and suffer from other deficiencies (Lichtenstein, Swatman, & Babu, 2003; Jensen & Potts, 2004). Still other privacy policies are specified using P3P (W3C) that allows a consumer’s browser to automatically check the privacy policy via a browser plug-in. This, of course, is better than plain English policies but a major drawback is that it is a “take-it-or-leave-it” approach. There is no recourse for the consumer who has a conflict with the Web site’s P3P policy, except to try another Web site. In this case, we have advocated a negotiations approach to resolve the conflict (Yee & Korba, Jan., May, 2003). However, this requires a machine-processable personal privacy policy for the consumer. We assume that providers in general have sufficient resources to generate their privacy policies. Certainly, the literature is full of works relating to enterprise privacy policies and models (e.g., Barth & Mitchell, 2005; Karjoth & Schunter 2002). Consumers, on the other hand, need help in formulating machine-processable privacy policies. In addition, the creation of such policies needs to be as easy as possible or consumers would simply avoid using them. Existing privacy specification languages such as P3P, APPEL (W3C; W3C, 2002), and EPAL (IBM) are far too complicated for the average internet user to understand. Understanding or changing a privacy policy expressed in these languages effectively requires knowing how to program. Moreover, most of these languages suffer from inadequate expressiveness (Stufflebeam, Anton, He, & Jain, 2004). What is needed is an easy, semi-automated way of seeding a personal privacy policy with a consumer’s privacy preferences. In this work, we present two semi-automated approaches for obtaining consumer personal privacy policies for e-services through seeding. This article is based on our work in Yee and Korba (2004). The section “Background” examines related work and the content of personal privacy policies. The section “Semi-Automated Seeding of Personal Privacy Policies” shows how personal privacy policies can be semi-automatically seeded or generated. The section “Future Trends” identifies some of the developments we see in this area over the next few years. We end with ”Conclusion”.

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.

Comment cette classification a été obtenuedéplier

Prédiction distillée sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.

score de la tête « metaresearch » (Codex)0,000
score de la tête « metaresearch » (Gemma)0,000
Version: codex-gemma-dda1882f352aStatut de validation: machine_predicted_unvalidated
Catégories candidatesMéta-épidémiologie (sens strict)
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Théorique ou conceptuel · Signal consensuel: Théorique ou conceptuel
GenreSignal candidat: Empirique · Signal consensuel: aucune
Score de désaccord entre enseignants0,968
Score d'incertitude au seuil1,000

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0000,000
Méta-épidémiologie (sens strict)0,0000,000
Méta-épidémiologie (sens large)0,0000,000
Bibliométrie0,0000,000
Études des sciences et des technologies0,0000,000
Communication savante0,0000,000
Science ouverte0,0010,000
Intégrité de la recherche0,0010,000
Charge utile insuffisante (le modèle a refusé de juger)0,0000,000

Scores machine (provisoires)

Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.

Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.

Tête enseignante Opus0,023
Tête enseignante GPT0,292
Écart entre enseignants0,269 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découle

Classification

machine, non validée

Prédiction automatique; un appel candidat d’une seule tête enseignante, pas un consensus.

Devis d'étudeThéorique ou conceptuel
Domainenon disponible
GenreEmpirique

Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».

En bref

Citations1
Publié2006
Routes d'admission1
Résumé présentoui

Explorer davantage

Même revueIGI Global eBooksMême sujetPrivacy, Security, and Data ProtectionTravaux en français237 207