Google中文網站管理員 - 中文網誌 [TW]

#NoHacked：如何辨識社交工程手法並保護自身安全

2015年8月11日星期二

原文：#NoHacked: How to recognise and protect yourself against social engineering 作者：Eric Kuan, Webmaster Relations Specialist， Yuan Niu, Webspam Analyst
我們將在今天的 #nohacked 活動裡，和大家談論社交工程。大家可以透過 #nohacked 主題標記追蹤在Twitter 和 Google+ 上的討論內容。(第一部分)

相信使用網路已經有一段時間的人可能都曾面臨某些形式的社交工程攻擊。所謂的社交工程，指的是以某種方式操控或欺騙使用者，企圖擷取使用者的機密資訊。網路詐騙人們所熟悉的網路詐騙是最常見的一種社交工程技術。具體來說，網路詐騙網站和電子郵件會藉由仿冒合法網站，誘騙您在這些網站上輸入使用者名稱和密碼之類的機密資訊。Google 近期的研究顯示，有些網路詐騙網站的成功率可達到 45%！當這類網站取得您的資訊後，可能將您的資訊出售，也可能用這些資訊來操控您的帳戶。其他社交工程攻擊手法如果您是網站擁有者，那麼除了網路詐騙之外，還有其他更多的社交工程攻擊手法必須注意，比如針對您網站上使用的軟體和工具進行攻擊。如果您需要下載或使用任何內容管理系統 (CMS)、外掛程式或附加元件，這些項目必須來自可信的來源，例如開發人員的網站內容。來自不可信任網站的軟體可能含有惡意漏洞，容易讓駭客入侵您的網站。舉例來說，「小布的寵物皇宮」最近聘請了網站管理員小王來幫忙架設網站。小王做了一些設計後，便開始著手收集架設網站所需的軟體。這時，他發現自己愛用的外掛程式 Photo Frame Beautifier 已經從官方 CMS 外掛程式網站下架，開發人員也已停止支援該外掛程式。於是，他很快地又找到了一個提供舊版外掛程式封存的網站，並且下載當中的外掛程式來架設網站。兩個月後，小王收到了 Search Console 的通知，指出他客戶的網站遭到駭客入侵。當他快速修正遭入侵的內容時，也發現了問題的來源。原來，他所用的 Photo Frame Beautifier 外掛程式已遭到第三方修改，成為了惡意人士入侵網站的漏洞。在移除外掛程式、修正遭入侵的內容，並且針對日後可能受到的攻擊採取預防措施後，小王在 Search Console 中提交了重審要求。如上所述，您可以看到正是因為小王的無意疏忽，才造成客戶的網站遭到入侵。防範社交工程攻擊社交工程是一種很有效的攻擊手法，因為落入這類陷阱的使用者很難發現不對勁的地方。為了防範社交工程陷阱，您可以採取下列基本策略。

保持警惕：每當您在網路上輸入機密資訊，或是安裝網路軟體時，最好秉持合理懷疑的態度。先檢查網址，確定您不是在惡意網站上輸入機密資訊。安裝網站軟體時，也必須確認軟體來自已知的可信任來源，例如開發人員網站。

使用雙重驗證：使用雙重驗證 (比如 Google 的兩步驟驗證) 可為您的帳戶安全再添一層防護，即使密碼遭竊也不至於造成損失。建議您盡量為所有帳戶啟用雙重驗證功能。我們會在下週更詳細地說明雙重驗證的優點。

更多社交工程相關資源：

進一步瞭解如何防範網路詐騙惡行

檢舉網路詐騙頁面

避免及回報假冒 Google 的詐騙陷阱

識別「網路詐騙」和「假冒」郵件

如果還有其他問題，歡迎前往網站管理員說明論壇提問，該網站管理員社群中的其他成員會非常樂意回答您的問題。您也可以加入我們在8月26日針對安全性問題所舉辦的 Hangout 直播。張貼者：

#NoHacked：如何避免成為駭客攻擊的目標

2015年7月30日星期四

#NoHacked: How to avoid being the target of hackers作者：Eric Kuan, Webmaster Relations Specialist and Yuan Niu, Webspam Analyst
不論要在網路上發佈任何內容，都必須優先確保資料內容的安全性。遭到駭客入侵不僅會對您的網路形象產生負面影響，還會造成重要私人資料的損失。過去一年來，Google 發現遭到入侵的網站數量增加了 180%。在我們努力抵禦駭客入侵攻勢的同時，您也可以採取以下措施來保護自己的線上內容。

