מדיניות פרטיות

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

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

המשמעות המעשית של ההבחנה מופיעה בסעיף 8 — היא קובעת למי פונים כדי לממש זכות.

על העסק ועל בעליו

• פרטי העסק: שם העסק, סוג העסק, טלפון, כתובת וכתובת האתר שנבחרה (ה“slug”).
• חשבון הכניסה: כתובת אימייל וסיסמה. הסיסמה מנוהלת במערכת ההזדהות של Supabase ואינה נשמרת אצלנו כטקסט קריא.
• אנשי צוות: שם, טלפון ותפקיד. עובד שקיבל הרשאת כניסה מקבל גם חשבון משלו, ורואה דרכו את התורים והלקוחות שלו בלבד.
• תוכן שאתם מעלים: לוגו, תמונת באנר, תמונות גלריה, רשימת השירותים והמחירים, שעות הפעילות, והמלצות שאתם מזינים (שם הממליץ, דירוג וטקסט).
• אישור התנאים: מועד אישור תנאי השימוש ומדיניות הפרטיות בהרשמה, וגרסת המסמכים שאושרה.
• רישום גבייה פנימי: סטטוס המנוי (ניסיון / פעיל / בפיגור / בוטל), הסכום החודשי שסוכם, מועד התשלום האחרון שנרשם והערה פנימית שלנו. הרישום הזה מתוחזק ידנית ואינו מוצג בלוח הבקרה.
• הודעת ביטול מנוי: אם ביטלתם את המנוי מהמסך המקוון — נשמרים מזהה העסק וה-slug שלו, שם העסק, מי מהחשבון לחץ, כתובת האימייל והשם של מי שלחץ, הסיבה אם בחרתם למסור אותה (השדה אופציונלי), מועד המסירה לפי שעון השרת, ומועד סיום ההתקשרות שנגזר ממנו. הרשומה הזאת אינה ניתנת לעריכה ואינה נמחקת — היא הראיה למועד שבו נמסרה ההודעה.
• רישום ההודעות ששלחנו לכם: לכל הודעה מאיתנו (שינוי מחיר, החלפת ספק משנה, עדכון תנאים) נשמרים סוג ההודעה, הנושא והגוף, ה-slug של העסק, מועד היצירה, האם ומתי נמסרה בפועל, ומועד האישור שלכם בלוח הבקרה. כתובת האימייל שאליה נשלחה ההודעה אינה נשמרת שם.

על לקוחות הקצה של העסק

את המידע הזה מזין הלקוח בעצמו באתר של העסק, או בעל העסק עבורו. אנחנו מחזיקים אותו עבור העסק — ראו סעיף 1, ואת “אם אתם לקוח קצה של אחד העסקים” בסעיף 9.

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

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

מידע טכני

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

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

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

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

אילו הרשאות אנו מבקשים בדיוק

• openid ו-email — כדי לדעת איזה חשבון Google חובר ולהציג אותו בהגדרות.
• calendar.events — יצירה ומחיקה של אירועי התורים שהפלטפורמה קובעת.
• calendar.readonly — קריאת הזמנים התפוסים כדי לא להציע ללקוח משבצת שכבר תפוסה.

Limited Use. השימוש שלנו במידע שמתקבל מממשקי Google, ובהעברתו לכל אפליקציה אחרת, עומד ב־Google API Services User Data Policy, לרבות דרישות ה-Limited Use. במפורש: איננו מוכרים נתוני Google ואיננו מעבירים אותם לצד שלישי; איננו משתמשים בהם לפרסום, לשיווק, לפרופיל שיווקי או למכירת מידע; איננו מאפשרים לאדם לקרוא אותם — למעט כשהדבר נדרש לתיקון תקלה שדווחה, לצורך אבטחה, או כשהחוק מחייב; ואיננו משתמשים בהם כדי לפתח, לשפר או לאמן מודלים כלליים של בינה מלאכותית או למידת מכונה. השימוש היחיד הוא הפעלת הפונקציה שלשמה חובר היומן, כמתואר למעלה.

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

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

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

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

• בסיס הנתונים, ההזדהות והקבצים יושבים בפרויקט Supabase באזור eu-central-1 — פרנקפורט, גרמניה.
• קוד השרת רץ ב-Vercel באזור fra1 — גם הוא פרנקפורט. זה מוגדר מפורשות בקובץ ההגדרות של הפרויקט, ולא נשאר לברירת המחדל של Vercel (וירג׳יניה, ארה״ב). קבצים סטטיים של האתר מוגשים מרשת הקצה הגלובלית של Vercel, שיכולה לשרת אותם משרת קרוב יותר לגולש.
• Resend, Google ו-ntfy — שירותים שמטה החברות שלהם מחוץ לאיחוד האירופי, ולכן המידע המצומצם שמגיע אליהם (כמפורט בטבלה בסעיף 5) עשוי להיות מעובד גם בארצות הברית או במקומות אחרים.

