08 6 / 2014

Weʼre still not allowed to post screen shots (the rumor sites will do that anyway) and I am not sure what qualifies as a “public review”. Am I not allowed to post my opinion about a new API or is that solely meant to prevent full reviews of the entire OS before the public release?

Assuming that talking on podcasts doesn’t qualify as “write public reviews”, this is a good news :)

17 5 / 2014

Our own Jafar Husain shared how we’re using the Reactive Extensions (Rx) library to build responsive UIs across our device experiences.

Pretty impressive talk on Rx by Netflix. Looks like a great alternative to Promises, on handling asynchronous behaviors such as remote API calls and even UI elements.

Permalink 2 notes

17 5 / 2014

Great post on Python 3 and Unicode (and UNIX).

The much more likely thing to happen is that people stick to Python 2 or build broken stuff on Python 3. Or they go with Go. Which uses an even simpler model than Python 2: everything is a byte string. The assumed encoding is UTF-8. End of the story.

Hopefully there’s a lot to learn from this post on the danger of defaulting everything to UTF-8 and forcing them. Assuming utf-8 by default is another story, and I find that Golang is doing this very well.

11 5 / 2014

Rebuild.fm Live push notifications

Rebuild のライブ配信スケジュールはカレンダーやTwitterでお知らせしています。配信開始の時間にモバイル端末でプッシュ通知を受け取る方法をいくつか紹介します。

Twitter アプリの通知を有効にする

Twitter のオフィシャルアプリ iOS / Google Play がインストールされている場合、@rebuildfm をフォローして push 通知を有効にすることができます。ライブ配信の30分前や開始時にお知らせしています。

アプリから @rebuildfm アカウントを開き、設定の「通知を有効にする」を選択すればOK。

ちなみにアカウントによっては、このオプションを有効にすると初期にフォローしたアカウントのほとんどでプッシュが有効になるバグがあるようです。アプリの設定から、Notifications > Tweets でリストが管理できます。

カレンダーを登録してアラート設定する

Live ページ に iCal と Google Calendar のリンクがあるので、これを iOSカレンダーやGoogle Calendar に登録します。

デフォルトではアラート設定されていないので、システム設定から、カレンダー>デフォルトアラート設定を指定します。

iOS でカレンダー単位のデフォルトアラート設定する方法が見つからなかったのですが、他に方法があれば教えて下さい。

スクリーンショットではiOS での場合を紹介しましたが Android でも Google Calendar や Twitter 公式アプリを使って同様に設定可能です。

Permalink 9 notes

08 5 / 2014

App Links

App Links - Link to what you want, wherever you are.

Publishing App Link metadata is as simple as adding a few lines to the tag in the HTML for your content. Apps that link to your content can then use this metadata to deep-link into your app, take users to an app store to download the app, or take them directly to the web to view the content. This allows developers to provide the best possible experience for their users when linking to their content.

This looks a lot like Mobile Link Discovery i published back in 2005, to support mobile-device compatible URL (this was before iPhone) in meta tags, so that search engines can link to the mobile friendly URL before even linking to it. Google Japan’s mobile search supported it.

Twitter does App Cards with its Twitter card as well, interesting to see where this goes, although i haven’t seen much adoption of it, given the Twitter card is only supported by Twitter native apps yet.

07 5 / 2014

Covert Redirect Vulnerability with OAuth 2

tl;dr Covert Redirect Vulnerability is a real, if not new, threat when combined with Implicit Grant Flow (not Code flow)

This Covert Redirect Vulnerability in OAuth 2 is an interesting one.

There’s a couple of defending arguments that this isn’t a flaw in OAuth itself.

While I agree that it isn’t a flaw in the protocol, I think the threat is a real one, combined with a) a loose validation on redirect_uri on the OAuth provider and b) an open redirector on the client site.

What seems odd to me in the defending arguments is that they mostly focus on the “code” response_type, and it’s argued that the attack is unlikely because a) obtaining a code doesn’t complete the attack and b) the open redirector needs to keep the query parameter, which is crazy.

They’re both correct.

However what needs to be addressed here is the Implicit Grant flow, where a token is immediately sent to the client redirect URI using the URI fragment.

When redirect_uri parameter can be set to an open redirector (like Amazon/ESPN case), the token is sent to it this way:

