1. CAMOUFLAGE:
AUTOMATED ANONYMIZATION
OF FIELD DATA
James Clause
University of Delaware
Alessandro Orso
Georgia Institute
of Technology

2. THE BIG PICTURE

3. THE BIG PICTURE

4. THE BIG PICTURE

5. THE BIG PICTURE

6. THE BIG PICTURE
• Apple crash reporter
• Windows error reporting
• Ubuntu Apport
• Gnome BugBuddy
• Mozilla / Google Breakpad
• many others
• Chilimbi and colleagues ’09
• Elbaum and Diep ’05
• Hilbert and Redmiles ’00
• Liblit and colleagues ’05
• Pavlopoulou andYoung ’99
• many others

7. PRIVACY CONCERNS

8. PRIVACY CONCERNS

9. Handling concerns in practice
PRIVACY CONCERNS

10. Handling concerns in practice
PRIVACY CONCERNS
• Ignore them

11. Handling concerns in practice
PRIVACY CONCERNS
• Ignore them
• Privacy policies

12. Handling concerns in practice
PRIVACY CONCERNS
• Ignore them
• Privacy policies
• Collect limited amounts of
information
• less likely to be sensitive
• can rely on user checking

13. PRIVACY CONCERNS
Unfortunately:
Register values
Stack dumps
Branch profiles
Path profiles
Test cases
Usefulness

14. PRIVACY CONCERNS
Privacy concerns
Unfortunately:
Register values
Stack dumps
Branch profiles
Path profiles
Test cases
Usefulness

15. PRIVACY CONCERNS
Privacy concerns
Unfortunately:
Register values
Stack dumps
Branch profiles
Path profiles
Test cases
Usefulness
GOAL: Enable the collection of detailed information
while reducing or eliminating privacy concerns.

16. PRIVACY CONCERNS
Privacy concerns
Unfortunately:
Register values
Stack dumps
Branch profiles
Path profiles
Test cases
Usefulness
GOAL: Enable the collection of detailed information
while reducing or eliminating privacy concerns.

17. OUTLINE
• Intuition
• Castro and colleagues’ technique
• Our improvements
• Path condition relaxation
• Breakable input conditions
• Evaluation
• Related work
• Conclusions and future work

18. Sensitive
input (I)
that causes F
Input domain
INTUITION

19. Sensitive
input (I)
that causes F
Input domain
Inputs that
cause F
INTUITION

20. Sensitive
input (I)
that causes F
Input domain
Inputs that
cause F
INTUITION
Anonymized
input (I’)
that also
causes F

21. Inputs that satisfy
F’s path condition Sensitive
input (I)
that causes F
Input domain
Inputs that
cause F
INTUITION
Anonymized
input (I’)
that also
causes F

22. CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
Path condition: set of constraints on a program’s
inputs that encode the conditions necessary for a
specific path to be executed.

23. boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)

24. boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
(sensitive)

25. Path Condition:
Symbolic State:
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
(sensitive)

26. Path Condition:
Symbolic State:
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
(sensitive)

27. Path Condition:
Symbolic State:
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
(sensitive)

28. Path Condition:
i1 <= 5
Symbolic State:
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
(sensitive)

29. Path Condition:
i1 <= 5
Symbolic State:
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
(sensitive)

30. Path Condition:
i1 <= 5
Symbolic State:
a→i1*2
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
(sensitive)

31. Path Condition:
i1 <= 5
Symbolic State:
a→i1*2
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
(sensitive)

32. Path Condition:
i1 <= 5
Symbolic State:
a→i1*2
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
∧ i2+i1*2 > 10
(sensitive)

33. Path Condition:
i1 <= 5
Symbolic State:
a→i1*2
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
∧ i2+i1*2 > 10
(sensitive)

34. Path Condition:
i1 <= 5
Symbolic State:
a→i1*2
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
CASTRO AND COLLEAGUES’ TECHNIQUE
(PATH CONDITION GENERATION)
5 3 0
x→i1
y→i2
z→i3
∧ i2+i1*2 > 10
∧ i3 == 0
(sensitive)