העברת מידע אל מחוץ לגבולות המדינה כפופה לתקנות הגנת הפרטיות (העברת מידע אל מאגרי מידע שמחוץ לגבולות המדינה), התשס״א-2001. עיקר המידע יושב באיחוד האירופי, שרמת ההגנה בו מוכרת כמספקת. לגבי הספקים שמחוץ לאיחוד — ההעברה נשענת על תנאי השירות ומדיניות הפרטיות של אותם ספקים, כפי שהם מקושרים בטבלה למעלה.

איך המאגר מסווג

תקנות הגנת הפרטיות (אבטחת מידע), התשע״ז-2017 מחלקות מאגרים לשלוש רמות אבטחה, לפי מה שיש בהם. הרמה נקבעת לכל מאגר בנפרד — כלומר לכל עסק בנפרד, ולא לפלטפורמה כולה: לכל עסק מאגר משלו, והוא בעל השליטה בו.

מאגר של קליניקה או של מטפל הוא ברמה בינונית, ולא “עשוי להיות”. היסטוריית התורים בו היא מידע על צנעת חייו האישיים של אדם, וההערה החופשית שבעל העסק כותב היא בפועל מקום שנרשם בו מידע רפואי — שניהם מנויים בתוספת הראשונה לתקנות. מאגר של מספרה או סטודיו, שההערות בו נקיות ממידע רגיש, עשוי להיות ברמה נמוכה יותר. הסף של הרמה הגבוהה (100,000 נושאי מידע, או יותר ממאה בעלי הרשאה) רחוק מאוד מכל עסק על הפלטפורמה.

ומה זה אומר עלינו, כמחזיקים. תקנה 19 מחילה על המחזיק את חובות בעל המאגר. בסיס נתונים אחד ומפתח שרת אחד משרתים את כל העסקים, ואי אפשר להפעיל בקרה על חלקם בלבד — ולכן הפלטפורמה נבנית לרמה הבינונית, הרמה הגבוהה ביותר שדייר כלשהו מייצר. ⚠️ ובאותה נשימה: שתי דרישות של הרמה הזאת אינן מתקיימות היום — נוהל אבטחה מאושר (תקנה 4; קיימת אצלנו טיוטה כתובה שטרם אושרה ואינה בתוקף) וביקורת תקופתית אחת ל-24 חודשים בידי גורם חיצוני (תקנה 16).

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

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

אילו אמצעי אבטחה קיימים בפועל

• בידוד בין עסקים ברמת בסיס הנתונים (RLS). ההפרדה נאכפת במסד עצמו ולא בקוד האתר — עסק אינו יכול לקרוא נתונים של עסק אחר גם בפנייה ישירה, וגם אם יש תקלה בקוד.
• הפרדת הרשאות בתוך העסק. עובד שקיבל חשבון רואה את התורים שלו, את הלקוחות שטיפל בהם ואת השעות שלו — לא של אחרים. רשימת ההמתנה, ייצוא הנתונים וניהול השירותים והשעות שמורים לבעל העסק בלבד.
• סיסמאות מנוהלות במערכת ההזדהות של Supabase ואינן נשמרות אצלנו כטקסט קריא.
• קודי אימות נשמרים כטביעה חד-כיוונית (HMAC-SHA256) ולא כקוד עצמו.
• אסימוני Google מוצפנים במנוחה (AES-256-GCM) ונגישים לשרת בלבד — לעולם לא נחשפים בדפדפן.
• הקישור לניהול תור שנשלח ללקוח מכיל אסימון מוצפן (AES-256-GCM) הקשור לעסק המסוים, ולא את מספר הטלפון — כך שהמספר אינו דולף לכתובות שנשמרות בהיסטוריית הדפדפן וביומנים.
• הגבלת קצב על טפסי ההרשמה, קביעת התור ורשימת ההמתנה, כדי למנוע הצפה וניחוש שיטתי.
• כותרות אבטחה בדפדפן: HTTPS כפוי (HSTS), מדיניות תוכן (CSP) שמתירה לדפדפן לתקשר עם האתר ועם Supabase בלבד, חסימת הטמעה במסגרת (X-Frame-Options), ואיסור ניחוש סוג קובץ (nosniff).

מי אצלנו יכול לגשת למידע

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

אירוע אבטחה

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

שימו לב לגבי קבצים

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

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

כל בקשה נשלחת אל uribusinessacct@gmail.com. נאשר את קבלתה בכתב ונטפל בה בתוך 14 יום. הטיפול נעשה בידי אדם ולא בידי מנגנון אוטומטי — אין בפלטפורמה תהליך מתוזמן שמוחק או מייצא מידע מעצמו.

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

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

איך מבקשים מחיקה

שולחים מייל מכתובת האימייל שאיתה נרשמתם אל uribusinessacct@gmail.com עם המילה “מחיקת נתונים” ושם העסק. נאשר את קבלת הבקשה בכתב. השליחה מכתובת האימייל הרשומה היא מה שמאמת שהבקשה באמת שלכם.