在 7 月，我們將繼續進行 #nohacked 推廣活動。這個月的重點是介紹如何避免網站遭受駭客攻擊，並讓您更深入瞭解這些駭客活動的方式。您可以在 Twitter 和 Google+ 上追蹤 #nohacked 推廣活動。在活動結尾，我們也會針對安全性問題舉辦一場 Google Hangouts，開放與會者向我們的安全性專家提問。在推廣活動開始之際，讓我們先為您提供一些維護網站安全的基本提示。提高帳戶安全性設定一個難以猜到或破解的密碼，是保護網站安全的先決要務。舉例來說，您可以在密碼中混用字母、數字及符號，或是指定一句通關密語。此外，密碼長度的重要性也不可輕忽，因為密碼越長，就越難被破解。網路上有許多資源可讓您測試密碼強度，您可以使用與自身密碼相似的密碼進行測試 (請不要在任何其他網站上輸入您真正的密碼)，即可瞭解自身密碼的大致強度。另外，請避免在不同服務中使用相同的密碼，因為當攻擊者取得他處洩漏的密碼清單或成功入侵其他服務後，常會利用從這些地方取得的使用者名稱和密碼組合企圖入侵更多帳戶。如果您的帳戶支援雙重驗證機制，建議您一併啟用這項功能。如此一來，便能大幅提升您的帳戶安全性，防禦各種形式的帳戶攻擊。我們會在兩週後更詳細地說明雙重驗證的優點。隨時更新網站所使用的軟體網站上存在的軟體漏洞，是駭客用來入侵網站的一種常見途徑。因此，請務必定期檢查您的網站是否有任何未更新的軟體，特別是針對安全性漏洞修補所做的更新。如果您使用 Apache、nginx 這類網路伺服器或商業網路伺服器軟體，請務必即時修補安全性漏洞。如果您的網站使用了內容管理系統 (CMS)、任何外掛程式或附加元件，則必須確保這些工具都是最新版本。另外，請為您的網路伺服器軟體和 CMS (如有使用) 註冊安全公告清單。也建議您將網站上不需要的附加元件和軟體全部移除，因為這些項目既可能造成安全性風險，也可能使網站效能降低。研究您的代管服務供應商如何處理安全性問題選擇代管服務供應商時，請務必將其安全性政策和對於網站遭入侵的處理方式納入考量。如果您目前有合作的代管服務供應商，您可以嘗試向對方瞭解，當您需要請他們協助處理個別網站問題時，是否能得到即時支援。您也可以參考網路上的評論，看看各家供應商是否有協助使用者清理網站上遭駭內容的實際業務。如果您自行管理伺服器，或使用虛擬私人伺服器 (VPS) 服務，則必須隨時準備處理可能發生的安全性問題。伺服器管理工作相當複雜，而伺服器管理員的其中一項重要工作，就是確保網路伺服器和內容管理軟體的漏洞和問題均已妥善修正，並且已更新到最新版本。如果您沒有必要自行管理伺服器，不妨花點時間瞭解您的代管服務供應商是否有提供管理服務。使用 Google 的各項工具即時瞭解網站上是否有駭客植入或竄改過的內容擁有可讓您主動監控網站的工具是很重要的，因為能夠越早發現網站遭到入侵的跡象，您就能越早修復網站。如果您尚未申請使用 Search Console，建議您可以試試這項服務。如果 Google 在您的網站上偵測到任何問題 (例如發現遭駭客植入或竄改過的內容)，就會透過 Search Console 通知您。您也可以為自己的網站設定 Google 快訊，以便在網站有可疑的結果時收到通知。舉例來說，如果您使用 www.example.com 這個網址經營了一家販售寵物配件網站，則可針對 [site:example.com <特價軟體>] 這個字串建立快訊；這樣一來，當您的網站遭到駭客入侵，突然出現關於特價軟體的內容時，您就會收到相關的通知。您可以使用不同的垃圾字詞為自己的網站建立多個快訊。如果您不知道該使用哪些垃圾字詞，請使用 Google 搜尋常見垃圾字詞。希望這些提示能幫助您在網路上維護您的網站安全。敬請追蹤我們的社交推廣活動，也歡迎透過 #nohacked 主題標記，分享任何關於維護網路安全的提示或技巧。如果還有其他問題，歡迎前往網站管理員說明論壇提問，該網站管理員社群中的其他成員會非常樂意回答您的問題。您也可以加入我們在8月26日針對安全性議題所舉辦的 Hangouts 直播。

