Heading image Heading image Heading image Heading image HTTPS://ARTURJANC.COM:443/

This is Artur Janc, possibly.
I work on the security and privacy of the web platform, focusing on the design of security mechanisms to protect web applications from common classes of vulnerabilities. This includes Content Security Policy, Fetch Metadata Request Headers, and Cross-Origin Opener Policy.

By day I'm a senior staff software engineer at Google, managing a team responsible for deploying security features across some of the web's most sensitive sites. We help other application owners by giving talks, building and sharing tools, and writing developer documentation.

I do security research and reviews of upcoming web platform features at W3C WebAppSec and through the Chrome intent triage process. Once in a while I also get away with starting substantial projects, but more often than not I tend to churn out random hacks.

If you're interested in this work, see the contact section below.
New & Popular
[2020] [talk] Isolation: The next web application security frontier (LocoMocoSec 2020) [...]
[2020] [blog post] Towards native security defenses for the web ecosystem (Google Security Blog) [...]
[2020] [research] Information Leaks via Safari's Intelligent Tracking Prevention (Google Research) [...]

[2019] [talk] Baby steps towards the precipice: How the web became a scary place and how we can fix it (USENIX Security 2019) [...]
[2019] [talk] Securing web apps with modern platform features (Google I/O 2019) [...]
Talks ...
Isolation: The next web application security frontier [...]
Application security engineers frequently grapple with the fact that web origins are only incidentally separated from one another; web security rules permit a surprising number of interactions which can be used to modify or infer the state of unrelated applications. The resulting attack surface is -- sadly -- one of the defining characteristics of the web security model, enabling multiple classes of hard-to-fix information leaks.

In recent years, the lack of true web isolation has led to problems on three main fronts. First, vulnerabilities exploitable via malicious cross-site interactions, such as CSRF and XSSI have continued to plague major applications. Second, XS-Leaks research has identified practical new attacks that exploit both legacy and new web platform behaviors, and resulted in new avenues to leak cross-origin data. Finally, transient execution vulnerabilities such as Spectre and Meltdown broke the illusion that the web is immune to CPU-level bugs, demonstrating tractable cross-site attacks based on leaking data in the address space of the attacking origin's web renderer process.

In response, web browsers have proposed and implemented major security mechanisms that give application developers the ability to lock down their applications from unwanted cross-origin interactions.

This talk covers the details of these features, focusing on Fetch Metadata Request Headers and Cross-Origin Opener Policy as means to isolate an application from the rest of the web. We share information from production rollouts of these features at Google to review deployment strategies and potential pitfalls. We also brainstorm the types of attacks that may be possible even in light of these restrictions, and discuss application patterns that developers will need to change to more comprehensively defend their sites.
⌖ LocoMocoSec 2020 [slides & video]

Baby steps towards the precipice: How the web became a scary place and how we can fix it [...]
This talk grappled with a fairly important question: what lies at the heart of the widespread insecurity of the web ecosystem?

The answer — at least in part — can be traced back to design choices made decades ago, when the goals and trade-offs for decisions affecting the web were fundamentally different than they are today. That is, the stunning success of the web as an application platform led to a situation where the security properties of the web haven't kept pace with the popularity and sensitivity of its applications.

Specifically, the talk argues for addressing the lack of safety of the web in three ways: designing new security mechanisms, deprecating unsafe legacy behaviors, and emphasizing security and privacy during the design of new web APIs.

Appropriately for a serious venue such as USENIX, the slides also feature dancing hamsters.
⌖ USENIX Security 2019 [slides]

Securing Web apps with modern platform features [...]
Recognizing the importance of adding security mechanisms to the web platform, browser vendors have recently shipped a bevy of powerful features that allow developers to protect their applications. This talk goes into detail about two major types of web security problems: injections and lack of isolation, and discusses four modern security mechanisms that protect against them: CSP3, Trusted Types, Fetch Metadata Request Headers, and Cross-Origin Opener Policy.

Here is the talk in one slide: Google I/O 2019 summary slide If you prefer your information in video form, you can watch this talk on YouTube.
⌖ Google I/O & Voxxed Days Singapore 2019 [slides]