מה נמחק ותוך כמה זמן

• לבקשת מחיקה — תוך 14 יום. נמחקים: העסק ואתרו הציבורי, פרטי בעל העסק, אנשי הצוות, השירותים, שעות הפעילות, ההמלצות, רשומות הגלריה, רשימת לקוחות הקצה והיסטוריית התורים, כרטיסי הלקוח וההערות שבהם, רשימת ההמתנה, מנויי ההתראות ואסימוני Google. המחיקה מבוצעת בידי אדם — אין תהליך מתוזמן שמריץ אותה. 14 יום הם ההתחייבות שלנו, לא פלט של מנגנון.
• בלי בקשה, אחרי סיום ההתקשרות — 30 יום. הנתונים נשמרים 30 יום מסיום ההתקשרות כדי לאפשר ייצוא או חרטה, ונמחקים אחריהם — גם כאן, ידנית. עד שהמחיקה מבוצעת בפועל הנתונים ממשיכים להתקיים במסד.
• נשמר בכל מקרה: מסמכים חשבונאיים (חשבוניות וקבלות) — הדין מחייב לשמור אותם, גם אחרי מחיקת כל השאר. הם מונפקים ומוחזקים אצל ספק החשבוניות שדרכו בוצע התשלום, ואצלנו לצורך זה בלבד.
• נשמר בכל מקרה, ובמכוון מעט — תיעוד שההסכמות ניתנו. אחרי מחיקת העסק נשארת אצלנו רשומה מצומצמת שאומרת שניתנה הסכמה: מאיזה סוג (הסכמה לדיוור, או אישור של מסמך משפטי), באיזו גרסת נוסח, מתי, ובאיזה עסק. אין בה טלפון, שם, כתובת אימייל או מזהה משתמש, ולכן אי אפשר ללמוד ממנה מי הסכים — היא אינה מידע אישי. היא קיימת מפני שתלונה או תביעה יכולות להגיע אחרי שהעסק כבר נמחק. ⚠️ המחיר מוצהר: רשומה כזאת מוכיחה שהסכמות ניתנו, כמה ומתי — לא שאדם מסוים הסכים. הראיה המלאה נמסרת לבעל העסק בגיבוי שמופק לפני המחיקה, והוא הצד שנושא בנטל ההוכחה.
• נשמר בכל מקרה — הודעת ביטול מנוי. אם מסרתם הודעת ביטול מהמסך המקוון, השורה שנרשמה שורדת את מחיקת החשבון. זה מכוון: היא הראיה למועד שבו נמסרה ההודעה, ומחיקת העסק שמוחקת אותה הייתה מוחקת את ההוכחה שהוא ביקש לבטל — בדיוק כשהיא נחוצה. מה שנשאר בה הוא שם העסק, ה-slug, מועד המסירה ומועד הסיום — כלומר מה שמוכיח מתי נמסרה ההודעה. כתובת האימייל, השם והסיבה מתאפסים באותה עסקה שבה נמחק העסק, בטריגר שרץ בבסיס הנתונים עצמו ולא בקוד האתר, ואילוץ במסד אוסר על שורה שכבר מוזערה להחזיק אותם שוב. ⚠️ והסתייגות אחת, כי מסמך שמבטיח יותר ממה שרץ אינו שווה דבר: המזעור קשור למחיקת העסק, והוא אינו מסלול מחיקה לפי בקשה: כל עוד העסק קיים, הטבלה נעולה בכוונה מפני עריכה ומפני מחיקה — וזה מה שהופך אותה לראיה — ולכן איננו יכולים למחוק ממנה שדות בודדים לבקשה בלי למחוק את החשבון עצמו.
• נשמר בכל מקרה — רישום ההודעות ששלחנו לכם. יומן ההודעות (שינוי מחיר, החלפת ספק משנה, עדכון תנאים) אינו נמחק עם העסק, מאותו נימוק: הטענה “העליתם מחיר בלי להודיע” מגיעה דווקא אחרי סוף ההתקשרות. אין בו שם, אין כתובת אימייל ואין מזהה משתמש — רק ה-slug של העסק, סוג ההודעה, תוכנה והמועדים.
• גיבויים: בסיס הנתונים מגובה באופן שוטף. רשומה שנמחקה עשויה להמשיך להתקיים בעותק גיבוי עד שהעותק נדרס במחזור הגיבוי הרגיל, ואינה משוחזרת משם אלא במקרה של תקלה בבסיס הנתונים כולו.

שני דברים שאינם נמחקים בקסקייד — ואיך הם מטופלים בפועל

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

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

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

אם אתם לקוח קצה של אחד העסקים

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

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

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

לכל שאלה בנוגע למדיניות זו, לנתונים שלכם או למימוש הזכויות שבסעיף 8: uribusinessacct@gmail.com

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

ראו גם: תנאי שימוש · הסכם החזקת מידע · הצהרת נגישות