קטגוריה: חוק

מתכנת IT

הרבה שנים שאני מנסה להסביר לאנשים מה המקצוע שלי. אני מנסה להסביר כי המקצוע שלי הוא "מתכנת IT", אבל אנשים חושבים כי אני מדבר על DevOps.
התשובה היא לא, זה לא DevOps.

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

עכשיו אשאל אתכם שאלה: האם איש DBA שייך לקבוצה הזו? התשובה היא כן. האם הוא איש DevOps? התשובה היא לא.

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

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

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

איש DBA יודע למשל המון על IO ועל דיסקים, וזיכרון, אבל זה לא אומר שהוא יודע מספיק בשביל להחליף ציוד, או לבחור חומרה בצורה נכונה. הוא רק יודע מה מסוגל לתת ביצועים טובים, אבל האם לוח מסוים עדיף? האם שרת מסוג מסוים? האם בקר מסוים? האם מעבד מדגם אחד טוב יותר וכיוב', הם פחות מהמומחיות שלו. זה לא אומר שהוא אינו יודע, זה אומר שהוא פחות חי את זה. זה יותר סוג של by-product של העבודה, מאשר המומחיות.

להמשיך לקרוא

אנדרואיד, mms ובעיית אבטחה עם פתרון ישים

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

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

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

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

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

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

כיצד עובד ה MMS? אני שולח הודעת SMS במבנה מסוים שאומר כי יש לי משהו כדוגמת תמונה בשרת שניתן להוריד באמצעות WAP.

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

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

אריקסון ו webrtc

כבר כתבתי בעבר על webrtc, אך זה עולם שכל הזמן משתנה ולא רק טכנולוגית.

אחד הדברים שמאוד נחמדים בעולם ה webrtc, זה היענות של מרבית החברות הגדולות בשוק בשביל לאמץ אותו.

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

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

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

החברה פתחה אתר בנושא, ושמה את הקוד שלה ב github, וגם הוא ברישיון פתוח – BSD.
הכלים שהיא משתמשת גם הם פתוחים, כדוגמת Gstreamer .
הם גם משתמשים במימוש של סיסקו – מימוש קוד פתוח עבור H.264, למעשה זה משהו שהם מספקים שגוגל בכלל לא.

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

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

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

כרגע יש קרב גדול על בחירת קודקים לוידאו, כאשר הקרב הוא בין H.264 לבין VP8 ובעתיד גם VP9.

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

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

webrtc ORTC

הקדמה

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

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

היא תומכת ב OPUS, ו G711, ומחייבת אותנו לעבוד בצורה מאובטחת תחת DTLS,

עכשיו כל מה שנשאר זה לממש מערכת סיגנלים כדוגמת SIP או כל פתרון אחר – פשוט יותר עם web sockets,שגם הוא כיום (לפי התקן של webrtc) חייב כבר להיות מאובטח תחת TLS, ויש לנו פיתרון סטרימינג מלא.

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

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

הדגמה קלה (מה RFC):

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=.
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

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

הנה הסבר על מה שאתם רואים מול העיניים שלכם:
האות v, מייצגת version – גרסת הפרוטוקול, שלפחות כרגע היא תמיד 0.
האות o, מייצגת origin של הבקשה, ומכילה (לפי הסדר) – שם משתמש, session id, בנוסף session-version, סוג רשת (אינטרנט), סוג הכתובת, כתובת הרשת.
האות s מייצגת את session, כלומר השם שלו.
האות c מייצגת מידע על connection. זה אומר סוג הרשת, סוג כתובת הרשת, כתובת הרשת.
הכוונה היא לאן רוצים להתחבר בשביל המדיה.
האות t מייצגת זמנים.
האות m מייצגת מדיה, עם סוג מדיה, פורט דינאמי, פרוטוקול משלוח של המדיה, ומידע הקשור לפרוטוקול.
האות a מייצגת attribute, שזה תכונות שונות, למשל כאן, זה מייצג איזה קוקדים של אודיו ישלחו, כולל הקוד שלהם שמוגדר ב RFC עבור כל סוג קודק.

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

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

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

תוכן

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

לפני ORTC, תכננו פרוטוקול אחר לגמרי, אשר היה מאוד low level, ומאוד קשה להגנה, וסיפק יותר מידי כוח בצד המשתמש. הפרוטוקול קיבל את השם Open Peer. אז בגלל הסיבות האלו, החליטו לרדת ממנו.

ואז ישבו הרבה אנשים, אשר רובם יצרו את webrtc ואת Open Peer, והחליטו על גרסה 1.1 לwebrtc בכנס מסחרי מסוים, אם כי למרות ההכרזה על 1.1 ההכרזה מרגישה יותר כמו 2.0.
השם לפרוטוקול החדש באותו כנס, קיבל את השם ORTC או Object Real Time Communication, אשר ה draft הראשון (מבחינת יכולת מימוש) שלו שוחרר באוגוסט 2014.
היכולת לעקוב אחרי דברים, נעשת באתר ייעודי לכך בשם ortc.org.

הרעיון הוא לספק סוג של API, שמצד אחד קל לתכנות, ומצד שני קל לאבטח, אשר מאפשר לשלוט בצורה קלה ופשוטה יותר במידע על המדיה, כאשר יש API בצד ה javascript, אך גם עם תאימות לאחור, בשביל לא לשבור פתרונות קיימים.
אבל לא סתם API, אלא הדגש הוא על גישה של Object Oriented, כאשר בעבר דיברו על כך שהיא תכלול את היכולת להחזיק אובייקטים של סוקטים בשם RTCSocket אשר ניתנים לשימוש מחודש במידת הצורך, ובכך בעצם לעשות שימושיות ב RTC ללא צורך באתחול מחודש של הכל. אך אינני מוצא זאת בdraft האחרון (נכון לכתיבת פוסט זה).

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

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

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

ואכן, זה מה שORTC מבצע. הם יצרו אובייקט בשם RTCRtpCapabilities, אשר התפקיד שלו לדבר על "מה אני צריך" עם הצד השני וניתן אפילו לעשות החלפה בזמן ריצה של המידע (ב SIP זה נקרא re-Invite).

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

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

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

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

למי הפרופיל רשת חברתית קיים אחרי המוות ?

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

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

facebookעכשיו השאלה היא לא רק למי שייך המידע, אלא מה קורה עם פרופיל שכזה כאשר אדם מת ?

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

מה אנחנו כבני אדם בכלל רוצים שיהיה בחברה שלנו במצב שכזה ?

פוסט למחשבה.

NaCl, Sodium והצפנה

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

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

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

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

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

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

תם עידן הפרטיות, תחי הפרטיות

Le roi est mort, vive le roi !

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

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

האם אני רוצה לשתף את הרחוב בכל דבר העובר עלי, או האם אני מעוניין להשאיר לעצמי דברים ?
האם אני באמת חושש מכך שיראו תמונה שלי וידעו שזה אני, או האם אין לי בעיה בכך ?

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

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

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

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

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

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

זה תלוי בנו בלבד, ובבחירות שלנו. אני מקווה שכולנו ננהג בחוכמה בנושא.

מוגש כחומר למחשבה.

הסכנות בשימוש md5 כסיסמה

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

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

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

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

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

במידה אתם מעוניינים לבצע שמירה של סיסמאות, ישנם כ3 אלגוריתמים מומלצים כיום:

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

איך לקרוא חוזה אחיד

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

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

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

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

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

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

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

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

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

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

חוק הנגישות סיבוב 2

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

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

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

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

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