35. i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
CASTRO AND COLLEAGUES’ TECHNIQUE
(CHOOSING ANONYMIZED INPUTS)

36. Constraint
Solver
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
CASTRO AND COLLEAGUES’ TECHNIQUE
(CHOOSING ANONYMIZED INPUTS)

37. Constraint
Solver
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
i1 == 5
i2 == 3
i3 == 0
CASTRO AND COLLEAGUES’ TECHNIQUE
(CHOOSING ANONYMIZED INPUTS)

38. OUR IMPROVEMENTS
Increase the number of
possible choices for I’
Chose I’ such that it is
as different as possible from I

39. OUR IMPROVEMENTS
Increase the number of
possible choices for I’
Chose I’ such that it is
as different as possible from I

40. PATH CONDITION RELAXATION
Sensitive
input (I)
that causes F
Input domain

41. PATH CONDITION RELAXATION
Sensitive
input (I)
that causes F
Input domain

42. PATH CONDITION RELAXATION
Sensitive
input (I)
that causes F
Input domain

43. PATH CONDITION RELAXATION
Sensitive
input (I)
that causes F
Input domain

44. PATH CONDITION RELAXATION
Sensitive
input (I)
that causes F
Input domain

45. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads

46. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads

47. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
x.equals(y);

48. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
x.equals(y);
abc abd

49. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
x.equals(y);
Traditional:
x0 == y0
∧ x1 == y1
∧ x2 != y2
abc abd

50. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
x.equals(y);
Traditional:
x0 == y0
∧ x1 == y1
∧ x2 != y2
Relaxed:
x0 != y0
∨ x1 != y1
∨ x2 != y2
abc abd

51. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads

52. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads

53. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}

54. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}
5

55. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}
Traditional:
x == 5
5

56. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
Relaxed:
x == 5
∨ x == 3
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}
Traditional:
x == 5
5

57. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}

58. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}
10

59. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}
Traditional:
x == 10
10

60. PATH CONDITION RELAXATION
1.Array inequalities 3. Multi-clause conditionals
2. Switch statements 4.Array reads
switch(x) {
case 1:
...
break;
case 3:
case 5:
...
break;
default:
...
}
Traditional:
x == 10
Relaxed:
x != 1
∧ x != 3
∧ x != 5
10

61. OUR IMPROVEMENTS
Increase the number of
possible choices for I’
Chose I’ such that it is
as different as possible from I

62. Constraint
Solver
BREAKABLE INPUT CONDITIONS
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0 i1 == 5
i2 == 3
i3 == 0

63. Constraint
Solver
BREAKABLE INPUT CONDITIONS
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0 i1 == 5
i2 == 3
i3 == 0
boolean foo(int x, int y, int z) {
if(x <= 5) {
int a = x * 2;
if(y + a > 10) {
if(z == 0) {
return true;
}
}
}
return false;
}
5 3 0

64. Constraint
Solver
BREAKABLE INPUT CONDITIONS
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0

65. Constraint
Solver
BREAKABLE INPUT CONDITIONS
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0

66. Constraint
Solver
BREAKABLE INPUT CONDITIONS
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0

67. Constraint
Solver
BREAKABLE INPUT CONDITIONS
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0

68. Constraint
Solver
BREAKABLE INPUT CONDITIONS
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0
i1 == 4
i2 == 10
i3 == 0

69. ASSUMPTIONS

70. ASSUMPTIONS
1. The failure f is observable and can be detected with an
assertion.
‣ common to all debugging techniques; holds in most, if not all, cases.

71. ASSUMPTIONS
1. The failure f is observable and can be detected with an
assertion.
‣ common to all debugging techniques; holds in most, if not all, cases.
2. Any input that satisfies the path condition results in f.
• Non-determinism
‣ common to all debugging techniques; requires a deterministic
replay mechanism
• Implicit checks (e.g., division by zero)
‣ likely that they do not involve relevant inputs
‣ make implicit checks explicit (e.g., 100/x → assert x != 0)

