Goedi02 historical (#100)

* Update _index.md

Editorial pass

* Update content-type.md

Editorial pass

* Update stateful-browser-features.md

Editorial pass

* Update stateful-browser-features.md

Fixing one small issue

Author: goedi02

content/docs/attacks/historical/_index.md

@@ -5,9 +5,9 @@ weight: 11
 
 # Historical Attacks
 
-The articles in this section present XS-Leaks that were addressed within the browser and don't work anymore. Some of the mitigations consist of:
+The articles in this section present XS-Leaks that have been addressed within browsers and no longer work. Different mitigation strategies were applied, such as:
 
-- Reduce the accuracy of some powerful APIs.
-- Add noise to a certain measurement to prevent any malicious inference from it.
-- Deprecate and remove features and APIs.
-- Change feature behavior.
+- Reducing the accuracy of some powerful APIs.
+- Adding noise to a certain measurement to prevent any malicious inference from it.
+- Deprecating and removing features and APIs.
+- Changing the feature's behavior.

content/docs/attacks/historical/content-type.md

@@ -15,15 +15,15 @@ defenses = [
 menu = "main"
 +++
 
-Leaking the Content-Type of a request could offer an attacker a new way to distinguish two requests from each other.
+Leaking the Content-Type of a request would provide attackers with a new way of distinguishing two requests from each other.
 
 ## typeMustMatch
 
-[`typeMustMatch`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLObjectElement/typeMustMatch) is a boolean that reflects the `typeMustMatch` attribute of the `object` element. It ensures a certain MIME type must be enforced when loading an object verifying if the `Content-Type` of the resource is the same as the one provided in the object. Unfortunately, this enforcement would allow attackers to leak the `Content-Type` and Status Codes returned by a website [^1]
+[`typeMustMatch`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLObjectElement/typeMustMatch) is a Boolean that reflects the `typeMustMatch` attribute of the `object` element. It ensures that a certain MIME type must be enforced when loading an object, by verifying if the `Content-Type` of the resource is the same as the one provided in the object. Unfortunately, this enforcement also allowed attackers to leak the `Content-Type` and Status Codes returned by a website [^1].
 
 ### Root Cause
 
-Considering the snippet below, `not_loaded` would be rendered if the returned `Content-Type` of `https://target/api` did not match the one in `type`, or the server returned a status different than `200`.
+Considering the snippet below, `not_loaded` would be rendered if the returned `Content-Type` of `https://target/api` did not match the one in `type`, or if the server returned a status different than `200`.
 
 ```html
 <object type="application/json"
@@ -34,7 +34,7 @@ not_loaded </object>
 
 #### Issues
 
-An attacker could leak the `Content-Type` and Status Codes of a website by detecting whether the object rendered, which will happen when [all the conditions]({{< ref "#root-cause" >}}) are met. The attacker could check the values of `clientHeight` and `clientWidth` which will likely be different than 0 when the object renders (and returns status `200`). Since `typeMustMatch` requires the server to return status `200` to load a resource, it would be possible to detect error pages, similarly to [Error Events]({{< ref "../error-events.md" >}}) XS-Leaks.
+An attacker could leak the `Content-Type` and Status Codes of a website by detecting whether the object rendered, which happens when [all conditions]({{< ref "#root-cause" >}}) are met. The attacker could check the values of `clientHeight` and `clientWidth` which are likely to be different than 0 when the object renders (and returns status `200`). Since `typeMustMatch` requires the server to return status `200` to load a resource, it would be possible to detect error pages, similar to [Error Events]({{< ref "../error-events.md" >}}) XS-Leaks.
 
 The example below shows how this behavior could be detected by embedding an object inside an `iframe` and checking the values of `clientHeight` and `clientWidth` when the `iframe` triggers the `onload` event.
 
@@ -62,7 +62,7 @@ ifr.onload = () => {
 
 ### Fix
 
-Firefox was the only browser supporting the `typeMustMatch` attribute [^2] and since no other browsers offered support, it was removed in version 68 and from the HTML Living Standard.
+Firefox was the only browser that supported the `typeMustMatch` attribute [^2], and since no other browsers offered support, it was removed in version 68 and from the HTML Living Standard.
 
 ## References
 

content/docs/attacks/historical/stateful-browser-features.md

@@ -9,28 +9,28 @@ defenses = [
 menu = "main"
 +++
 
-Some browser features/extensions change the way requests are processed depending on certain website states generated by the browser. Attackers can sometimes observe the whole process and mess with the browser, triggering actions that produce side-effects on those states.
+Some browser features/extensions change the way requests are processed, depending on certain website states generated by the browser. Attackers can sometimes observe the whole process and mess with the browser, triggering actions that produce side effects on those states.
 
-## WebKit - ITP
+## WebKit – ITP
 
-[Intelligent Tracking Prevention](https://webkit.org/tracking-prevention/) (ITP) is a privacy feature part of [WebKit Tracking Prevention technologies](https://webkit.org/tracking-prevention/). It’s a conjunction of several features to prevent a website from tracking a user under a third-party context. Unfortunately, the initial design introduced a new XS-Leak [^1], allowing attackers to abuse the states implicitly created by ITP to classify websites as trackers.
+[Intelligent Tracking Prevention](https://webkit.org/tracking-prevention/) (ITP) is a privacy feature which is part of [WebKit Tracking Prevention technologies](https://webkit.org/tracking-prevention/). It's a conjunction of several features and aims to prevent a website from tracking a user under a third-party context. Unfortunately, the initial design introduced a new XS-Leak [^1], allowing attackers to abuse the states implicitly created by ITP to classify websites as trackers.
 
 ### Root Cause
 
-To classify whether a website has tracking capabilities, ITP collects statistics on resource loads as well as user interactions in websites such as clicks, taps, or text entries. Based on the classification of these statistics, ITP gives a strike to a website if it is believed to have tracking capabilities. After 3 strikes a website is put on a deny list and is treated differently by the browser in future requests.
+To classify whether a website has tracking capabilities, ITP collects statistics on resource loads as well as on user interactions with websites such as clicks, taps, or text entries. Based on the classification of these statistics, ITP gives a strike to a website if it is believed to have tracking capabilities. After 3 strikes, a website is put on a deny list and is treated differently by the browser in future requests.
 
 #### Issues
 
-One of the issues of ITP is that attackers can manipulate it to arbitrarily enforce certain behaviors. For example, one could force ITP to give a strike to a domain and check if the domain entered the deny list. This could be levered in different ways, for example:
+One of the issues of ITP is that attackers can manipulate it to arbitrarily enforce certain behaviors. For example, an attacker could force ITP to give a strike to a domain and check if the domain entered the deny list. This information could be leveraged in different ways, for example to:
 
-- Leaking the user's browsing habits based off of how many strikes are necessary for a domain to enter the deny list
-- Using the deny list to implement an XS-Search attack against a page that includes cross-site resources only when results are present
+- Leak the user's browsing habits based on how many strikes are necessary for a domain to enter the deny list.
+- Use the deny list to implement an XS-Search attack against a page that includes cross-site resources only when results are present.
 
 ### Fix
 
-To [fix the issue](https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/), instead of relying on classifications, ITP now considers every site as a "tracking" one by default. This removes the implicit states which allowed attackers to detect certain ITP behaviors.
+To [fix the issue](https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/), ITP now considers every site to be a "tracking" site by default, instead of relying on classifications. This removes the implicit states which allowed attackers to detect certain ITP behaviors.
 
 ## References
 
 [^1]: Information Leaks via Safari’s Intelligent Tracking Prevention, [link](https://arxiv.org/pdf/2001.07421.pdf)
-[^2]: Preventing Tracking Prevention Tracking, [link](https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/)
+[^2]: Preventing Tracking Prevention Tracking, [link](https://webkit.org/blog/9661/preventing-tracking-prevention-tracking/)