Autocomplete API 更新

2015年7月27日星期一

Update on the Autocomplete API Peter Chiu, Autocomplete team Google 搜尋提供的自動完成服務會在使用者輸入搜尋字詞的當下，嘗試預測查詢字詞。多年來，許多開發人員使用非官方和未發佈的 API，將自動完成的結果與自己的服務進行整合，而且完全不加以限制。後來，發現自動完成 API 的開發人員整合了自動完成服務，而且讓這項服務獨立於 Google 搜尋之外。

開發人員社群會透過未發佈的 API，對特定 Google 服務進行反向工程，而且多次獲得驚人的成果。舉例來說，我們看到創意十足的工程師將地圖資料和其他資料來源加以結合，創造出絕佳的功用，因此我們在幾個月之後，決定將 Google Maps API 列為正式受支援的 API。我們目前支援超過 80 個 API，可供開發人員用來將 Google 服務整合至個人的應用程式。不過，在某些情況下，使用不支援且未發佈的 API，也可能導致該 API 停止提供服務。這個情況就是其中一例。

我們建立自動完成功能是為了讓搜尋功能更加完善，從未想過這項功能會用於與預測使用者搜尋查詢完全無關的用途。長久下來我們瞭解到一件事，雖然我們想像得到將自動完成資料資訊提供運用在與搜尋結果無關的用途上，可能會帶來些許價值，但總體來說，我們自動完成功能的內容原本就是為了與網路搜尋結果配合使用，而且已針對這項用途進行最佳化，因此將這項功能應用在網路搜尋之外的情況並無法為使用者提供實質助益。

為了讓搜尋中的自動完成功能維持完整性，我們將於2015年8月10日起，限制未經授權的人士存取尚未發佈的自動完成 API。我們想確保使用者能受惠於自動完成功能的原始設計功用，也就是與搜尋緊密結合的服務。我們相信這樣才能使這兩項服務提供最佳使用體驗。

對於仍想在個人網站上使用自動完成服務的發佈者和開發人員，我們有個替代方案。Google 自訂搜尋引擎可讓網站繼續使用搜尋功能中的自動完成功能。這項異動不會影響到任何已使用 Google CSE 的合作夥伴。至於其他使用者，如果您想在2015年8月10日後繼續使用自動完成功能，請參閱我們 CSE 申請網頁中的說明。

Google+：應用程式下載插頁廣告的個案研究

2015年7月27日星期一

Google+: A case study on App Download Interstitials 許多行動網站會利用應用程式插頁廣告進行宣傳，鼓勵使用者下載自家的原生行動應用程式。有的原生應用程式不僅能提供更豐富的使用體驗，就連目前難以透過瀏覽器執行的一些裝置功能，也都能為其所用。因此，很多應用程式擁有者都認為，他們應該多多鼓勵使用者安裝自家線上資源或服務的原生應用程式。不過目前我們還不清楚如何拿捏宣傳應用程式的力度，而整頁的插頁廣告實際上也可能妨礙使用者取得需要的內容。

我們決定以 Google+ 行動網路平台做為觀察對象，進一步檢視插頁廣告的使用效果。在我們進行內部使用體驗調查後，發現使用者對插頁廣告的觀感不佳，而 Jennifer Gove 去年在 IO 大會上的精彩演講也強調了這一點。
雖然我們憑直覺認為應該移除插頁廣告，但我們更相信數字會說話這個不變的道理，於是我們開始研究插頁廣告對使用者的影響。分析結果顯示：

＊9% 造訪插頁廣告頁面的使用者按下了 [取得應用程式] 按鈕 (請注意，這之中包含已安裝應用程式的人，以及其後並未在應用程式商店下載應用程式的人)。

＊69% 造訪插頁廣告頁面的使用者直接離開了頁面。他們既沒有前往應用程式商店，也沒有繼續瀏覽我們的行動網站。

儘管對任何廣告活動來說，9% 聽來是很不錯的點閱率，但是我們更重視的數字其實是那些因為插頁廣告造成負面體驗而放棄探索我們產品的使用者人數。得到這樣的數據後，我們在 2014 年 7 月決定進行一項實驗，看看移除插頁廣告對產品的實際使用情形有何影響。我們參考行動版網站搜尋引擎最佳化指南中避免常見錯誤一節的建議，加入了 Smart App Banner，以干擾性較低的方式繼續宣傳原生應用程式，而實驗結果著實令人驚艷：

