You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

リリースもされたので、考えていたことを少し書いておこうと思う。 接触確認アプリは、仕組みの説明やQ＆Aにおいて、個人情報や位置情報を収集することはないと度々説明されている。だからといって利用者の個人情報や位置情報が、不本意に第三者に漏れるといったことが起きないかというと、そういうわけでもないだろう。接触確認アプリ単体では個人情報や位置情報の収集が行われなくとも、別の第三者や企業から個人情報や位置情報が収集可能になる機会は増加する。 アプリ利用者の場合アプリを利用するユーザーの場合を想定してみよう。 接触確認アプリが普及すればするほど、Bluetoothを普段からオンにしたままにするユーザーの割合が増えることになるだろう。普段はBluetoothをオフにして必要な時だけオンにしていたユーザーは行動を変化させることになるし、今までBluetooth対応機器やビーコンを用いたサービスを使ったこと

covid19-twitter-research_01.md 生活と意見: ソーシャルディスタンスなどと称してユーザー名や文章にスペースを挟む行為についての苦情 更新履歴 2020-05-13 追記 継続して観測していて、対応が行われたアカウントの記録などを残している https://twitter.com/bulkneets/status/1259419102851903490 FAQとして「機械が人間の都合に合わせろ」に対する反論を取り急ぎ置いておく 走り書きで書いた https://twitter.com/bulkneets/status/1260524434256879617 https://twitter.com/voqn/status/1259515760986095617 記事下部に、フィードバックなどを追記した。 はじめに この文章は mala (twitter: @bul

@bulkneets だったら黙ってろクソが。

表題の件について、ソース不明の噂話や、意味を理解しないままリスクを誇張して拡散される様子を数日前から見ることができる。放っといて収まるかと思っていたらnanapiが大拡散していた。記事を書いているのはnanapiの社長であるkensuuである。時給800円のバイトかと思ったらkensuuである。 http://nanapi.jp/37983/ この件についての見解をいくつかTwitterに書いた。 まあ、全くのノーリスクというわけでも無いだろう。 正確に言えば「この設定が意味を持つような不適切な実装をしてはならない」 「表示」するだけならば、広告主や、他の広告ネットワークに対して、あなたのプロフィール画像や表示名に対してアクセスを許可する必要がない。facebook.comのiframeを使って直接Facebookから表示するだけだ。この意味がわからなかったらウェブ系の仕事に関わっているプ

わたくしは立場上、実装がダメなことにはとやかく言いますがポリシーについてはとやかく言わないことをポリシーとしており、また個人的にも所属組織的にも付き合いがある企業様を痛烈に批判するというのはブーメランとか槍とか鉄砲玉とかソーシャルメディアガイドラインとか飛んできたりしてリスキーではあるのですが、どう見てもアウトだろこれ、と考えるに至りまして筆を取らせていただく次第です。 これ http://d.hatena.ne.jp/kanose/20120306/hbmbutton http://blog.dtpwiki.jp/dtp/2011/09/post-9367.html どう見てもアウトだろ。理由は単純で、そういう目的で設置されたボタンではないし、はてなブックマークボタンが設置されているサイトは、はてなの管理してないサイトなのではてなの裁量でやってはいけないからです。いつから「はてな」は「は

Hatena::Staff Advent Calendar 2011の14日目の記事です。 こんにちは、この度ははてなブログ開設おめでとうございます。はてなとは何の関係もないmalaです。みなさん色々ありましたね、色々ありました。何を書くのか全く考えなしにネタでこの企画に応募してしまったわけですが、せっかくなのではてなのことや、インターネットのことなんかについて軽く書いてみたいと思います。 自分が初めてインターネットに繋いだのは14歳の頃でした、それ以前もパソコン通信的なものに多少触れたりすることはあったと思います。15歳の頃からPerlを書き始め、一番最初に作ったホームページはgeocitiesではなくprohostingでした。それは所謂一般的なホームページですら無く、誰でも書き換えることが可能なものでした。今で言うとwikiなのでしょうか、wikiでしょうけど当時はwikiという言葉

Explore Recent Photos Trending Events The Commons Flickr Galleries World Map Camera Finder Flickr Blog Prints The Print Shop Prints & Wall Art Photo Books Get Pro Pro Plans Stats Dashboard Get Auto-Uploadr Log In Sign Up Log In Explore Trending Events The Commons Flickr Galleries Flickr Blog The Print Shop Prints & Wall Art Photo Books Get Pro About Jobs Blog Advertise Developers Guidelines Help P

台風の災害で川に流された人が、匿名での報道を希望していたのが、NHKで実名報道された件について、家族がブログを書いた。 http://papabaka.exblog.jp/14605955/ http://papabaka.exblog.jp/14615317/ このブログの記事が広まったことに対して困惑しているブログ管理人が“それよりlivedoorニュースは何の断りもなく僕のblogを引用しての記事ですから、これってどうなのかな？と思っています。僕は個人的に拡散を望んでいないこともご理解いただければ助かります”と言っていて、それに対するのmala氏の意見。

たまたま見ていたら流れていたのでまとめました。 よくわかってません。 関連： はるかぜちゃん 非公式RTについてのポリシーを語る > http://togetter.com/li/178285

