カテゴリー
プライバシー

Consent-O-Matic 「Cookies使ってもいいですね?」等の質問を回答してくれるブラウザ拡張

cavi-au/Consent-O-Matic は、ウェブサイトを初めて訪問した時などに出てくる「Cookies 等を使って閲覧状況を記憶してもいいですか?」系の確認ダイアログを、自動的に回答してくれるブラウザ拡張です。

あるサイトではこんなダイアログが最初に出て、ユーザー追跡しますけどいいですかと確認されます。

Consent-O-Matic を入れていると、同じサイトがいきなりOKを押した状態になります。

どのサイトでも常に「許可」にして進むわけではなく、ブラウザ拡張機能の設定画面であらかじめ自分が決めておいた希望するYes/No を、そのサイトに初めて行った際に自動的に入力してくれるという動作です。

ですので、その時その時で適当に判断して決めるよりも、一貫した返答になるということも有り得ますね。

設定の種類は、「自分の好みを覚えたりするならOK」「性能測定やアクセス解析ならOK」「広告ネットワークに見せるIDならOK」「過去の閲覧内容や閲覧行動を使ったカスタマイズはOK」「過去の広告表示や広告クリック等の情報を使ったカスタマイズはOK」「その他」と分けて指定できるようです。

rules にいくつもルールの定義がありますが、これは Cookies の利用やその利用目的などを明示するダイアログを表示するwebサービスがいくつもあり、大手ニュースサイトなどでもそれらのサービスを利用しているため、サービス毎にルールを作ってメンテナンスしているのだと思われます。

新しいサイトに行くたびにダイアログを見て選択をしている時間をカットできると思えば、仕事効率化のツールとも言えますね。

Consent-O-Matic には、今のところ Chrome拡張Firefox拡張 が存在します。

via Hacker News

カテゴリー
fun

Pythonによる自動化の結果、ニューヨーク中でタダメシが食えるようになったエンジニアの話

いかにして私はPython/自動化/AI/インスタグラムを使いニューヨーク市で無料の食事をできるようになったか(How I Eat For Free in NYC Using Python, Automation, Artificial Intelligence, and Instagram)という記事が面白かったのでご紹介。

ニューヨーク在住のデータサイエンティスト、クリス・ブエッティさん(Chris Buetti)が明かした、3万フォロワー超の人気アカウントを育てた秘密。

データサイエンス/ソフトウェア開発の知識、自由な時間とインスタグラムの知識があれば再現可能だといいます。

Instagramを育てる

Pythonスクリプトで、毎日、一日に数回、ニューヨークに関する写真をInstagram に自動投稿させます。ブログ主によると、Instagram の「発見」ページに掲載してもらうにはこれが大事だそう。一日も欠かさず、何週間も続けることで掲載されやすくなるそうで、ほとんどの人力Instagramer はこれで競争から脱落してしまうということ。

人気が出そうな写真を機械学習で選ばせる

投稿内容の画像ですが、当初は、他のInstagramユーザーの新着投稿から画像をスクレイプし、オリジナルへのリンクをつけて投稿していたそうです。

ニューヨークの写真を投稿している50人のInstagramユーザーのページをスクレイプし、写真だけでなくキャプションやイイネの数も保存します。

キャプションから宣伝目的と思われる文章、「購入」とか「限定」といったものがあれば外し、再生回数やイイネの数が多いものをフィルタすることで、質の高い評判を呼んでいる写真だけを選び取らせます。

また、コメントが投稿できなくなっている投稿については、写真を取り込まないようにしたそうです。コメント欄が閉じられている投稿は、リスクが高いと判断してとのこと。

当初はルールベースでやっていたこのフィルタを、さらに機械学習に置き換え、自分で目視で良い/悪いのデータセットを作ったりの手間も掛け、結果として「より人気を得る写真」のみを転載するボットが完成したということ。

他人の写真勝手に再利用するのは問題なのでは、と思いますが、スクレイプ元にリンクをして「問題があれば言ってくれれば消します」と書いておくと、ほぼ苦情は来なかったそう。

また、最新版のボットでは、他のInstagrammer の写真をコピーするのは止めて、ロイヤリティーフリーの素材サイトをスクレイプした画像を投稿するように変更したそうで、今後は著作権侵害だと言われるリスクも減らしているよう。こちらは十分な独自のフォロワーを確保した後だからこそ可能なのかもしれませんが。

コメントやタグを機械学習で作らせる

写真に添えるコメントは、当初、どんな写真につけても通用しそうな文章のパターンをリスト化し、それをランダムで出していたそうです。