Web application vulnerability trends in the wild [...]
This talk gives an overview of the classes of vulnerabilities affecting the Google ecosystem, focusing on web application bugs — the majority of the high-risk issues reported under the Google VRP.

Going somewhat beyond reviewing bug trends, the talk categorizes web security issues into three main classes: lack of transport safety, injections, and cross-site leaks. It outlines how the specifications owned by the W3C WebAppSec working group map to the defensive mechanisms application developers need to secure their applications.

It is a precursor to the USENIX Security talk.
⌖ W3C TPAC, WebAppSec 2018 [slides]

Content Security Policy adoption at Google [...]
This short talk described the results of the adoption of strict CSP at Google, including a review of browser features that would help application developers during their CSP deployments.

The second half of the talk discusses results from a study of the feasibility of adopting suborigins based on data from an experimental Chrome extension to test suborigins compatibility.
⌖ W3C TPAC, WebAppSec 2017 [slides]

Security in the world of JS frameworks [...]
Modern JavaScript frameworks make web development much easier, but they also carry a risk of introducing new classes of vulnerabilities. In particular, given the ease with which XSS bugs can creep into an otherwise well-behaved codebase, new client-side APIs carry the risk of introducing new inection vectors.

This talk provices an overview of the types of vulnerabilities common in AngularJS applications, from client-side template injections to XSS in native AngularJS APIs such as $http.jsonp, $http.get, $interpolate, $compile, and $parse.
⌖ JSConf EU 2015 [slides]

Rootkits in your web application [...]
What's the worst that can happen when your application suffers from XSS? We're all used to demonstrating injections with alert(document.domain), but it's worthwhile to think about the malicious potential of a serious XSS bug in a sensitive applica­tion, especially if exploited by a motivated and capable attacker.

This talk goes into detail about the avenues to achieve persistence after script execution, pointing out a fair number of similarities to system-level compromises.
⌖ 28th Chaos Commnication Congress, 2011 [slides]

Feasibility and real-world implications of web browser history detection [...]
This W2SP talk discussed the dangers of attacks on browsing history using the CSS :visited pseudoclass. In a nutshell, it was bad (more details are in the papers linked in the research section) and browser vendors took steps to fix the problem.
⌖ Web 2.0 Security and Privacy workshop, 2010 [slides]
Projects ...
Light Sensor project icon
The ambient light sensor can – surprisingly – be used to leak cross-site data. This tiny project shows how. [...]
Conducted in collaboration with Lukasz Olejnik, this bit of practical research demonstrated the potential of the AmbientLightSensor API to leak sensitive data to websites.

In short, readings from the sensor may allow websites to infer the color of the user's screen; in the simplest variant, determine whether it's black or white depending on the amount of reflected light reaching the sensor. Interestingly, this becomes a side-channel information leak in cases where the website is prohibited from directly learning the color of the screen (for example when displaying cross-origin frames or images).

Light sensor project screenshot

All the cool details are described in Lukasz's blog post.

A popular wargame with real code examples explaining how to exploit XSS bugs and defend against them. [...]
One of the best ways to understand the common patterns of web vulnerabilities — XSS, CSRF, clickjacking and XS-leaks — is to try your hand at exploiting them in a real, vulnerable application.

The XSS Game, meant for regular web developers rather than seasoned security professionals, is a simple introduction to the topic of cross-site scripting, guiding the player through six levels of increasing difficulty. It is an external version of a security exercise used for many years as part of the Google SWE onboarding process.

The game has been played by hundreds of thousands of developers and is a common part of a considerable number of web security courses.

XSS Game screenshot

Note: Since this project launched, several high-quality web security resources have sprung up, offering a more comprehensive introduction to web security. If you're looking for a refresher course, check out the Web Security Academy.

History detection project icon
A proof-of-concept of the impact of history detection, including fairly smart detectors for sensitive data. [...]
Since the very beginnings of the web, the CSS :visited pseudoclass has been known to reveal users' web browsing histories by allowing sites to style visited links differently from unvisited ones and then read the color with which the links are displayed.

whattheinternetknowsaboutyou.com (WTIKAY) was a site demonstrating the privacy impact of this information leak, showing how any web page could check for millions of visited URLs in a matter of minutes. WTIKAY used some fairly nifty tricks such as highly optimized history detection and integration with search engines to perform a deep checks of URLs on sites the user had visited.

