אני לא יודע כמה מכם שמו לב, אבל בלוגר החליפו את הדרך בה הם מאפשרים לבעל הבלוג לא לכלול את המחשב שלו במניין הצפיות בבלוג. בעבר, היה מדובר בחלון קופץ עם ההגדרות, שנראה בערך ככה:
כעת לחיצה על הכפתור מובילה לדף חדש בכתובת שנראית פחות או יותר ככה: https://<blog_name>.blogspot.com/b/statsCookieManage (זה אינו קישור!)
אני מניח שאחת הסיבות לשינוי הזה נובעת מתלונות רבות שהיו על כך שהתכונה הזו לא עובדת (האינטרנט מלא בהן, פשוט לכו לחפש). יכול להיות שיש גם קשר לעבודה עם עוגיות צד שלישי והניסיון לצמצם את השימוש בהן, אבל בכל מקרה - מה היא השאלה הראשונה שעולה בראשו של בודק תוכנה שרואה את ההתנהגות החדשה הזו? נכון מאוד! האם אני יכול לעשות את אותו הדבר בבלוגים שאינם שלי? חמש שניות לאחר מכן, קיבלתי תשובה - אני יכול לגשת לדף הזה, ולפחות למראית עין, ההשפעה של סימון "אל תעקוב אחרי הצפיות שלי" זהה למה שקורה בבלוג שלי.
תגובה ראשונה - מצאתי באג!
ושנייה אחר כך - רגע, אולי זה בכוונה?
מצד אחד, המוצר אינו עקבי ביחס להיסטוריה של עצמו, שכן בעבר ניתן היה לגשת לאפשרות הזו רק דרך ממשק הניהול, וממילא רק לבלוגים שאני מנהל. בנוסף, מה יקרה אם כולם יבחרו לסמן את התיבה הזו? ספירת הכניסות תהפוך ללא אפקטיבית. לכאורה - תקלה.
מצד שני, יש בזמן האחרון מודעות גבוהה יותר לחשיבות של פרטיות הגולשים. אולי האפשרות הזו גלויה בכוונה? אולי רוצים לאפשר למי שהפרטיות חשובה לו לא להיספר בתוך מניין המבקרים בבלוג? זו כנראה לא הדרך בה אני הייתי נוקט, אבל אולי כך אמור האתר להתנהג?
כמובן, הדילמה הזו קיימת לא רק במקרה כזה בו אין לי מושג מה המטרה מאחורי הפיצ'ר, לפעמים ההתלבטות הזו קיימת גם במוצר אותו אני בודק ומכיר היטב. למשל - האם חשוב יותר להציג הודעת שגיאה מועילה למשתמש, או לחסום את האפשרות של תוקף לזהות משתמשים דרך הודעת השגיאה? האם הצפנה של עוד פיסת מידע מצדיקה את הפגיעה בביצועים? האם לתת למוקד התמיכה מידע נוסף, או להגן על פרטיות המשתמש?
במקרה הזה, אני חושב שניתן לטעון שמדובר בבאג - בלוגר לא מספקים לקורא שום דרך לגלות על קיומו של הפיצ'ר החדש. אם אני גולש לבלוג של מישהו אחר, אין שום דרך בה אני יכול להגיע לדף שמאפשר לי לבטל את המעקב אחרי, כך שאני לא מאמין שמדובר בצעד שנועד לאפשר פרטיות, אלא פשוט בשתי דרישות פונקציונליות שמתנגשות ואף אחד לא שם לב אליהן. מצד שני - התרחיש כולו סיפק לי תרגיל מחשבתי מעניין.
האם יש לכם רעיונות נוספים לסימנים שעוזרים להבין בין בחירה מודעת בדרישה אחת על פני השנייה, ובין סתם באג?
הדילמה הזו קיימת בכל פעם בה שתי דרישות מתנגשות, אבל איתור של דרישות מתנגשות, במיוחד אם אחת מהן "שקופה" (כלומר - לא מקושרת לדרישה פונקציונלית, ולא בהכרח מדידה). לא קל לשים לב שהוספת אימות דו שלבי (2 factor authentication) יכולה ממש להרגיש את המשתמש, או שאיסוף פרטים מועילים עבור התמיכה הטכנית יכולים לפגוע בפרטיות הלקוחות שלהם.
האם יש לכם משהו שאתם עושים כדי למצוא התנגשויות מהסוג הזה?
-------------------------------------------------------------------------------
כעת לחיצה על הכפתור מובילה לדף חדש בכתובת שנראית פחות או יותר ככה: https://<blog_name>.blogspot.com/b/statsCookieManage (זה אינו קישור!)
אני מניח שאחת הסיבות לשינוי הזה נובעת מתלונות רבות שהיו על כך שהתכונה הזו לא עובדת (האינטרנט מלא בהן, פשוט לכו לחפש). יכול להיות שיש גם קשר לעבודה עם עוגיות צד שלישי והניסיון לצמצם את השימוש בהן, אבל בכל מקרה - מה היא השאלה הראשונה שעולה בראשו של בודק תוכנה שרואה את ההתנהגות החדשה הזו? נכון מאוד! האם אני יכול לעשות את אותו הדבר בבלוגים שאינם שלי? חמש שניות לאחר מכן, קיבלתי תשובה - אני יכול לגשת לדף הזה, ולפחות למראית עין, ההשפעה של סימון "אל תעקוב אחרי הצפיות שלי" זהה למה שקורה בבלוג שלי.
תגובה ראשונה - מצאתי באג!
ושנייה אחר כך - רגע, אולי זה בכוונה?
מצד אחד, המוצר אינו עקבי ביחס להיסטוריה של עצמו, שכן בעבר ניתן היה לגשת לאפשרות הזו רק דרך ממשק הניהול, וממילא רק לבלוגים שאני מנהל. בנוסף, מה יקרה אם כולם יבחרו לסמן את התיבה הזו? ספירת הכניסות תהפוך ללא אפקטיבית. לכאורה - תקלה.
מצד שני, יש בזמן האחרון מודעות גבוהה יותר לחשיבות של פרטיות הגולשים. אולי האפשרות הזו גלויה בכוונה? אולי רוצים לאפשר למי שהפרטיות חשובה לו לא להיספר בתוך מניין המבקרים בבלוג? זו כנראה לא הדרך בה אני הייתי נוקט, אבל אולי כך אמור האתר להתנהג?
כמובן, הדילמה הזו קיימת לא רק במקרה כזה בו אין לי מושג מה המטרה מאחורי הפיצ'ר, לפעמים ההתלבטות הזו קיימת גם במוצר אותו אני בודק ומכיר היטב. למשל - האם חשוב יותר להציג הודעת שגיאה מועילה למשתמש, או לחסום את האפשרות של תוקף לזהות משתמשים דרך הודעת השגיאה? האם הצפנה של עוד פיסת מידע מצדיקה את הפגיעה בביצועים? האם לתת למוקד התמיכה מידע נוסף, או להגן על פרטיות המשתמש?
במקרה הזה, אני חושב שניתן לטעון שמדובר בבאג - בלוגר לא מספקים לקורא שום דרך לגלות על קיומו של הפיצ'ר החדש. אם אני גולש לבלוג של מישהו אחר, אין שום דרך בה אני יכול להגיע לדף שמאפשר לי לבטל את המעקב אחרי, כך שאני לא מאמין שמדובר בצעד שנועד לאפשר פרטיות, אלא פשוט בשתי דרישות פונקציונליות שמתנגשות ואף אחד לא שם לב אליהן. מצד שני - התרחיש כולו סיפק לי תרגיל מחשבתי מעניין.
האם יש לכם רעיונות נוספים לסימנים שעוזרים להבין בין בחירה מודעת בדרישה אחת על פני השנייה, ובין סתם באג?
הדילמה הזו קיימת בכל פעם בה שתי דרישות מתנגשות, אבל איתור של דרישות מתנגשות, במיוחד אם אחת מהן "שקופה" (כלומר - לא מקושרת לדרישה פונקציונלית, ולא בהכרח מדידה). לא קל לשים לב שהוספת אימות דו שלבי (2 factor authentication) יכולה ממש להרגיש את המשתמש, או שאיסוף פרטים מועילים עבור התמיכה הטכנית יכולים לפגוע בפרטיות הלקוחות שלהם.
האם יש לכם משהו שאתם עושים כדי למצוא התנגשויות מהסוג הזה?
-------------------------------------------------------------------------------
I don't know how many of you have noticed, but Blogger has changed the way the "don't track your own pageviews" work.
At first, it looked like this:
Now, the user is redirected to a new page https://<blog_name>.blogspot.com/b/statsCookieManage (This is not a link!), I guess that one of the reasons, or maybe even the only one, for this change was the number of complaints that the previous implementation was broken and many people complained about it (google it), probably due to most browsers making the life more difficult for 3rd party cookies. Indeed, the new mechanism does redirect to the blog domain, so it shouldn't cause many problems on that aspect.
Anyhow, what's the first question that pops to a tester's mind when faced with such a feature? Indeed, it is "can I use this feature on blogs not under my control?". So, quickly after making sure to work around what seems to be another bug (This new feature does not seems to be working across regional domains, so I made sure to check both .com and .co.il ), I went to another blog I follow and got the relevant URL, and Lo and behold - nothing blocks my way.
Also, as far as I can tell - the behavior seems to be the same (Sure, I couldn't go and check the actual stats, but I got an identical cookie to present).
My first reaction: "Yay! I found a bug!".
And a second later - "Wait a second. maybe this is on purpose?"
On one hand, this feature is not consistent with its history, and therefore, also with my expectations as a user - before, it didn't seem that I was able to opt-out of the tracking of blogs that I don't own, and as a blog owner - I actually look now and then at the pageviews stats and would be very sad if my readers would hide this way.
But, on the other hand, privacy is a really strong trend these days, and perhaps it is an improvement that enables user to control who sees them and who doesn't. It might not be the way I would do things, but maybe this behavior is intentional?
Certainly, this problem is not unique to cases where I'm completely out of the loop and have no idea of the business model behind the product. I might find myself facing the same question when working on the product I'm testing. Should we present a helpful, informative, error message, or prevent an attacker from enumerating our current users by checking the error message? Is encrypting another piece of information worth the impact on performance? Should we provide the customer support useful information or protect the end-user privacy? The decision is not always obvious.
In this particular case, I think it's safe to assume a bug - if this was a privacy enhancement, it should have been accessible from any blog I read - not only from the management section. So, instead of a (security) requirement trumping another requirement, I think that the root cause is just that it is a case where a requirement is having an unexpected effect on another.
At least, I got a nice thinking exercise out of it.
Do you have ideas that helps to determine when there was a conscious choice to prefer a requirement over another, and when it's simply a bug?
Also, noticing requirements collision is not always easy - it is very easy to miss the fact that our two-factor-authentication may actually be really annoying to the user? or that when we collect data to improve our services we might be collecting that hinders the user privacy?
How would you suggest to spot conflicts between transparent requirements (transparent requirements = properties of the software that are not "it does X", but rather "it is...", most illities are transparent, as is performance and responsiveness) and functional ones?
No comments:
Post a Comment