מה שיותר מפתיע מהקביעה הנ”ל הינה מי שקובע אותה.

המשפט נאמר ע”י לא אחר מאשר דובר מיקרוסופט.

זאת חתיכת פירסומת…

שחר

וללא מאמינים – הנה הקישור ל-ynet.

נכון שראיתם ישר על מה אני מדבר מהכתבה של ynet? מה, לא? אז אני אסביר.

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

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

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

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

כבר כתבתי על זה בעבר כאן וגם כאן.

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

שמעתם? רכישה לכל דבר. אני חושב שזה יום גדול.

שחר

אזהרה חמורה!

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

משום מה, ההפניה של ynet לחלוטין הרסה את יעד ההפניה הנכון. הגבתי על כתבה ב-YNet (תגובה מס’ 7), שהפנתה לקטע שכתבתי על SHA-1. אלא שהמערכת של ynet אכלה את ה-&, מה שגורם למי שעוקב אחרי הקישור להגיע הנה ולחשוב שאני סוחט כניסות לבלוג.

אז התכוונתי לקשר לקישור שלעיל.

שחר

סמנו ביומנכם את ה-12 באפריל. זהו היום שבו כדאי להדליק את המחשב שלכם מאוד בזהירות. ב-12 באפריל מיקרוסופט עומדת להפוך את ההתקנה של SP2 על המחשבים לברירת המחדל.

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

כאשר באים להתמודד עם איומי אבטחת מידע נהוג לדבר על “חלון החשיפה” (Window of exposure). ז”א, עד כמה אני צפוי לראות התקפות מוצלחות על באג נתון.

בגדול, הגרף של חלון החשיפה נראה כך:


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

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

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

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

הבעיה היא בעיית האמינות.

סטטיסטית, ונגד זה אין מה לעשות, קורה שעדכון תוכנה דופק משהו. כאשר יצא SP2 לראשונה, כחמישה אחוז מהמחשבים שהתקינו אותו לא הצליחו לעשות boot אחר כך. בהיסטוריה של מיקרוסופט היו לא מעט עדכוני אבטחה שפגעו בפונקציונליות. למשל, אם המחשב שלכם מציג את כותרות החלונות בעברית משמאל לימין כאשר החלון מוקטן, זה בגלל עדכון אבטחה מספר MS04-011. אחוזי עדכוני האבטחה שמיקרוסופט דופקת הם לא גבוהים במיוחד. מצד שני, כשיש כל כך הרבה מהם….

ואז עומד מנהל אבטחת מידע מול הודעה כמו זו שיצאה על MS04-011, ומסתכל על ה-known issues. בינהם: המחשב לא עולה, אי אפשר לעשות login, אורקל מפסיק לעבוד, וכן הלאה וכן הלאה.

במצב כזה יש רק פתרון אחד. לא להתקין את העדכון. זה שתולעת Sasser יצאה, שמנצלת את אחד החורים ש-MS04-011 אמור היה לפתור, כאשר עדיין אין פתרון משביע רצון להתקנה של העדכון, לא שיפר את המצב.

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

מיקרוסופט מנסה להלחם בתופעה. זה בסדר כל עוד העדכונים שלה אמינים. מה יקרה, אבל, בפעם הבאה שייצא עדכון באותה רמת גימור של MS04-011? האם מיקרוסופט תיקח אחריות על אבדן הפריון של 10% ממחשבי העולם שהפסיק לעבוד בבת אחת? רשיון משתמש הקצה שלה טוען שלא.

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

שחר

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

למרבה השמחה, את השלב הזה הצלחתי לעבור.

עכשיו כל מה שנשאר זה עבודה קשה. עם זה אני אדע להסתדר….

שחר

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

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

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

עדיין, לפעמים אין ברירה. לפעמים צריך לאפשר ביצוע של התאמות אישיות ברמה מאוד גבוהה, או שהמוצר לא מפיק את הפוטנציאל שלו. במצב כזה, נהוגים כמה פתרונות. אף אחד מהם לא טוב.
2. לשים את כל האפשרויות במסך אחד עצום. המשתמש מקבל מסף מלא מלא אופציות, כתובות צפוף, וללא יכולת להבין מה חשוב ומה לא.
3. לדרג את האופציות, תוך שימוש בתפריטים ותפריטי עזר. זוהי האופציה שבה בחרו מיקרוסופט בשביל Office. זוהי אפשרות שמגדילה באופן משמעותי את האיזון בין הצורך לתת גישה לאפשרויות לבין הצורך לא להעיק יותר מידי על המשתמש. הבעיה היא שאז למשתמש מאוד קשה לזכור איפה ומה הוא מוצא. אתה זוכר שיש אפשרות ב-Word לייצר תבניות של מסמכים עם שמות שונים להדפסה, אבל איפה לעזאזל האפשרות הזו היתה? בחלונות וב-Office ניסו להקטין את הבעיה על ידי זה שאופציות לא מופיעות עד שלא השתמשתם בהן פעם אחת (Personalized menus). באופן אישי, אני מרגיש שזה מוסיף לבילבול מכך שיש הרבה אופציות את זה שהתפריטים לעולם אל נראים אותו הדבר פעמיים.
4. לשים בתפריטים הגרפיים רק את הדברים העיקריים, ואז לשים במקום משני, לא גרפי, את שאר האופציות. על חלונות המקום המשני מכונה “Registry”. מצד אחד, הבילבול למשתמש הפשוט הינו מינימלי. מצד שני, אין שום דרך לדעת אילו אופציות נוספות יש, או מה המשמעות שלהן.

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

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

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

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

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