History detection project screenshot

Soon after this research was published, browsers took steps to mitigate this issue. In 2020, research done by Sarah Bird et al. from Mozilla and published at SOUPS, replicated the results and confirmed its major conclusions.

Lingro project icon
Online community-editable dictionary and a set of tools to help language learners master vocabulary. [...]
Lingro is my would-be startup project, launched out of college with my friend Paul Kastner. It's a somewhat flexible online dictionary that helps you read in a foreign language and easily look up words you don't know; it saves each word in its original context to make it easier for you to learn vocabulery.

The dictionaries used in Lingro are all based on freely-licensed sources and translations can be contributed by anyone. Since launch, Lingro has translated over 4 million words and is still actively used by a few thousand users each month.

Lingro project screenshot
Research ...
Oh, the Places You'll Go! Finding Our Way Back from the Web Platform's Ill-conceived Jaunts [...]

In its transition from the original concept of a mesh of hypertext documents into the world's most successful application ecosystem, the open web platform has steadily, iteratively, accumulated a large number of unsafe features and behaviors. These features lead to vulnerabilities in web applications, enable attacks on web users, and often add significant complexity to developers' mental models of the web and to user-agent implementations.

In this paper, we start from a scattered list of concrete grievances about the web platform based on informal discussions among browser- and web security engineers. After reviewing the details of these issues, we work towards a model of the root causes of the problems, categorizing them based on the type of risk they introduce to the platform. We then identify possible solutions for each class of issues, dividing them by the most effective approach to address it.

In the end, we arrive at a general blueprint for backing out of these dead ends. We propose a three-pronged approach which includes changing web browser defaults, creating a slew of features for web authors to opt out of dangerous behaviors, and adding new security primitives. We then show how this approach can be practically applied to address each of the individual problems, providing a conceptual framework for solving unsafe legacy web platform behaviors
– A. Janc, M. West
⌖ SecWeb 2020 [PDF]

Information Leaks via Safari's Intelligent Tracking Prevention [...]

Intelligent Tracking Prevention (ITP) is a privacy mechanism implemented by Apple's Safari browser, released in October 2017. ITP aims to reduce the cross-site tracking of web users by limiting the capabilities of cookies and other website data.

As part of a routine security review, the Information Security Engineering team at Google has identified multiple security and privacy issues in Safari's ITP design. These issues have a number of unexpected consequences, including the disclosure of the user's web browsing habits, allowing persistent cross-site tracking, and enabling cross-site information leaks (including cross-site search).

