2012年4月26日

網路拍賣的第三方結帳系統不安全請小心下標!

幾個月前曾在某知名拍賣網站買過一些小東西送人,像是仿 MacBook Air 的化妝鏡;照理說過了幾個月,我應該要忘得一乾二淨才對(年紀到了快三十歲都會出現的小毛病)。

但是,我卻對那次的交易難以忘懷。

這應該開心嗎?不!

那次的購物經驗並沒有令人難忘的經驗,但每隔一個月左右就會有人貼心地打電話來告訴我。

拜託!好心的人吶!別再浪費電話錢打來要我回想這檔小事了。

今天在開會的時候,看到一通 02 開頭的電話,以為又是哪家台北廠商打來、有什麼好康可以挖,所以我就接起電話。

電話那頭:「請問是 XXX 先生嗎?」

ME:「哦!我就是。」

電話那頭:「您記得 X 個月前在我們公司 XXXX 買的商品,...」

ME:「喔喔!我記得啊!」

(還沒等她再開口,我就接下去講。)

ME:「是不是關於分期付款的問題?」

(詐騙集團那麼高利潤的行業,連找個口音聽起來「正」的客服代表打電話有什麼困難嗎?一定要每次打來都是讓人聽了很不酥符的「歐巴桑」聲音就對了。)

電話那頭:「您已經知道啦!那有沒有去 ATM 設定嗎?」

(第一次遇到沒掛我電話還繼續喇嘞下去的詐騙集團。但聽這不酥符的聲音,實在讓我沒什麼興趣再接下去講,...)

ME:「處理好啦!」

(掛斷電話...嘟......)

我一直以為詐騙集團應該都是很聰明的人在經營的行業,照理說應該要隨著科技日新月異,手法層出不窮;但每個月打來騷擾我,至少也找個聲音聽起來賞心悅目,讓人家有一點遐想空間的專業電話客服嘛!聽到沙啞歐巴桑聲音,而且不帶一絲台灣人講話的人情味,更不是打來報明牌,這就叫人火冒三丈!

但我認為詐騙集團只是老鼠屎其中的一沱,這整個問題背後,不是詐騙集團的首腦和歐巴桑聲音的小姐合謀就能搞定;問題的根源還是在於資料外洩。

因為有好心的詐騙集團每月按時提醒,我一直清楚記得當初是怎麼下標、購買網拍商品。

那家店基本上按照著拍賣網站的規定經營,照原金額下標,沒有什麼偷雞摸狗的走偏門行為。

但是在完成下標後,賣家提示必須到 XXX 網站填寫表單,這就是所謂的第三方結帳系統。

我並沒有仔細閱讀「關於我」的習慣,有少數賣家把很多重要的資訊都寫在「關於我」,但是又用了很不明顯、沒有標明重點的字體,然後內容寫得落落長。但我不是下標後發現手續很麻煩就想棄標的買家,雖然賣家強制規定一定要填寫結帳系統才出貨讓我覺得不太方便,最後當然還是得守信用完成交易。

大概在 8~10 年前,即使是最多人用的拍賣網站,功能還是相當不全,下標後必須靠著電子郵件及電話的聯繫,才能完成付款核對、出貨通知。

所以那時候的第三方結帳系統解決很多問題,像是詳細商品內容選項、核對付款資料、訂單處理狀態查詢、物流追蹤、更新狀態訊息通知等等,補足了拍賣網站功能的不足。

但其實第三方結帳系統並不安全,特別是我在接二連三接到疑似不同詐騙集團打來的電話,資料來源都是同一個賣家,而且這個賣家就是必須使用第三方結帳系統才出貨,這讓問題的根源變得相當明顯。

我不覺得目前最大的幾家拍賣網站,已經能做到滴水不漏的100%安全保證,對軟體開發及資訊安全有些興趣,使我瞭解百分之百的安全根本不存在,除非網站不是由人開發的。

不過近幾年來,因為資安問題造成個資外洩的問題太嚴重,因此比較大型的幾個主要拍賣網站,已經用了很多辦法想解決問題。看起來是有些成效,每個月多次使用網拍購物的經驗,近來已經鮮少遇到交易資料外流而接到詐騙電話,除了少數「強迫使用第三方結帳系統」才能完成交易的店家。

