Merge pull request #16 from TallTed/patch-1

wrap overly long lines in index.bs

index.bs

@@ -53,7 +53,9 @@ Issue(6):
 
 ## Serving user-created files ## {#serving-user-created-files}
 
-When Solid Servers [[Solid.Protocol]] serve files created by different users, they break the common Web assumption that files and/or applications served within the same origin are automatically equally trustworthy.
+When Solid Servers [[Solid.Protocol]] serve files created by different users,
+they break the common Web assumption that files and/or applications served
+within the same origin are automatically equally trustworthy.
 
 An attacker could be any agent — human, browser, browser-based application,
 etc. — with a WebID. They need append/write access to the user's server
@@ -74,35 +76,46 @@ benign application.
 
 #### Prerequisites
 
-* When multiple agents are allowed to perform append or write operations in a storage, the attacker has append or write access to a publicly readable resource in a storage.
-* The server serves [[SolidOS]] under the same domain (e.g., by default, [[Community.Solid.Server]] serves everything under the same domain).
-* Once the victim is logged in via [[SolidOS]], any new session is automatically logged in to the same account.
+* When multiple agents are allowed to perform append or write operations in a storage,
+the attacker has append or write access to a publicly readable resource in a storage.
+* The server serves [[SolidOS]] under the same domain (e.g., by default,
+[[Community.Solid.Server]] serves everything under the same domain).
+* Once the victim is logged in via [[SolidOS]], any new session is automatically logged
+in to the same account.
 
 #### Attack
 
-The attacker writes a malicious `text/html` file to the server. When this file is opened by the user:
+The attacker writes a malicious `text/html` file to the server. When this file is opened
+by the user:
 
-1. It opens [[SolidOS]] in a new tab and saves the window reference. (If the writer of this document recalls correctly, opening any non-existent resource from the server returns [[SolidOS]].)
+1. It opens [[SolidOS]] in a new tab and saves the window reference. (If the writer of
+this document recalls correctly, opening any non-existent resource from the server returns [[SolidOS]].)
 1. [[SolidOS]] automatically logs in, as the user who logged in there previously.
-1. The `text/html` file can access [[SolidOS]] via the window reference, including performing authenticated fetch.
-1. The `text/html` file can make any request in the name of the currently logged-in user, through this authenticated fetch.
+1. The `text/html` file can access [[SolidOS]] via the window reference, including
+performing authenticated fetch.
+1. The `text/html` file can make any request in the name of the currently logged-in user,
+through this authenticated fetch.
 
 
 ### Steal login credentials
 
-If a user saves credentials for an application on the same site as the Solid server, a malicious application could steal these credentials.
+If a user saves credentials for an application on the same site as the Solid server,
+a malicious application could steal these credentials.
 
 #### Prerequisites
 
 * The attacker has append/write access to a publicly readable folder/file on the server.
 * The victim uses the IDP of the (small) [[Community.Solid.Server]] server.
 * The storages are on the same domain as the IDP (default for [[Community.Solid.Server]]).
-* The user saved their login credentials (`/idp/login/` for [[Community.Solid.Server]]) via the browser or a password manager extension.
+* The user saved their login credentials (`/idp/login/` for [[Community.Solid.Server]])
+via the browser or a password manager extension.
 
 
 #### Attack
 
-The attacker writes a malicious `text/html` file to the server. Depending on the tool used to store the login credentials, the actual autofill/suggestion behaviour can vary. For instance, if a user who saved login credentials with Chrome opens the malicious file:
+The attacker writes a malicious `text/html` file to the server. Depending on the tool used
+to store the login credentials, the actual autofill/suggestion behaviour can vary. For instance,
+if a user who saved login credentials with Chrome opens the malicious file:
 
 1. The victim performs any interaction with the site (e.g., clicking on a cookie banner).
 1. Chrome automatically fills in `<input>` fields for the user name and password with the saved credentials.
@@ -111,12 +124,21 @@ The attacker writes a malicious `text/html` file to the server. Depending on the
 
 ### Countermeasures ### {#serving-user-created-files-countermeasures}
 
-* Multiple agents can create files on the same server, which could render `same-origin` security boundaries useless.
-* As one possible countermeasure, servers could add a [`Content-Security-Policy: sandbox`](https://www.w3.org/TR/CSP3/#directive-sandbox) header to artificially enable `same-origin` security policies for files served on the same origin.
+* Multiple agents can create files on the same server, which could render `same-origin`
+security boundaries useless.
+* As one possible countermeasure, servers could add a
+[`Content-Security-Policy: sandbox`](https://www.w3.org/TR/CSP3/#directive-sandbox) header
+to artificially enable `same-origin` security policies for files served on the same origin.
 
 #### Considerations
 
-Servers are strongly encouraged to consider the countermeasures in the context of the use cases they want to enable or disable on a given storage. For instance, using `Content-Security-Policy: sandbox` will universally prohibit various functionalities for applications, including but not limited to accessing local storage, executing scripts, using forms, interacting with plugins, or including external content. This broad range of restrictions may not be desirable for various categories of applications that rely on client-side storage mechanisms, collaborative features, or dynamic content interaction.
+Servers are strongly encouraged to consider the countermeasures in the context of the use cases
+they want to enable or disable on a given storage. For instance, using
+`Content-Security-Policy: sandbox` will universally prohibit various functionalities for
+applications, including but not limited to accessing local storage, executing scripts,
+using forms, interacting with plugins, or including external content. This broad range of
+restrictions may not be desirable for various categories of applications that rely on
+client-side storage mechanisms, collaborative features, or dynamic content interaction.
 
 ## Protecting WebID Document ## {#protecting-webid-document}