Publishing personal content on the web is gaining increased popularity with dramatic growth in social networking web- sites, and availability of cheap personal domain names and hosting services. Although the Internet enables easy pub- lishing of any content intended to be generally accessible, restricting personal content to a selected group of contacts is more di\ufb03cult. Social networking websites partially enable users to restrict access to a selected group of users of the same network by explicitly creating a \u201cfriends\u2019 list.\u201d While this limited restriction supports users\u2019 privacy on those (few) selected websites, personal websites must still largely be pro- tected manually by sharing passwords or obscure links. Our focus is the general problem of privacy-enabled web con- tent sharing from any user-chosen web server. By leverag- ing the existing \u201ccircle of trust\u201d in popular Instant Messag- ing (IM) networks, we propose a scheme called IM-based Privacy-Enhanced Content Sharing (IMPECS) for personal web content sharing. IMPECS enables a publishing user\u2019s personal data to be accessible only to her IM contacts. A user can put her personal web page on any web server she wants (vs. being restricted to a speci\ufb01c social networking website), and maintain privacy of her content without re- quiring site-speci\ufb01c passwords. Our prototype of IMPECS required only minor modi\ufb01cations to an IM server, and PHP scripts on a web server. The general idea behind IMPECS extends beyond IM and IM circles of trust; any equiva- lent scheme, (ideally) containing pre-arranged groups, could similarly be leveraged.

Copyright is held by the International World Wide Web Conference Com- mittee (IW3C2). Distribution of these papers is limited to classroom use, and personal use by others.

Through social networking and photo-sharing websites, and personal blogs, it is becoming increasingly popular to make personal content available on the Internet. For some users, these sites provide a textual and/or pictorial docu- mentary of life. Primarily because it is the easiest mode of operation, many users of these services allow their personal web content to be accessed by all other Internet users, often with the false impression that none other than their family or friends would look into their personal online posts [29]. Privacy concerns are largely being ignored (sometimes un- knowingly) in the current rush to onlinelifecasting.

Social networking websites such as Facebook and MyS- pace provide access control mechanisms for partially restrict- ing personal content to a known circle of contacts; photo- sharing websites such as Flickr and Shutter\ufb02y provide sim- ilar mechanisms. A user can invite her friends and family to be added to herpermitted list, and can authorize only such people to view her web content, but only if they create accounts at the publishing user\u2019s social networking site. Al- though users reportedly disclose personal data in abundance at these social networking sites, a relatively small number of users limit access to their pro\ufb01les only to a friends\u2019 cir- cle; several studies provide evidence of such behaviour [21, 29, 39, 51]. While this limited restriction might help users\u2019 privacy, this applies only for the content on those (few) sites.

We focus on the general problem of privacy-enabled web content sharing from any user-chosen web server. Many users now own domain names for hosting personal web- sites, facilitated by the very low price; as of October 2007, a top-level domain name may cost less than $6/year, with $4/month commercial hosting fees. Most ISPs also o\ufb00er free web spaces for home users. It is thus cheap and easy to make any personal data available to anyone around the globe through a website; however, restricting such content to a selected group of people is more di\ufb03cult. Currently this is achieved primarily by either (i) advertising an obscure link through personal email, i.e., a URL which is not linked from any other web page; or (ii) protecting a web page with a password, and distributing that password among chosen contacts through email, instant messaging (IM), or phone.

Emailing an obscure URL to many contacts (friends and family members) is a rather cumbersome approach, espe- cially if the shared URLs are often updated. Password pro- tection (e.g. HTTP Authentication [18], forcing a login di- alogue/page) is not uncommon among the more technically inclined, but this leads to yet one more password to share and maintain, and once a password is shared with some-

one, the access grant cannot be retracted without chang- ing the password (which also requires distributing the new password to all other contacts). Also, anyone who learns the shared password can view the protected content without the publishing user\u2019s consent; anyone knowing the password can pass it on to others, and such transitive access is not gener- ally preventable.

Relying on the immense popularity of public instant mes- saging (IM) networks,1 we propose a scheme called IM-based Privacy-Enhanced Content Sharing (IMPECS) to disseminate personal web content by leveraging the established \u201ccircle of trust\u201d on IM networks. We assume both publishing and viewing users can, or already do use IM. A user\u2019s web con- tent can be viewed only by her IM contacts. Further re- strictions can be applied depending on which group of users (e.g. family, friends, co-workers) a speci\ufb01c contact is placed in by apublishing user, i.e., one who originally makes per- sonal content available for her IM contacts. Aviewing user is one who wants to view such content. We assume that a web server and an IM server share a user-speci\ufb01c content sharing key; a \u2018ticket\u2019 (similar to a session cookie) is gener- ated by the IM server for a viewing user using the content key of a publishing user, and the web server validates the ticket before serving data from a user\u2019s web folder (cf. Ker- beros [31]). Our primary goal is to enhance privacy (i.e. con\ufb01dentiality) of users\u2019 personal web content; we do not aim for very high-end or military-grade security, as the se- curity of IMPECS is limited by the underlying IM and web communication protocols, which in current practice trans- fer most content in plaintext although authentication pass- words are generally sent over SSL (cf. [26, 11]). The main intended feature of IMPECS is that total strangers are pre- cluded from direct access to a user\u2019s personal web content, but \u201cfriends\u201d as designated by the user\u2019s IMcontact list are allowed access (without requiring any special shared pass- word). IMPECS also prevents large-scale web crawlers and auto-indexers from tagging personal data and pictures (see e.g. [4, 27]). However, malicious IM contacts of a publish- ing user may of course re-post the user\u2019s private content to a public web forum, and we are not proposing any form of digital rights management (DRM) control.