72. ASSUMPTIONS

73. ASSUMPTIONS
✘

74. ASSUMPTIONS
✘

76. 1. The failure f is observable and can be detected with an
assertion.
‣ common to all debugging techniques; holds in most, if not all, cases.

77. 1. The failure f is observable and can be detected with an
assertion.
‣ common to all debugging techniques; holds in most, if not all, cases.
2. Any input that satisfies the path condition results in f.
• Non-determinism
‣ common to all debugging techniques; requires a deterministic
replay mechanism
• Implicit checks (e.g., division by zero)
‣ likely that they do not involve relevant inputs
‣ make implicit checks explicit (e.g., 100/x → assert x != 0)

79. EVALUATION

80. EVALUATION
1 Feasibility
Can the approach
generate, in a reasonable
amount of time,
anonymized inputs that
reproduce a failure?

81. EVALUATION
1 Feasibility
Can the approach
generate, in a reasonable
amount of time,
anonymized inputs that
reproduce a failure?
Strength
How much information
about the original inputs
is revealed?
2

82. EVALUATION
Effectiveness
Are the anonymized
inputs safe to send to
developers?
31 Feasibility
Can the approach
generate, in a reasonable
amount of time,
anonymized inputs that
reproduce a failure?
Strength
How much information
about the original inputs
is revealed?
2

83. EVALUATION
Effectiveness
Are the anonymized
inputs safe to send to
developers?
31 Feasibility
Can the approach
generate, in a reasonable
amount of time,
anonymized inputs that
reproduce a failure?
Strength
How much information
about the original inputs
is revealed?
2 4 Improvement
Does the use of path
condition relaxation and
breakable input
conditions provide any
benefits over the basic
approach?

84. i1 == 4
i2 == 10
i3 == 0
Constraint
Solver
PROTOTYPE IMPLEMENTATION
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0

85. i1 == 4
i2 == 10
i3 == 0
Constraint
Solver
PROTOTYPE IMPLEMENTATION
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0
Java
Pathfinder
Java
Pathfinder

86. i1 == 4
i2 == 10
i3 == 0
Constraint
Solver
PROTOTYPE IMPLEMENTATION
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0
Java
Pathfinder
Java
Pathfinder
Yices

87. i1 == 4
i2 == 10
i3 == 0
Constraint
Solver
PROTOTYPE IMPLEMENTATION
Path Condition:
i1 <= 5
∧ i2+i1*2 > 10
∧ i3 == 0
Breakable
Input Condition:
i1 != 5
∧ i2 != 3
∧ i3 != 0
Java
Pathfinder
Java
Pathfinder
Yices
Ruby
scripts
Executable
inputs

88. SUBJECTS
• Columba: 1 fault
• htmlparser: 1 fault
• Printtokens: 2 faults
• NanoXML: 16 faults
(20 faults, total)

89. SUBJECTS
• Columba: 1 fault
• htmlparser: 1 fault
• Printtokens: 2 faults
• NanoXML: 16 faults
Select sensitive failure-inducing inputs
• 170 total inputs
• manually generated or included with subject
• 100 bytes to 5MB in size
(20 faults, total)

90. SUBJECTS
• Columba: 1 fault
• htmlparser: 1 fault
• Printtokens: 2 faults
• NanoXML: 16 faults
Select sensitive failure-inducing inputs
• 170 total inputs
• manually generated or included with subject
• 100 bytes to 5MB in size
(Assume all of each input is potentially sensitive)
(20 faults, total)

91. RQ1:FEASIBILITY
0
150
300
450
600
0
5
10
15
20
columba
htmlparser
printtokens1
printtokens2
nanoxml1
nanoxml2
nanoxml3
nanoxml4
nanoxml5
nanoxml6
nanoxml7
nanoxml8
nanoxml9
nanoxml10
nanoxml11
nanoxml12
nanoxml13
nenoxml14
nanoxml15
nanoxml16
Average
executiontime(s)
Average
solvertime(s)

