在上一篇 2010-12-08 Plurk 訊息量統計 裡面我有提到，"整個Plurk的訊息量整體看來還是有成長的，但是成長的到底是活人還是BOT就不得而知了"
而Plurk的Bot(機器人)是個存在已久的問題，從2009年上半噗浪在台灣開始風行後，就開始陸續竄出不少Bot，有些是互動搞笑有趣的，但也有些是商業廣告性質的，像是 2009-10-26 不請自來的Plurk廣告機器人 這篇提到的就屬於比較讓人討厭的，還有那種號稱幫你維持或提昇Karma要你把帳號密碼給它的Bot更是討厭。
這類的從早期的米窩、卡馬救星、plurk-ad系列的魔鏡、發浪，到後來進化版的卡馬幫&珊蒂系列(還用到appspot)，個人是覺得那些開發廣告Bot的人對Plurk的傷害遠大於他們自己的獲利。
而另外還有一類是屬於互動性的，藏在回應中的機器人像是什麼轉噗機、搞冰友系列、布魯斯推推...族繁不及備載。
常常看到朋友發噗以後馬上有回應，結果點開看前三四條全是這種bot回應也是讓人不太舒服。
像是這樣的噗～看久了真的會受不了只好取消掉追蹤～
第一類自動代理發廣告噗幫人維持Karma的Bot比較難以量化，因為一旦USER將帳號密碼交給他們以後，它便會以該User的身份代為發噗，只能從Plurk Serch帶入關鍵字來大概看到底有多氾濫，像是
米窩 http://www.plurk.com/psearch#q=maiio
卡馬救星 http://www.plurk.com/psearch#q=some-mkt
plurk-ad系列的魔鏡、發浪 http://www.plurk.com/psearch#q=plurk-ad
卡馬幫 & 珊蒂XX館系列 http://www.plurk.com/psearch#q=appspot
隨便搜一下都可以看到每分鐘都有在發，但是因為不容易由外部看出具體數字所以難以估算所佔的比例。
而第二種回應類的Bot就比較容易鎖定跟估算了，因為都是固定帳號回應，而回應數也能看得到，所以我這邊就做了一個簡單的粗略統計。
首先先算出一天Plurk總共有多少回應，下面我就抓2010-12-01 00:00:00～2010-12-07 00:00:00 這6天
可以看出目前Plurk每日總回應數約在500萬～630萬之間，平均值抓580萬。
再來是針對目前已知的回應機器人帳號頁面上的總回應數除以天數後可以得出平均每日回應數，再進行加總
這樣算出來這些回應機器人總共的每日回應數為 322,633
這樣估出 Bot機器人回應佔總回應數比例為 32萬/580萬＝5.5%
當然這數字只是概略推算僅供參考～
下面為統計資料用的google試算表
2010-12-08
2010-12-08 Plurk BOT 概略統計
2010-12-08 Plurk 訊息量統計
今天在 Inside網路趨勢與行銷 的噗浪表示：雖然樂透要關，但流量還在成長，還雇了3位台灣人 這篇發現被點名了，裡面提到Plurk的Alvin在噗浪官方文章「A little update」裡面有說Plurk仍在持續成長，並提供成長趨勢圖
這兩張分別是從 2008年6月到2010年10月每日的responses及plurks的成長曲線(還有一張是每日登入Users，這數字外人就拿不到了)。
而我去年12月份 2009-12-21 Plurk 訊息量統計 做的統計推論是Plurk成長在趨緩。基本上兩者走勢差距是有點大，這也勾起我的好奇心再把資料撈出來比對看看到底是怎麼一回事，好在我之前的每小時整點定位紀錄的BOT始終有在運作，所以相關的數字一直都有紀錄著。
只是一方面因為忙，另一方面個人感覺Plurk的熱度很明顯退燒了（君不見當初那一票自稱微網誌/噗浪的行銷大師及達人們去年下半年起就陸續跳槽去非死不可了），所以後來也就懶得再算了。
不過既然點到我那這邊就再次把數字統計資料畫一畫吧。
首先先看看最近一週 20101128～20101205 的統計
綠色區塊是每小時新增的plurk數量，而藍色線條則是每小時新增的response數量
初步看來走勢還是跟之前沒太大區別，也就是2009-05-12 Plurk訊息成長量週統計所提到的，跟台灣上班族的打混摸魚趨勢依舊是基本相符的 XD
不過對比下去年的數字 2009-11-01 ~ 2009-11-08
去年2009-11-01 ~ 2009-11-08 當週平均每小時新增了 30,069則plurk & 125,627則回應
而
今年2010-11-28 ~ 2010-12-05 當週平均每小時新增了 54,264則plurk & 242,887則回應
由數字上來看過去這13個月訊息量成長了八九成。
接下來把時間區間拉長 由 20091101 ～ 20101201 這13個月來看
是有成長，但是從圖表來看感覺上幅度不是那麼的大。
下圖是把每小時plurk數量獨立出來
下圖是把每小時response數量獨立出來
然後再把兩邊的圖粗估出大概時間區間及長寬比例縮放調整後來進行走勢比對
（Alvin的圖是從2008年6月到2010年10月，而我的圖是2009年11月到2010年12月）
以plurk增加數量趨勢來看-藍色區塊為Alvin的圖表，套上綠色區塊是我的圖表
以response增加數量趨勢來看-藍色區塊為Alvin的圖表，套上深藍色線條是我的圖表
基本上兩者走勢大致相符，也就是說Plurk的訊息量依舊在持續成長中。
而兩邊的圖表分開來看之所以差別那麼大是因為時間區間及長寬比例不同所導致的。
像是我去年底統計時的時間區間是 2009-05-10 ~ 2009-12-20
對照到Alvin的圖時間跟比例上大概就是
那時間區段之中正好經歷2009年八月台灣莫拉客風災對Plurk所產生的一個明顯高峰，但是之後因為非死不可挾開心農場大舉入侵台灣而造成Plurk的流量成長趨緩。
至於如何解讀就看個人了，不過總歸來說還是有成長的，但是成長的到底是活人還是BOT就不得而知了 XD
把那段期間的資料調出來看，發現是發生在 2010-09-19(星期日)
按理說若照之前一般的趨勢來看週日的plurk/response數量應該是會低才對，結果那天反而比平常高，尤其是下午時段，查了一下才知道2010-09-19當天是凡那比颱風肆虐台灣的日子，難怪當天整體訊息量會飆高，所以Plurk的訊息量還是跟台灣重大天災息息相關的，這不知道是該替Plurk & 台灣高興還是難過？ @@"
2010-10-08
2010-10-08 Facebook Javascript SDK in IE8 problem
自從Facebook今年初發布 Graph API 並開始提供新的 SDK 以後，Facebook的相關APP開發規範就一直在進行修正調整，同時原本開發者費了不少時間才熟悉的FBML APP將會被淘汰掉，
在Facebook Markup Language (FBML) - Facebook Developers:裡面有提到：
Note: We do not recommend FBML for new developers. If you aren't already using FBML, you should instead implement your application within an iframe, using the JavaScript SDK and social plugins for client-side integration with Facebook services . The one exception: if you absolutely must create an application that appears as a tab on a Facebook Page, you will need to use FBML for now; tabs do not currently support iframes directly. We will be transitioning tabs to iframes later this year -- please see the developer roadmap for more details.
而在 2010-08-20 的Facebook Developer Blog Facebook Platform Roadmap Update (2010-8-20) 中更是明確指出：
By the end of this year, we will no longer allow new FBML applications to be created, so all new canvas applications and Page tabs will have to be based on IFrames and our JavaScript SDK.
既然Facebook都這樣說了，那就乖乖的來重新熟悉 iframe + JavaScript SDK 的開發模式，結果開始以後才發現 JavaScript SDK 說明文件 跟之前的developer wiki (新API公佈後沒多久就被拿掉了)相比資料少的可憐；資料少也就算了， 還有不少莫名其妙的問題。
尤其是在IE8的環境下更是討厭，
以下就把這段時間遇到的問題跟解決方式整理一下作個紀錄：
1. FB.Event.subscribe的auth.login事件在IE8底下會有無窮迴圈的問題
用IE8開啟 測試APP 1 http://apps.facebook.com/fbuiwithiexssfilter/test1/
這個簡單的測試APP 在Firefox / Chrome 這些非IE的瀏覽器下都運作正常，但是在IE8底下
FB.Event.subscribe('auth.login', function() {
window.location.reload();
});
就會出現無窮迴圈不斷地reload
關於這問題在 Facebook Platform Developer Forum 中有人提出兩種解法http://forum.developers.facebook.net/viewtopic.php?id=60411
第一種是在HTML中加上
讓IE進入相容模式(此解法在FB.ui 的 stream.publish 發布塗鴉牆內含中文訊息時會有被IE8的XSS filter給阻擋的問題，這部份後面再說明，而且我測試無效)
第二種是在http header中加上 P3P CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
in Apache2 , add
header add P3P 'CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"'
in .htaccess file (must enable apache mod_headers)
= or =
in php , add
header('P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"');
用工具看http header可以確認是否有正確加入 P3P的http表頭
經過這樣處裡後原先 FB.Event.subscribe 的 auth.login事件在IE8底下就正常了
可用IE8開啟 測試APP 2 http://apps.facebook.com/fbuiwithiexssfilter/test2/ 進行測試
跟前面測試APP 1一樣的code在這就不會有無窮迴圈的問題了。
2.FB.ui stream.publish 發布塗鴉牆內含中文訊息時會被IE8的XSS (Cross Site Scripting) filter判定為cross-site attack而阻擋的問題
現在Facebook對於APP塗鴉牆發布做了很嚴苛的限制，之前大家都在用的自動發布的方式很容易被判定為違規而被禁用塗鴉牆發布功能(已經聽到不少APP被砍或是塗鴉牆發布被禁用的案例，尤其是8月開始Facebook的自動偵測系統大發威，砍掉不少app)，所以要發布塗鴉牆都建議採用popup出預覽待使用者確定後發出才比較安全，在新的Facebook Javascript SDK中此種方法用的是FB.ui ，但是也有不少朋友在開發測試時遭遇到FB.ui開啟的內容被IE8的XSS filter給擋掉的問題，造成在IE8底下沒法正常發送塗鴉牆。
這問題也卡了我很久，全用英文就沒這問題，只要有非英文字元就有可能觸發，而且中文字越多機率越高，就算運氣好沒有被IE8 XSS filter擋掉，但是也會非常的慢(CPU Loading暴升且把IE8卡住)，怎麼交叉測試都沒用，有時多一字/少一字結果就完全不同，而把增減的那字獨立拿出測試又沒問題，實在是找不到規則可尋。
IE8開啟 測試APP 3 http://apps.facebook.com/fbuiwithiexssfilter/test3/
其中的 pubish with english content (dialog) | pubish with english content (popup) 這兩個按鈕都可以正常打開發布塗鴉牆的預覽頁面(純英文內容)，
但是發布有中文訊息的塗鴉牆就容易被IE8的XSS filter給阻擋掉
pubish with chinese content (dialog) 內嵌dialog視窗模式
pubish with chinese content (popup) 外跳popup視窗模式
雖然說可以把IE8的XSS filter給關掉就不會有這被卡的問題了
但是以APP開發者的立場來說不可能要求使用者把IE8的這個重要安全功能給disable掉，所以還是得要找出有效解才行。
在經過多方測試比對後發現是我犯了一個差不多先生等級的低級錯誤，就是HTML最前方的!DOCTYPE定義區段沒寫才造成的。這在非IE8瀏覽器下基本都不會有影響的，但是在IE8底下就會造成這問題！
IE8你也太太太要求標準了吧 ~~
用IE8開啟 測試APP 4 http://apps.facebook.com/fbuiwithiexssfilter/test4/
在這個測試中在HTML最前面補上了 <!DOCTYPE html>
同樣的中文內容在測試APP3中會被擋掉的在這就都可以正常了
在這裡又要順帶一提前面提到的IE8相容性檢視了，若是在IE8針對要用FB.ui發布塗鴉牆的頁面打開相容性檢視的話，中文內容依舊有可能會觸發XSS filter
所以用 Facebook Javascript SDK 的 FB.ui 發布中文內容塗鴉牆，為了配合廣大的IE8 User，
務必要遵循標準在HTML最前面加上 <!DOCTYPE html> ，同時User得要避免使用IE8 的相容性檢視(Compatibility View) 功能才行。
還有一件事要提一下，在九月底十月初Facebook已經把APP發布的塗鴉牆訊息在動態消息(News Feed)中的呈現方式改掉了， 在 Facebook Developer Blog 2010-09-22的
Making Games on Facebook Better裡面寫到
Application stories will only be shown to those who are already engaging with the application.
也就是說在User的動態消息(News Feed)中現在只看得到自己曾經安裝過的APP的訊息，像以前那樣想要靠發布塗鴉牆來散布宣傳吸引其他使用者進來的時代已經結束了，這對不玩遊戲的User是個好消息，但對APP開發者來說是個噩耗！之前改掉通知時就一堆APP慘兮兮了，後來大家改用塗鴉牆來散布消息，現在又改這就讓APP開發者/經營者幹到沒力啊。
寫到這還是要靠么一下
在Facebook Platform Developer Forum 裡面這位開發者說的 這段話也是我想說的：
even after three years of this cr@p is still amazes me how on earth Facebook manage to push things like this to the live site, do they have no testing procedures at all?
另外這篇 The Facebook API: A Case Study in Not Caring About Developers
POOR DOCUMENTATION
POOR TESTABILITY
NO RESPONSE TO SERIOUS ISSUES
CONSTANTLY CHANGING API
也道出了Facebook Application Developers的心聲
很多問題文件資料都沒寫，得要Developer自己想辦法去論壇大海撈針才行，問題是有幾個Developer有那麼多美國時間整天泡在論壇上？ 很機車咧！！
最後再打個廣告
反非死不可粉絲頁 歡迎跟我一樣被Facebook搞到起度爛的開發者一起來交流交流 ～
2010-08-30
2010-08-30 FaceBook App "disappeared" or "Publishing Feed Stories disabled" collection
Collection from
FaceBook Developer Forum
( http://forum.developers.facebook.net/ ) about
App "disappeared" or "Publishing Feed Stories disabled"
2009-03-31
ERROR 200: Feed story publishing is disabled for this application
2009-11-29
Facebook Restrictions??
2010-01-09
I restricted :S
2010-03-12
My Application disappeared P1 P2 P3 P4
2010-04-16
Publishing Feed Stories disabled
2010-05-17
My App Disappeared
2010-06-06
Publishing Feed Stories disabled
2010-06-22
please help me my app disappeared
2010-07-25
All my applications disappeared
2010-08-20
App Deleted (Need Urgent Help)
2010-08-06
Publishing Feed Stories disabled
2010-08-23
Application Love is.. Fans has been disabled! Why?
2010-08-24
abusive application
2010-08-27
Publishing Feed Stories disabled after using fb:comments
2010-08-27
Publishing Feed Stories disabled
2010-08-30
active app mysteriously disappeared
For every FaceBook Application Developers:
Be careful!!
and may not give you any warning or notice before they do that!!
Who will be next??
2010-08-20
2010-08-20 Facebook 無預警移除 APP. e04!!
在FACEBOOK火熱的今天，軟體公司開發應用程式/社交遊戲放到FaceBook上增加曝光度及流量已經成為一門顯學了，但是有人碰過辛苦開發且經營了一段時間的APP被FaceBook毫無預警給幹掉嗎？
不要懷疑，還真有這種事，很不幸的我就遇到了。
我們處裡的是一款代理自韓國的FlashGame進行FACEBOOK的APP介接整合，基本功能也很單純，就是在FaceBook上開一個進入遊戲的入口，加上一些基本的社交功能（邀請好友/經使用者同意授權後於塗鴉牆發布遊戲訊息/好友的遊戲分數排名），實在也想不出有哪裡違反了FaceBook的使用條款。
在 2010-08-19 (四) 下午兩點二十分左右，我們有位同仁發現他的FB 帳號被FaceBook停權
畫面如下
得需要透過手機驗證過後重設密碼才能再次登入，非常的怪異。
結果設完後發現我們兩週前才上架的app消失了
此時發現問題大條了，結果交叉比對後發現跟這個APP有關連的四個管理帳號全被FaceBook停權。而將此四個帳號重設密碼解封之後發現原本的APP徹底消失，一點痕跡也不留。
由我們Server上的最後LOG時間判斷，問題是發生在 14:13 分，之後就沒有request進來了。
在查找過程中發現FaceBook幹的非常徹底，所有殘渣都沒有留下，包含APP URL頁面，APP粉絲頁面，USER的應用程式書籤，USER的應用程式權限設定等等所有跟該APP有關的部份全部都消失。
在評估過後決定先進行重建設定的工作 （原本APP上線十多天有六七千個User跟粉絲全沒了）
重建過程中發現 原本的Canvas Page URL 完全不給設定。會出現
Validation failed.
The Canvas Page URL you requested is not allowed.
而且確定不是重名，若是Canvas Page URL重複則會出現
Validation failed.
Unable to update Canvas Page URL: The Canvas Page URL you requested is already taken.
這情況非常詭異，因為原先的Canvas Page URL命名並沒有違反FACEBOOK的規範才對，建置完成後也提交給FaceBook並通過了( Directory Status: Approved )，同時也上線運作了十多天了。
根據上述情況推斷該APP是被FaceBook列入黑名單之中了，
由四個管理員帳號都被FB停權的狀況來看，APP肯定不是被我們自己人給誤刪，而是被FaceBook給刪掉了。至於FaceBook為何要把APP幹掉同時將所有管理員帳號停權就不得而知了，因為並沒有收到任何通知或警告。認知中我們APP應該也沒有違反FaceBook政策的部份，要是有人惡意舉報應該也要有夠多的數量才會讓FaceBook這樣幹才對。
最後無奈之下只好更改Canvas Page URL重新設定APP
新APP設定好之後程式中的
Application ID / API Key / Application Secret / Canvas URL 這些資料全都得要隨之更新
先前累積下來的數千個粉絲全部沒了，得要重新讓USER加入
而且因為Canvas Page & APP ID 都換掉了，所以所有網站及廣宣連結全得替換。
而先前公司已經在FaceBook投放了將近USD$1000的廣宣費用也都打水飄了
嘗試要尋找申訴管道找了很久，終於在FaceBook開發論壇中找到有其他人遭遇類似的問題
Facebook Platform Developer Forum / My Application disappeared:
這一整個討論串非常的有意思，事情是從今年三月開始發生的。
然後在第三頁中 3月19日 FaceBook管理者承認是有問題造成部份好的APP因為BUG被無預警誤殺並提供申訴取回
結果到了 3月31日有開發者回應說
從別人的經驗看來就算是通過申訴一兩週之後拿回來的也是個廢物了。
我昨天也在論壇回報後，得到的回覆是
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Hello,
For issues like this, please refer to our Help Center FAQs on the issue: http://www.facebook.com/help/?faq=17553
Thanks,
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
可是那個FAQ link得要把語系換成英文才看的到，中文語系是連不到的
這也就算了
語系換成英文就看到了
結果說要去填一個form然後等一到兩週！那是不是這一兩個禮拜我的app都關門大吉了
就算真要等一到兩週也就算了，結果那個form 連結 http://www.facebook.com/help/contact.php?show_form=dev_name_appeal 還是壞的 .....
會跳回到Help Center頁面去
在該討論串最後有其他相同情況的app開發者留言說
這就是在裝笑為嘛！！
後來從論壇中找到一個
FaceBook Developer Help Contact Form
http://www.facebook.com/developers/developer_help.php
藏的真好，我是去填了資料，但是基本上我也不報任何期望了！！
就算等了一兩個禮拜拿回來以後又能幹嘛？
在沒有收到任何通知或警告的情況下整個APP就被FaceBook莫名其妙給幹掉了！
而且我還真想不出有哪裡違反FaceBook的Policy嚴重到必須要將四個該APP管理員都給停權停掉？
這慘痛的經驗提供各位FaceBook應用程式開發者作為借鏡。
～～靠山山倒啊靠人人跑啊～～
2010-08-20 16:00 update:
剛在 Facebook Platform Developer Forum / My Application disappeared: 這討論串中看到有人比我更慘
心情頓時舒坦了些 XD
另外要在抱怨一下，
Facebook Platform Developer Forum http://forum.developers.facebook.net/
Facebook Platform bug tracking system http://bugs.developers.facebook.net/
這論壇跟bug回報系統的帳號居然沒有跟FaceBook整合
也就是你要上開發者論壇問問題得要去註冊一個帳號，發現Bug要到Bugzilla回報又得在建立一個帳號。
從這可以看出FaceBook對於第三方應用程式開發者有多麼的不重視與不用心了。
2010-08-21 06:30 update:
FaceBook的人員為了APP消失的問題特別在開發論壇中開了一個置頂的公告串
Sticky: What to do if your application disappeared or was disabled
看來這問題最近嚴重到FaceBook不得不去面對了。
而那個FAQ裡面原本壞掉的APP申訴連結 http://www.facebook.com/help/contact.php?show_form=dev_disable_appeal 也總算可用了
填完表格送出後收到一封系統自動回覆的MAIL
需要一到兩週的時間，新的都設好了到時候舊的再拿回來也沒用，我主要也就想看看FaceBook到底會怎麼回答。
2010-08-23 update:
收到FaceBook的申訴回覆了，非常的制式
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
We appreciate your inquiry and we apologize for any inconvenience caused. Please note that we have automated systems in place to remove applications that are abusing our product, such as publishing excessively to the Stream, or receiving negative feedback from our users. Unfortunately, we will not be able to reinstate your application, as it was removed by our automated systems. We realize that it might be a challenge to start fresh, but when an application is disabled for violating our terms and policies it is completely removed from the site permanently.
Going forward, please make sure to keep our policies in mind, as this is important for your success on Facebook Platform and to ensure that you're bringing users a great experience with your application. We strive to make our policies as clear as possible, shaping them to best serve users and the entire Platform ecosystem. We hold our developers to a high standard and trust that they will use our communication channels in ways that promote fair growth across Platform.
If you would like to re-launch your application, please feel free to do so after you are certain that it meets our terms and policies, which you can find below. Thank you in advance for your cooperation.
Developer Principles and Policies: http://developers.facebook.com/policy/
Policy Examples and Explanations: http://developers.facebook.com/docs/guides/policy/examples_and_explanations
Developer Forum: http://forum.developers.facebook.com
Statement of Rights and Responsibilities: http://www.facebook.com/terms.php
Thanks,
Platform Policy Team
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
簡單來說就是：
你的APP是被我們自動偵測系統給幹掉的，不要肖想我們會還給你了，至於你的APP為何會被幹掉？這一定是你違反了我們的政策，但是違反了哪條林北不告訴你 XD ！！
你自己看著辦吧！！
2010-08-30 update:
我把FaceBook Developer Forum裡面關於APP被幹掉或是塗鴉牆功能被停用的苦主PO文靠夭的整理了一下
2010-08-30 FaceBook App "disappeared" or "Publishing Feed Stories disabled" collection
至於其他自認倒楣摸摸鼻子沒上去反應的有多少就不得而知了。
發表文章
