なぜ金持ちは「(生産性を下げる)労働者監視AI」に騙されるのか投稿者: heatwave_p2p 投稿日: 2025/1/142025/1/14 Pluralistic 金持ちは自分の行動に確信を持っている――と思いこむと大きな落とし穴にハマってしまう。たとえば、こんなふうに。「広告テクノロジーは人々の批判的思考をすり抜け、ビッグデータのインサイトを駆使して、人々の心を操って洗脳できるんだろう。もしそうでないなら、金持ちがそんな広告に巨額の投資をするはずがないじゃないか。」 https://pluralistic.net/2020/12/06/surveillance-tulip-bulbs/#adtech-bubble あるいは、「プライベートエクイティの略奪者たちは投資家を富ませてくれるのだろう。そうでないなら、金持ちが彼らに何兆ドルもの資金を託すはずがない。」 https://the
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 2024/09/10にIdle Detection APIというAPIが更新されていました。 ステータスはDraft Community Group Reportです。 これはコミュニティによる提案であり、W3Cによる正式な勧告ではありません。 個人や団体レベルでも、とりあえずRFCを作ってみたり検討したりできる段階ということです。 以下はこの提案を管理しているGitHubから、このRFCの意義を解説したReadmeの紹介です。 User Idle Detection API このAPIでは、開発者はユーザがアイドル状態になったとき(キ
またしてもプライバシーより自社の利益を優先したGoogle――サードパーティークッキー廃止を撤回投稿者: heatwave_p2p 投稿日: 2024/8/292024/8/29 Electronic Frontier Foundation 先週、Googleは方針を転換し、Chromeでサードパーティクッキーをブロックするという長年の約束を撤回した。この決定は、ユーザのプライバシーに悪影響を及ぼす一方、Google自身のビジネスには大変に都合がいい。サードパーティクッキーは、企業が監視や広告ターゲティングを目的として、広範囲に及ぶユーザのオンライン活動を詮索できるトラッキング技術だ。これらのクッキーがもたらす消費者への悪影響は長年にわたって詳細に記録されていて、SafariとFirefoxはすでに2020年からサードパーティクッキーをブロックしている。Googleもこの事実を認識しており
システムプラットフォームチーム SREのid:MysticDollです。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の5月号です。先月分は id:heleeen さんの Mackerel で行った障害対応演習を紹介します でした。 先月 Platform Engineering Meetup #8 にて 「はてなにおけるメール基盤とDMARC対応」というタイトルで登壇させて頂きました。 speakerdeck.com この記事では資料では紹介しきれなかった、メール送信基盤の監視で気をつけるべきSMTPのステータスの仕様とそれらを踏まえた監視方法について紹介します。 メールのステータス形式 SMTP Reply Code 1桁目 2桁目 3桁目 DSN 1つ目 2つ目 3つ目 Postfixのログからのエラーのメトリクス化 まとめ メールのステータス形式 SMTPにお
テレワーク中に従業員の作業実態を監視するための新技術を導入する雇用者が増えるなか、慢性的なサボり疑惑があった従業員をクビにした保険会社インシュアランス・オーストラリア・グループ(IAG)が“サボりの実態”を把握するために取り入れた方法とは。 「たまに買い物に行くことはありますが…」 豪保険会社IAGがサボり疑惑のあった女性の勤務実態を調査するために取り入れたのが、キーボードを打った回数を監視できるテクノロジー。 約18年勤務していたという女性は、自宅勤務をしていたここ数年で与えられたタスクが未達となる案件が目立ったため、マネージャーが女性に指導を行なうとともに勤務状況を調査。 その結果、調査した49日中、47日は就業開始時刻を守っていなかったこと、29日は就業終了時刻前にいなくなっていたこと、4日は全く仕事をしていなかったことが分かり、さらに、キーボードのキーを物理的に押した回数を計る調査
こんにちはNewsPicks SREチームの飯野です。 今年の1月入社の新入社員です。そろそろお仕事に慣れてきました。今回は研修と研修の合間に地道に行っていたCloudWatchアラームの整理について話していきたいと思います。ちょっと長くなりますがお付き合いください。 よくわからないしアラームを整理しよう まずはスプレッドシートで一覧してみよう 整理の方針を決めよう さまざまな問題をかかえたアラームたち Case#1 AlarmActionが未設定のアラーム(5個) Case#2 ActionのSNSトピックが存在しないアラーム(16個) Actionを差し替えるのはちょっと手間 Case#3 ActionのSNSトピックの通知先が退職した社員のメールアドレス(97個) Case#4 監視先のDynamoDBのテーブルがすでに存在しないアラーム(97個中の85個) Case#5 監視先のE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く