Streamlining the Sign-in Flow Using Credential Management API | Web Updates - Google Developers
洗練されたユーザー エクスペリエンスを提供するには、ウェブサイトでユーザーが自身の認証を行えることが重要です。認証されたユーザーは、専用のプロファイルを使用して相互にやり取りしたり、デバイス間でデータを同期したり、オフライン中にデータを処理したりできます。このリストはさまざまな機能を備えています。しかし、パスワードの作成、記憶、入力は、エンドユーザーにとって面倒になる傾向があり、特にモバイル画面では、異なるサイトで同じパスワードを使い回してしまいます。これは当然 セキュリティリスクです Chrome の最新バージョン（51）は、Credential Management API をサポートしています。これは W3C の規格追跡案で、デベロッパーがブラウザの認証情報マネージャーにプログラムでアクセスできるようにし、ユーザーがより簡単にログインできるようにしています。 Credential M
RFC的に、HTTPヘッダってどんな値を使えるんでしたっけ？のメモ - 小野マトペの納豆ペペロンチーノ日記
Web APIを開発していると、HTTPのヘッダについてRFCにおける規約を確認しなきゃいけない場面がたまにあるので、今回調べたことをまとめた。 HTTP/1.1のRFC HTTP/1.1のRFCといえば、長らくRFC2616であったが、2014年にRFC7230〜7239が発行され、2616は廃止された。 RFC2616 ハイパーテキスト転送プロトコル -- HTTP/1.1 RFC7230〜RFC2739 HTTP/1.1 — RFC 7230 〜 7235 — 日本語訳 両者の変更点については、RFC 723xの付録に記述されているので参照のこと。Content-MD5が廃止されたり、ちょいちょい面白い。文章としても723xの方が分かりやすくなっているので、一度目を通しておくことをお勧めする。 HTTP/1.1 が更新された | The Long Wait あたらしいHTTPの話をし
Identity and Access Management - RSA 2017 Security Foundations Seminar
The document discusses identity and access management trends from the past to present to future. It covers the history of passwords and early single sign-on systems. It then summarizes key standards and protocols like SAML, OAuth, OpenID Connect, and FIDO. It discusses how these have enabled single sign-on to SaaS applications and stronger authentication. Emerging trends discussed include biometri
ブロックチェーン技術は本当に有望なのか？ - Qiita
（2017年6月時点において）ここしばらくでのブロックチェーン技術の盛り上がりには圧倒される一方で、いざ、その技術的な実装内容について調べると共に、期待と現実との間での若干のギャップにとまどうところもあります。この記事ではそうした（個人的な）とまどいの内容を、「ブロックチェーン技術の有望性」という命題を軸とする形で、簡単な解説を交えつつ共有させていただきます。 （本記事の筆者と同じく）「熱狂の只中にあるブロックチェーン技術に飛びついて良いものか？」と自問されている各位にとっての参考としていただければ幸いです。 本記事のまとめ ブロックチェーン技術の一義的な効用はビジネスネットワークへの参加者の「信用」を補完することである。そのため、既に十分な「信用」を獲得している主体によるブロックチェーン技術活用の余地には疑問符が付く。 ブロックチェーン技術の活用余地を拡大するにあたっては、ブロックチェー
App Engine アプリのコールドブート パフォーマンスを最適化する | Google Cloud 公式ブログ
編集部注 : 数か月前、Android デベロッパーとして有名な Colt McAnlis が Google Cloud の Developer Advocate チームに異動してきました。彼はすぐに、GCP アセットから最高のパフォーマンスを引き出すことをテーマとする新しい連載ブログ（および動画ブログ）、Google Cloud Performance Atlas の制作に取りかかりました。今回の投稿は彼の最初の動画ブログの要点をまとめたもので、App Engine standard environment のコールドブート パフォーマンスに関する問題を取り上げています。 ロード バランサが組み込まれている App Engine standard environment には、トラフィックの需要に基づいてインスタンスの起動や終了が行えるというすばらしい特徴があります。プロビジョニングの必
uReplicator: Uber Engineering’s Robust Kafka Replicator
You’re seeing information for Japan . To see local features and services for another location, select a different city. Show more Uber’s Analytics Pipeline At Uber, we use Apache Kafka as a message bus for connecting different parts of the ecosystem. We collect system and application logs as well as event data from the rider and driver apps. Then we make this data available to a variety of downstr
The Log: What every software engineer should know about real-time data's unifying abstraction | LinkedIn Engineering
The Log: What every software engineer should know about real-time data's unifying abstraction I joined LinkedIn about six years ago at a particularly interesting time. We were just beginning to run up against the limits of our monolithic, centralized database and needed to start the transition to a portfolio of specialized distributed systems. This has been an interesting experience: we built, dep
Amazon KMS を利用した 秘密情報管理 ruby ライブラリ Voynich
Amazon KMS を利用した 秘密情報管理 ruby ライブラリ Voynich Tweet 先日、秘密情報暗号化を管理する ruby ライブラリ Voynich を公開しました。 本記事では、Voynich の使い方と開発に至った背景を紹介します。 Voynich とは Voynich は 鍵管理に Amazon KMS (Key Management Service) を利用した秘密情報管理 ruby ライブラリです。ActiveRecord をデータの保存先として利用するため、基本的には Rails アプリケーションでのデータ暗号化に用いることを想定しています。データの暗号化には AES-GCM-256 を用いており、データの認証にも対応しています。 なぜ Voynich を開発したのか Web アプリケーションは常にセキュリティ的な脅威に直面しているので、DB に保存されている
ソシャゲ開発経験から学んだゲームに Redis を使う際の Tips
近年の KVS では割と Redis が覇権を取っていることもあり(当社比), 社内の多くのプロジェクトで Redis を使用するようになりました. ということでノウハウ的なのも溜まってきたのでまとめたいと思います. (大量のユーザーデータを扱うソシャゲにしか当てはまらない部分もあるかと思います) 単純にパフォーマンスを RDB < Redis と思い込んでとりあえずでキャッシュしない 「Redis は速い」と言われますが, インデックスをちゃんと貼った RDB のクエリも そこまで遅いわけではありません. 結局通信コストの方が遥かに大きいので内部の 取得時間差はトータルで考えると多くの場合誤差です. 特に RDB の主キーのみで取得できるようなデータを Redis にキャッシュすることに メリットはありません. キャッシュするコードを書くコストの方が高くつきます. キャッシュするのは R
Best practices for App Engine startup time: Google Cloud Performance Atlas | Google Cloud Blog
Best practices for App Engine startup time: Google Cloud Performance Atlas [Editor’s note: In the past couple of months, Colt McAnlis of Android Developers fame joined the Google Cloud developer advocate team. He jumped right in and started blogging — and vlogging — for the new Google Cloud Performance Atlas series, focused on extracting the best performance from your GCP assets. Check out this sy
Peter Bourgon · A theory of modern Go
2017 06 09 tl;dr: magic is bad; global state is magic → no package level vars; no func init The single best property of Go is that it is basically non-magical. With very few exceptions, a straight-line reading of Go code leaves no ambiguity about definitions, dependency relationships, or runtime behavior. This makes Go relatively easy to read, which in turn makes it relatively easy to maintain, wh
図面とともにあらんことを！--ShowNetのトポロジ図 (1/4) - ネットワークのゲンバ | Interop Tokyo 2013
NOC 図面担当、河口と申します。あきみち君のブログでも以前ご紹介頂きましたので、ご存じの方もいらっしゃるかもしれません。図面担当は ShowNet のトポロジ図だけではなく、ポップや壁紙もやるような、NOC チームの中でも本筋からちょっと逸れたポジションです。 本日は、そういった一見地味な仕事の目線で ShowNet 構築のゲンバのお話をしようと思います。 私が INTEROP へ初めて参加したのは学生の頃ですから、かれこれ 17 年にもなります。華々しい NOC のエリート軍団とは異なり、雑草のような私がこれほど長期に渡って採用されたのも、ひとえにこの特技：図面に熱くなれる。これに他なりません。 それが連中にバレてからというもの、なんたることでしょう。ShowNet の図面を 12 年間も引いています。 これをお読みの皆さんから見れば、INTEROP も普通のイベントとさほど変わらない
GraphQLのレスポンスJSONに対応するstructからクエリを生成できるgo-graphql-query - 詩と創作・思索のひろば
このあいだ GitHub が公開していた GraphQL API が便利そうだったので使おうと思ったのだけど、求めたライブラリがなかったので作った次第です。 ここで GraphQL についての説明はしませんが、結果の JSON とクエリが同じ形を持っているのが便利で美しいですね。ということは API の結果の JSON を受け取る struct から GraphQL のクエリが生成できるのが自然でしょう。そういうことをやってくれるシンプルなライブラリです。 GitHub - motemen/go-graphql-query API シンプルな例 ディレクティブとエイリアス 引数と変数 インラインフラグメント 複雑な例 軽い気持ちで書きはじめたところ GraphQL に予想外の表現力があることがわかったのでけっこう無理をしているところもあります。一般的にどんな使い方がなされるのかわかってない
攻略！ #PokemonGo のログインと OpenID Connect
いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。
AIを利用したシステム開発を受託したベンダが絶対に知っておくべきポイントと具体的契約条項｜知的財産・IT・人工知能・ベンチャービジネスの法律相談なら【STORIA法律事務所】
この記事は「AI法務Q＆A～AIの生成・保護・活用に関する法務Q＆A～」のうちのQ＆Aの１つです。 Q＆Aの全体像については「AI法務Q＆A～AIの生成・保護・活用に関する法務Q＆A～」をご参照ください。 「AIを利用したシステム」の開発は、これまでのシステム開発と異なる点があり、特にベンダ側が知っておくべきポイントが何点かあります。 【AIシステム開発に際してベンダが知っておくべきポイント】 １ まずは「できないこと」をはっきりさせ、ユーザーの期待値のコントロールをする ２ 成果物に関する権利の取り扱いが一番のポイント ３ 生成した学習済モデルについて蒸留行為や派生モデル生成行為をすることがOKかNGか ４ モデル生成のためにユーザーから提供を受けるデータの取り扱いに注意する ５ システム障害が生じたときの責任分担が不明確になりがちなので要注意 この記事では、ユーザーとベンダがシステム開
署名式 SRI(Subresource Integrity)の議論 - ASnoKaze blog
W3CのWeb Application Securityワーキンググループで、署名式 SRIの議論が出ていたので簡単に書く 背景 セキュリティ向上の目的で、Webページ上で読み込まれるリソース(JavaScript等)を制限する方法に、CSP(Content Security Policy)やSRI(Subresource Integrity)と言った技術がある。 CSP CSPを利用することで、読み込むJavaScriptを信頼できるURLのみに制限出来る。 CSPのscript-srcディレクティブで、以下のように制限できる。 script-src https://example.com/script/trusted.js しかし、CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of
OpenAMでOAuth 2.0 Device Flow - Qiita
Web Viewや外部のブラウザが利用できないデバイス スマートフォン上で動作するネイティブアプリや、ブラウザ上で動作するシングルページアプリケーションであれば、ユーザー認証・認可をすることができます。しかし、セットトップボックスや〇〇tvみたいなデバイスの多くはサインイン画面を表示できないため、こういったデバイス向けのインターフェースが必要となります。 UIをもたないClient向けにAccess Tokenを発行するフローがOAuth 2.0 Device Flowです。現在はドラフトスペックですが、以下に定義されています。 https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03 たぶん、説明するより図を見た方がわかりやすいと思います。 認証はResource Ownerが持っている別のUI（ブラウザなど）で行うんですが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユーザーインターフェイス解剖学（公開版）
Introducing Chaperone: How Uber Engineering Audits Apache Kafka End-to-End
MQTT とはなんだったのか
