Protecting Users by Confining JavaScript with SWAPI Deian Stefan, - - PowerPoint PPT Presentation

▶
protecting users by confining javascript with swapi
SMART_READER_LITE
LIVE PREVIEW

Protecting Users by Confining JavaScript with SWAPI Deian Stefan, - - PowerPoint PPT Presentation

Jan 04, 2023 659 likes •1.65k views

Protecting Users by Confining JavaScript with SWAPI Deian Stefan, Petr Marchenko, Brad Karp, David Mazires, Dave Herman, and John C. Mitchell Modern websites are complex Modern websites are complex Modern websites are complex Page code

slide-1
SLIDE 1

Protecting Users by Confining JavaScript with SWAPI

Deian Stefan, Petr Marchenko, Brad Karp, David Mazières, Dave Herman, and John C. Mitchell

slide-2
SLIDE 2

Modern websites are complex

slide-3
SLIDE 3

Modern websites are complex

slide-4
SLIDE 4

Modern websites are complex

Page code

slide-5
SLIDE 5

Modern websites are complex

Page code Ad code

slide-6
SLIDE 6

Modern websites are complex

Page code Ad code Third-party APIs

slide-7
SLIDE 7

Modern websites are complex

Page code Third-party libraries Ad code Third-party APIs

slide-8
SLIDE 8

Modern websites are complex

Page code Third-party libraries Ad code Third-party APIs Extensions

slide-9
SLIDE 9

Modern websites handle sensitive information

  • Financial data

➤ Online banking, tax filing, shopping, budgeting, …

  • Health data

➤ Genomics, prescriptions, …

  • Personal data

➤ Email, messaging, affiliations, …

slide-10
SLIDE 10

Many parties are interested in the sensitive data

  • Financial data

➤ Black-hat hackers, …

  • Health data

➤ Insurance companies, …

  • Personal data

➤ Ad companies, big governments, …

slide-11
SLIDE 11

Many parties are interested in the sensitive data

  • Financial data

➤ Black-hat hackers, …

  • Health data

➤ Insurance companies, …

  • Personal data

➤ Ad companies, big governments, …

slide-12
SLIDE 12

Many parties are interested in the sensitive data

  • Financial data

➤ Black-hat hackers, …

  • Health data

➤ Insurance companies, …

  • Personal data

➤ Ad companies, big governments, …

slide-13
SLIDE 13

Many parties are interested in the sensitive data

  • Financial data

➤ Black-hat hackers, …

  • Health data

➤ Insurance companies, …

  • Personal data

➤ Ad companies, big governments, …

slide-14
SLIDE 14

How do we protect sensitive data?

Non requirements

… information exchange is still more important than secrecy.

Tim Berners-Lee, 1989

slide-15
SLIDE 15

How do we protect sensitive data?

Non requirements

… information exchange is still more important than secrecy.

Tim Berners-Lee, 1989

still somewhat true…

slide-16
SLIDE 16

How do we protect sensitive data?

Non requirements

… information exchange is still more important than secrecy.

Tim Berners-Lee, 1989

still somewhat true… but this was before the Web became the platform…

slide-17
SLIDE 17

What is the state of the art in web security?

  • Same Origin Policy
  • Content Security Policy
  • Sandboxing



 


slide-18
SLIDE 18

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

slide-19
SLIDE 19

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

slide-20
SLIDE 20

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

slide-21
SLIDE 21

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

postMessage

slide-22
SLIDE 22

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

postMessage

✓

slide-23
SLIDE 23

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

postMessage

✓

JSON

slide-24
SLIDE 24

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

postMessage

✓

JSON

slide-25
SLIDE 25

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

postMessage

✓

JSON

slide-26
SLIDE 26

Same Origin Policy

Idea: isolate content from different origins

➤ E.g., can’t access document of cross-origin page ➤ E.g., can’t inspect responses from cross-origin



 
 
 
 
 c.com b.com a.com

postMessage

✓

JSON

slide-27
SLIDE 27

Same Origin Policy

Limitations:

➤ Some DOM objects leak data

  • E.g., image size can leak if user is logged in

➤ Data exfiltration is trivial

  • E.g., any XHR request can contain data form page

➤ Cross-origin scripts run with privilege of page

➠ Injected scripts can corrupt and leak user data!