http://provider.example/oauth?
  response_type=token&
  client_id=xyz&
  redirect_uri=http://client.example/redir%3fto=http...

which goes to:

http://client.example/redir?
  to=http://malicious.example/
  #access_token=xyz

People tend to believe that the URI fragments will be thrown away in the next redirect:

So that is all true, where it gets strange is that the browser he is using seems to pass the URI fragment in the URI through the redirector. This is not possible if the browser has not been tampered with.

It is possible with the standard behavior of the browsers.

With my experiments, current Chrome and Firefox will keep that URI fragments and access the malicious site with the fragment. W3C document suggests that sending it is the desired behavior. Safari doesn’t seem to send it, and it’s considered a bug. I haven’t tested but MS Blog suggests that IE10 preserves the fragment, matching “the updated standard documents”.

So, the victim is now redirected to http://malicious.example/#access_token=xyz.

Now, the fragment isn’t sent to the malicious site over the wire as part of an HTTP request, but once the browser gets to the page it’s game over - the site can grab the token using JavaScript via location.hash pretty easily.

Having said that, the right answer to this threat would be:

  • Strict validation on redirect_uri
  • Do not implement an open redirector on the client domain

and RFC6819 has already covered those as well.

Yes this is a FB/ESPN/Amazon problem, and No, this isn’t a design flaw in OAuth 2.0 - however, the defense argument saying “this attack is unlikely because getting a code doesn’t complete attacks” or “tokens won’t be preserved during redirects in regular browsers” is a wrong one.

Permalink 5 notes

28 4 / 2014

Daisuke Makiさん (@lestrrat) をゲストに迎えて、Go言語について話しました。

先週のダブルヘッダー分2回めを配信しました。

1つのエピソードで1つの話題ってのはちょっとひさしぶりかもしれないですね。話の流れとかも準備が必要ですが、盛り上がって楽しかったです。

配信準備だけしておいて、publishだけドイツから作業しましたが最初日付を間違えていたり、FeedpressのAPIが落ちていたりでちょっとあせりました。Note to self ですが、フィードの日付はPodcastにおいてはだいぶ重要です。間違えるとクライアントが変にキャッシュしたりする。。

UPDATE 上記に関連しますが、Apple の Podcasts.app でep42が表示されないというご意見をいくつかもらっています。ログをみるかぎり、いつもより2割程度オーディオへのダウンロードがすくない感じ。

フィード自体を削除して再購読してもらうと表示されると思います。お手数おかけします。

UPDATE2 上記は古いフィードURL (bulknews時代) を購読していた場合のリダイレクトがうまく動いていない問題でした。FeedPressがリニューアルしてここの仕様変更をしたようです。修正したので、再購読する必要なく、更新で表示されるとおもいます。

Permalink 5 notes

31 3 / 2014

Hakuro Matsudaさん (@hak)、Seiji Honmaさん (@honmax) をゲストに迎えて、Gun-Do、Anker、BatteryBox、Oculus Rift、Project Morpheus、THREEsなどについて話しました。

ゲーム業界の生き字引ことhakuroさんとhonmaxさんとガジェット、ディープなゲーム話で盛り上がりました。ライブでは若干危険な発言も飛び出していましたが、本編ではカットされています、ご了承をw

特別編 のほうもよろしくおねがいします。

Permalink 3 notes

30 3 / 2014

Naoki Hiroshima さん、Kazuho Okui さんをゲストに迎えて、将棋、スマートフォン、CarPlay、Google などについて話しました。

4月以降、旅行などで配信できないときのためにストック収録してみましたが、生配信が好評だったので有料配信してみます。どれくらいダウンロードしてもらえるかのテストです。

内容については、概要に書いてあるとおりですが、「刈谷市、昭和、見積もりについて」といったほうが近いかもしれません :)

Permalink 1 note

23 3 / 2014

Naoki Hiroshimaさんをゲストに迎えて、Two Factor Auth、iPhone、Android Wear、Hack/HHVM、将棋電王戦、2048などについて話しました。

スペシャルゲストがついに登場してくれました。

将棋とかゲートボールの話をすると文化人っぽいようですw

※ 最初の1分半ほど僕の側の録音がPCからになっていますが、すぐに治りますので、ご了承くださいませ

Permalink 4 notes