如果使用外部的結帳系統,可以讓交易過程更方便,那也就算了。但最近的使用經驗是, 這些第三方結帳系統,介面很難用、操作過程很麻煩、已經下標的商品還要手動輸入一次資料。這實在令人費解為何少數賣家,仍堅持要買家在下標後使用其他網站才能結帳。

目前主流的拍賣網站,都已內建了合併結帳、詳細規格選擇、交易付款機制、出貨通知等,也提供相對較好的交易安全保障。

所以,我想請還在堅持使用第三方結帳系統的賣家,請花點時間學習拍賣網站的功能,不要再為了自己方便堅持使用過時的結帳機制。

如果你是買家,在網拍買東西時,請注意賣家是不是一定要用第三方結帳系統才能交易。如果是的話,請考慮一下個人資料、商品交易明細在網路裸奔可能帶來的後遺症。

2012年4月10日

入圍 2012 全國開放軟體創作競賽 - 雲端網際服務與其他應用產學合作組


嘿嘿,我們進入決賽了!為了我今年最想要的 Herman Miller Embody Chairs,接下來有得忙碌一整個月啦!

2012年4月9日

HITACHI RD200-FN 節能除濕機,跟霉味說掰掰

前陣子相信不少人家裡都被濕氣侵擾,住在中南部我還是第一次遇到家裡頭濕答答,不管開窗、開冷氣機下去除濕,好像效果都很有限。