slide-28
SLIDE 28

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com a.com

slide-29
SLIDE 29

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

slide-30
SLIDE 30

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

✓

slide-31
SLIDE 31

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

✓

JSON

slide-32
SLIDE 32

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

✓

JSON

slide-33
SLIDE 33

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

✓

JSON

slide-34
SLIDE 34

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

✓

JSON

slide-35
SLIDE 35

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

✓

JSON

slide-36
SLIDE 36

Content Security Policy

Goal: prevent and limit damage of XSS attacks
 Idea: restrict resource loading to a white-list

➤ E.g., default-src ‘self’ http://b.com; img-src *



 
 
 
 
 c.com b.com a.com

✓

JSON

slide-37
SLIDE 37

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com a.com a.com

slide-38
SLIDE 38

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com a.com a.com

slide-39
SLIDE 39

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com a.com a.com unq0

slide-40
SLIDE 40

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com a.com a.com unq0

slide-41
SLIDE 41

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com

✓

a.com a.com unq0

slide-42
SLIDE 42

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com

✓

a.com a.com unq0

slide-43
SLIDE 43

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com

✓

a.com a.com unq0 unq1

slide-44
SLIDE 44

Sandboxing

Idea: restrict actions page can perform

➤ E.g., directive sandbox allow-scripts


ensures iframe has 
 unique origin

➤ E.g., directive sandbox


ensures iframe has 
 unique origin and cannot
 execute JavaScript


a.com a.com

✓

a.com a.com unq0 unq1

slide-45
SLIDE 45

Content Security Policy & Sandboxing

Limitations:

➤ Data exfiltration is only partly contained

  • Can leak to origins we can load resources from,


and sibling frames or child Workers (via postMessage)

➤ Scripts still run with privilege of page

  • Can we reason about security of jQuery-sized lib?
slide-46
SLIDE 46

What is the state of the art in web security?

  • Same Origin Policy
  • Content Security Policy
  • Sandboxing



 


slide-47
SLIDE 47

What is the state of the art in web security?

  • Same Origin Policy
  • Content Security Policy
  • Sandboxing



 


All-or-nothing discretionary access control: 
 access data ➠ ability to leak it

slide-48
SLIDE 48

Where this falls short…

slide-49
SLIDE 49

Where this falls short…

Third-party APIs

slide-50
SLIDE 50

Where this falls short…

Third-party APIs Mashups

slide-51
SLIDE 51

Where this falls short…

Third-party APIs Third-party libraries Mashups

slide-52
SLIDE 52

Where this falls short…

Third-party APIs Third-party libraries Mashups Third-party mashups

slide-53
SLIDE 53

Where this falls short…

Third-party APIs Third-party libraries Mashups Third-party mashups Extensions

slide-54
SLIDE 54

Where this falls short…

Third-party APIs Third-party libraries Mashups Third-party mashups Extensions

slide-55
SLIDE 55


 
 
 Guarantee: checker cannot leak password

➤ At worst: checker lies about strength of password

Password-strength checker

b.ru/chk.html a.com

slide-56
SLIDE 56

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

slide-57
SLIDE 57

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

p45s

slide-58
SLIDE 58

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

slide-59
SLIDE 59

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

slide-60
SLIDE 60

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

slide-61
SLIDE 61

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

slide-62
SLIDE 62

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

slide-63
SLIDE 63

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

slide-64
SLIDE 64

Confining the checker using existing mechanisms

  • Host the checker code on a.com
  • CSP & Sandboxing

➤ Need JavaScript: sandbox allow-scripts ➤ Restrict all communication: 


default-src ‘none’ ‘unsafe-inline’


a.com/chk.html a.com b.ru

Actually can leak to iframes, so 
 need to use also Workers…

slide-65
SLIDE 65

Why is this unsatisfactory?

  • Functionality of library is limited

➤ E.g., library cannot fetch resources from network

  • Requires server-side support to set policy
  • Security policy is not first-class

➤ Library cannot use code it itself doesn’t trust

  • Security policy is not symmetric

➤ Library cannot consider parent untrusted

slide-66
SLIDE 66

A new approach: Secure Web API

Idea (a): Provide means for associating security label with data

➤ E.g., password is sensitive to a.com

Idea (b): Ensure code is confined to obey labels by associating labels with browsing contexts

