0.
לפני כחודש כתבתי על הדרישה להגן על משתמשי הענן מפני ספקי שירותי האחסון שלהם. הצעתי להפעיל מנגנון שמגן על המשתמש מפני ספק השירות ומצפין את הקבצים כך שלספק השירות לא תהיה גישה לקבצים עצמם ונתתי את Dropbox כדוגמא. הסיבה שנתתי את דרופבוקס היתה בגלל הארכיטקטורה של השירות. אפשר לומר שידעתי שאירועי החודש האחרון אמורים להתרחש, פשוט לא ידעתי מתי. ומה קרה? ראשית, גילינו שדרופבוקס לא הגנה על משתמשיה מפני הענן ואפשרה לרשויות אכיפת חוק לגשת לקבצי המשתמשים חלק ממדיניות הפרטיות של החברה. שנית, דרופבוקס התנהגה בצורה רעה כאשר פעלה לסגירת פרויקט שיתוף קבצים בקוד פתוח אשר מבוסס על שירותיה אשר היה מבוסס על פרצת אבטחה שהיתה בדרופבוקס, והפכה לשירות ולא לבאג.
1.
כדי להבין איך השירות עבד, צריך להבין איך דרופבוקס מתמודדת עם קבצים, כחלק מהשירות: דרופבוקס מזהה קבצים ואת חתימותיהם הדיגיטליות, וכשהיא רואה שיש לה עותק של הקובץ, היא משתמשת בעותק הקיים של הקובץ במקום להעתיק אותו ממשתמש הקצה. כך, לדוגמא, אם אני רציתי לאחסן את קבצי הMP3 (שנרכשו כחוק) של ג'סטין ביבר, בתיקיית הדרופבוקס שלי, אז כאשר אני מתחבר לרשת, דרופבוקס תזהה שיש לה כבר את הקבצים האלו (ממשתמש אחר, שגם כן רכש אותם כחוק, כמובן) ופשוט תעתיק אותם לתיקיה שלי. זה לא באג, אלא שירות: הוא חוסך אחסון, רוחב פס וכח מחשוב ומאפשר למשתמשים לנהל מערכות משגשגות.
2.
אלא, שהשירות אפשר דבר נוסף: קבוצת אנשים החליטה להשתמש בדרופבוקס על מנת לשתף קבצים: כל שהם היו צריכים לעשות הוא לדעת את ערך הHASH של קובץ מסוים (מפתח שנוצר מאותו הקובץ) ומאותו הרגע, דרופבוקס השלים את השאר. כמובן, הם יכלו תמיד לייצר תיקיה משותפת של הורדות פיראטיות ולחלוק אותה עם הציבור, אבל הם החליטו לייצר מערכת "עמית-לעמית" מבוססת על הענן. אלא, שדרופבוקס לא אהבה את הרעיון בכלל ו ביקשה מהחברה שמאחסנת את הפרויקט למחוק אותו בטענה לפגיעה בזכויות יוצרים (ובין היתר בזכויות היוצרים של דרופבוקס עצמה), כיוון שהחברה המאחסנת נקראת, באורח פלא, דרופבוקס, הרי שלא היתה צפויה התנגדות קשה מדי. מעבר לכך, דרופבוקס שינו את השירות שלהם כדי למנוע מהאפשרות הזו לשוב .
3.
דרופשיפ, הפרויקט שאפשר לשתף קבצים באמצעות השירות לא עשה דבר לא חוקי, הוא בסך הכל הציף שוב את אותה הבעיה ש AIMSter הציפה לפני עשור, כאשר היא השתמשה בחורים בצ'ט על מנת לשתף קבצים. דרופשיפ מצאו שבשביל לשתף קובץ בדרופבוקס, די בכך שיהיה לך את מפתח הHASH שלו: לא משהו שהוא כל כך בעייתי. בסופו של דבר, דרופשיפ אפשרו לציבור לראות את הבעיה שקיימת בדרופבוקס, את הבעיה שכל אדם יכול להעתיק כל קובץ מכל דרופבוקס אחר מבלי לדעת דבר מלבד הHASH של אותו הקובץ; זה כבר לא היה שירות, אלא חור אבטחה, והדרך היחידה לטפל בחור האבטחה הזה הוא לכתוב מחדש את דרופבוקס עם מחשבה על פרטיות מראש.
4.
דרופבוקס יצאו כשידם על התחתונה. אחרי שזכו ליחסי ציבור מרהיבים והגיעו ל25,000,000 משתמשים מבלי לפרסם ואך ורק על ידי שיווק מפה לאוזן, דומה שהם קפצו גבוה מדי. חירות וגמישות הן שתי הסיבות העיקריות להשתמש בדרופבוקס, כמו גם העדר תחרות. אולם, מרגע שאתה יודע שהמידע שלך לא רק שלא מאובטח אלא גם תחת בקרה מתמדת, אתה מרגיש הרבה פחות בטוח בענן.
5.
אולי הגיע הזמן להסתכל על מודל האחסון בענן שוב; דרופבוקס היתה נהדרת כל עוד היא החזיקה, אבל אולי כדאי שתלך בדרכו של הדודו ותוחלף על ידי שירות אחסון שיתופי, אינטראקטיבי וידידותי למשתמש.
אתה מתפלא ש DB צריכה לציית לחוק ?
כמובן שהיא צריכה למסור מידע לרשויות החוק ע"פ צו חיפוש חוקי.
כמו שאתה חייב, וכל חברה חייבת לציית לחוקים במדינה בו היא פועלת.
כל מה ש DB עשו זה לציין זאת במפורש בתנאי השרות. ביג דיל.
לגבי פרוייקט הקוד הפתוח: DB הגנו על עצמם בפני תביעה עתידית שבוודאי היתה מגיעה אלמלא מנעו את הפיכת המערכת שלהם למערכת שיתוף קבצים. והם עשו זאת בהדברות ולא ע"י איומי עו"ד ותביעות. מה אתה מצפה מהם לעשות – לתת לחברה לרדת ביגון שאולה עבור פרוייקט OSS שמטרתו בעיקר פיראטיות ?
בקיצור – הם עדיין הכי טובים במה השם עושים.
אם אתה רוצה ליצור חברה יותר טובה, בבקשה.
אבל סתם ללכלך ?
שי,
ברור לי שהם צריכים לציית לחוק. אלא, שהם יכולים לבנות את ארכיטקטורת השירות שלהם בצורה בה הם יענו למשטרה: "תקשיבו, אין לנו גישה לקבצים האלה".
במצב כזה, הם עדיין לא יהיו אחראים משפטית והם גם יצאו הרבה יותר בסדר.
ודרופשיפ היא שטות, היא שטות בעיקר כי היא סתם משתמשת ברוחב הפס של דרופבוקס. אבל היא תוצאה של אותה ארכיטקטורה עקומה. כשיסדרו את הארכיטקטורה העקומה, אז לא תהיה דרופשיפ ולא תהיה בעיית פרטיות.
אני לא בטוח אם הדרישה שלך מדרופבוקס כל כך פשוטה ליישום. אני משתמש בכלי בשביל לשתף המון קבצים עם אנשים (סיכומי שיעורים, אבל בטח יום אחד גם זה יהיה לא חוקי). להצפין את הקבצים בלי שלדרופבוקס יהיה את המפתח פירושו להחזיק סוג של מנגנון ניהול מפתחות הצפנה בצד משתמש הקצה, מה שלדעתי יכול לייצר בעיות תפעוליות לאורך זמן (למשל, אם מחשב המשתמש קרס, אצל מי המפתח? לא בדרופבוקס, כדי להגן עליך ולא אצלך כי המחשב שלך נצלה). אני חושב שצריך לאפשר הצפנה של קבצים כדי להגן על משתמשים, אבל אני לא חושב שזה יוכל לשמש כהגנה מפני החוק, כיוון שהמתפתח צריך להיות היכן שהוא, לרוב גם אצל ספק השירות.
אתה מציע להם ארכיטקטורה שונה.
זכותך להקים מערכת כזו, אבל זו לא המערכת שהם רצו להקים.
הם תמיד היו ברורים וכנים לגבי המערכת שהם בונים – על יתרונותיה (יכולת להוריד קבצים מכל תוכנת גלישה ישירוות מהאתר, למשל), וחסרונותיה – הקבצים לא מוצפנים בשרת.
רעיונות ההצפנה שאתה מציע הם מובנים מאליהם (הצפנה בצד הקליינט עם קצת מלח), ואין ספק שהם יכלו לבצע אותם אם היו רוצים. אני מניח שהסיבה לארכיטרטורה שלהם היא שהם חושבים על שרותים נוספים שהם יוכלו להציע אם יש להם את היכולת הטכנית לגשת לקבצים (חיפוש, עריכה וכו והכל מתוך הווב) – מעבר ליכולת הגישה מכל מקום ללא התקנת תוכנה, שהוא נימוק חזק לכשעצמו.
בקיצור – אתה טוען שללקוחות שמעדיפים פרטיות על נוחות קיימת בתאוריה מערכת אחרת שעדיפה על DB. נו טוב.
עומר,
אתה מתאר בדיוק למה במערכת כמו DB יש איזון בין נוחות וגמישות לאבטחה ופרטיות. אני (וכנראה אתה) מעדיפים את האיזון הנוכחי, יונתן כנראה מעדיף איזון אחר.
ראו דיון שהיה לי ב"באז" בעניין (אנגלית, סליחה) http://goo.gl/KWvbR
עומר – אין סיבה למה לא להחזיק את המפתח ב-dropbox כל עוד הוא מוצפן גם הוא.
אני למשל משתמש ב-Keepass לשמירת הססמאות שלי. הוא יושב ב-Dropbox ומשותף בין שני מחשבים (ככה הוא גם מתעדכן). קובץ הססמאות עצמו מוצפן ומוגן בססמא של מעל ל20 תווים.
בנוסף יש לי גיבוי של Keepass על דיסק און קי שאני מעדכן כל כמה זמן.
אגב יש כעת פתרונות שמאפשרים הצפנה בתוך DB כגון למשל יצירת ארכיב מוצפן בתוכו. אני בטוח שאם נחפש נמצא גם כלי שמאפשר הצפנה פר קובץ.
מעניין איך דרופבוקס ניגש לקבצים שחלונות מצפינה עם האופציה Encrypt. האם מבחינתה הקובץ מוצפן או שהיא ניגשת כאילו מהיוזר שלי, ולכן זה שקוף לה.
טוב עניין ההצפנה של חלונות לא עבד כי דרופבוקס מיוזר אחר פשוט לא קיבל גישה לקובץ המוצפן.
אפשרות אחרת היא שימוש בתוכניות שמצפינות על בסיס קבצים.
כגון BoxCryptor או SecretSync
כפי שאגב דרופבוקס ממליצים בעצמם בוויקי ובפורומים.
אגב סעיף 2 מטעה – לא הוגשה תלונה של זכויות יוצרים. המערכת שלהם שולחת אזהרה אוטומטית בתבנית כזו כאשר קובץ כלשהו מסומן כנוגד את תנאי השימוש. הם התנצלו על העניין כבר.
גם הסעיף הראשון מטעה, השיטה בה היא "פעלה לסגירת פרוייקט קוד פתוח" היא פשוט שליחת בקשה למקים הפרוייקט שמסבירה לו כי הפרוייקט עלול להיות מנוצל לרעה. הוא סגר את הפרוייקט מיוזמתו.
להחזיק מפתח מוצפן בשרת ומפתח למפתח אצל הלקוח שקול לגמרי להחזקת מפתח אצל הלקוח.
המקרה של keypass לא דומה ישירות. אם אתה רוצה אנלוגיה, אז מבחינת DB קובץ המפתחות של KP הוא סתם קובץ נתונים שמוחזק מוצפן בשרת עם מפתח בלקוח. העובדה שהוא מכיל מפתחות היא משנית ולא מעניינת את השרת.
המפתח צריך להיות אצל המשתמש או אצל הספק. אלה שתי האפשרויות היחידות (נתעלם מרגע מהאפשרות להציע ספק שלישי שינהל מפתחות כשירות עסקי). אם הוא אצל המשתמש זה מאובטח, אבל מחייב את המשתמש לנהל את התפעול, בדיוק המקום בו רוב המשתמשים נכשלים. להחזיק את המפתח אצל הספק טוב תפעולית ופחות מאובטח. בשני המקרים ניתן לבחור את המידה בה אנו רוצים לקחת סיכון (על הציר של תפעול מול אבטחה), אבל אין בחירה ללא סיכון.
להחזיק את המפתח אצל הספק זה בד"כ יותר מאובטח. כי אתה תאבד את הדיסק-און-קי שעליו המפתח, ודרופבוקס – כנראה שלו. כי לך יש מעט להפסיד אם המפתח אבד, ולדרופבוקס יש הרבה.
להחזיק את המפתח בדיסק און קי זה מאובטח למדי, כי זה קובץ המפתחות מוצפן בעצמו עם ססמא.
ויש עותקים בדרופבוקס לגיבוי.