＊我們行動網站上的單日活躍使用者增加了 17%。

＊Google+ iOS 原生應用程式的安裝次數幾乎沒有受到影響 (減少 2%；大部分 Android 裝置均內建 Google+，所以此處不列出 Android 裝置的安裝次數資料)。

基於以上結果，我們決定讓插頁廣告永遠退出歷史舞台。我們認為能讓產品的使用人數增加，代表這樣的改變對產品絕對只有好處。希望將這個經驗與您分享後，您可以重新考慮是否繼續使用插頁廣告來宣傳應用程式。歡迎您和我們一起排除障礙，創造更方便實用的行動網路環境！

Google 如何處理新的頂層網域

2015年7月22日星期三

Google's handling of new top level domains 作者： John Mueller,Webmaster Trends Analyst

由於新的一般頂層網域 (gTLD) 越來越多，在此我們為您提供進一步的說明，協助您瞭解 Google 搜尋服務如何處理這些頂層網域。據我們所知，使用者對於 Google 處理 .guru、.how 或 .BRAND 等等新型一般頂層網域 (TLD) 的方式有許多疑問及誤解，以下是一些常見問題：

問：新的 gTLD 會對搜尋服務造成什麼影響？Google 會修改搜尋演算法以偏重這些 TLD 嗎？這些 TLD 對搜尋結果的實際影響力為何？

答：整體而言，我們的系統處理這些新 gTLD 的方式和處理其他 gTLD (例如 .com 與 .org) 的方式並無不同。TLD 中的關鍵字不會對搜尋結果產生任何正面或負面影響。

問：IDN TLD (例如 .みんな) 的情況又是如何呢？Googlebot 會檢索這類 TLD 並且建立索引，來支援搜尋功能嗎？

答：是的。我們使用這些 TLD 的方式與其他 TLD 無異 (確認的方法十分簡單，只要使用 [site:みんな] 這類查詢就可以了)。Google 處理 Punycode 版本主機名稱的方式和處理未編碼版本的方式相同，因此您無需個別重新導向或加以標準化。至於網址的其他部分，使用非 ASCII 字元時，請務必使用 UTF-8 處理路徑和網址的查詢字串。

問：.BRAND TLD 在搜尋結果中的加權比重會與 .com 有任何差異嗎？

答：沒有差異。我們處理這些 TLD 的方式和處理其他 gTLD 的方式相同。這些 TLD 必須具備同樣的地理定位設定和組態；而我們在檢索這些網址、建立索引或進行排名時，都不會為這些 TLD 提供更多加權或改變任何處理方式。

問：Google 如何處理新的區域 TLD 或城市 TLD (例如 .london 或 .bayern)？

答：即使某些 TLD 明顯為區域專屬的 TLD，我們依然會以處理 gTLD 的方式來處理這類 TLD。我們在處理地區性 TLD (例如 .eu 和 .asia) 時也採取同樣的做法。日後可能會有些許例外情況，這取決於實務上的使用情形。如需進一步瞭解多地區和多語言版本的網站，以及如何在 Search Console 指定相關的地理區域，請前往說明中心參閱相關文章。

問：真正的 ccTLD (國家/地區代碼頂層網域) 情況又是如何呢？使用者在這些國家/地區中進行搜尋時，Google 會因為本地網域而偏重 ccTLD (例如 .uk、.ae 等) 嗎？

答：依據預設，多數的 ccTLD (包括例外情況) 都會導致 Google 使用這些 ccTLD 來為網站指定地理區域；也就是說，這些 ccTLD 能夠讓我們得知該網站可能與特定國家/地區的關聯性更高。再次提醒您，如需進一步瞭解多地區和多語言版本的網站，請前往說明中心參閱相關文章。

問：我為了達成搜尋引擎最佳化 (SEO) 的目標，將網域從 .com 遷移至新的 TLD，Google 會提供任何相關支援嗎？我該如何在遷移網站的同時確保搜尋排名或紀錄不會因此受到任何影響？

答：我們的說明中心提供了各種網站遷移說明文件供您參考。我們會按照處理其他網站遷移作業的方式來處理這類網站遷移。也就是說，搜尋服務需要一段時間來處理網域異動 (除了搜尋之外，使用者也會希望原本的電子郵件地址能夠再使用一段時間)，因此一般而言，建議您最好選擇能夠符合長期所需的網域。