92. RQ1:FEASIBILITY
0
150
300
450
600
0
5
10
15
20
columba
htmlparser
printtokens1
printtokens2
nanoxml1
nanoxml2
nanoxml3
nanoxml4
nanoxml5
nanoxml6
nanoxml7
nanoxml8
nanoxml9
nanoxml10
nanoxml11
nanoxml12
nanoxml13
nenoxml14
nanoxml15
nanoxml16
Average
executiontime(s)
Average
solvertime(s)
Inputs can be anonymized in a reasonable
amount of time (easily done overnight)

93. Average % Bits Revealed Average % Residue
RQ2: STRENGTH

94. Average % Bits Revealed Average % Residue
RQ2: STRENGTH
Measures how many inputs
that satisfy the path
condition
Little
information revealed

95. Average % Bits Revealed Average % Residue
RQ2: STRENGTH
Measures how many inputs
that satisfy the path
condition
Lots of
information revealed

96. Average % Bits Revealed Average % Residue
RQ2: STRENGTH
Measures how many inputs
that satisfy the path
condition
Measures how much of the
anonymized input is identical
to the original input
AAAAAA
secret
AAAAAA
...
AAAAAA
BBBBBB
secret
BBBBBB
...
BBBBBB
I’
Lots of
information revealed
I

97. Average % Bits Revealed Average % Residue
RQ2: STRENGTH
Measures how many inputs
that satisfy the path
condition
Measures how much of the
anonymized input is identical
to the original input
AAAAAA
secret
AAAAAA
...
AAAAAA
BBBBBB
secret
BBBBBB
...
BBBBBB
I’
Lots of
information revealed
I

98. RQ2: STRENGTH
0
25
50
75
100
0
25
50
75
100
columba
htmlparser
printtokens1
printtokens2
nanoxml1
nanoxml2
nanoxml3
nanoxml4
nanoxml5
nanoxml6
nanoxml7
nanoxml8
nanoxml9
nanoxml10
nanoxml11
nanoxml12
nanoxml13
nenoxml14
nanoxml15
nanoxml16
Average
%BitsRevealed
Average
%Residue

99. RQ2: STRENGTH
0
25
50
75
100
0
25
50
75
100
columba
htmlparser
printtokens1
printtokens2
nanoxml1
nanoxml2
nanoxml3
nanoxml4
nanoxml5
nanoxml6
nanoxml7
nanoxml8
nanoxml9
nanoxml10
nanoxml11
nanoxml12
nanoxml13
nenoxml14
nanoxml15
nanoxml16
Average
%BitsRevealed
Average
%Residue
Anonymized inputs reveal, on average, between
60% (worst case) and 2% (best case) of the
information in the original inputs

100. RQ3: EFFECTIVENESS
NANOXML
<!DOCTYPE Foo [
<!ELEMENT Foo (ns:Bar)>
<!ATTLIST Foo
xmlns CDATA #FIXED 'http://nanoxml.n3.net/bar'
a CDATA #REQUIRED>
<!ELEMENT ns:Bar (Blah)>
<!ATTLIST ns:Bar
xmlns:ns CDATA #FIXED 'http://nanoxml.n3.net/bar'>
<!ELEMENT Blah EMPTY>
<!ATTLIST Blah
x CDATA #REQUIRED
ns:x CDATA #REQUIRED>
]>
<!-- comment -->
<Foo a='very' b='secret' c='stuff'>vaz
<ns:Bar>
<Blah x="1" ns:x="2"/>
</ns:Bar>
</Foo>

101. RQ3: EFFECTIVENESS
NANOXML
<!DOCTYPE [
<! >
<!ATTLIST
#FIXED ' '
>
<!E >
<!ATTLIST
#FIXED ' '>
<!E >
<!ATTLIST
#
: # >
]>
<!-- -->
< =' ' =' ' =' '>
< : >
< =" " : =" "/>
</ :

