Verifying Web Browser Extensions’ Compliance with Private-Browsing Mode

Lerner, Benjamin S.; Elberty, Liam; Poole, Neal; Krishnamurthi, Shriram

doi:10.1007/978-3-642-40203-6_4

Cited by 29 publications

(23 citation statements)

References 11 publications

(12 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Lerner et al [9] examine Mozilla Firefox extensions for potential violations of private browsing mode. In this mode, browsers should not leave on disk any data that relates to the user's private browsing session.…”

Section: Violations Of Private Browsing In Extensionsmentioning

confidence: 99%

“…Progressive Types The ADsafety and private browsing projects [9,15] used type systems to ensure safety properties on target programs, but perhaps surprisingly, allowed programs to typecheck that contained obvious "traditional" type errors, such as possibly having a non-function in functioncall position. Such errors could not compromise the intended safety guarantees (as erroneous code would just halt), and so did not need to be prevented.…”

Section: Extensible or Modular Type Systemsmentioning

confidence: 99%

See 1 more Smart Citation

TeJaS

Lerner

Politz

Guha

et al. 2013

Proceedings of the 9th Symposium on Dynamic Languages

Self Cite

View full text Add to dashboard Cite

JavaScript programs vary widely in functionality, complexity, and use, and analyses of these programs must accommodate such variations. Type-based analyses are typically the simplest such analyses, but due to the language's subtle idioms and many application-specific needs-such as ensuring general-purpose type correctness, security properties, or proper library usage-we have found that a single type system does not suffice for all purposes. However, these varied uses still share many reusable common elements.In this paper we present TeJaS, a framework for building type systems for JavaScript. TeJaS has been engineered modularly to encourage experimentation. Its initial type environment is reified, to admit easy modeling of the various execution contexts of JavaScript programs, and its type language and typing rules are extensible, to enable variations of the type system to be constructed easily.The paper presents the base TeJaS type system, which performs traditional type-checking for JavaScript. Because JavaScript demands complex types, we explain several design decisions to improve user ergonomics. We then describe TeJaS's modular structure, and illustrate it by reconstructing the essence of a very different type system for JavaScript. Systems built from TeJaS have been applied to several real-world, third-party JavaScript programs.There is a venerable line of research on retrofitting type systems onto previously "untyped" languages, with Morris's seminal dissertation [11] an early example. In practice, these languages are not actually free of types; rather, all type discrimination is performed by primitive operations at runtime. A common practice for retrofitting type systems has been to identify the resulting set of run-time errors and try to eliminate them statically. For instance, Smalltalk type systems [1, 22] focused on eliminating message-not-found errors, and Soft Scheme [25] addressed the wide range of Scheme dynamic errors. Identifying run-time errors and catching them statically can be viewed as the design principle for retrofitted type systems.Unfortunately, this principle is rather difficult to apply to JavaScript (JS), because there are so few actual run-time errors. 1 In this, JS inherits the forgiving mentality of the browser environment where it was born; instead of flagging errors and halting execution, it simply continues running. As a result, operations that in other languages might reasonably be expected to generate errors do not in JS: subtracting one string from another, accessing an array outside its bounds, reading and writing non-existent fields, calling functions with the wrong number of arguments, etc.Obviously, every one of these operations has a welldefined semantics in JS (usually, ironically, involving the value undefined). Therefore, it becomes a purpose-specific judgment call whether or not these should be considered static type errors. If the purpose is to enforce a strict, Javalike programming style, they should probably all be considered errors. If, in contrast, the goal is ...

show abstract

Section: Violations Of Private Browsing In Extensionsmentioning

confidence: 99%

Section: Extensible or Modular Type Systemsmentioning

confidence: 99%

TeJaS

Lerner

Politz

Guha

et al. 2013

Proceedings of the 9th Symposium on Dynamic Languages

Self Cite

View full text Add to dashboard Cite

show abstract

“…Veil does not try to stop information leaks from GPU RAM [31], but GPU RAM is never swapped to persistent storage. Poorly-written or malicious browser extensions that leak sensitive page data [32] are also outside the scope of this paper.…”

Section: Threat Modelmentioning

confidence: 99%

Veil: Private Browsing Semantics Without Browser-side Assistance

Wang

Mickens

Zeldovich

2018

Proceedings 2018 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…Similarly, Lerner et al [34,35] extend JavaScript with a type system to statically verify that extensions do not violate the browser's private browsing mode; their approach requires developers to write annotations only where code might violate private browsing expectations. It also requires a skilled auditor to manually verify declassifications.…”

Section: Collaborative Modelmentioning

confidence: 99%

Collaborative Verification of Information Flow for a High-Assurance App Store

Ernst

Just

Millstein

et al. 2014

Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security

View full text Add to dashboard Cite

Current app stores distribute some malware to unsuspecting users, even though the app approval process may be costly and timeconsuming. High-integrity app stores must provide stronger guarantees that their apps are not malicious. We propose a verification model for use in such app stores to guarantee that the apps are free of malicious information flows. In our model, the software vendor and the app store auditor collaborate -each does tasks that are easy for her/him, reducing overall verification cost. The software vendor provides a behavioral specification of information flow (at a finer granularity than used by current app stores) and source code annotated with information-flow type qualifiers. A flow-sensitive, context-sensitive information-flow type system checks the information flow type qualifiers in the source code and proves that only information flows in the specification can occur at run time. The app store auditor uses the vendor-provided source code to manually verify declassifications.We have implemented the information-flow type system for Android apps written in Java, and we evaluated both its effectiveness at detecting information-flow violations and its usability in practice. In an adversarial Red Team evaluation, we analyzed 72 apps (576,000 LOC) for malware. The 57 Trojans among these had been written specifically to defeat a malware analysis such as ours. Nonetheless, our information-flow type system was effective: it detected 96% of malware whose malicious behavior was related to information flow and 82% of all malware. In addition to the adversarial evaluation, we evaluated the practicality of using the collaborative model. The programmer annotation burden is low: 6 annotations per 100 LOC. Every sound analysis requires a human to review potential false alarms, and in our experiments, this took 30 minutes per 1,000 LOC for an auditor unfamiliar with the app.

show abstract

Verifying Web Browser Extensions’ Compliance with Private-Browsing Mode

Cited by 29 publications

References 11 publications

TeJaS

TeJaS

Veil: Private Browsing Semantics Without Browser-side Assistance

Collaborative Verification of Information Flow for a High-Assurance App Store

Contact Info

Product

Resources

About