這是俗稱的「透南風(吹南風)」現象,氣象站則表示,這是因為鋒面過境,高溫的西南風含的水氣濃度高,接觸低溫地板及牆壁而凝結成水,產生「反潮」。濕度高,急性呼吸道病患就診也增加約二成,醫師提醒民眾開冷氣及除濕機,並要小心滑倒。(自由時報

我比較擔心發霉的東西,其實只有攝影器材和音樂光碟,因此也買了三個電子防潮箱;除此之外,倒沒有特別想過除濕機的需求,總覺得只要常開窗通風、偶爾開冷氣機除濕就夠了。

但是三月份的時候,經常在家裡嗅到霉味,尤其是在現在這種怪天氣,三不五時下一陣大雨,之後又出大太陽,就會讓家裡濕氣霉味都跑出來。這讓我開始有點擔心滿屋的 3C 產品、書籍,也開始考慮除濕機的需求。

在爬文之後,發現不少人推薦 HITACHI、MITSUBISHI 的除濕機;除濕機的價格至少都要五、六千起跳,日系的售價和便宜品牌比較起來,也不會相差太多,加上個人對品牌的偏好,就決定買 HITACHI。

從廠商型錄網站,就可以清楚知道各種型號。 Y! 拍搜尋一下型號,就可以知道售價範圍(網拍的售價大部分都要打電話過去議價)。


以外型來說,我比較喜歡 RD-16/RD-12 的設計;但是努力搜尋一下台中的家電行,才發現三月買除濕機並不是好時機,因為到處都缺貨。

最後我是在斗六的店家找到 RD-200FN 的現貨,而且僅有一台,完全沒得挑,考慮了一下就搬了台回家。

以 RD-200 來說,FB/FN 是最新上市的機種,屬於能源效率一級。在能源標章網站可以搜尋想買的家電檢測結果,畢竟新舊款價格沒差多少,當然要選比較省電的。

RD-200 的面板看起來有點複雜,但其實功能就那幾個,選擇模式、風速和定時

側面的出風口打開後,會切換成乾衣模式,可以針對小範圍進行快速除濕

RD-200 的水槽是5公升,在房間用大約12小時要倒一次水,背面可以接排水管

下過雨後家中濕度會超過85%,雨停後除濕10小時後可降至60%以下
以中南部來說,我家公寓大約35坪左右,四房二廳只要買一台 RD-200FN 就已足夠應付,因為房間濕度降至50%,只要沒再下雨就可以連續維持幾天,各個房間輪流用就可以維持在舒適的濕度。HITACHI 除濕機底部有滑輪的設計,可以很方便移動。

使用後我發現不管家裡濕氣問題嚴不嚴重,其實買台除濕機都會很管用,例如廚房的櫥櫃、客廳和臥室的鞋櫃、櫥櫃及系統櫃,還有很怕發霉的衣櫃,以及家裡舖設的木地板,只要定期進行除濕,就可以去除討厭的霉味;有時候可能自己覺得霉味不嚴重,但其實只是已經習慣味道了 :XD

更新:

  1. 2012-12-03 最近的連日雨感覺人都快發霉了,所以除濕機要每天開;雖然不同容量有價差,但是好裡家在當初選這台容量不算太小,不用很頻繁倒水(倒水實在很麻煩!)。

2012年4月8日

解決 Google Chrome 瀏覽器不能正常播放 Flash/SWF 檔案問題,Ubuntu Linux

這個網址是 Adobe 提供的 Flash Player 測試網頁,如果看到下圖右下方的版本資訊,表示 Flash 播放器正常運作。

http://www.adobe.com/software/flash/about/



在 Chrome 瀏覽器網址列輸入「chrome://plugins/」,並切換「詳細資訊」檢視。


找到 Flash 的設定,將 Adobe 以外的 flash plugin 都停用。


Ubuntu 如果沒有 /usr/lib/adobe-flashplugin/libflashplayer.so 這個檔案,需要用 apt-get 補安裝:

sudo apt-get install adobe-flashplugin


2012年4月7日

無為草堂人文茶館,台中,食記

在嚴長壽的「我所看見的未來」書中,對台中的「無為草堂」讚譽有加。利用春假五日連假,帶著家中愛泡茶的兩老尋訪無為。這間茶館很特別,附近是高樓林立的都會叢林,從勤美誠品為起點,公益路是台中特色美食的精華路段,走到大墩路也差不多到了美食商圈的盡頭,而路口瞥見藏在林蔭中的古厝,就是無為草堂。

在這裡我第一次學泡茶,聽著阿爸講著他三十年泡茶經驗的心得。

傳統茶道對青年人來說愈來愈陌生,畢竟,到春水堂點個特大杯冰茶,或是在星巴克點杯熱咖啡,實在比泡茶方便多了,畢竟很難打開 MacBook 一邊寫 Blog 或上 Facebook,又一邊注意著煮熱開水、沖泡茶葉。

如果想要休息、放鬆一下,我認為到無為草堂是個相當不錯的選擇。這裡大多座位區都規劃成塌塌米的小包廂,可以在較不被打擾的空間下喝茶聊天,而窗外的景致就像時空倒退百年,綠蔭、鯉魚池、閣樓、涼亭、屋瓦木身取代水泥建築,就像回到手機、電腦還沒發明的年代,籠罩在充滿閑情逸致的氛圍。

無為草堂位於公益路與大墩路交叉處,特約停車場就在大墩廣場燦坤3C旁邊。

地址:台中市公益路二段106號
電話:04-2329-6707


















2012年4月6日

入門程式設計的好工具 Processing

Processing 打造一個簡單易用的程式語言,即使不懂程式設計的新手,也能剪剪貼貼、依樣畫葫蘆動手完成有趣的程式。有趣是個重點,使用 Processing 寫程式就是比其他語言更有趣,因為它著重在「繪圖」,讓你天馬行空的創意能夠藉由撰寫程式發揮出來,讓每個人都能發揮與生俱來的創造藝術能力。

Processing 的起源是 Ben Fry 和 Casey Reas 於 2001 年在 MIT 發展,它以視覺化的方式,讓學習者撰寫電腦程式,就像在畫素描一樣,而 Processing 也將程式碼保存在稱為 Sketchbook 的區域。

O'Reilly 最近出版的一本新書「Processing 入門:互動式圖形實作介紹」(中文版),就是由 Ben Fry 及 Casey Reas 親自撰寫,將這套好用的軟體正式介紹給學習者。

2012年4月5日

測試網站是否投入長城懷抱了?


GFW(長城防火牆,Great Firewall)是中华人民共和国政府為了「和諧」建造的網際網路過濾機制;以本網誌來說,因為使用 Google Blogger 服務架設,長期以來都是處於「被和諧」的狀態,偶爾有少數翻牆過來的訪客,但數量真是稀少 : )