This report is a modestly expanded version of our original vulnerability submission to Apple (WebKit bug #201319), providing additional context and edited for clarity. A number of the issues discussed here have been addressed in Safari 13.0.4 and iOS 13.3, released in December 2019.
– A. Janc, L. Weichselbaum, K. Kotowicz, R. Clapis
⌖ Google Research, 2020 [PDF]

CSP is dead, long live CSP! On the insecurity of whitelists and the future of Content Security Policy. [...]

Content Security Policy is a web platform mechanism designed to mitigate cross-site scripting (XSS), the top security vulnerability in modern web applications. In this paper, we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies.

We base our Internet-wide analysis on a search engine corpus of approximately 100 billion pages from over 1 billion hostnames; the result covers CSP deployments on 1,680,867 hosts with 26,011 unique CSP policies — the most comprehensive study to date. We introduce the security-relevant aspects of the CSP specification and provide an in-depth analysis of its threat model, focusing on XSS protections. We identify three common classes of CSP bypasses and explain how they subvert the security of a policy.

We then turn to a quantitative analysis of policies deployed on the Internet in order to understand their security benefits. We observe that 14 out of the 15 domains most commonly whitelisted for loading scripts contain unsafe endpoints; as a consequence, 75.81% of distinct policies use script whitelists that allow attackers to bypass CSP. In total, we find that 94.68% of policies that attempt to limit script execution are ineffective, and that 99.34% of hosts with CSP use policies that offer no benefit against XSS.

Finally, we propose the 'strict-dynamic' keyword, an addition to the specification that facilitates the creation of policies based on cryptographic nonces, without relying on domain whitelists. We discuss our experience deploying such a nonce-based policy in a complex application and provide guidance to web authors for improving their policies.
– L. Weichselbaum, M. Spagnuolo, S. Lekies, A. Janc
⌖ ACM CCS 2016 [PDF]

Why Johnny can't browse in peace: On the uniqueness of web browsing history patterns. [...]

We present the results of the first large-scale study of the unique­ness of Web browsing histories, gathered from a total of 368,284 Internet users who visited a history detection demon­stration website.

Our results show that for a majority of users (69%), the browsing history is unique and that users for whom we could detect at least 4 visited websites were uniquely identified by their histories in 97% of cases. We observe a significant rate of stability in browser history fingerprints: for repeat visitors, 38% of fingerprints are identical over time, and differing ones were correlated with original history contents, indicating static browsing preferences (for history subvectors of size 50). We report a striking result that it is enough to test for a small number of pages in order to both enumerate users' interests and perform an efficient and unique behavioral fingerprint; we show that testing 50 web pages is enough to fingerprint 42% of users in our database, increasing to 70% with 500 web pages.

Finally, we show that indirect history data, such as information about categories of visited websites can also be effective in fingerprinting users, and that similar fingerprinting can be performed by common script providers such as Google or Facebook.
– L. Olejnik, C. Castelluccia, A. Janc
⌖ HotPETs 2012 [PDF]

Feasibility and real-world implications of web browser history detection [...]

Browser history detection through the Cascading Style Sheets visited pseudoclass has long been known to the academic security community and browser vendors, but has been largely dismissed as an issue of marginal impact.

In this paper we present several crucial real-world considerations of CSS-based history detection to assess the feasibility of conduc­ting such attacks in the wild. We analyze Web browser behavior and detectability of content returned via various protocols and HTTP response codes. We develop an algorithm for efficient examination of large link sets and evaluate its performance in modern browsers. Compared to existing methods our approach is up to 6 times faster, and is able to detect as many as 30,000 links per second in recent browsers on modern consumer-grade hardware.

We present a web-based system capable of effectively detecting clients' browsing histories and categorizing detected information. We analyze and discuss real-world results obtained from 271,576 Internet users. Our results indicate that at least 76% of Internet users are vulnerable to history detection; for a test of most popular Internet websites we were able to detect, on average, 62 visited locations. We also demonstrate the potential for detecting private data such as zipcodes or search queries typed into online forms. Our results confirm the feasibility of conducting attacks on user privacy using CSS-based history detection and demonstrate that such attacks are realizable with minimal resources.
– A. Janc, L. Olejnik
⌖ W2SP 2010 [PDF]
Position Papers & Other Writing...
Towards native security defenses for the web ecosystem [...]
This Google Security Blog post covers how the ISE team at Google deploys web platform security mechanisms to protect our sensitive applications from two major classes of security bugs: injections (XSS) and issues that undermine isolation between applications (XS-leaks).

Specifically, it outlines our work on Trusted Types, nonce-based Content Security Policy, Fetch Metadata Request Headers and the Cross-Origin Opener Policy.
– A. Janc, L. Weichselbaum (2020) [link]

Cross-Origin Opener Policy and Cross-Origin Embedder Policy explained [...]
We live in a world with transient execution vulnerabilities, where a browsing process running attacker's JavaScript can load cross-site resources, or potentially share memory with the process belonging to another origin. This poses significant problems for browser developers and application owners because it undermines fundamental security guarantees we've come to expect from the web.

This article goes into details about two mechanisms: Cross-Origin Opener Policy and Cross-Origin Embedder Policy, that – when used together – provide sufficient isolation that allows a browser to give a document access to powerful low-level APIs.
– A. Janc, A. van Kesteren, C. Reis (2019) [link]

HTTP Archive's Web Alamanac 2019: Security [...]
The Web Almanac project is an ambitious attempt to capture the state of the web across various axes: what are web pages composed of an what this means for user experience, performance, accessibility, and, yes, security.

The Security chapter, written primarily by Scott Helme with a few contributions from yours truly, reviews the web-wide use of defensive mechanisms to protect applications from common web vulnerabilities. It's a fairly comprehensive analysis with a possibly thought-provoking list of features useful to developers of sensitive webapps.
– S. Helme, A. Janc (2019) [link]

How do we stop spilling the beans across origins? A primer on cross-origin information leaks. [...]
This survey paper outlines, at a high level, the classes of web attacks which are exempt of the confines of the same-origin policy, leading to endemic vulnerabilities such as CSRF, XSSI, clickjacking and cross-site search.

It evaluates proposals for several new web isolation mechanisms – CORB, CORP, Fetch Metadata, SameSite cookies and COOP – from the point of view of the protections they offer against these bugs.

Perhaps most importantly, it makes a case for a principled approach to these types of problems by designing more comprehensive security features that address the bulk of the known sources of cross-origin leakiness.
– A. Janc, M. West (2018) [link]

Why the web needs finer-grained origins [...]
The concept of an origin is baked into the web platform like almost no other feature, defining the trust principal underpins pretty much all web security. This makes any changes to this concept particularly tricky because of the ripple effects they send through the very fabric of the web.

But what if we could make it more extensible? Allowing developers to define more granular origins could provide strong protections against common vulnerabilities such as XSS. This paper makes a case that such work would be beneficial for the web in the long run.
– A. Janc (2017) [link]

Technical analysis of client identification mechanisms [...]
In a fairly exciting bit of work with the incomparable lcamtuf we took a broad look at fingerprinting vectors available to websites.

Since the paper was written, fingerprinting and device identifica­tion have become even more of a hot topic, but the paper has aged fairly well: many of the vectors outlined in the document continue to pose significant problems for browser vendors' comprehensive anti-fingerprinting efforts.
– A. Janc, M. Zalewski (2013) [link]

Reshaping web defenses with strict Content Security Policy [link] & Google strict CSP guidelines [link] [...]
Legacy Content Security Policy configurations based on URL whitelists have been shown to be ineffective as a countermeasure against XSS. Instead, an approach based on script nonces offers significant adoption and security benefits, and is the preferred method of deploying CSP in large applications at Google.

This documentation explains the nonce-based strict CSP approach in detail.
– A. Janc, M. Spagnuolo, L. Weichselbaum, D. Ross (2016)

Google's introduction to cross-site scripting [...]
What is XSS? If you need a refresher with some interactive examples, this page is surely just what you need.
– A. Janc, J. Munoz (2014) [link]
Security Tools & Assorted Code ...
A few utilities to help with the adoption of web security features, written by the excellent folks on our team:
CSP Evaluator (source): Popular strength checker for CSP, including an extension for on-the-fly CSP strength checks
– Written by Lukas Weichselbaum
CSP Mitigator: extension to test site compatibility with a custom CSP policy, focusing on nonce-based CSP.
– Written by David Ross
Fetch Metadata Request Headers playground: a demo site demonstrating Fetch Metadata protections.
– Written by Maciej Trzos

...and a smattering of tools and helper scripts to test web browser implementations of new security features:
'strict-dynamic' testbed: demo of the compability of CSP3's 'strict-dynamic' keyword with popular JS widgets
/s/script-nonce-security: tests for CSP nonce hardening
NetTest: a network performance measurement JS library
Fun: Bugs, PoCs, etc. ...
Because security engineers just wanna have fun:
r00tz HTML game: A simple application to teach kids HTML at DEFCON using the XSS Game engine (with Arnie Techavimol).
cachetime2: Timing cross-site loads with abortable fetch.
scroll-to-selector woes: A demonstration of information leaks introduced when scrolling to untrusted CSS selectors.
Booleans in structured headers: The root cause of a recent problem with structured headers traced back to AD 1200.
DNS NCACHE covert channel: Can you synchronize your worm by making lookups of non-existent DNS labels? Yes. Should you? No.
was_parser_inserted: An interesting way to bypass 'strict-dynamic' due to script element manipulations.
I'm fairly easy to find in the usual places: Twitter, GitHub, Google Scholar, Stack Overflow, and LinkedIn (my resume is also here). If you prefer a more old-school communication channel, my email address is printed in the console when you open this page.

If the work above seems like your cup of tea, make sure to also check out some of the folks mentioned on this slide, many of whom were were my mentors, friends or frenemies.

Importantly, we're usually hiring for the Information Security Engineering team at Google -- see here for details!