スマフォのリワード広告におけるUDIDに依存しない設計案 - snippets from shinichitomita’s journal
前回のまとめ 前エントリで触れたとおり、スマートフォンのUDIDの問題点というのは、自分の把握する限り３つあった。 1. サーバとのセッションを管理するための認証に使われてしまっている 2. アプリケーションをまたがっての行動トラッキングに使われてしまっている 3. スマフォにおけるリワード広告がUDIDが取れることに依存した実装になっている。 このうち、1. に関しては代替案があり、ほぼ既存のユーザビリティを損なわない形に実装できるものなので、単に実装側の怠慢か知識不足に帰結されると感じている。今の時点でこれほど安易に使われてしまっているのは残念なことではあるかもしれないが、今後改善できる余地がある。 2. に関しては、実はデバイス固有IDであることについてはそれほどこの時点では問題ではなく、単にトラッキングされることに対してユーザの同意も拒否も介在する余地が無い、というところを問題にし
なぜiOSでUDIDが必要とされていたのか、メモ - snippets from shinichitomita’s journal
iOSやその開発事情に詳しいと言える状態にはないので、調査を兼ねて書く。 Apple Sneaks A Big Change Into iOS 5: Phasing Out Developer Access To The UDID – TechCrunch http://wirelesswire.jp/Watching_World/201108221335.html 上記の「iOSでUDIDの利用が禁止」というニュースを聞いた時、正直TL上にこんなにいっぱい反応が貼り出されるとは思っていなかった。さすがにUDIDをいじるのはまずいよね、っていうコンセンサスは開発者の間では常識的部類に入ってくるのだろうと楽観的に捉えていたのかもしれない。 以下、なぜUDIDがそのようにスマートフォン開発者に利用されてきたのかについて、調べた限りでまとめてみた。 アプリケーションのサーバとのセッション保持 い
訪問者のTwitterアカウントをWebサイトが知る方法について - snippets from shinichitomita’s journal
覚えている人もいるだろうけど、その昔、Twitterには「WWWあしあと」とも言うべき機能（というよりも欠陥に近い）があった。要は、ユーザ自身のタイムラインのツイート情報をWebブラウザ上のJavaScriptからとってこれたため、どのTwitterユーザがWebサイトに訪問しているかをまったく簡単に特定することができたのだが、残念ながらというかやっぱりねというか、Twitterがメジャーになるにつれてそのような完全プライバシー無視な機能は（おそらく良識により）排除されていった。 その後、OAuthによるアクセス承認の仕組みがTwitterより提供されることで、外部Webサイトが訪問者のTwitter上のアイデンティティ情報をオフィシャルに許された形で知ることができるようになった。これは、情報を取得する前にユーザの同意を得ることが前提なため、全てのサイトにTwitterIDが垂れ流しになっ
jsAutoPageScraperというのを作った - snippets from shinichitomita’s journal
http://coderepos.org/share/wiki/jsAutoPageScraper 概要 ブックマークレット開発などにおいて、JavaScriptでのHTMLスクレーピングを支援します。検索結果などの複数のレコードをJavaScriptの配列に変換して取得できます。ページングを利用しているサイトでは、意識することなく複数ページにまたがってレコードを取得できます。 特徴 クロスブラウザで動作します。 スクレーピングする要素の指定にはXPathを使います。IEとかSafari2の場合はJavaScript-XPathをロードして使います。 AutoPagerizeとかLDRizeのSITEINFO形式（一部）を利用できます。 使い方 1. jsAutoPageScraperをcodereposからチェックアウトし、適当なサーバにアップします svn co http://svn.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