102. Wayne,Bartley,Bartley,Wayne,wbartly@acp.com,,
Ronald,Kahle,Kahle,Ron,ron.kahle@kahle.com,,
Wilma,Lavelle,Lavelle,Wilma,,lavelle678@aol.com,
Jesse,Hammonds,Hammonds,Jesse,,hamj34@comcast.com,
Amy,Uhl,Uhl,Amy,uhla@corp1.com,uhla@gmail.com,
Hazel,Miracle,Miracle,Hazel,hazel.miracle@corp2.com,,
Roxanne,Nealy,Nealy,Roxie,,roxie.nearly@gmail.com,
Heather,Kane,Kane,Heather,kaneh@corp2.com,,
Rosa,Stovall,Stovall,Rosa,,sstoval@aol.com,
Peter,Hyden,Hyden,Pete,,peteh1989@velocity.net,
Jeffrey,Wesson,Wesson,Jeff,jwesson@corp4.com,,
Virginia,Mendoza,Mendoza,Ginny,gmendoza@corp4.com,,
Richard,Robledo,Robledo,Ralph,ralphrobledo@corp1.com,,
Edward,Blanding,Blanding,Ed,,eblanding@gmail.com,
Sean,Pulliam,Pulliam,Sean,spulliam@corp2.com,,
Steven,Kocher,Kocher,Steve,kocher@kocher.com,,
Tony,Whitlock,Whitlock,Tony,,tw14567@aol.com,
Frank,Earl,Earl,Frankie,,,
Shelly,Riojas,Riojas,Shelly,srojas@corp6.com,,
RQ3: EFFECTIVENESS
COLUMBA
, , , , ,,
, , , , ,,
, , , ,, ,
, , , ,, ,
, , , , , ,
, , , , ,,
, , , ,, ,
, , , , ,,
, , , ,, ,
, , , ,, ,
, , , , ,,
, , , , ,,
, , , , ,,
, , , ,, ,
, , , , ,,
, , , , ,,
, , , ,, ,
, , , ,,,

103. RQ3: EFFECTIVENESS
COLUMBA
, , , , ,,
, , , , ,,
, , , ,, ,
, , , ,, ,
, , , , , ,
, , , , ,,
, , , ,, ,
, , , , ,,
, , , ,, ,
, , , ,, ,
, , , , ,,
, , , , ,,
, , , , ,,
, , , ,, ,
, , , , ,,
, , , , ,,
, , , ,, ,
, , , ,,,

