Privacy, permissions, and information security

Draft
This page is not complete.

As users use the web for more and more of their daily tasks, more of their private or personally-identifying information they share, ideally only with sitews they trust. Cooperation among web content, the web browser, and the web server is needed to achieve as much privacy and information security as possible. In this article, we examine how to create web content that minimizes the risk of users' personal information or imagery being obtained unexpectedly by third parties.

Security and privacy defined

Before going into greater depth as to how the mechanisms available to protect users are used and how they work together, it's useful to define some terms.

Personally identifiable information

Personally identifiable information (PII) is information which can be used, in whole or in part, to track down and/or identify a specific person. As such, PII extends beyond the web to all aspects of life. For example, if a site leaks a list of users' names and zip codes online, a bad actor could almost certainly track down at least some percentage of those users by simply using the corresponding phone books.

Personally identification can include information like usernames, real names, passwords, phone numbers or addresses (or even portions of them), information about medical history, Social Security Numbers, driver licenses, or any other form of ID or ID number, credit card information, and so forth. It's a very broad range of information. Whenever working with data, always stop and think: is there any way this can be used to even through many steps identify a specific person?

Privacy

The concept of privacy is somewhat hard to define. Everyone has some idea what it means to keep something private, but when talking about the privacy of data, it becomes murky. Fundamentally, privacy of your data on the internet is about ensuring that information that has personal implications is kept out of the hands of unauthorized persons or organizations, regardless of how it's obtained.

Privacy exceptions may be granted to specific sites or applications, but it may also be granted conditionally, such as by permitting only a select group of people to access it, or only allowing the information to be accessed and used for a limited period of time.

Security

Security is about the active protection of data or a system against being accessed, downloaded, or operated by people or organizations that don't have permission to do so. Good security practices aim to prevent unauthorized access to systems or data, regardless of what the target is.

Personal and private information

<what kind of information is private or personal?>

Privacy risks

<what are ways personal information can be gotten by third parties?>

Privacy and security controls

There are multiple layers of controls for helping to protect users against security and privacy breaches. These start at the web server, include the very communication layer used over the network,  and then extend through the web browser's security offerings before reaching your web app code and the efforts it takes to secure itself and the data the user entrusts to it.

There are several web technologies and features at play to manage privacy and security. The following list includes features affecting both, since many of these features are used for both.

Web technologies and features used to enforce security and privacy
Technology or feature Description
Certificate Transparency An open standard for monitoring and auditing certificates, creating a database of public logs that can be used to help identify incorrect or malicious certificates
Content Security Policy Provides the ability to define the extent to which a document's content can be accessed by other devices over the web; used in particular to prevent or mitigate attacks on the server
Feature Policy Lets web developers selectively enable, disable, and modify the behavior of certain features and APIs both for a document and for subdocuments loaded in <iframe>s
<iframe>'s allow attribute Technically part of Feature Policy, the allow attribute on an <iframe> specifies which web features the document in the frame should be allowed to access
HTTP Public Key Pinning (HPKP) HPKP is used by servers to instruct a client to associate a specific public key with the server going forward in order to decrease the likelihood of man-in-the-middle attacks
HTTP Strict Transport Security (HSTS) HSTS is used by servers to let them protect themselves from protocol downgrade and cookie hijack attacks by letting sites tell clients that they can only use HTTPS to communicate with the server
HTTP/2 While HTTP/2 technically does not have to use encryption, most browser developers are only supporting it when used with HTTPS, so it can be thought of in that regard as being security-related
Permissions API Provides a way to determine the status of permissions for the current browser context
Transport Layer Security (TLS); formerly known as Secure Sockets Layer (SSL) TLS provides security and privacy by encrypting data during transport over the network. This is the technology behind the HTTPS (HyperText Transport Protocol Secured) protocol

Not all of these are generally directly used within code; notably, the Permissions API, Feature Policy, and the allow attribute on <iframe> elements are primary tools directly used by code to help secure a site and its content.

Keeping personal data safe

Managing site permissions

Bringing it all together

<using Feature Policy with permissions and so forth; how to use them together, how they interact, etc>

Permission requests in <iframe> elements

Things can get tricky when your web app uses the <iframe> element to embed content from another site inside your own, especially if the document you load into the frame has its own permission needs to consider.

While specifications for these technologies either state or recommend tactics for handling situations like this, browsers may offer different solutions to improve security even further or to try new features, or try to reduce complexity for users, among other possible reasons.

<--- allow attribute, feature policy, and permissions api stuff --->

A specific user experience issue that often arises is a document that's loaded with permission to access a resource and the document contains an <iframe> with the allow attribute to delegate that permission to the contents of the frame. In this case, it's possible for the user to wind up being prompted repeatedly for that same resource, first by the main page, then by the document in the frame.

Browsers may choose to provide ways around this. For example, in Firefox 73, the user permission requests were revised so that when an <iframe> uses the allow keyword to delegate permission to the embeded document, the browser asks the user to grant the parent document permission to use the resource, and that permission is then shared with the embedded content that requested the resource to begin with.

<-- diagram and/or code snippet to clarify things-->

See also