שני אגבים:
א. בלינוקס יש איזון יפיפה בין השניים. כל השירותים של המערכת מנוהלים על ידי קבצי תצורה מילוליים, אבל קיימים כלים גרפיים שמנהלים אותם. כך אתם יכולים לבחור באיזה עולם אתם מעדיפים לחיות. למעשה, אני למדתי להפעיל את GDB (שהוא debugger שורת פקודה) על ידי זה שהשתמשתי במעטפות גרפיות שלו (בעיקר DDD), וראיתי אילו פקודות הוא מוציא כשאני לוחץ על הכפתור המתאים.
ב. אפילו מיקרוסופט הבינו שלא ניתן (או לא הגיוני) לעשות דברים מסויימים בצורה גרפית. הם הכניסו את Windows Scripting Host, שהם לא פחות מאשר קבצי shell script לעשות את הפעולות שניתן היה, בעיקרון, לעשות רק בצורה גרפית בחלונות. כמובן שמכיון שהכלים האילו אינם בשימוש יומיומי, הם לא באותה רמת הגימור והליטוש כמו מקבילהם בעולם היוניקס.

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

שחר

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

ידיעה בסלאשדוט מפנה לידיעה ב-The Inquirer, שבתורה מפנה לידיעה ב-Computer World, ולהלן התמצית.

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

וכל הסימנים מראים שהוא כבר כאן.

מאיפה אני יודע את זה? תשובה: כל מאבקי הרוגלות למניהם בסך הכל הולכים בעקבות כלי ה-rootkit.

עכשיו ההסבר.

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

הדור הראשון של rootkits היה תמים ביחס. על יוניקס היה פשוט נהוג להתקין כלים חלופיים לפקודות כמו “ls”, “top”, “ps” וכו. על חלונות זה התבטא בלהתקין ברקע תוכנות שליטה מרחוק, כמו “Backoriffice“. הבעיה עם הכלים האילו היתה שהיה יחסית קל לגלות ולהוריד אותם.

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

ואז הגיע הדור השלישי. אילו מכונים “kernel mode rootkit”. הרעיון מאחוריהם (בניגוד לביצוע) הוא פשוט. במקום לנסות לשנות את הקריאות למערכת של התוכנות שעליהן רוצים להשפיע, משנים את מה שהמערכת עושה כשהיא מקבלת את הקריאות הרגילות. במילים אחרות – מזריקים את הקוד העויין לליבה של המערכת, וברמה הזו משנים את מה שהמערכת עושה.

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

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

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

העניין עלה כאשר היה באד באחד מהכלים הנ”ל שהסתובב בעולם. בניגוד לבאג בתוכנה רגילה, באג בליבה גורם לקריסת כל המחשב, עם הודעה מטעם הליבה שמשהו רע קרה. מכיוון שההודעה הנ”ל, בחלונות, כתובה בלבן על רקע כחול, היא זכתה לשם “Blue Screen of Death”, או BSOD (מסך כחול בעברית). במילים אחרות, kernel rootkits על חלונות נגלים רק כאשר יש בהם באג.

לפני שאני ממשיך, אני ממליץ לכל משתמשי הלינוקס מבין קוראי להוריד ולהריץ תוכנה בשם chkrootkit, אשר עושה עבודה לא רעה בלגלות האם יש kernel mode rootkit על המכונה (וגם rootkits רגילים יותר).

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

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

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

מסקנות

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

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

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

שחר

איוון ליאו פוטי מדווח ברשימת התפוצה של מפתחי Wine שהכלי החדש של מיקרוסופט לבדיקה האם החלונות שברשותכם חוקי מכיל את המחרוזת “SoftwareWineWineConfig”.

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

אבל מידי פעם יש מישהו שנותן סיבה שלא קשורה ל-Wine עצמו, לגבי למה הוא רוצה לדעת אם הוא רץ על Wine. התשובה שניתנת לו היא “תבדוק קיום של מפתח ברג’יסטרי בשם HKEY_LOCAL_MACHINESoftwareWine”.

Wine מחזיק ברג’סטרי שלו כל מיני נתונים (ומזה כחצי שנה גם את כל מה שנהוג היה שיהיה בקובץ הקונפיגורציה, תחת “HKLMSoftwareWineWineConfig”). מכיוון שלא סביר שתוכנה שרצה על חלונות רגיל תכיל את המפתח הזה, קיום של המפתח הזה מצביע על כך שהתוכנה רצה על Wine.

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

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

שחר

אל תגידו שלא הזהרתי אתכם!

כנראה שפרצו גם את Sha-1. ביחד עם הפריצה של MD5 בתיאור שבלינק למעלה, זה אומר שיש התקפות ידועות על כל האלגוריתמים שבשימוש כיום. למרות שכנראה שזה עוד לא משפיע על השימוש היומיומי בחתימות דיגיטליות (ויש כזה, תאמינו לי), זה כן אומר שכנראה הגיע הזמן להתחיל לחפש תחליפים.

ותזכרו – כבר לפני חצי שנה הזהרתי אתכם…..

שחר

מזל טוב לכולנו

שחר