mirror of
https://github.com/privacyguides/privacyguides.org.git
synced 2024-12-25 23:49:35 -05:00
62 lines
9.7 KiB
Markdown
62 lines
9.7 KiB
Markdown
|
---
|
||
|
title: "תפיסות מוטעות נפוצות"
|
||
|
icon: 'material/robot-confused'
|
||
|
---
|
||
|
|
||
|
## "תוכנת קוד פתוח תמיד מאובטחת" או "תוכנה קניינית מאובטחת יותר"
|
||
|
|
||
|
מיתוסים אלו נובעים ממספר דעות קדומות, אך האם קוד המקור זמין ואופן רישיון התוכנה אינו משפיע מטבעו על אבטחתה בשום צורה. == לתוכנת קוד פתוח יש את ה*פוטנציאל* להיות מאובטח יותר מתוכנה קניינית, אבל אין שום ערובה שזה המצב.== כאשר אתה מעריך תוכנה, עליך להסתכל על המוניטין והאבטחה של כל כלי על בסיס אישי.
|
||
|
|
||
|
תוכנת קוד פתוח *ניתנת* לביקורת על ידי צדדים שלישיים, ולעתים קרובות היא שקופה יותר לגבי נקודות תורפה אפשריות מאשר עמיתים קנייניים. זה גם מאפשר לך לסקור את הקוד ולהשבית כל פונקציונליות חשודה שתמצא בעצמך. עם זאת, *אלא אם כן תעשה זאת*, אין ערובה שהקוד הוערך אי פעם, במיוחד עם פרויקטי תוכנה קטנים יותר. תהליך הפיתוח הפתוח נוצל לפעמים גם כדי להכניס פרצות חדשות אפילו לפרויקטים גדולים.[^1]
|
||
|
|
||
|
בצד השני, תוכנה קניינית פחות שקופה, אבל זה לא מרמז על כך שהיא לא מאובטחת. פרויקטי תוכנה קנייניים גדולים ניתנים לביקורת פנימית ועל ידי סוכנויות צד שלישי, וחוקרי אבטחה בלתי תלויים עדיין יכולים למצוא נקודות תורפה עם טכניקות כמו הנדסה לאחור.
|
||
|
|
||
|
כדי להימנע מהחלטות מוטות, *חיוני* שתעריך את תקני הפרטיות והאבטחה של התוכנה שבה אתה משתמש.
|
||
|
|
||
|
## "שינוי באמון יכול להגביר את הפרטיות"
|
||
|
|
||
|
אנחנו מדברים הרבה על "שינוי אמון" כאשר דנים בפתרונות כמו VPNs (המסיטים את האמון שאתה נותן בספק אינטרנט שלך לספק VPN). למרות שזה מגן על נתוני הגלישה שלך מספק האינטרנט שלך *באופן ספציפי*, לספק ה-VPN שתבחר עדיין יש גישה לנתוני הגלישה שלך: הנתונים שלך אינם מאובטחים לחלוטין מכל הצדדים. משמעות הדבר היא:
|
||
|
|
||
|
1. עליך לנקוט משנה זהירות בעת בחירת ספק להעביר אליו אמון.
|
||
|
2. אתה עדיין צריך להשתמש בטכניקות אחרות, כמו E2EE, כדי להגן על הנתונים שלך לחלוטין. חוסר אמון בספק אחד בלבד כדי לסמוך על אחר אינו מאבטח הנתונים שלך.
|
||
|
|
||
|
## "פתרונות המתמקדים בפרטיות הם אמינים מטבעם"
|
||
|
|
||
|
התמקדות אך ורק במדיניות הפרטיות ושיווק של כלי או ספק יכול לעוור אותך לחולשותיו. כאשר אתה מחפש פתרון פרטי יותר, עליך לקבוע מהי הבעיה הבסיסית ולמצוא פתרונות טכניים לבעיה זו. לדוגמה, ייתכן שתרצה להימנע מ Google Drive, המעניק ל - גוגל גישה לכל הנתונים שלך. הבעיה הבסיסית במקרה זה היא חוסר ב-E2EE, אז כדאי לוודא שהספק אליו אתם עוברים מיישם את E2EE, או להשתמש בכלי (כמו [Cryptomator](../encryption.md#cryptomator-cloud)) המספק E2EE בכל ספק ענן. מעבר לספק "ממוקד פרטיות" (שאינו מיישם E2EE) לא פותר את הבעיה שלך: הוא פשוט מעביר את האמון מגוגל לספק הזה.
|
||
|
|
||
|
מדיניות הפרטיות והנהלים העסקיים של ספקים שאתה בוחר חשובים מאוד, אך יש להתייחס אליהם כמשניים להבטחות טכניות לפרטיות שלך: אל תעביר אמון לספק אחר כאשר אמון בספק אינו דרישה כלל.
|
||
|
|
||
|
## "מסובך זה יותר טוב"
|
||
|
|
||
|
לעתים קרובות אנחנו רואים אנשים שמתארים מודלים של איום על פרטיות שהם מורכבים מדי. לעתים קרובות, פתרונות אלה כוללים בעיות כמו חשבונות דוא"ל רבים ושונים או התקנות מסובכות עם הרבה העברת חלקים ותנאים. התשובות הן בדרך כלל תשובות לשאלה "מהי הדרך הטובה ביותר לעשות *X*?"
|
||
|
|
||
|
מציאת הפתרון "הטוב ביותר" עבורך לא בהכרח אומרת שאתה מחפש פתרון לא נכון עם עשרות תנאים - לעתים קרובות קשה לעבוד עם פתרונות אלה באופן מציאותי. כפי שציינו קודם לכן, אבטחה באה לעתים קרובות במחיר של נוחות. בהמשך אנו מספקים כמה טיפים:
|
||
|
|
||
|
1. ==פעולות צריכות לשרת מטרה מסוימת:== תחשוב איך לעשות מה שאתה רוצה עם הכי פחות פעולות.
|
||
|
2. ==הסר נקודות כשל אנושיות:== אנחנו נכשלים, מתעייפים ושוכחים דברים. כדי לשמור על אבטחה, הימנע מהסתמכות על תנאים ותהליכים ידניים שאתה צריך לזכור.
|
||
|
3. ==השתמש ברמת ההגנה הנכונה עבור מה שאתה מתכוון.== לעתים קרובות אנו רואים המלצות על מה שנקרא פתרונות אכיפת חוק או הוכחת זימון. אלה דורשים לעתים קרובות ידע מומחה ובדרך כלל הם לא מה שאנשים רוצים. אין טעם לבנות מודל איום מורכב לאנונימיות אם ניתן בקלות לבטל את האנונימיות באמצעות פיקוח פשוט.
|
||
|
|
||
|
אז איך זה עשוי להיראות?
|
||
|
|
||
|
אחד מדגמי האיום המובהקים ביותר הוא כזה שבו אנשים *יודעים מי אתה* ואחד שבו הם לא יודעים. תמיד יהיו מצבים שבהם אתה חייב להצהיר על שמך החוקי ויש אחרים שבהם אתה לא צריך.
|
||
|
|
||
|
1. **זהות ידועה** - זהות ידועה משמשת לדברים שבהם עליך להצהיר על שמך. ישנם מסמכים וחוזים משפטיים רבים שבהם נדרשת זהות משפטית. זה יכול לנוע בין פתיחת חשבון בנק, חתימה על חוזה שכירות, השגת דרכון, הצהרות מכס בעת יבוא פריטים או התמודדות אחרת עם הממשלה שלך. דברים אלה יובילו בדרך כלל לאישורים כגון כרטיסי אשראי, בדיקות דירוג אשראי, מספרי חשבונות ואולי כתובות פיזיות.
|
||
|
|
||
|
אנחנו לא ממליצים להשתמש ב-VPN או ב-Tor עבור אף אחד מהדברים האלה, מכיוון שהזהות שלך כבר ידועה באמצעים אחרים.
|
||
|
|
||
|
!!! tip "טיפ"
|
||
|
|
||
|
בעת קניות באינטרנט, השימוש ב[ארונית חבילות](https://en.wikipedia.org/wiki/Parcel_locker) יכול לעזור לשמור על פרטיות הכתובת הפיזית שלך.
|
||
|
|
||
|
2. **זהות לא ידועה** - זהות לא ידועה יכולה להיות שם בדוי יציב שאתה משתמש בו באופן קבוע. זה לא אנונימי כי זה לא משתנה. אם אתה חלק מקהילה מקוונת, ייתכן שתרצה לשמור על דמות שאחרים מכירים. שם בדוי זה אינו אנונימי מכיוון שאם מנוטרים מספיק זמן - פרטים על הבעלים יכולים לחשוף מידע נוסף, כגון האופן שבו הם כותבים, הידע הכללי שלהם לגבי נושאים מעניינים וכו'.
|
||
|
|
||
|
ייתכן שתרצו להשתמש ב - VPN כדי להסתיר את כתובת ה - IP שלכם. קשה יותר להסוות עסקאות פיננסיות: תוכל לשקול להשתמש במטבעות קריפטוגרפיים אנונימיים, כגון [Monero](https://www.getmonero.org/). שימוש בהעברת אלטקוין עשוי גם לעזור להסוות את מקור המטבע שלך. בדרך כלל, ההחלפות דורשות את השלמת KYC (הכר את הלקוח שלך) לפני שהן יאפשרו לך להחליף מטבע פיאט לכל סוג של מטבע קריפטוגרפי. גם אפשרויות מפגש מקומיות עשויות להוות פתרון; עם זאת, אלה לעתים קרובות יותר יקרים ולפעמים גם דורשים KYC.
|
||
|
|
||
|
3. **זהות אנונימית** - גם עם ניסיון, זהויות אנונימיות קשות לשמירה לאורך תקופות זמן ארוכות. הן צריכות להיות זהויות קצרות טווח וקצרות מועד המסובבות באופן קבוע.
|
||
|
|
||
|
שימוש ב- Tor יכול לעזור בזה. ראוי גם לציין כי אנונימיות רבה יותר אפשרית באמצעות תקשורת אסינכרונית: תקשורת בזמן אמת חשופה לניתוח של דפוסי הקלדה (כלומר יותר מפסקת טקסט, מופצת בפורום, באמצעות דואר אלקטרוני וכו')
|
||
|
|
||
|
--8<-- "includes/abbreviations.he.txt"
|
||
|
|
||
|
[^1]: אחת הדוגמאות הבולטות לכך היא [תקרית 2021 שבה חוקרים מאוניברסיטת מינסוטה הציגו שלוש נקודות תורפה לפרויקט פיתוח ליבת לינוקס](https://cse.umn.edu/cs/linux-incident).
|