➤ E.g., password can only be sent to entities that

are as sensitive as a.com 
 (via XHR, postMessage, storage, …)

slide-67
SLIDE 67

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru a.com

slide-68
SLIDE 68

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru

public b.ru

a.com

a.com

slide-69
SLIDE 69

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru

public b.ru

?

a.com

a.com

slide-70
SLIDE 70

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru

public b.ru

a.com

a.com

slide-71
SLIDE 71

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

a.com

a.com

slide-72
SLIDE 72

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

a.com

a.com

slide-73
SLIDE 73

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

a.com

a.com

slide-74
SLIDE 74

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

a.com

a.com

slide-75
SLIDE 75

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

a.com

a.com

?

slide-76
SLIDE 76

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

a.com

a.com

slide-77
SLIDE 77

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru postMessage({level: “a.com”}, “b.ru” , Label())

?

a.com

a.com

slide-78
SLIDE 78

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru postMessage({level: “a.com”}, “b.ru” , Label())

a.com

a.com

slide-79
SLIDE 79

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

{level: “a.com”}

a.com

a.com

slide-80
SLIDE 80

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public public b.ru

{level: “a.com”}

a.com

a.com SWAPI.label = event.data.level;

slide-81
SLIDE 81

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru

{level: “a.com”}

a.com

a.com

a.com SWAPI.label = event.data.level;

slide-82
SLIDE 82

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru

{level: “a.com”}

a.com

a.com

a.com SWAPI.label = event.data.level;

slide-83
SLIDE 83

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com

slide-84
SLIDE 84

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com postMessage({pass: ...}, “b.ru” , Label(“a.com”))

?

slide-85
SLIDE 85

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com postMessage({pass: ...}, “b.ru” , Label(“a.com”))

?

{pass: ...}

slide-86
SLIDE 86

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com

{pass: ...}

slide-87
SLIDE 87

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com

slide-88
SLIDE 88

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com

slide-89
SLIDE 89

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com Can leak password to a.com
 Fix: create fresh labels to ensure checker is fully confined

slide-90
SLIDE 90

Confining the checker with SWAPI

  • Express sensitivity of data

➤ Checker can only receive password if its context

label is as sensitive as the password

  • Use new postMessage API to send password

➤ Source specifies sensitivity of data at time of send





a.com b.ru/chk.html b.ru

public b.ru a.com

a.com

a.com

slide-91
SLIDE 91

What can we do with this?

Third-party APIs Third-party libraries Mashups Third-party mashups Extensions

slide-92
SLIDE 92

Rest of SWAPI

  • Privileges

➤ Origin can use privilege to exfiltrate its own data

  • Labeled DOM (light-weight) workers

➤ Extensions: Untrusted code executed in unprivileged worker


Like Chrome-extension model, but uses confinement

➤ Third-party libs: Worker contains page TCB and page privilege


Confined page contains untrusted jQuery

  • Labeled XHR constructor

➤ Allow reading cross-origin responses, but restrict context

from writing it arbitrarily

slide-93
SLIDE 93

What can we do with this?

Third-party APIs Third-party libraries Mashups Third-party mashups Extensions

slide-94
SLIDE 94

What can we do with this?

Third-party APIs Third-party libraries Mashups Third-party mashups Extensions

And more…

slide-95
SLIDE 95

Implementation

  • A minimally intrusive implementation

➤ Set CSP & iframe sandbox dynamically, according to

context label

➤ Restrict postMessage and object access according

to context label (even for same origin contexts!)

➤ Opt-in: enabled when using any SWAPI feature

  • Implemented in Firefox and Chromium

➤ Negligible performance impact

slide-96
SLIDE 96

Summary

  • Client-side security mechanism
  • Security policy is first-class

➤ Any code can impose restrictions oh what the

receiver can do with the data before sending it

  • Security policy is symmetric

➤ Iframes and workers can impose restrictions on

parent code when sending messages

★ Consequence: don’t need to trade off functionality and security

slide-97
SLIDE 97

Thanks.
 Stay tuned…

Many thanks to Edward Z. Yang, Stefan Heule, Bobby Holley, Blake Kaplan, Garrett Robinson, and Brian Smith.

that can only talk to your friends that can only talk to your friends

————-——

—-—

————-——

—-—

————-——

—-—

————-——

—-—