經常有人問我怎麼知道自己的網站是否「被和諧」了,所以特別將用於測試連線的網站整理如下:

http://www.websitepulse.com/help/testtools.china-test.html


http://www.greatfirewallofchina.org/


當然,這種網站是給身於牆外的我們測試,其結果也僅供參考。

但如果對方有人可以幫忙,或者可以遠端連線到對方機器,其實最準確的方式,應該是透過網路除錯工具,例如 nslookup、dig、ping、traceroute/tracert、nmap...等,才能知道哪個節點出錯了。

即使網站目前沒有「被和諧」,也不必高興太早;因為網站經營在中华人民共和国必須有政府許可,稱為ICP(中华人民共和国电信与信息服务业务经营许可证),如果沒有合法的經營管道,就別想賺人民幣啦!就算現在網站可以通,也難保哪天睡一覺醒來,長城就把你的網站包圍了。這就是現實...

2012年4月4日

筆記:Amazon S3 及 CloudFront 費用計算

今年開始陸續將一些 Web 搭配 Amazon S3 / Cloud Front 雲端服務,除了先前文章中談過的 CDN(放置 Web Static Assets,如 CSS/JS/ICON...)用途外,我也嘗試使用 S3 + CloudFront 提供以下檔案的儲存與傳輸加速。
  • PLWeb.org 的程式碼編輯器(單一 USER 的下載量約 9.3MB)
  • ContPub.org 的電子書(每本電子書的容量約 300KB 至 3MB)

使用 S3 + CloudFront 的好處很多,例如取之不盡用之不竭的傳輸頻寬(實測幾乎都有大於100Mbps)、儲存空間(就算大於10TB也沒問題),也不必擔心負載過量的問題。網站以 Web-based 架構建置,搭配 S3 + CloudFront 處理使用者上下傳檔案的部分,就可以輕鬆享受以下的好處:
  • 網站及資料庫本身仍可架設在自有的伺服器,僅檔案部分交由 S3 + CloudFront 處理。
  • 輕鬆享有與跨國企業同級的頻寬,超過 100Mbps 的上傳頻寬,以種花電信的企業型光世代固定制方案來說,光是 5Mbps 的上傳頻寬就要月付近 2000 元,而且還不是很穩定 : )
  • 輕鬆享有與跨國企業同級的機房,S3 有良好的 HA(高可用性),Amazon 宣稱可達 99.999999999% durability and 99.99% availability。
  • 透過 CloudFront 建置的內容傳遞網路,在世界多個國家都能享有良好的檔案傳輸速度。
  • S3、CloudFront 沒有分級,不管中小企業或跨國大企業,都是享有同樣的高規格服務,而且是依使用量計費。
  • S3 比起一般自建的伺服器更可靠,畢竟備用電力、備援網路、防災防震、異地備份這些建置費用太過昂貴;但為了避免極端的意外發生,S3 的使用者,也可以購買一般的高容量硬碟或 NAS,定期將檔案同步備份。
  • S3 提供足夠的頻寬,可以滿足需求的變化。例如網站可能在某個時期需要極高的頻寬(例如100Mbps),但平時大部分時間只需要很低的頻寬(例如1Mbps),為了保證服務的品質,可能需要為了短時間的需求租用100Mbps,但大部分的時間頻寬都是閒置,雲端的儲存服務則可以解決這種過度投資帶來的浪費,你需要多少頻寬,它就給你多少,依照實際用量計費。

即使這些好處看得到也吃得到,但是,我們更關心的:到底要付出多少錢?Amazon 公告的 Pricing 很詳細,但也讓人看得霧煞煞,心裡冒出不少問號。

這個月我終於收到一筆超過 $10 USD 的帳單,可以檢視 S3 及 CloudFront 的實際收費 : )

這是3月份 PLWeb.org 的造訪人次,因為是會員制網站,實際訪問量並不高,但其中有九成會執行檔案下載動作。

主要的費用是 CloudFront 的傳輸費部份,因為網站的主要使用者來自台灣,所以費用都落在亞太地區(東京或新加坡)。CloudFront 會自動選擇網路距離比較近的機房,其中大部份都來自東京,實測的結果種花電信到東京機房的傳輸確實比較快。從費用說明可以看到,費率高低是:東京 > 新加坡 > 南美 > 歐洲 = 美國。