例として「ここどこか知ってる?」「ニューヨークで好きなバーをコメントして!」「死ぬまでニューヨークを楽しめ」みたいなコメントが出ています。

次にクレジット。出典を示すことで画像を再利用したことへの苦情が減ると考えたのか、誰の写真かというのをコメントに書くことに気を配ったようです。まずは引用元のアカウントを書きますが、引用元のアカウントが撮影した写真とは限りません。そこで、引用元のコメントにあるクレジット情報を正規表現で抽出したり、写真にタグをつけたユーザー名を抽出したりすることで、可能性のあるユーザーを列挙しているようです。これも自動です。

写真をコピーされたことへの苦情どころか、「シェアしてくれてありがとう!」という反応すら来るようになったのだとか。

ハッシュタグは、一枚の写真に最大30個がつけられるそうです。知らなかった。そして、おそらく、良いタグをつけるほど広まるのにも有利なのでしょう。ということで、100個のタグ候補リストを作り、そこからランダムで30個を選びつけさせています。これも手動ユーザーにとっては面倒で徹底できないところでしょう。

また、公開後にはつけたタグとイイネの相関も調べて、人気がでそうなタグを探すということもしているとか。

成果を刈り取る

インスタグラムのダイレクトメッセージやメールで、「メインディッシュ無料にしてくれたらポジティブなレビューを投稿するよ」と提案すると、ほとんどのレストランが無料の食事やギフト券を確約してくれるそうです。多くのレストランではこういったプロモーションのための予算が取ってあり、あまりにうまくいったものだから友人や家族で手分けして食べに行ったりしたそうです。

現在は、レストランに売り込みして無料サービスを受け取るDMやメールを送るためのスクリプトも動かしているそうで、こちらも自動化達成されていますね。

さて、実際にどんな Instagram アカウントなのか気になると思いますが、@beautiful.newyorkcity がそれ。現在は3万人を越えたフォロワーがいるようですが、無料の食事にありつくにはこれぐらいで十分なのですね。

コメント欄はいつも同じような当たり障りのない事を、しかも何度も繰り返しているだけなのですが、多数のアカウントをフォローしている人は読んでないか、気にもしていないのかもしれません。「みんなが見てるよ。みんながイイネしてるよ」という状態が、さらに多くのイイネを呼び、それをプラットフォームが推薦することでさらに成長のスパイラルが加速していく、といったところでしょうか。

先週、『Instagramが「いいね!」数公開を中止を検討、群衆心理の抑制を狙う』という記事が出ていましたが、ソーシャルメディアのイイネ/Like の数は、今やこういった操作のターゲットになってしまっているのかもしれません。

via Eater

カテゴリー
技術

BugBug – 機械学習によるバグの自動トリアージ by Mozilla/Firefox

Mozilla Hacks で、2月から導入された BugBug というバグレポートの自動分類ツールの紹介が読めます。

Mozilla の様々な製品/コンポーネントに対して発行されたバグ報告を、とりあえずどの製品のどのコンポーネントに属するものかを分類して、そのコンポーネントの担当者に早く届くようにする、というのか今回のツール導入の目的だそうです。

大災害時などに負傷者の治療作業の順番をつける「トリアージ」と同様のことをバグに対して行う「バグトリアージ」というわけ。

“Teaching machines to triage Firefox bugs” より、概念図

これまではというと、ボランティアや開発者が人手でバグを分類し設定することで担当者に届けられていたのですが、ここの分類に日数が掛かっていて、バグが解消されるまでの期間が長くなっていた、と。

機械学習で分類させるには、どんなバグレポートがどのコンポーネントに対するものか、という過去の正しいデータが必要ですが、Mozilla でこれまで発行されたバグレポートは20年以上の期間での153万件を越えるそう。

これが人力でおおむね正しく分類されているので、これをXGBoostに食わせることで、新たに到着したバグレポートが属するコンポーネントの予測が自動的にできるのだそうです。

2月末に一部のプロダクトに対して導入運用を始め、350件のバグを自動分類し、そのチケットの解決までの日数の(外れ値を除いた)中央値は2日間と改善されたそう。ちなみに、今は60%の信頼度で分類して、80%以上の適合率を達成しているそうです。

今後の計画としては、重複チケットの検出、バグレポートに欠けている内容(たとえばバグの再現方法)を見つけて報告者に追加してもらう、リリース版での重要なバグを素早く発見する、などを検討しているということ。

大きな製品になるとバグレポートも膨大に届き、切り分けだけでたいへんな人的リソースを必要とするのでしょうけれど、その部分の自動化は開発側にも利用者側にも大きな恩恵を与えそうですね。

via VentureBeat