מבחני הקלדה מזהים רמאות באמצעות בדיקת יומן ההקשות שמאחורי כל תוצאה. המבחן שלנו מחשב מחדש כל תוצאה מיומן ההקשות שלה, בודק hash, בוחן את המבנה והתזמון של היומן, ומחזיק מחוץ לטבלאות הציבוריות כל תוצאה מתוזמנת מעל 130 WPM שגם התזמון שלה נראה חריג, עד שתעברו מבחן חוזר. בדיקות התזמון תופסות בוטים רשלניים; המבחן החוזר מכריח בוט זהיר לעשות הכול שוב.
הבוט הראשון שעבר את בדיקות התזמון שלנו היה שלנו.
כלי העזר שלנו לבדיקות מקצה לקצה לחץ על מקשים במרווח קבוע של 40 אלפיות שנייה, כי זה מה שסקריפט בדיקה עושה. השרת חישב מחדש את התוצאה, אישר את ה-hash, ודירג את הריצה כחשודה: אפס שונות בין הקשות, אפס rollover, זמני החזקה זהים. היינו צריכים להוסיף רעד אקראי לכל מילה והפסקות "מחשבה" מזדמנות של 80 עד 300 אלפיות שנייה לפני שחבילת הבדיקות שלנו עצמנו הצליחה לשלוח תוצאה שנראית אנושית. האפשרות עדיין נמצאת בקוד, תחת השם humanLike.
הבדיקות עובדות נגד כל מה שלא מתאמץ, וכל מה שמתאמץ יכול לעבור אותן, ולכן התכנון שם את המשקל האמיתי על מבחן חוזר.
שלב ראשון: לחשב הכול מחדש
הדפדפן שלכם לא שולח לנו WPM. הוא שולח את יומן ההקשות (כל אירוע keydown, keyup, input ו-composition, עם חותמת זמן מהשעון המונוטוני performance.now()), את המדדים שהוא חישב, ו-hash מסוג SHA-256 של התוצאה הקנונית.
השרת מריץ את אותו קוד מדדים על היומן ומשווה. אם מספר כלשהו שונה ביותר מ-0.01, התוצאה נדחית כ-metrics_mismatch. אם ה-hash לא תואם, היא נדחית כ-hash_mismatch. תוסף דפדפן שעורך את שדה ה-WPM, הרמאות הנפוצה ביותר באתרים שסומכים על הלקוח, נכשל כאן. אותן פונקציות מפיקות את המספר שעל המסך שלכם ואת המספר שבמסד הנתונים, ולכן דף המדדים שלנו יכול להבטיח שהדוגמה המחושבת שלו משתחזרת עד שתי ספרות אחרי הנקודה.
למה לא למדוד את זמן המבחן בשרת? כי אז התוצאה שלכם הייתה כוללת את הרשת. כל הקשה הייתה מגיעה אלינו קצת באיחור, בכמות שמשתנה לפי החיבור שלכם, ומקליד מהיר על קו איטי היה מפסיד מהירות שהייתה לו באמת. היומן נותן לנו את השעון של הלקוח לטובת הדיוק ואת החישוב מחדש של השרת לטובת היושר.
שלב שני: האם היומן הגיוני?
לפני כל ניתוח תזמון, בדיקות פשוטות של צורת השליחה:
- המבחן חייב להימשך לפחות 15 שניות או 10 מילים. ריצות קצרות יותר רועשות מדי לדירוג והכי קלות לניפוח.
- תוצאה לא יכולה להגיע לפני שהמבחן יכול היה להסתיים: זמן ההתחלה שלו ועוד האורך שלו. תוצאה של 60 שניות שמגיעה עשרים שניות אחרי שהתחילה לא קרתה.
- מספר האירועים חייב להתאים לתווים שהוקלדו.
- במחשב, כל אירוע input חייב לבוא אחרי keydown בתוך 50 אלפיות שנייה. זה תופס טקסט מודבק, אירועי input מתוסרטים ואת רוב הכלים להזרקת הקשות, שמזרימים טקסט בלי מקש פיזי. הקלדה דרך עורך שיטת קלט (IME composition) פטורה, ותוצאות מטלפון לא נכנסות לטבלאות הציבוריות.
- יומן בלי התחלה, בלי סוף או עם חותמות זמן לא מונוטוניות הוא פגום ונדחה מיד.
שום דבר מזה לא מתוחכם, אבל זה מסיר את רוב הכמות.
שלב שלישי: מה תזמון ההקשות יכול לחשוף?
זה החלק שבכוונה לא תיעדנו במלואו: רשימת המאפיינים פומבית, הספים והמשקלים לא. סף שמתפרסם הוא מטרה. אם היינו אומרים "סטיית תקן מתחת ל-N אלפיות שנייה מסומנת", הגרסה הבאה של כל סקריפט הייתה מוסיפה N ועוד אחת. המאפיינים שאנחנו מנקדים:
הפער הממוצע בין מקשים וכמה הוא משתנה. הקלדה אנושית אינה סדירה. במחקר של Dhakal ועמיתיו מ-2018 על 168,960 מקלידים, המרווח הממוצע בין מקשים היה כ-239 אלפיות שנייה עם סטיית תקן של כ-112 אלפיות שנייה. לסקריפט שמקליד במרווח קבוע כמעט אין שונות; מחקר מ-2025 ב-arXiv על CAPTCHA מבוסס הקשות ראה בדיוק את זה בבוט הבדיקה שלו, שהקליד בהשהיה קבועה של 50 אלפיות שנייה. זה האות החזק ביותר שלנו, וזה שכלי העזר שלנו נתקל בו.
שיעור הפערים מתחת ל-40 אלפיות שנייה. פער של 40 אלפיות שנייה, לאורך זמן, הוא 1,500 תווים בדקה, או 300 WPM לפי חמישה תווים למילה. אצבעות כן מפיקות פערים בודדים קצרים כאלה כשהן מחפות בין מקשים בזמן rollover, כך שפער קצר אחד לא אומר כלום. יומן שבו חלק גדול מהפערים קצר כל כך אינו הקלדה.
זמני החזקת מקשים. אצבעות אמיתיות משתנות בעשרות אלפיות שנייה; לאירועים סינתטיים יש לעיתים קרובות זמני החזקה זהים או קרובים לאפס, כי הכלי משגר keydown ו-keyup אחד אחרי השני.
יחס ה-rollover. באיזו תדירות המקש הבא יורד לפני שהקודם עולה. Dhakal מדד יחס rollover ממוצע של 25%, כשרוב המקלידים המהירים עושים rollover ב-40 עד 70% מהלחיצות, והמקשים חופפים ב-30 אלפיות שנייה בממוצע. מקלידים איטיים כמעט לא משתמשים בו, כך שתוצאה מהירה בלי rollover בולטת. בוטים רק לעיתים רחוקות מחפים בין מקשים.
ההפסקה הארוכה ביותר, תנודות מהירות משנייה לשנייה, ושיעור הפערים מעל שנייה אחת. אנשים מהססים בדרכים שסקריפט צריך שיגידו לו לחקות.
מודל ניקוד משלב את אלה ויכול לסמן תוצאה כחשודה. מתחת ל-130 WPM, סימון לא דוחה שום דבר בפני עצמו. התוצאה שלכם אף פעם לא מוסתרת מכם; הבדיקות האלה מחליטות רק אם היא תדורג.
האם רמאות במבחן הקלדה יכולה לעבור בדיקות תזמון?
כן, אם הרמאות בנויה בזהירות. מאמר מינואר 2026 ב-arXiv של David Condrey בחן גלאים מבוססי תזמון הקשות שנועדו להבחין בין טקסט שהוקלד על ידי אדם לטקסט שנוצר בבינה מלאכותית. הם הפרידו באופן מושלם הזרקה אוטומטית לחלוטין, אבל התקפות עם תזמון אנושי (אדם שמקליד מחדש טקסט של בינה מלאכותית, או תוכנה שדוגמת השהיות מנתוני הקלדה אנושיים) חמקו מכל חמשת המסווגים בשיעורים של 99.8% לפחות. המאמר עוסק בזיהוי מחברים, לא במבחני הקלדה, אבל הלקח עובר: שלב שלישי תופס את הרשלנים ולא הרבה יותר.
כלי הבדיקה שלנו מראה את אותו דבר בקנה מידה קטן: רעד אקראי וכמה הפסקות העבירו אותו מסינתטי בעליל לסביר.
לכן שלב שלישי הוא מסנן. ההכרעה מגיעה משלב רביעי.
שלב רביעי: מבחן האימות החוזר
אם תוצאה מתוזמנת היא מעל 130 WPM וגם התזמון שלה נראה חריג, אתם רואים אותה והיא נשמרת, אבל היא נשארת מחוץ לטבלאות הציבוריות עד שתעברו מבחן אימות חוזר. זה מבחן חדש של 30 שניות, וצריך להגיע בו לפחות ל-75% מהמהירות שהצהרתם עליה. הצלחה מקרית חד־פעמית או יומן מושאל לא שורדים ריצה שנייה.
למה 130 WPM? זה בערך פי שניים וחצי מהממוצע של 51.56 WPM בנתונים של Dhakal, הרבה מעבר לרוב המקלידים, ומי שבאמת מקליד כל כך מהר יכול לעשות את זה פעמיים. תוצאה מהירה פתאומית עם תזמון מוזר היא הצורה שיומן מושאל או סקריפט מייצרים, ואם היא כנה, מבחן אחד נוסף הוא מחיר קטן.
המבחן החוזר הוא מבחן הקלדה רגיל, בטקסט רגיל, לא תמונה מעוותת או דף של סמלים מוזרים. טקסט שקשה לקרוא מאט את כולם, ומי שהוא מאט הכי הרבה הם המקלידים המהירים והישרים שהמבחן החוזר קיים כדי לנקות. אימות שמקלידים מהירים וישרים נכשלים בו גרוע מהיעדר אימות. טקסט רגיל גם הופך את הבדיקה להוגנת: היומן של המבחן החוזר עצמו עובר את אותן בדיקות תזמון כמו כל תוצאה אחרת.
הגבלות קצב וחסימות
השליחות מוגבלות בקצב: שלושים בדקה לכל משתמש מחובר, שישים לכל כתובת IP. חשבון שממשיך להיתקל בבדיקות מקבל חסימת צל, כלומר מוסתר בשקט מהטבלאות, ושלושה אירועי מניעת רמאות חמורים בתוך 24 שעות מפעילים את זה אוטומטית. ספירת אירועים בתוך חלון זמן אומרת שתוצאה מוזרה אחת אף פעם לא תעלה לכם בחשבון, בעוד שסקריפט שנכשל שוב ושוב נעצר מהר.
טבלאות המובילים של כל הזמנים דורשות גם 30 דקות של הקלדה בחשבון, כך שחשבון חדש עם ריצה מושלמת אחת לא יכול להגיע לראשן.
מה גורם לסימון בטעות
רוב התוצאות המסומנות אינן רמאות. הדרכים הכנות להיתקל בבדיקה:
תיקון אוטומטי בטלפון. החלפה מגיעה כאירוע input אחד שמשנה כמה תווים. אנחנו סופרים אותה כלחיצה אחת, מסמנים אותה ומשאירים את התוצאה מחוץ לטבלאות הציבוריות עם הערה, לא עם דחייה.
טקסט מודבק. הדבקה חסומה, ותוצאה שבה היה ניסיון הדבקה לא נכנסת לטבלאות.
מעבר בין לשוניות. מיקוד שעוזב את הדף ליותר משתי שניות במהלך מבחן מסמן אותו כמופרע; הוא נשמר ומוצג אבל לא מדורג.
השהיה. פער של יותר מחמש שניות במבחן מילים או ציטוט מסמן את התוצאה כמושהית. אותו טיפול.
IME composition. קלט ביפנית, בקוריאנית ובסינית מגיע דרך אירועי composition, ולכן אנחנו מדלגים עליהם בכלל ה-keydown. אם משהו עדיין נראה לא בסדר, זה באג, ונשמח לקבל את היומן.
תוצאות לא מקוונות. תוצאה שסונכרנה יותר מעשר דקות אחרי שהסתיימה נשארת בהיסטוריה שלכם בלי דירוג, כי אנחנו לא יכולים לאמת את השעון שלה.
להיות מהירים באמת. מעל 130 WPM תפגשו את המבחן החוזר, כנראה ביום הטוב הראשון שלכם.
איך מערערים
כל החרגה מציגה את הסיבה שלה בהיסטוריה שלכם. אם אתם חושבים שטעינו לגבי תוצאה או הגבלה, שלחו מייל לכתובת הערעורים שבדף מניעת הרמאות שלנו מהכתובת שרשומה בחשבון שלכם, עם הקישור לתוצאה או התאריך והשעה של המבחן. אדם צופה בשחזור ההקשות ועונה תוך כמה ימים. ערעורים אף פעם לא מוכרעים על ידי המודל האוטומטי לבדו.
האם בדיוק פרסמנו מדריך לעקיפת הבדיקות? חלקית. רשימת המאפיינים תמיד הייתה ניתנת לגילוי מתוך ההתנהגות, והספים נשארים פרטיים. המבחן החוזר הוא החלק שחשוב, והדרך לעבור אותו היא להקליד.
שאלות נפוצות
איך מבחני הקלדה מזהים בוטים?
הטובים קוראים את יומן ההקשות: האם מאחורי כל תו יש לחיצת מקש, כמה הפערים בין המקשים משתנים, ואיך מקשים מוחזקים וחופפים. סקריפטים נוטים להיות סדירים מדי; בוטים זהירים יכולים לחקות בני אדם, ולכן אנחנו מוסיפים מבחן חוזר.
האם בוט יכול לעבור את מניעת הרמאות של מבחן הקלדה?
בוט זהיר יכול לעבור בדיקות תזמון: מחקר על גלאים מבוססי תזמון הקשות מצא שתזמון מזויף דמוי־אנושי חמק מהם כמעט בכל פעם. לכן אנחנו מחזיקים תוצאות מהירות למבחן חוזר, שבוט צריך לעבור שוב עם יומן שני שעובר את אותן בדיקות.
למה תוצאת מבחן ההקלדה שלי לא דורגה?
בדרך כלל מבחן קצר מ-15 שניות או מ-10 מילים, הפסקה של יותר מחמש שניות, מעבר בין לשוניות, או תוצאה מעל 130 WPM שממתינה למבחן החוזר שלה. ההיסטוריה שלכם מציגה את הסיבה.