雖然我的 CloudFront 檔案來源是 S3,但 S3 的部份幾乎沒產生什麼費用,一部分的原因是 AWS 第一年有免費的儲存容量額度,而 Request 的費用則相當低廉。

如果需要傳輸量的明細,AWS 也提供 Usage Report,格式包含 CSV 及 XML。

這是 CSV 版本的明細範例,列表是該月每天的流量狀況。

因為 AWS 目前沒有漂亮的圖形化 Usage Report,用慣 Google Analytics 的網站經營者,可能會想要這種一目了然的簡潔報表,這個畫面是 S3STAT 網站,月付 $5 USD 的價格,就可以得到更 friendly 的報表。

在計算過後,我目前考慮先取消部分的 CloudFront 服務,因為單月 55GB 的傳輸量都落在亞太區,產生的費用是 $10 USD 左右;若是把這個費用加到 Linode,則可以從 Linode 512 升級成 768 方案,傳輸額度就會比原本的 200GB 增加為 300GB,即增加了 100GB 的額度,而 Linode 機房選擇在東京,對亞太地區的傳輸速度也已能夠滿足了。

Ubuntu 12.04 帶來全新 HUD 選單介面設計

令人期待的 Ubuntu 12.04 採用改良後的 Unity 5.0 桌面,應用程式的捷徑更容易找到,操作方式更貼近使用者的思考。全新的應用程式選單設計也值得注意,新的選單設計被開發團隊稱為 HUD(Heads Up Display),此舉又為 Ubuntu 桌面系統帶來獨具風格的創新設計,先不管使用者是否能接受改變,能夠看到 Linux 桌面系統走出自己的路,就是一件令人欣喜的事。

HUD 的中文通常翻譯為「抬頭顯示器」,也就是航空或汽車駕駛艙,將儀表重要資訊投影在屏幕,讓駕駛者不必低頭觀看儀表板,就能在注視前方專心駕駛的同時也能獲悉重要資訊的回饋。

用於駕駛艙的抬頭顯示器(HUD)
既然應用程式的選單設計也稱為 HUD,顧名思義就是要讓使用者在專心操作應用程式時,不會被傳統選單打擾思緒。傳統的選單設計有什麼問題呢?當應用程式功能愈強大、選單功能愈多時,使用者就只能從分類中尋找需要的選項,有時候選單不會只有一層,如果想要加快操作速度,就必須記憶快捷鍵。回憶一下早期的 Office 2000/2003,應該就很容易瞭解複雜的選單是什麼樣子,而 Office 2007/2010 的全新介面也刻意將傳統選單隱藏起來。

這幾篇文章可以快速瞭解 Ubuntu 帶來的 HUD 設計。


我認為一般使用者應該能逐漸接受這種新的設計,因為「搜尋」已經成為使用電腦的一種基本操作行為,例如,我們通常不會記住網址,即使是常用的網站,通常還是會在瀏覽器的網址列、搜尋列,或者進入  Google/Yahoo 搜尋畫面後,打入部分的關鍵字進行檢索,因為愈來愈聰明的搜尋演算法,通常只需要很少的關鍵字就能找到想要的網站,比起從分類、我的最愛/書籤中找網站,直接打關鍵字找網站通常更迅速,甚至關鍵字還沒打完就能找到需要的網站。

而這個搜尋的行為已經被用在新一代作業系統的應用程式捷徑目錄,例如 GNOME Shell 或 Unity 的應用程式目錄,只要鍵入「term」就能找到「GNOME 終端機」之類的捷徑。

用鍵盤輸入簡短的幾個字母進行搜尋,對大腦來說相當直覺,因為我們需要使用某一項功能時,大腦已經浮現出關鍵字,若直接經過雙手輸入幾個字就能找到功能,效率就會非常高、不太會打斷思考;而傳統的作法則多了很多步驟,我們需要先將手移開鍵盤開始操作滑鼠,大腦此時必須暫停已經專注的思考,開始回想要怎麼找到這個功能,有時還可能要花上一些時間尋找。對許多需要大量操作鍵盤的工作來說,不斷使用滑鼠只為了操作選單,對工作效率確實帶來負面影響。

