מעקב אחר אפליקציית האינטרנט באמצעות Reporting API

אפשר להשתמש ב-Reporting API כדי לעקוב אחרי הפרות אבטחה, קריאות ל-API שהוצאו משימוש ועוד.

Maud Nalpas

חלק מהשגיאות מתרחשות רק בסביבת הייצור. לא תראו אותם באופן מקומי או במהלך הפיתוח כי משתמשים אמיתיים, רשתות אמיתיות ומכשירים אמיתיים משנים את המשחק. ‫Reporting API עוזר לזהות חלק מהשגיאות האלה – כמו הפרות אבטחה או קריאות API שהוצאו משימוש ועומדות לצאת משימוש באתר שלכם, והוא מעביר אותן לנקודת קצה שציינתם.

הוא מאפשר להצהיר על מה שרוצים לעקוב אחריו באמצעות כותרות HTTP, והוא מופעל על ידי הדפדפן.

הגדרת Reporting API מאפשרת לכם לדעת אם משתמשים נתקלים בסוגי השגיאות האלה, כדי שתוכלו לתקן אותן.

במאמר הזה מוסבר מה אפשר לעשות באמצעות ה-API הזה ואיך משתמשים בו. שנתחיל?

סקירה כללית

נניח שהאתר שלכם, site.example, כולל Content-Security-Policy ו-Document-Policy. לא יודעים מה הן עושות? זה בסדר, עדיין תוכלו להבין את הדוגמה הזו.

אתם מחליטים לעקוב אחרי האתר כדי לדעת מתי יש הפרות של המדיניות הזו, אבל גם כדי לעקוב אחרי ממשקי API שיצאו משימוש או שעומדים לצאת משימוש, שאולי נמצאים בבסיס הקוד שלכם.

כדי לעשות את זה, מגדירים כותרת Reporting-Endpoints וממפים את שמות נקודות הקצה האלה באמצעות ההנחיה report-to במדיניות, במקומות שבהם זה נדרש.

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint

קורה משהו בלתי צפוי, וחלק מהמשתמשים שלכם מפרים את כללי המדיניות האלה.

דוגמאות להפרות

index.html

<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>

script.js, נטען על ידי index.html

// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
  document.write('<h1>hi</h1>');
} catch (e) {
  console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;

הדפדפן יוצר דוח על הפרת CSP, דוח על הפרת מדיניות מסמכים ודוח על הוצאה משימוש, שכוללים את הבעיות האלה.

אחרי עיכוב קצר – עד דקה – הדפדפן שולח את הדוחות לנקודת הקצה שהוגדרה לסוג ההפרה הזה. הדוחות נשלחים מחוץ לפס על ידי הדפדפן עצמו (לא על ידי השרת או האתר שלכם).

נקודות הקצה מקבלות את הדוחות האלה.

עכשיו אפשר לגשת לדוחות בנקודות הקצה האלה ולעקוב אחרי מה שהשתבש. אתם מוכנים להתחיל לפתור את הבעיה שמשפיעה על המשתמשים.

דוח לדוגמה

{
  "age": 2,
  "body": {
    "blockedURL": "https://site2.example/script.js",
    "disposition": "enforce",
    "documentURL": "https://site.example",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
    "referrer": "https://site.example",
    "sample": "",
    "statusCode": 200
  },
  "type": "csp-violation",
  "url": "https://site.example",
  "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}

תרחישים לדוגמה וסוגי דוחות

אפשר להגדיר את Reporting API כדי לעזור לכם לעקוב אחרי סוגים רבים של אזהרות או בעיות מעניינות שמתרחשות באתר:

דוחות

איך נראים הדוחות?

הדפדפן שולח דוחות לנקודת הקצה שהגדרתם. הוא שולח בקשות שנראות כך:

POST
Content-Type: application/reports+json

המטען הייעודי (payload) של הבקשות האלה הוא רשימה של דוחות.

רשימה לדוגמה של דוחות

[
  {
    "age": 420,
    "body": {
      "columnNumber": 12,
      "disposition": "enforce",
      "lineNumber": 11,
      "message": "Document policy violation: document-write is not allowed in this document.",
      "policyId": "document-write",
      "sourceFile": "https://site.example/script.js"
    },
    "type": "document-policy-violation",
    "url": "https://site.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  },
  {
    "age": 510,
    "body": {
      "blockedURL": "https://site.example/img.jpg",
      "destination": "image",
      "disposition": "enforce",
      "type": "corp"
    },
    "type": "coep",
    "url": "https://dummy.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  }
]

אלה הנתונים שמופיעים בכל אחד מהדוחות האלה:

דוחות עם פרטי כניסה

נקודות קצה של דיווח שיש להן אותו מקור כמו לדף שיוצר את הדוח מקבלות את פרטי הכניסה (קובצי Cookie) בבקשות שמכילות את הדוחות.

יכול להיות שהפרטים יספקו הקשר נוסף ומועיל לגבי הדוח. לדוגמה, אם החשבון של משתמש מסוים מפעיל שגיאות באופן עקבי, או אם רצף מסוים של פעולות שבוצעו בדפים אחרים מפעיל דוח בדף הזה.

מתי ואיך הדפדפן שולח דוחות?

הדוחות נמסרים מחוץ לפס של האתר: הדפדפן קובע מתי הדוחות נשלחים לנקודות הקצה שהוגדרו. בנוסף, אין דרך לקבוע מתי הדפדפן ישלח דוחות. הוא מתעד אותם, מכניס אותם לתור ושולח אותם באופן אוטומטי בזמן המתאים.

כלומר, אין כמעט חשש לבעיות בביצועים כשמשתמשים ב-Reporting API.

הדוחות נשלחים באיחור – עד דקה – כדי להגדיל את הסיכוי לשלוח דוחות בקבוצות. כך נחסך רוחב פס כדי לא להעמיס על החיבור לרשת של המשתמש, וזה חשוב במיוחד בניידים. הדפדפן יכול גם לעכב את המסירה אם הוא עסוק בעיבוד של עבודה בעדיפות גבוהה יותר, או אם המשתמש נמצא ברשת איטית או עמוסה באותו הזמן.

בעיות שקשורות לצד שלישי ולצד ראשון

דוחות שנוצרים בגלל הפרות או הוצאות משימוש שמתרחשות בדף שלכם יישלחו לנקודות הקצה שהגדרתם. ההפרות האלה כוללות הפרות שבוצעו על ידי סקריפטים של צד שלישי שפועלים בדף שלכם.

הפרות או הוצאות משימוש שקרו ב-iframe חוצה מקור שמוטמע בדף לא ידווחו לנקודות הקצה (לפחות לא כברירת מחדל). יכול להיות ש-iframe יגדיר דיווח משלו ואפילו ידווח לשירות הדיווח של האתר שלכם – כלומר, של הצד הראשון – אבל זה תלוי באתר שמוצג בתוך המסגרת. חשוב גם לדעת שרוב הדוחות נוצרים רק אם יש הפרה של המדיניות בדף, ושהמדיניות של הדף שונה מהמדיניות של ה-iframe.

דוגמה עם הוצאה משימוש

תמיכה בדפדפנים

בטבלה הבאה מפורט סיכום של התמיכה בדפדפנים ב-Reporting API v1, כלומר עם הכותרת Reporting-Endpoints. התמיכה בדפדפנים ב-Reporting API v0 (הכותרת Report-To) זהה, למעט סוג דוח אחד: רישום שגיאות ברשת לא נתמך ב-Reporting API החדש. פרטים נוספים זמינים במדריך להעברת נתונים.

הטבלה הזו מסכמת רק את התמיכה ב-report-to עם הכותרת החדשה Reporting-Endpoints. אם אתם רוצים לעבור אל Reporting-Endpoints, כדאי לקרוא את הטיפים להעברת נתונים (מיגרציה) של דיווח CSP.

שימוש ב-Reporting API

החלטה לאן לשלוח את הדוחות

יש לך שתי אפשרויות:

• שליחת דוחות לשירות קיים של איסוף דוחות.
• שליחת דוחות למאגר דוחות שאתם יוצרים ומפעילים בעצמכם.

אפשרות 1: שימוש בשירות קיים לאיסוף דוחות

דוגמאות לשירותים לאיסוף דוחות:

• report-uri
• uriports

אם יש לך פתרונות אחרים, אפשר לפתוח בעיה כדי להודיע לנו, ואנחנו נעדכן את הפוסט הזה.

בנוסף למחיר, חשוב להביא בחשבון את הנקודות הבאות כשבוחרים כלי לאיסוף נתונים לצורך דיווח: 🧐

• האם הכלי הזה לתיוג תומך בכל סוגי הדוחות? לדוגמה, לא כל הפתרונות של נקודות קצה לדיווח תומכים בדוחות COOP/COEP.
• האם יש לך אפשרות לשתף את כתובות ה-URL של האפליקציה עם כלי של צד שלישי לאיסוף דוחות? גם אם הדפדפן מסיר מידע רגיש מכתובות ה-URL האלה, יכול להיות שהמידע הרגיש ידלוף בדרך הזו. אם זה נשמע מסוכן מדי לאפליקציה שלכם, אתם יכולים להפעיל נקודת קצה משלכם לדיווח.

אפשרות 2: יצירה והפעלה של כלי לאיסוף דוחות

בניית שרת משלכם שמקבל דוחות היא לא דבר פשוט. כדי להתחיל, אפשר ליצור עותק של קוד בסיסי קל משקל. הוא מבוסס על Express ויכול לקבל ולהציג דוחות.

כשיוצרים כלי משלכם לאיסוף דוחות:

• בודקים אם יש בקשות POST עם Content-Type של application/reports+json כדי לזהות בקשות לדוחות שנשלחו מהדפדפן לנקודת הקצה.
• אם נקודת הקצה נמצאת במקור אחר מהאתר שלכם, צריך לוודא שהיא תומכת בבקשות CORS מסוג preflight.

אפשרות 3: שילוב של אפשרות 1 ואפשרות 2

יכול להיות שתרצו שספק מסוים יטפל בסוגים מסוימים של דוחות, אבל תעדיפו להשתמש בפתרון פנימי לסוגים אחרים.

במקרה כזה, מגדירים כמה נקודות קצה באופן הבא:

Reporting-Endpoints: endpoint-1="https://reports-collector.example", endpoint-2="https://my-custom-endpoint.example"

הגדרת הכותרת של Reporting-Endpoints

מגדירים כותרת תגובה Reporting-Endpoints. הערך שלו חייב להיות אחד או סדרה של זוגות מפתח/ערך שמופרדים בפסיקים:

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

אם אתם עוברים מגרסה קודמת של Reporting API לגרסה החדשה, כדאי להגדיר גם את Reporting-Endpoints וגם את Report-To. פרטים נוספים זמינים במדריך להעברת נתונים. בפרט, אם אתם משתמשים בדיווח על Content-Security-Policyהפרות באמצעות ההנחיה report-uri בלבד, כדאי לעיין בשלבי ההעברה לדיווח CSP.

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: ...

מפתחות (שמות של נקודות קצה)

כל מפתח יכול להיות שם שתבחרו, כמו main-endpoint או endpoint-1. אתם יכולים להגדיר נקודות קצה שונות עם שמות שונים לסוגים שונים של דוחות – לדוגמה, my-coop-endpoint, my-csp-endpoint. כך תוכלו להפנות דוחות לנקודות קצה שונות בהתאם לסוג שלהם.

אם רוצים לקבל דוחות על התערבות, הוצאה משימוש, קריסה או שילוב של אלה, צריך להגדיר נקודת קצה בשם default.

אם הכותרת Reporting-Endpoints לא מגדירה נקודת קצה של default, דוחות מהסוג הזה לא יישלחו (אבל הם ייווצרו).

ערכים (כתובות URL)

כל ערך הוא כתובת URL לבחירתכם, שאליה יישלחו הדוחות. כתובת ה-URL שצריך להגדיר כאן תלויה בהחלטה שהתקבלה בשלב 1.

כתובת URL של נקודת קצה:

• הנתיב חייב להתחיל בלוכסן (/). אין תמיכה בנתיבים יחסיים.
• יכול להיות חוצה מקורות, אבל במקרה כזה פרטי הכניסה לא נשלחים עם הדוחות.

דוגמאות

Reporting-Endpoints: my-coop-endpoint="https://reports.example/coop", my-csp-endpoint="https://reports.example/csp", default="https://reports.example/default"

אחר כך אפשר להשתמש בכל נקודת קצה עם שם במדיניות המתאימה, או להשתמש בנקודת קצה אחת בכל המדיניות.

איפה מגדירים את הכותרת?

ב-Reporting API החדש – זה שמוסבר בפוסט הזה – הדוחות מוגבלים למסמכים. כלומר, למקור נתון אחד יכולים להיות מסמכים שונים, כמו site.example/page1 ו-site.example/page2, ששולחים דוחות לנקודות קצה שונות.

כדי לקבל דוח על הפרות או על הוצאה משימוש שמתרחשים בכל דף באתר, צריך להגדיר את הכותרת כתוכנת ביניים בכל התגובות.

דוגמה לשימוש ב-Express:

const REPORTING_ENDPOINT_BASE = 'https://report.example';
const REPORTING_ENDPOINT_MAIN = `${REPORTING_ENDPOINT_BASE}/main`;
const REPORTING_ENDPOINT_DEFAULT = `${REPORTING_ENDPOINT_BASE}/default`;

app.use(function (request, response, next) {
  // Set up the Reporting API
  response.set(
    'Reporting-Endpoints',
    `main-endpoint="${REPORTING_ENDPOINT_MAIN}", default="${REPORTING_ENDPOINT_DEFAULT}"`,
  );
  next();
});

עריכת כללי המדיניות

אחרי שמגדירים את הכותרת Reporting-Endpoints, מוסיפים הנחיה report-to לכל כותרת מדיניות שרוצים לקבל לגביה דוחות על הפרות. הערך של report-to צריך להיות אחת מנקודות הקצה שנתתם להן שם והגדרתם.

אפשר להשתמש בנקודת קצה אחת לכמה כללי מדיניות, או להשתמש בנקודות קצה שונות בכללי מדיניות שונים.

לא צריך להשתמש ב-report-to כדי לדווח על הוצאה משימוש, התערבות וקריסה. הדוחות האלה לא קשורים למדיניות כלשהי. הם נוצרים כל עוד מוגדרת נקודת קצה של default ונשלחים לנקודת הקצה הזו של default.

דוגמה

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0;report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the default endpoint

ניפוי באגים בהגדרת הדיווח

יצירת דוחות באופן מכוון

כשמגדירים את Reporting API, סביר להניח שתצטרכו להפר את המדיניות בכוונה כדי לבדוק אם הדוחות נוצרים ונשלחים כמצופה.

חוסכים זמן

יכול להיות שהדוחות יישלחו בעיכוב של כדקה, שזה זמן ארוך כשמבצעים ניפוי באגים. 😴 למרבה המזל, כשמבצעים ניפוי באגים ב-Chrome, אפשר להשתמש בדגל --short-reporting-delay כדי לקבל דוחות ברגע שהם נוצרים.

כדי להפעיל את הדגל הזה, מריצים את הפקודה הבאה בטרמינל:

YOUR_PATH/TO/EXECUTABLE/Chrome --short-reporting-delay

שימוש בכלי הפיתוח

ב-Chrome, משתמשים בכלי הפיתוח כדי לראות את הדוחות שנשלחו או יישלחו.

נכון לאוקטובר 2021, התכונה הזו היא ניסיונית. כדי להשתמש בו, פועלים לפי השלבים הבאים:

1. משתמשים בגרסה 96 של Chrome ומעלה (כדי לבדוק, מקלידים chrome://version בדפדפן)
2. מקלידים או מדביקים את chrome://flags/#enable-experimental-web-platform-features בסרגל הכתובות של Chrome.
3. לוחצים על הפעלה.
4. מפעילים מחדש את הדפדפן.
5. פותחים את כלי הפיתוח ל-Chrome.
6. בכלי הפיתוח ל-Chrome, פותחים את ההגדרות. בקטע Experiments (ניסויים), לוחצים על Enable Reporting API panel in the Application panel (הפעלת חלונית Reporting API בחלונית Application).
7. טוענים מחדש את כלי הפיתוח.
8. טוענים מחדש את הדף. דוחות שנוצרו על ידי כלי הפיתוח של הדף שפתוח בדפדפן יופיעו בחלונית Application בכלי הפיתוח ל-Chrome, בקטע Reporting API.

סטטוס הדוח

בעמודה סטטוס אפשר לראות אם הדוח נשלח בהצלחה.

דוחות מוסרים אחרי זמן מה, בין אם הם נשלחו בהצלחה ובין אם לא.

פתרון בעיות

האם הדוחות לא נוצרים או לא נשלחים כמצופה לנקודת הקצה? ריכזנו כאן כמה טיפים לפתרון הבעיה.

דוחות לא נוצרים

דוחות שמופיעים בכלי הפיתוח נוצרו בצורה תקינה. אם הדוח שציפיתם לו לא מופיע ברשימה:

• בודקים את report-to במדיניות. אם ההגדרה הזו שגויה, לא ייווצר דוח. כדי לפתור את הבעיה, צריך לעבור אל עריכת כללי המדיניות. דרך נוספת לפתור את הבעיה היא לבדוק את מסוף כלי הפיתוח ב-Chrome: אם מופיעה שגיאה במסוף לגבי ההפרה שציפיתם לה, סביר להניח שהמדיניות מוגדרת בצורה נכונה.
• חשוב לזכור שברשימה הזו יופיעו רק הדוחות שנוצרו עבור המסמך שבו כלי הפיתוח פתוחים. לדוגמה: אם באתר שלכם site1.example מוטמע iframe site2.example שמפר מדיניות ולכן נוצר דוח, הדוח הזה יופיע ב-DevTools רק אם תפתחו את ה-iframe בחלון משלו ותפתחו את DevTools עבור החלון הזה.

הדוחות נוצרים אבל לא נשלחים או לא מתקבלים

מה קורה אם אפשר לראות דוח בכלי הפיתוח, אבל נקודת הקצה לא מקבלת אותו?

• חשוב להשתמש בעיכובים קצרים. יכול להיות שאתם לא רואים דוח כי הוא עדיין לא נשלח.

• בודקים את הגדרת הכותרת Reporting-Endpoints. אם יש בעיה בדוח, הוא לא יישלח גם אם הוא נוצר בצורה תקינה. במקרה הזה, הסטטוס של הדוח בכלי הפיתוח יישאר Queued (יכול להיות שהוא ישתנה ל-Pending ואז יחזור במהירות ל-Queued כשייעשה ניסיון מסירה). הנה כמה טעויות נפוצות שעלולות לגרום לבעיה הזו:

• נעשה שימוש בנקודת הקצה, אבל היא לא הוגדרה. דוגמה:

 Document-Policy: document-write=?0;report-to=endpoint-1;
 Reporting-Endpoints: default="https://reports.example/default"

• נקודת הקצה (endpoint) default חסרה. סוגים מסוימים של דוחות, כמו דוחות הוצאה משימוש ודוחות התערבות, יישלחו רק לנקודת הקצה שנקראת default. מידע נוסף זמין במאמר הגדרת הכותרת Reporting-Endpoints.

• בודקים את התחביר של כותרות המדיניות, למשל אם חסר מרכאות. לפרטים

• בודקים שנקודת הקצה יכולה לטפל בבקשות נכנסות.

  • מוודאים שנקודת הקצה תומכת בבקשות קדם-הפעלה של CORS. אם לא, הוא לא יוכל לקבל דוחות.

  • בודקים את ההתנהגות של נקודת הקצה. כדי לעשות זאת, במקום ליצור דוחות באופן ידני, אפשר לבצע אמולציה של הדפדפן על ידי שליחת בקשות לנקודת הקצה שנראות כמו הבקשות שהדפדפן ישלח. מריצים את הפקודה הבאה:

  curl --header "Content-Type: application/reports+json" \
    --request POST \
    --data '[{"age":420,"body":{"columnNumber":12,"disposition":"enforce","lineNumber":11,"message":"Document policy violation: document-write is not allowed in this document.","policyId":"document-write","sourceFile":"https://dummy.example/script.js"},"type":"document-policy-violation","url":"https://dummy.example/","user_agent":"xxx"},{"age":510,"body":{"blockedURL":"https://dummy.example/img.jpg","destination":"image","disposition":"enforce","type":"corp"},"type":"coep","url":"https://dummy.example/","user_agent":"xxx"}]' \
    YOUR_ENDPOINT
  

  נקודת הקצה צריכה להשיב קוד הצלחה (200 או קוד תשובה אחר שמציין הצלחה 2xx). אם היא לא עושה זאת, יש בעיה בהגדרה שלה.

מנגנוני דיווח קשורים

דוחות בלבד

כותרות המדיניות של -Report-Only וReporting-Endpoints פועלות יחד.

נקודות הקצה שהוגדרו ב-Reporting-Endpoints וצוינו בשדה report-to של Content-Security-Policy, Cross-Origin-Embedder-Policy ו-Cross-Origin-Opener-Policy יקבלו דוחות אם תהיה הפרה של כללי המדיניות האלה.

אפשר לציין נקודות קצה שהוגדרו ב-Reporting-Endpoints גם בשדה report-to של Content-Security-Policy-Report-Only, Cross-Origin-Embedder-Policy-Report-Only ו-Cross-Origin-Opener-Policy-Report-Only. הם גם יקבלו דוחות על הפרות של כללי המדיניות האלה.

הדוחות נשלחים בשני המקרים, אבל הכותרות של -Report-Only לא אוכפות את המדיניות: שום דבר לא ייפגע או ייחסם בפועל, אבל תקבלו דוחות על מה היה נשבר או נחסם.

ReportingObserver

ממשק ה-JavaScript API‏ ReportingObserver יכול לעזור לכם לעקוב אחרי אזהרות בצד הלקוח.

ReportingObserver וגם הכותרת Reporting-Endpoints יוצרים דוחות שנראים זהים, אבל הם מאפשרים תרחישי שימוש שונים במקצת.

כדאי להשתמש ב-ReportingObserver אם:

• אתם רוצים לעקוב רק אחרי הוצאה משימוש או אחרי התערבויות של הדפדפן. ‫ReportingObserver מציג אזהרות בצד הלקוח כמו הוצאה משימוש והתערבויות של הדפדפן, אבל בניגוד ל-Reporting-Endpoints, הוא לא מתעד סוגים אחרים של דוחות כמו הפרות של CSP או COOP/COEP.
• אתם צריכים להגיב להפרות האלה בזמן אמת. ReportingObserver מאפשר לצרף קריאה חוזרת לאירוע של הפרה.
• רוצים לצרף מידע נוסף לדוח כדי לסייע בניפוי הבאגים, באמצעות הקריאה החוזרת המותאמת אישית.

הבדל נוסף הוא ש-ReportingObserver מוגדר רק בצד הלקוח: אתם יכולים להשתמש בו גם אם אין לכם שליטה בכותרות בצד השרת ואתם לא יכולים להגדיר את Reporting-Endpoints.

קריאה נוספת

• מדריך להעברה מ-Reporting API גרסה 0 לגרסה 1
• ReportingObserver
• מפרט: גרסה קודמת של Reporting API‏ (v0)
• מפרט: Reporting API חדש (גרסה 1)

תמונה ראשית (Hero) מאת Nine Koepfer / @enka80 ב-Unsplash, נערכה. תודה רבה לאיאן קללנד, לאייג'י קיטאמורה ולמיליקה מיחייליה על הביקורות וההצעות שלהם בנוגע למסמך הזה.