先週、Feedlyは物議を醸す新しい「機能」を展開した -- フィードリンクをハイジャックして、何百万ものブロガーからトラフィックを奪うことだ。
共有リンクをFeedlyでリダイレクトして、オリジナルサイトの記事ではなく、Feedlyの独自の見解にリダイレクトすることは、多くのブログのオリジナルコンテンツクリエイターにとって懸念事項だ。これはトラフィックの損失をもたらすだけでなく、特定のブログをフォローしている人にとっても欺瞞的だ。
人々が怒っている理由と、あるブロガーが状況を正すためにどのように貢献したのかの全容を説明する。また、彼らのソースコードを深く掘り下げて、彼らの汚い小細工がどれほどのものであるかを示す。
出所:このニュースのオリジナルソースはThe Digital Readerだった -- 私は少し深く調査して、彼らが何を企んでいるのかを正確に把握することにした。
まず、良いニュース
執筆時点で、短縮されたFeedlyリンクが実際に発信元のサイトに送信されるように、その動作はいくらか修正されたが、HTTPステータスコードを素早く調べたところ、リダイレクトは301または302リダイレクト(Feedlyが送信している200は「はい、そのページがあります、お待ちください」を意味し、404は「見つかりません」を意味し、301は「別のURLに永続的にリダイレクト」を意味し、302は「一時的なリダイレクト」を意味する)という典型的なサーバーレベルの方法で行われていないことが判明した。
これはリダイレクトがJavaScriptで実行されていることを意味していたので、私はもっと知りたかった。curlと呼ばれるコマンドラインのウェブページフェッチングツールを使って、リダイレクトが行われる前にTechmeme.comへのサンプルのFeedlyリンクのソースコードを取得することができた(CURLはJavaScriptを実行しないため) -- そしてそれは驚くべき情報を明らかにした。私が発見したものを以下に示す。
(もしあなたが見てみたいと思うなら、私はここに完全なソースをアップロードした -- 私は以下にいくつかの興味深いスニペットだけを掲載するつもりだ)
コンテンツが盗まれて他の場所で再公開されることの基本的なSEOへの影響を心配する人もいた。良いニュースは、FeedlyがGoogleに対してすべてのリンク値を元のサイトに渡すように指示するrel="canonical"メタタグを正しく設定したことだ。しかし、これは苦情が始まってから追加されたのか、最初から存在していたのかを確かめることは不可能だ。
<link rel="canonical" href="http://www.techmeme.com/131202/p30#a131202p30" />
彼らは広告を削除している
おそらくReadabilityタイプの機能を複製しようとした誤った試みで、ページをその中核的な要素まで削ぎ落とすFeedlyは、元のフィード項目に埋め込まれていた可能性のあるすべての広告、追跡、ソーシャルシェアボタンを削除していた。削除されているものの全リストを以下に示す:
var visualExcludePatterns = [ "feedproxy","feedburner","/~","feeds.wordpress.com","stats.wordpress.com","googleadservices.com","feedads","tweet-this", "fmpub","-ads","_ads","pheedo","zemanta","u.npr.org/iserver","openx.org","slashdot-it","smilies","/ico-","commindo-media.de","creatives.commindo-media","doubleclick.net","i.techcrunch","adview","/feed.gif",".ads.","/avw.php”,"wp-digg-this","feed-injector","/plugins/","tweetmeme.com","_icon_","/ad-","share-buttons","feedsportal.com","buysellads", "holstee","musictapp","/ad_","/button/","donate.png","/sponsors/","googlesyndication.com","/pagead","/adx","assets/feed-fb","assets/feed-tw","feedburner.com/~ff","gstatic.com","feedsportal.com"];
何らかの理由で「寄付」ボタンを取り除くことは特に腹立たしいことのように思える。
彼らはリンクをハイジャックしている
ここで最も深刻な問題にたどり着いたが、Feedlyがサイトからコンテンツをスクレイピングしているだけでなく、元のソーシャルボタンをすべて削除してメタデータを書き換えていたのだ。これは、その後誰かがそのアイテムを共有した場合、実際にはFeedlyのリンクを共有することになり、元の投稿を共有することにはならないことを意味する。そのリンクをクリックした人は誰でも、Feedlyに直行することになる。
それで何が問題なのかとあなたは尋ねるかもしれない。投稿がバイラルになると、ページビューや広告収入が増加し、オーディエンスが拡大されるため、問題のサイトには大きな利益をもたらす可能性がある。Feedlyはその特定の利益をサイトから完全に奪い取り、独自のユーザーベースを拡大していた。Feedlyのコードには、ユーザーを関連するアプリストアのページに誘導するモバイルデバイスのチェックが含まれていた。
function action( where ) { var actionName = "follow"; var url = "http://feedly.com/#" + encodeURIComponent( "subscription/" + feedInfo.id ); if( /iPhone|iPad/i.test( navigator.userAgent ) ) { actionName = "install"; url = "http://itunes.apple.com/us/app/feedly/id396069556"; } else if( /android/i.test( navigator.userAgent ) ) { actionName = "install"; url = "market://details?id=com.devhd.feedly"; } _gaq.push( [ '_trackEvent', bucket(), actionName + "." + where, feedInfo.id ] ); window.setTimeout( function() { document.location.href = url;}, 20 ); window.event.cancelBubble = true window.event.stopPropagation(); window.event.preventDefault(); }
それは「記事を見やすくすること」ではなかった -- それはトラフィックを盗むことであり、単純明快だ。それは本当にクールではない。
彼らの最初の修正: ハードコードされた除外リスト
The Digital Readerが最初にFeedlyに苦情を申し立てたとき、彼らの対応は、除外リストを含めるようにJavaScriptを再コーディングすることだった。彼らは文字通り、すべてのFeedlyリンクにチェックを追加して、それがThe Digital Readerからのアイテムかどうかを確認し、そうであればページのハイジャックをバイパスするようにした。
var siteExcludePatterns = [ "/TheDigitalReader/" ]; function shouldExcludeSite( url )
これはもちろん、これを行うにはまったくばかげた方法だ -- 彼らは時間が経つにつれて、より多くのブロガーが苦情を言うにつれて、そのリストに追加することを計画していたのだろうか?
The Digital ReaderのNateは次のように応答した:
あなたのハイジャックからオプトアウトすることを要求するのは何のつもりですか?誰かに財布を殴るのをやめるように頼まなければならないと言っているようなものです。それでもあなたはそれが合理的だと思いますか?
彼らの2番目の修正: すべてのコードをバイパスするクイックハック
私が想定できるのは、その後圧倒的な数の苦情が寄せられたため、ハイジャックフィルターを次のように調整したということだ:
if( kind == "partial" || shouldExcludeSite( "http://www.techmeme.com/131202/p30#a131202p30" ) || true ) { document.body.innerHTML = ""; document.location.href = "http://www.techmeme.com/131202/p30#a131202p30"; }
「部分的」とは、スクレイプされたコンテンツが完全なフィードであるか部分的なフィードであるかを指す -- 結局のところ、抜粋のみを公開するフィードをハイジャックする意味はない。おそらく、この関数は、ユーザーを元のサイトに送信するかどうかの選択時に発生した唯一のチェックとして始まった。その後、最初の修正が見られ、このサイトがオプトアウトしたサイトのリストにあるかどうかをチェックする関数が呼び出される。しかし、その後、最終的な修正が導入された。
|| true.
プログラミングの経験があれば、"以下のコードは常に実行される"というクイックハックを認識するだろうし、それは通常、デバッグでのみ使用される。これらの3つの条件のいずれかが真である場合(最初の2つはもはや重要ではない)、Feedlyはユーザーを即座に元のサイトにリダイレクトする。
そして、それが現在の状況だ。それでは、私たちはここで何を学んだのだろうか?
基本的に、Feedlyは一種の簡素化された読書体験の創造に取り組んだが、そのやり方 -- その後のソーシャルシェアを通じて独自のサービスを宣伝するためにリンクを書き換えることは、かなりひどいものだった。これは、Feedlyが最近行った唯一の悪い動きでもない - 先月、彼らはGoogle+アカウントでのログインを要求し始めた(YouTubeでGoogle+ログインがどれだけうまく機能しているかを見て、そうしたのだろうと推測する)が、それもすぐに元に戻された。教訓は -- あなたはすでにProアカウントのために99ドルを支払うのにまんまと騙されていなければ、別のフィードリーダーを探し始めるべきかもしれないということだ。
コメントする