希望上述的說明有助您進一步瞭解我們如何處理新的頂層網域。如有任何問題，歡迎在此提出，或是前往說明論壇提問。

透過 goo.gl 設定應用程式深層連結

2015年5月28日星期四

原文：App deep linking with goo.gl作者：Fabian Schlup，工程師
即日起，無論您的內容是在 Android 應用程式中、 iOS 應用程式中還是網站中，您都可以將 goo.gl 短連結設為單獨的連結並套用到自己所有的內容。按照必要的步驟針對 Android 和 iOS 將應用程式編入索引後， goo.gl 網址就會將已安裝您的應用程式的使用者直接導向應用程式中的適當頁面，並將其他使用者導向您的網站。這樣一來，您的應用程式使用者就會有更多機會再次與您的應用程式互動。這樣功能既適用於新的短網址，也適用於以前的網址。因此，連結到您內容的全部現有 goo.gl 短連結也會將使用者導向您的應用程式。

分享「因平台制宜」的連結如要充分發揮這項功能的作用，您也可以將 URL Shortener API 整合到應用程式的分享流程中，這樣使用者分享的連結就會將訪客自動重新導向您的跨平台原生應用程式。此外，其他人也可以在自己的網站和應用程式中嵌入透過深層連結直接連到您應用程式的連結。以 Google 地圖為例，有了全新的跨平台 goo.gl 連結，透過地圖的分享按鈕所產生的連結就能為每個人提供最理想的分享方式。開啟後，該連結會自動偵測使用者的作業平台並檢查他們是否安裝了 Google 地圖。如果使用者安裝了 Google 地圖，短連結就會直接在 Android 或 iOS 裝置上的 Google 地圖應用程式中開啟相關內容。如果使用者未安裝該應用程式或者透過桌機瀏覽，短連結就會開啟 Google 地圖網站上的相關網頁。您不妨來試一下！測試前別忘了在手機上安裝 Google 地圖應用程式：http://goo.gl/maps/xlWFj。設定方式 如何透過 goo.gl 設定應用程式深層連結：

參閱 g.co/AppIndexing，完成相關必要步驟，將 Android 和 iOS 應用程式編入Google 搜尋索引。請注意，凡是 iOS 開發人員都可以使用 goo.gl 深層連結，這與目前透過 Google 搜尋提供的深層連結不同。完成此步驟後，現有的 goo.gl 短連結就會透過深層連結將使用者導向您的應用程式。

您可以視需要將 URL Shortener API 整合到應用程式的分享流程、您的電子郵件廣告活動等項目中，透過程式產生會以深層連結形式直接連回您應用程式的連結。

希望您喜歡這個新功能，並且擁有愉快的跨平台分享體驗！

在 Google 搜尋中顯示 iOS 應用程式內容

2015年5月28日星期四

原文：Surfacing content from iOS apps in Google Search作者：Eli Wald，產品經理
最近我們一直致力於協助使用者在 Google 搜尋結果中尋找 Android 應用程式中的相關內容，即日起，「應用程式索引」功能也可以運用在 iOS 應用程式上，也就是說，Android 和 iOS 的使用者都可以直接透過 Google 搜尋開啟行動應用程式內容。在未來幾天內，首批已經編入索引中的應用程式連結將陸續顯示在 Google App 以及 Chrome 的搜尋結果中，全球的已登入使用者皆可透過 iOS 裝置看見：

如何將您的 iOS 應用程式編入索引雖然即將推出的 iOS 應用程式索引功能只有為數不多的合作夥伴參與測試，但我們正持續努力，希望能盡快開放這項技術給更多應用程式開發人員。與此同時，您可以按照下列步驟搶先體驗 iOS 應用程式索引功能：1. 在您的 iOS 應用程式中新增深層連結支援功能。 2. 確保使用者只要點擊一次就可以返回搜尋結果。3. 在您的網站上提供深層連結註解。4. 如果您對此感興趣，請與我們聯絡。請注意，將您的意願告知我們，並不保證您的應用程式深層連結一定會顯示在 iOS 搜尋結果中。如果您會參加本週的 Google I/O 大會，可以注意一下「將您的應用程式編入 Google 索引」這場演講，以便進一步瞭解「應用程式索引」功能。您也可以在 g.co/AppIndexing 找到有關 iOS 應用程式索引的詳細說明文件。如果您有其他任何問題，請參閱網站管理員說明論壇。

中文網站管理員 - 中文網誌