mixiが6年以上に渡って放置してきた足あと機能を使って訪問者の個人特定が可能な脆弱性を修正した。簡単に説明するとmixi以外のサイトからでもユーザーに気付かれずに、その人のmixiアカウントを特定するということが出来たが、出来なくなった。(正確にはユーザーが気付いたとしても特定された後) アダルトサイトが訪問者のmixiアカウント収集したり、ワンクリック詐欺サイトがmixiアカウント特定して追い込みかけたり、知らない人からメッセージ送られてきてURL開いたらmixiアカウント特定されてたり、そういうことが今まで出来ていたのが出来なくなった。 過去にもいろんな人が言及してるし、すでに終わった議論だと思ってる人もいるだろう。世間一般にどれぐらい認知されていたのかはよく分からないが、少なくとも技術者やセキュリティ研究者の間ではよく知られている問題だった。 http://internet.kil

http://ma.la/fb/ というのを書いたので、経緯と補足を書きます。 読むのが面倒くさい人向けに、ものすごく簡単に要約しておきます。 Facebookにはリンクを他人と共有するいいねボタン(likeボタン)というのがある。 Facebookの「ファンページ」なるものをつくると、いいねボタンを押したのが誰だか分かる機能がある。 ユーザーに気付かれないように細工したiframe内のボタンをクリックさせたりするクリックジャッキングという攻撃手法があり、いいねボタンを強制的に押させることが出来る これによって悪意のあるサイトは、訪問者のFacebookアカウントを特定することが出来る この手の問題はFacebookに限った話ではない。CSRFやクリックジャッキングで行われたアクションの結果が第三者から観測可能な全てのサービスにある。 例えば強制的にはてなブックマークさせたりはてなスターを

スペインの話なんだけど http://www.inside-games.jp/article/2011/02/15/47390.html 「脅迫事件」であるのに、犯人が何を要求していたのか分からないというニュース記事で、大変な違和感がある。そして参考リンクのAFP通信の記事を読んでも良くわからない。軽く調べた結果、任天堂スペインのなんかのキャンペーンのサイトにとてもひどい脆弱性があり個人情報を取得したハッカー(adan_geckoさん)が脆弱性の報告と共にお前のサイトは個人情報保護のための適切な手段をとっておらず犯罪なのでデータ保護当局に告発する用意がある、法的トラブルを避けるために交渉したいと電話番号書いたメールを送信、サイトは停止、adan_geckoさんがelotrolaob.netのフォーラム上で脆弱性があったこと個人情報を入手していることを告白、脅迫と受け取られてスペインのメディ

ソースをろくに確認せずに取り敢えず拡散する 自分の発言の責任が希薄になるように計算されたテンプレート 詳細はリンク先で 真偽不明ですが取り敢えず拡散 自己責任で 元情報が訂正されても、拡散した誤情報は消えない 「あなたのGmailをすべて盗まれる」問題 http://b.hatena.ne.jp/entry/jp.techcrunch.com/archives/20101120whoa-google-thats-a-pretty-big-security-hole/ http://topsy.com/jp.techcrunch.com/archives/20101120whoa-google-thats-a-pretty-big-security-hole/ http://disqus.com/guest/84d6bff45c2112e083c425e39f954f5e/ http://t

なんか技術的におかしなことを言っている人がいたら追記していくかも知れません。 クロール頻度が妥当かどうかの話 ウェブサーバーはマルチスレッド、マルチプロセスなどで複数のリクエストを同時に処理できるようになっているのが一般的であるため「前回のリクエストが完了してから、次のリクエストを投げる」実装になっている限りは「サーバーの性能を100%使いきって他の利用者が利用できない状態」になることは、通常起きません。 例外的なケースもあります。 ウェブサーバーがリクエスト完了後に何らかの処理を行うような実装になっていて、リクエストのペースによっては処理が溜まっていって追いつかなくなる。 ロードバランサ、リバースプロキシを使ったフロントエンド/バックエンドの構成になっているサーバーで、フロントエンドがタイムアウトと判断して早々にエラーを返したが実際はバックエンドで処理が続いている。 例えば1秒で処理が終

こんにちは、趣味や業務で大手ポータルサイトのサービスで稼働しているいくつかのクローラの開発とメンテナンスを行っているmalaです。 さて先日、岡崎市立中央図書館Webサイトをクロールしていた人が逮捕、勾留、実名報道されるという事件がありました。 関連URL: http://librahack.jp/ 電話してみた的な話 http://www.nantoka.com/~kei/diary/?20100622S1 http://blog.rocaz.net/2010/06/945.html http://blog.rocaz.net/2010/07/951.html この件につきまして法的なことはともかくとして技術者視点での私見を書きたいと思います。法的なことは差し置いて書きますが、それは法的なことを軽んじているわけではなく、法律の制定やら運用やらは、その法律によって影響が出る全ての人々の常識

テスト2 http://twitter.com/bulkneets/status/14709561442:twitter http://twitter.com/bulkneets/status/14709580403:twitter http://twitter.com/bulkneets/status/14709645227:twitter http://twitter.com/bulkneets/status/14710383488:twitter