Users increasingly encounter moments when a website asks for permission to gather some personal data or access to their device hardware: "Can we access your GPS position? Your microphone or camera? Your Bluetooth? Can we send you push notifications about breaking news or premium chocolate subscription offers?"

Permissions, as these asks are known, give the web exciting powers. Already around a dozen browser features range from tapping low-level hardware and software functions like the clipboard to the increasingly persistent ability of sites to access files on a user’s disk. More are soon to come. But with great power comes more security and privacy risks. At this point, there are few viable alternatives for websites to manage access in any way other than asking users, and assuming they understand the risks involved.

These permissions are typically very easy for users to manage. When the user grants a permission, the browser often memorizes it and never asks again, for better or for worse. It's known that users are prone to fatigue from repeated and unwanted prompts. But in general, permissions are a good thing, allowing users to block sites from accessing sensitive data and tools, and allowing access to the trusted ones. But those data and tools might remain vulnerable. Permissions seemingly shift the responsibility of protection from browsers to individual sites, and to the users themselves who grant permissions and are generally assumed to know what they are doing. The mechanism therefore gives rise to a special relationship between site and user, one that could at some point be abused.

Let’s assume malicious hackers breach a site and gain control over its content—the source code, embedded elements like images, the served scripts, even third-party scripts. This is in no way an unlikely scenario, as evidenced by past breaches of Slack, Ticketmaster, British Airways, and many others that happen to fall victim to cyberattack targeting integrity. (Some sites are even compromised by several threat actors What could they do with permissions? An awful lot. They could access any feature of any user who had granted the site access. They’d turn assets into liabilities.

Among other security and privacy issues we could imagine permission fissure ending in events like:

• Webcams and microphones could be unexpectedly activated out of the blue, or attackers could abuse Web Audio API to track user devices with “unhearable” beacons or even send data out of band.
• Notification API or Push API messages seeming to come from a source the user trusts could be sent with links to malware, or even display disinformation and propaganda in a coordinated manner, simultaneously to many users.

Permissions are designed to mitigate these kinds of risks. But if a site with large user base falls victim to a supply chain attack impacting site integrity, the protection model would completely fall apart and many features would be subject to the attackers’ whims. A wave of negative press would certainly follow such a breach, especially if the attacked site was large or trusted.

Even though none of these scenarios is known to have happened yet, as permissions become more ubiquitous, it’s paramount to consider these risks at the design stage and to be as transparent with the user as possible. Can we expect users to understand the fundamental difference between granting access to an installed mobile application (often in a controlled environment) and a remote website? If not, sites should be clear about this prior to prompting for permission.

In some cases of breach, it might not be difficult to imagine that regulatory aspects such as GDPR could become relevant. This territory is not well understood today. While it might not be clear if granting a permission means “unambiguous and informed consent,” it does suggest a token of trust between the user and the site, clearly communicated by the user. These decisions are explicit, even though almost no website today explains the rationale or use cases prior to asking to use a permission-gated function, a frequently seen antipattern when a random site keep asking for the ability to display notifications.

Sites should devote extra care when requesting to use sensitive browser functionality. Specifically, one would imagine websites wanting to be sure if, when, and how permissions are used. To assess their potential exposure risk, sites should also know how many of their users have granted permissions. It is not clear if websites even think of making inventory lists of such sensitive uses today. But if there was a breach, many would likely ask these questions.

Site operators could prepare for these kinds of dangers by knowing if sensitive mechanisms are in use, monitoring their uses, and logging which particular users signed in for permission-gated content. Website operators need to keep track of the undesirable site modifications by protecting system integrity. While this problem is a broad challenge, web-wise the use of mechanisms guaranteeing at the least the integrity of embedded subresources should be the norm.

Web browsers could also help by offering simple and easy ways for users to inspect permissions granted to sites, and withdraw seamlessly. Fortunately in the last few years, browsers have made impressive progress in this area. Lastly, regulators and enforcers should work to understand the implications of this possible new relationship between users and services. As the pace of web evolution is accelerating, monitoring those changes are pressing.

Web standardization plays a crucial role not only for interoperability, but also for ensuring user trust in the technology, including the security and privacy guarantees. Standardization might be seen as a form of regulating how the technology works. But if so, due to the increasing role technology plays in societies, the emerging question of oversight and social control may appear sooner or later. This doesn’t mean that we should invite the trend of national “cybersovereignty” increasingly felt in many parts of the world to impact technology standards. It simply means we should uphold the pillars of interoperable software and hardware, which make the web, at its best, such a useful and illuminating place to be.

This article previously appeared in Wired on 19/11/19.