當然,並不需要將 HUD 定義成「取代」傳統選單的設計,它只是提供使用者另一種快捷的操作方式。有很多時候熟記快捷鍵可以得到更高的效率,有很多功能一時可能也想不到要用什麼關鍵字尋找(特別是對中文使用者來說)。

這是 Ubuntu 發佈的 HUD 介紹影片: Introducing the HUD to Ubuntu



若想要體驗 HUD 的功能,可以先安裝或升級到 Ubuntu 12.04,HUD 是系統已經預設啟用的設定,使用方法是在應用程式畫面操作時,按下鍵盤的 ALT(輕按一下就放開,否則會變成選單出現在系統列),之後就能輸入關鍵字(英文字母)來尋找選項。

在文字終端機模式下,可以用以下指令加裝套件,就能使用 hud-cli 指令啟用文字介面的 HUD 功能。

sudo apt-get install indicator-appmenu-tools

不過有點可惜的是,目前 hud-cli 並無法正確支援中文,會有出現亂碼的情形。

2012年4月2日

筆記:減少 JSON 資料體積

將 Database 查詢的 Result Set 完整回傳到 Client/Browser 端,通常會使用 JSON 及 XML 兩種格式,若是用於網頁的 AJAX,比較好的作法是 JSON,體積稍微小一些,接收端的解析速度也快。

若以 API 形式設計資料存取服務,則可以使用路徑來區別回傳格式,例如:

/service/readData.xml
/service/readData.json

利用 MVC 框架提供的 Route 自訂功能,可以讓 Server 端程式自動依照網址指定的格式處理回傳資料。

由於 JSON 是文字型態的資料,且大量資料容易有重複的情況,將產生的資料經過  GZIP 或 DEFLATE 壓縮處理,可以節省不少傳輸時間及頻寬。

Apache 伺服器可以搭配 mod_deflate 模組。
Nginx 可以搭配 HttpGzipModule 模組。

若不透過伺服器,利用 Web App 本身的 GZIP 模組也可以達到壓縮效果。

PHP 可使用 ob_gzhandler
Node.js 可以搭配 zlibgzippo(靜態檔案),關於 zlib 可參考我提供的範本

當然,JSON本身的資料格式也有機會壓縮,例如:

[{a: 1, b: 2, c: 3},{a: 2, b: 3, c: 4}]

這個 JSON 範例資料,可以看到在每一筆 row 都重複了 a, b, c 的 field 名稱。HPack 及 CJSON 兩個演算法的目的,就是要壓縮這種形態的資料。

使用 HPack 與 CJSON 演算法來壓縮 JSON

其中 HPack 已經更名為 JSONH(Homogeneous Collection Compressor)。

JSONH 的壓縮效果相當好,搭配 GZIP/DEFLATE 可以達到相當不錯的壓縮率。

JSONH 在 Server 端提供 Ruby / Python / PHP 函式庫,將資料經演算壓縮後,丟給 Browser 端,再使用 JavaScript 的函式庫還原成原始的資料。照理說 JSONH 的 JavaScript 有機會給 CommonJS/Node.js 使用,也就是同時用於 Server/Browser 兩端(這個假設尚未驗證)。

在 ExtJS 的 Data Reader 中,有  XML、Array 及 JSON 三種,先不管 XML,其中 Array 及 JSON 其實都是同樣的 JSON 結構,只是 Array 並不包含 field 名稱(也就是說 JSON Reader 是 Array 裡面裝 Object,而 Array Reader 則是 Array 裡面裝 Array)。

Ext.data.reader.Array
Ext.data.reader.Json

以這兩種 Reader 來說,大部分情況都建議用 JSON Reader,因為回傳的資料可以透過 field 名稱索引出對應的資料,但 Array Reader 就必須依賴陣列中元素的先後次序來映射資料。

但是遇到資料量非常大、卻又需要一次全部讀取到 Client 端(保存到 ExtJS 的 Data Store 中),就可以考慮用 Array Reader,兩者的資料體積可能相差非常多。

lyhcode by lyhcode
歡迎轉載,請務必註明出處!