104. RQ3: EFFECTIVENESS
HTMLPARSER
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/
xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>james clause @ gatech | home</title>
<style type="text/css" media="screen" title="">
<!--/*--><![CDATA[<!--*/
body {
margin: 0px;
...
/*]]>*/-->
</style>
</head>
<body>
...
</body>

105. RQ3: EFFECTIVENESS
HTMLPARSER
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/
xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>james clause @ gatech | home</title>
<style type="text/css" media="screen" title="">
<!--/*--><![CDATA[<!--*/
body {
margin: 0px;
...
/*]]>*/-->
</style>
</head>
<body>
...
</body>

106. RQ3: EFFECTIVENESS
HTMLPARSER
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/
xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>james clause @ gatech | home</title>
<style type="text/css" media="screen" title="">
<!--/*--><![CDATA[<!--*/
body {
margin: 0px;
...
/*]]>*/-->
</style>
</head>
<body>
...
</body>
The portions of the inputs that remain after
anonymization tend to be structural in nature and
therefore are safe to send to developers

107. RQ4: IMPROVEMENT

108. RQ4: IMPROVEMENT
0
25
50
75
100
0
25
50
75
100
columba
htmlparser
printtokens1
printtokens2
nanoxml1
nanoxml2
nanoxml3
nanoxml4
nanoxml5
nanoxml6
nanoxml7
nanoxml8
nanoxml9
nanoxml10
nanoxml11
nanoxml12
nanoxml13
nenoxml14
nanoxml15
nanoxml16
%Improvement
BitsRevealed
%Improvement
Residue

109. RQ4: IMPROVEMENT
0
25
50
75
100
0
25
50
75
100
columba
htmlparser
printtokens1
printtokens2
nanoxml1
nanoxml2
nanoxml3
nanoxml4
nanoxml5
nanoxml6
nanoxml7
nanoxml8
nanoxml9
nanoxml10
nanoxml11
nanoxml12
nanoxml13
nenoxml14
nanoxml15
nanoxml16
%Improvement
BitsRevealed
%Improvement
Residue
Inputs anonymized using our improvements
reveal an average of 30% less bits of information
and 40% less residue.
(With only a marginal increase in time.)

110. RELATED WORK

111. RELATED WORK
• Castro and colleagues ’08

112. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03

113. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03
• Uses dynamic taint analysis to identify and remove sensitive information in crash
dumps.

114. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03
• Uses dynamic taint analysis to identify and remove sensitive information in crash
dumps.
• Wang and colleagues ’08

115. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03
• Uses dynamic taint analysis to identify and remove sensitive information in crash
dumps.
• Wang and colleagues ’08
• Uses a combination of dynamic taint analysis, symbolic execution and Q/A with a
client machine to construct anonymized inputs

116. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03
• Uses dynamic taint analysis to identify and remove sensitive information in crash
dumps.
• Wang and colleagues ’08
• Uses a combination of dynamic taint analysis, symbolic execution and Q/A with a
client machine to construct anonymized inputs
• Data set anonymization techniques (e.g., k-anonymization)

117. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03
• Uses dynamic taint analysis to identify and remove sensitive information in crash
dumps.
• Wang and colleagues ’08
• Uses a combination of dynamic taint analysis, symbolic execution and Q/A with a
client machine to construct anonymized inputs
• Data set anonymization techniques (e.g., k-anonymization)
• Budi and colleagues ’11

118. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03
• Uses dynamic taint analysis to identify and remove sensitive information in crash
dumps.
• Wang and colleagues ’08
• Uses a combination of dynamic taint analysis, symbolic execution and Q/A with a
client machine to construct anonymized inputs
• Data set anonymization techniques (e.g., k-anonymization)
• Budi and colleagues ’11
• Grechanik and colleagues ’11

119. RELATED WORK
• Castro and colleagues ’08
• Broadwell and colleagues ’03
• Uses dynamic taint analysis to identify and remove sensitive information in crash
dumps.
• Wang and colleagues ’08
• Uses a combination of dynamic taint analysis, symbolic execution and Q/A with a
client machine to construct anonymized inputs
• Data set anonymization techniques (e.g., k-anonymization)
• Budi and colleagues ’11
• Grechanik and colleagues ’11
• Dynamic symbolic execution techniques

120. FUTURE WORK

121. FUTURE WORK
• Additional quality metrics that:
• consider additional aspects of privacy loss
• consider the relative sensitivity of different inputs
• are intuitive and easy to use

122. FUTURE WORK
• Additional quality metrics that:
• consider additional aspects of privacy loss
• consider the relative sensitivity of different inputs
• are intuitive and easy to use
• Conduction additional (human) studies
• additional (larger) subjects

123. FUTURE WORK
• Additional quality metrics that:
• consider additional aspects of privacy loss
• consider the relative sensitivity of different inputs
• are intuitive and easy to use
• Conduction additional (human) studies
• additional (larger) subjects
• Investigate the combination of anonymization and
minimization

124. SUMMARY

125. SUMMARY
1. An approach for automatically anonymizing failure-inducing
inputs
• extends Castro and colleagues’ technique through the
novel concepts of path condition relaxation and
breakable input conditions

126. SUMMARY
1. An approach for automatically anonymizing failure-inducing
inputs
• extends Castro and colleagues’ technique through the
novel concepts of path condition relaxation and
breakable input conditions
2. An empirical evaluation that demonstrates, for the subjects
considered, our approach is:
• feasible — generates anonymized inputs in < 10 minutes
• effective — anonymized inputs did not contain sensitive
information
• an improvement over the state-of-the-art

127. QUESTIONS?