When URLs containing application parameters are posted in public settings privacy can be compromised if the those arguments contain personal or tracking data. To this end we describe a privacy aware link shortening service that attempt to strip sensitive and non-essential parameters based on difference algorithms and human feedback. Our implementation, CleanURL, allows users to validate our automated logic and provides them with intuition about how these otherwise opaque arguments function. Finally, we apply CleanURL over a large Twitter URL corpus to measure the prevalence of such privacy leaks and further motivate our tool

Aviv, Adam

Kim, Daniel

Su, Kevin

West, Andrew G.

English

Kosmopolis

CleanURL: A Privacy Aware Link Shortener

ScholarlyCommons@Penn

University of Pennsylvania ScholarlyCommons Technical Reports (CIS) Department of Computer & Information Science 1-1-2012 CleanURL: A Privacy Aware Link Shortener Daniel Kim University of Pennsylvania, dki@seas.upenn.edu Kevin Su University of Pennsylvania, kevinsu@seas.upenn.edu Andrew G. West University of Pennsylvania, westand@cis.upenn.edu Adam Aviv University of Pennsylvania, aviv@seas.upenn.edu Follow this and additional works at: https://repository.upenn.edu/cis_reports  Part of the Computer Engineering Commons Recommended Citation Daniel Kim, Kevin Su, Andrew G. West, and Adam Aviv, "CleanURL: A Privacy Aware Link Shortener", . January 2012. This paper is posted at ScholarlyCommons. https://repository.upenn.edu/cis_reports/978 For more information, please contact repository@pobox.upenn.edu. CleanURL: A Privacy Aware Link Shortener Abstract When URLs containing application parameters are posted in public settings privacy can be compromised if the those arguments contain personal or tracking data. To this end we describe a privacy aware link shortening service that attempt to strip sensitive and non-essential parameters based on difference algorithms and human feedback. Our implementation, CleanURL, allows users to validate our automated logic and provides them with intuition about how these otherwise opaque arguments function. Finally, we apply CleanURL over a large Twitter URL corpus to measure the prevalence of such privacy leaks and further motivate our tool. Disciplines Computer Engineering This technical report is available at ScholarlyCommons: https://repository.upenn.edu/cis_reports/978 CleanURL: A Privacy Aware Link ShortenerDaniel Kim, Kevin Su, Andrew G. West, and Adam J. AvivDepartment of Computer and Information ScienceUniversity of Pennsylvania – Philadelphia, PA, USA{dki, kevinsu, westand, aviv}@seas.upenn.eduABSTRACTWhen URLs containing application parameters are posted inpublic settings privacy can be compromised if the those argu-ments contain personal or tracking data. To this end we de-scribe a privacy aware link shortening service that attemptsto strip sensitive and non-essential parameters based on dif-ference algorithms and human feedback. Our implementa-tion, CleanURL, allows users to validate our automated logicand provides them with intuition about how these otherwiseopaque arguments function. Finally, we apply CleanURLover a large Twitter URL corpus to measure the prevalenceof such privacy leaks and further motivate our tool.1. INTRODUCTIONUniform resource locators (URLs) often contain function-ality that allows data to be passed to web applications. Forexample, consider the following URL:http://www.example.com?key1=val1&key2=val2There, the key-value pairs which proceed the question markare collectively called the query string. Such parameters arecommon in practice for purposes of referrer tracking, useridentification, and storage of session data.Privacy concerns can arise when a user posts a URL con-taining a query string in a public forum (e.g., a social net-work or micro-blogging platform) as parameters might con-tain/encode sensitive information. Moreover, since manyposting environments are profile driven, a history of contri-butions could reveal considerable private user data.When a parameter is interpreted by the server-side appli-cation it may or may not affect how the browser visuallyrenders the page. Thus, privacy leaks occurring as the re-sult of non-rendered parameters are avoidable given theirpurpose is orthogonal to that of link sharing, which is toshare content. Certain users may be cognizant of this fact,but manual removal and inspection is an arduous task. Morelikely, most users are unaware of the threat. Thus, we aim toprovide an intuitive and efficient means by which to visual-ize parameter output, educate about the potential dangers,and produce more secure links. This is realized as a privacy-aware link shortening service (CleanURL).We begin by using visual and textual comparisons (i.e.,diff algorithms) to determine whether or not a parameter’sCopyright is held by the author/owner. Permission to make digital or hardcopies of this work for personal or classroom use is granted without fee.inclusion affects rendering. Dynamic webpage content (e.g.,advertisements) can blur such distinctions. Thus, we createan interface that allows end-users to visually confirm/correctour generated rankings regarding URL reduction (Sec. 2).Over time, this feedback can be aggregated to refine ourapproach and increase usability by reducing service over-head. Moreover, we use our technique to conduct an un-supervised measurement study over a corpus of 1.6 millionTwitter URLs. We found that half of the URLs have argu-ments, and of those, 63% contain non-rendered arguments;a cause for privacy concern (Sec. 3).2. LINK SHORTENING SERVICEIn describing our link shortener, we begin by using diffalgorithms to estimate parameter necessity (Sec. 2.1) beforeintegrating these into a user-facing interface (Sec. 2.2).2.1 Estimating Argument NecessityGiven two URLS (i.e., one inclusive and another exclu-sive of some parameter) it is our goal to determine whetherthat parameter is a rendered one (i.e., induces non-randomcontent change). We consider two approaches:• Visual diff: The two URLs are rendered as down-scaled bitmaps with a standardized viewport and theHamming distance between the images is calculated.• HTML tag diff: The HTML source of the two URLsis parsed to remove visible text content. Over the re-maining content (i.e., HTML tags) a standard textualdiff is applied (based on longest common subsequence)and the size of the delta/patch is computed.While visual difference is perhaps the most intuitive com-parison method, one must also accommodate dynamic con-tent. Even when an identical URL is fetched multiple timesin succession the pages may render differently. Often, thiscomes in the form of different advertisement images whoseprominent sizing can skew visual diff calculation.The HTML tag diff provides an additional perspective.While visually different when rendered, advertisement place-ment code is generally quite static in nature (perhaps onlychanging the image path, if anything).Both diff algorithms return real-valued measures that canbe used jointly to determine the relevance of a URL argu-ment. The values are aggregated and compared against athreshold to force a binary decision of whether the versionsare sufficiently similar. This threshold should be selectedsuch that it is tolerant of dynamic content (see Sec. 3.1).1Your cleaned URL: [[base_url]]/R09XVIUh3www.example.com?key1=val1&key2=val2&key3=val3Choose the left-most version that appears as you expect.Our best guess has been selected by default.2http://www.example.com?key1=val1...1Figure 1: Simplified screenshots detailing end-userinteraction with the CleanURL interface.2.2 CleanURL User InterfaceA typical session with the link shortener is visually de-picted in Fig. 1. A user begins by entering a URL in asimple form field and pressing the “submit” button. Thissets off the computational phase whereby all combinationsof parameters from the query URL are enumerated. For eachparameter combination the webpage source (i.e., HTML) isdownloaded, rendered as a small screenshot, and comparedagainst the original URL via our diff functions. The diffoutput is used to sort combinations based on: (1) their abil-ity to faithfully render the original URL, and (2) internal tothat, the number of query string parameters.This ordering is the basis by which screenshots are pre-sented in a “shuﬄe” selector to the end-user (see Fig. 1).The “optimal” version is selected by default: the combina-tion with the minimal number of parameters that still ex-ceeds the similarity threshold. Our design goal was to visu-alize the impact of URL manipulation to achieve end-userawareness while still maintaining a clean, simple, and us-able interface. The user is free to browse/shuﬄe through allpresented combinations and a shortened URL (per standardhashing) is returned once a selection is made.This act of human selection is essentially an evaluation ofour automated technique. However, we could also imaginethat humans might go a step further in choosing to elimi-nate parameters that do affect page rendering (e.g., but areorthogonal to the page’s main content). Such feedback isput to use to use shortly (Sec. 3).CleanURL’s implementation is coded in Django, a Pythonweb application framework. Screenshot generation uses theQtWebKit engine supported by a VNC server.3. UTILIZING FEEDBACK LOOPSFeedback from the interface allows refinement of auto-mated techniques to minimize users’ time investment andheighten trust (Sec. 3.1). Confident in our system’s abil-ities, the approach can be employed autonomously over alarge corpus of URLs to estimate the prevalence and prop-erties of privacy leaks “in the wild” (Sec. 3.2).KEY NAME PER%utm_source 15.5%utm_medium 14.6%utm_feed, feed, f 12.4%ref, _r 5.2%utm_campaign, campaign 4.9%Table 1: Most commonly stripped parameter keys.Percentage is out of total of all stripped instances.N 0 1 2 3 . . . 8CDF% 100% 52.5% 5.5% 1.9% . . . 0.03%Table 2: Percentage of URLs having ≥ N key-valuepairs in the query string.3.1 Usability ImprovementsHuman feedback establishes ground truth regarding “op-timal” parameter selection. With these labels, the two diffvalues (Sec. 2.1) could be fed as features to a supervisedmachining technique to improve threshold selection. Giventhat CleanURL has not been deployed to the public we areyet to perform such optimization.However, we believe the accuracy of CleanURL’s auto-mated logic is paramount in achieving service adoption giventhat human selection phase is the only overhead in usingCleanURL relative to a traditional link shortener.A popular system would also generate sufficient feedbackto reason about parameter keys in a lexical fashion, e.g., that“userid=” tags are typically stripped from submitted URLs.In this vein we have manually authored a static list of keysthat tend to reveal private data (e.g., username, location,etc.). If one of these keys cannot be safely stripped theuser is warned, prompting manual inspection and possibleabandonment (i.e., the link is fundamentally insecure).3.2 Motivational Measurement StudyWe now use CleanURL’s logic to demonstrate the real-world presence of privacy sensitive URLs. We manually setselection thresholds using a combination of our expertise,the diff score distribution, and a small number of inspections(i.e., there is some margin of error).We analyze a corpus consisting of 1.7 million URLs thatappeared in Twitter posts. Tab. 2 shows the number of key-value pairs in query strings. We are fortunate that high pairquantities are rare as their combinatorial explosion wouldcreate interface latency. The figure also shows 52% of URLs(884,000 in total) have at least one parameter and theseformed our working set moving forward.Running these through the CleanURL system we foundthat 63% of URLs have at least one parameter stripped af-ter inspection (i.e., original URL vs. CleanURL’s “optimal”prediction). Clearly, the presence of non-rendered parame-ters is pervasive. We also inspect the key names which wereremoved, with Tab. 1 showing the five most common (group-ing those of similar name). Notable is the fact that all fiveare used for tracking purposes measuring referring websites,ad campaign effectiveness, traffic analytics, etc. Thus, notonly can the parameters be safely removed, but it should beapparent their removal would positively impact the privacyof the CleanURL user.2

https://repository.upenn.edu/cgi/viewcontent.cgi?article=2024&amp;context=cis_reports

CleanURL: A Privacy Aware Link Shortener

Abstract

Similar works

Full text

Available Versions

Kosmopolis

ScholarlyCommons@Penn