1.Privacy-Enhanced Sharing. A publishing user\u2019s personal web content can be viewed only by the IM contacts that she pre-approves. Thus privacy of a user\u2019s web content is restricted to a designated group. For many existing IMusers, such groups can be lever- aged without additional setup costs.

2.Usable Security. The privacy enhancement does not require a viewing user to separately update his IM client, or remember the publishing user\u2019s URL, or have access to a site-speci\ufb01c password to view the pub- lisher\u2019s content. Similarly, the publishing user need not carry out any extra steps beyond existing management of an IM contact list, although \ufb01ner granularity lists can optionally be created by advanced users.

websites, a user can publish her web content at any web server of her choice, and yet be able to maintain greater access control on her content.

4.Decreased Risks Related to Sharing. By re- stricting open access to personal details, IMPECS re- duces opportunities for launching context-aware, tar- geted phishing attacks [30, 44, 50].

To test our design, we built a prototype of IMPECS using the IETF standardized Extensible Messaging and Presence Protocol (XMPP [40, 41], i.e., the Jabber IM protocol). This required only minor modi\ufb01cations to the IMserver, and PHP scripts on a web server. Our implementation source code is available on request.

PECS scheme, threat model and operational assumptions. Our prototype implementation is discussed in Section 3, along with brief comments on deployment issues. A vari- ant of IMPECS is discussed in Section 4. Section 5 provides further motivation, an overview of existing and proposed work related to personal content sharing, and a compari- son of IMPECS with these in terms of user convenience and usability. Section 6 concludes.

In this section, we describe the proposed IMPECS scheme, threat model and operational assumptions. Table 1 summa- rizes our notation. We assume readers are familiar with basic IM de\ufb01nitions such aspresence andcontact list (e.g. see [25]).

Two IM users Alice and Bob, both members of each other\u2019s respective contact lists.A is the publishing user;B is the viewing user.

A \u2018registration\u2019 URL generated bySw when re- quested byA. The content sharing key and re- strictions are shared betweenSw andSi through this URL.

A \u2018viewing\u2019 URL (for accessing URLA) contain- ing a ticketTiw, generated bySi at the request ofB.

site on a web serverSw.A registers her site with an IM serverSi, and sets permission for the site, e.g., which con- tacts can access which pages/folders. For example, contacts in the group \u201cfriends\u201d may have di\ufb00erent permissions than the group \u201cfamily.\u201dSw andSi share a user-speci\ufb01c content sharing key forA. IM contacts ofA can see (through their IM clients) whetherA o\ufb00ers any personal URL which they are permitted to view. When a contactB wants to visitA\u2019s advertised personal website (or any pages thereon),B sends a request toSi to visit the website. Depending on restric- tionsR (e.g. duration, frequency) for viewing web pages at URLA,Si generates a \u2018ticket\u2019 (similar to a session cookie), and sends a special URL toB along with the ticket.B re- ceives the URL instantly (e.g. as an IM text message) from

counts at the same IM serverSi. (Note thatA andB may use di\ufb00erent IM servers, as long as their IM servers facili- tate communication between the users, e.g., as in distributed XMPP [40], Windows Live/Yahoo! Messenger.) Both users have added each other into their contact lists; adding some- one to a contact list requires explicit permission from the user being added (a common practice in most IMnetworks).

(e.g. \u201cfamily\u201d, \u201cfriends\u201d, \u201cco-workers\u201d).A maintains an ac- count with a web serverSw, and uploads some personal pic- tures or \ufb01les under a web folder URLA atSw.A wants to share URLA with a select group of IMcontacts includingB.

2.A uploads her personal \ufb01les and sets restrictions on URLA, e.g., the length of time a ticket will remain valid after being generated bySi (using e.g. HTML check-boxes or drop-down lists).A then requestsSw to generate a registration URL for URLA.

3.Sw generates a random content sharing keyKAw (e.g. 128 bits, su\ufb03cient for precluding o\ufb04ine dictionary at- tacks) and stores it in a protected database, or in a \ufb01le

through HTTPS). Here, by<URLA > we mean the ac- tual URL (without the \u2018scheme name\u2019), not a label for that URL (i.e. not the string \u201cURLA\u201d).

5.A forwards URLAR toSi, for the purpose of registering this information withSi.Si stores URLA,IDAw,KAw andR for future ticket generation.

1.B logs intoSi (e.g. using his regular IM password over SSL), and receives his contact list as usual in IM. As part of IMPECS,B also receives a list of private URLs, o\ufb00ered by his contacts, which are authorized to be ac- cessed byB.

the ticketTiw, and compares whetherA\u2019s user ID in the URL is the same as inside the ticket.Sw also checks the restrictions; e.g.,R could be as simple as a timestamp, in which caseSi encrypts the current timestamp into the ticket andSw accepts that ticket if received within a speci\ufb01c time period (e.g. 60 seconds, as set byA).

5.Sw sends the content hosted at URLA toB after val- idatingB\u2019s ticketTiw in URLAT (as in step 4). If a valid ticket is not supplied,Sw denies access to URLA.

of content hosted at URLA, by making a copy of the web- site and posting it on a publicly accessible site, or sending a valid ticket to anyoneB wants. AlthoughA cannot stop