  |
はてなキーワード:dnsとは
最近のブラウザーは通信を暗号化して、プライバシーとセキュリティをより強化する機能がある。
なお、ほとんどのブラウザーでデフォルト設定はオフで、必要ならオンに変更する必要があるので注意。
オンにすると一部サイトでは海外扱いになり不具合が発生する。フレッツIPv6閉域網にもフレッツ外の扱いになるため接続できない。また、Wikipediaはプロキシ接続での編集を一切禁止しており、プロキシ扱いになるため、編集ができなくなる (編集頻度が多いなら例外設定やスマートフォンではアプリから編集するなど検討を) 。
なお、ブラウザーによってはIPv4接続でも暗号化機能をオンにするとIPv6専用ウェブサイトにアクセスできるようになる場合がある。
IPv6で接続しているかを確認したい場合は、anond:20260215110540 を参考に。
そんな機能はない。
※追記: ただし、HTTPS化されているウェブサイトをHTTPS優先で接続する設定は、この記事に記載の全ブラウザーで (Chromeでも) できる。一番下の追記1も参照。
Googleは広告会社でもあるので、プライバシー保護とは基本的に相性が悪いと考えるべきだろう。
利用者も世界最多であるがゆえのデータ量でユーザーに (プライバシーより利便性という形で)還元するという方向である。Google Mapsの渋滞表示や施設の混雑状況表示はこれで成り立っているというのがある。
なお、拡張機能でVPNは個人的にはおすすめしない。VPNアプリを使用するべきだろう。
2つのリレーを使うようになっていて、1つ目はISPからAppleへのリレー、2つ目はAppleからコンテンツプロバイダーへのリレーになっている。コンテンツプロバイダーは公開されていないが、プライベートリレーをオンにしたときに表示されるIPアドレスを見るに、Cloudflareがその1プロバイダーにふくまれているっぽい。
無料でも初期設定でメールやSafariのトラッキングコンテンツ (アクセス解析など) のみ保護してくれるが、有料プラン (2026年2月現在最低月額150円) に加入してプライベートリレーをオンにすることで、Safariでアクセスするすべてのウェブサイトが保護対象になる。
暗号化サービスとしては日本トップレベルの普及率となっているため、不具合の発生率は低め。
検索結果の精度向上のため位置情報 (GPSではなくISPによるもの) を保持するかプライバシー保護向上のため国情報のみ使用するかを選択できる。ブラウザーでradikoを再生するとかなら (エリアフリープランを除き)位置情報を保持する設定にすべきだろう。
なお、AppleのウェブサイトにIPアドレスと位置情報の一覧 (CSV) が公開されている。アクセス制御が必要なら参考にしてほしい。
https://developer.apple.com/jp/icloud/prepare-your-network-for-icloud-private-relay/
"Microsoft Edge セキュアネットワーク" という機能。Cloudflareに接続される。現時点では、PCのみ対応でモバイルでは使用できない。
個人のMicrosoft アカウントでサインインすることで、5GB / 月の容量を使用できる。保護レベルは3段階から選択でき、指定したサイト、最適化 (初期設定) 、すべてのサイトから選択する。指定したサイトとすべてのサイトはその名のとおりだが、最適化は容量を節約するため、動画視聴サイトが自動的に保護対象から除外されるなど、5GBをなるべく使い切ることがないよう、うまいこと調整してくれる。
現時点では、企業では使用不可。 "最新情報にご期待ください" とのことだが...。
"BraveVPN" という機能。Guardianに接続される。月額9ドル99セント、または年額99ドル99セントで10台まで保護できるうえに、なんとブラウザー以外も含めた全アプリを保護してくれるとのこと。
プロトコルにLightway (ExpressVPNで使用しているものと同じ) を採用しており、消費電力の少なさを売りにしている。
無料だと3地域のサーバーに接続できるが、有料プラン (月8ドル / 年48ドル) にすると30以上の国別サーバーに接続でき、ブラウザー以外も保護されるようになるとのこと。
とはいえ無料でも無制限に使用できる (この記事の中では) 唯一のブラウザーなので、Opera内だけ保護してなおかつ地域限定コンテンツも使用しないなら選択肢になる。
有料 (月9ドル99セント / 年99ドル99セント) だが日本は対象地域ではないため使用できない。
有料だが日本は現在対象地域ではないため使用できない。ただしウェイトリストに登録できる。
マルチホップ機能が使用できる。これはパフォーマンスと消費電力が犠牲になるが、2か国のサーバーにリレー接続することでよりプライバシーが保護されるという仕組み。
1つめのほうについて書いた段落は投稿してすぐに消した。それまでの間についてしまった反応だが ("この内容を登録する" を押す前に "確認する" を押さなかった自分の落ち度ではあるが) 、返信する。
2つめのほうはそれより後だが、内容がほぼ同じのためまとめて返信する。
確かにHTTPSは日常閲覧するサイトの9割 (個人差はあるが一般的な使い方の人の場合) になっており、長期間更新放置されているサイトもHTTPS化される例 (かめプロジェクトなど) が増えているため、ほとんどの人にとってはなくても困らない機能だろう。なお、ChromeであってもHTTPS化されているサイトは優先的にHTTPSで接続する設定はできる (これは本文で書き漏れていたため追記した) 。
ただ、残りの1割のサイトはいまだに暗号化が行われておらず、このようなサイトを閲覧する機会が多い人は、暗号化機能を使用する価値があると考えている。
とはいえ、そのようなサイトはプライバシーのみならずセキュリティリスクでもあるので、可能ならば避けて他のHTTPS対応サイトで代替できないかを検討するべきではあるが。
--- ここから2026-02-16 ---
ほとんどのウェブサイトは、接続元の判定ではなくトラッキング機能で判定しているため、この機能による影響はない。
ただし、Chromeを除くほとんどのインターネットブラウザーはトラッキング機能を遮断するようになっていて、そちらの機能で支障が発生することもある。ポイ活をよく使用するのであれば、暗号化機能よりむしろトラッキング防止機能をオフにするのがよい。
Safariの場合、Safari設定の "プライバシーとセキュリティ" に "サイト越えトラッキングを防ぐ" があるのでオフにする。 "詳細" に "高度なトラッキングとフィンガープリント保護" があるので、これもオフにする。 "すべてのCookie をブロック" はさすがにオフだとは思うが、もしオンになっていたらこれもオフ。
Edgeの場合は、設定の "プライバシー" に "追跡防止" があるのでオフにする。
楽天などポイ活専用アプリも提供しているところなら、専用アプリを使用するのもひとつ。
ないところなら、デフォルト設定で追跡防止をしていないChromeをポイ活専用ブラウザーにしてしまうのもひとつの方法。
なお、iOSはOSの制約上、他社のブラウザーやアプリ内ブラウザーなどにもSafariと同様のトラッキング防止機能が適用されるので、ブラウザーの設定とOSの設定の両方でトラッキングできるように設定する必要がある。これについてははてなブログ・ブックマークアプリにも影響があり、はてな公式のお知らせにも掲載があるので、こちらで設定方法を確認してほしい。
これは大正解。ただし、デフォルト設定がオフ、もしくはプライベートブラウズ限定になっているブラウザーも多いので (オフ設定でもURLのところの警告チップは出る) 、追記1に書いた1割のサイトをよく見るとかでもなければオンにすることをおすすめしたい。自分もオンに設定している。
Vivaldi もあるよ。
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）:Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）:Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml"title="RSS"href="/feed.xml">
<meta property="og:title" content="あなたの名前 |ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home /About /Posts</nav>
<footer>© 2025あなたの名前</footer>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
Route 53 の“データプレーン（DNS応答）”はSLA100% と明記されています。
ただしこれは「停止がゼロを保証」ではなく、停止があればサービスクレジットで補償するという“契約上の約束（SLA）”です。
LINEオープンチャット「はてなブックマーカー」の１週間分の要約を、さらにAIを使用し、試験的にまとめまています。
https://anond.hatelabo.jp/20240722084249
根源的に悪いのは広告業者ではあるんだけど。
軽く調べた限り、画面一番下の小さなバナー動画広告枠が表示されたらアウト。表示されない時もある。しかしこいつがCPU消費モンスター。
私のiPhone12mini (経年劣化によるバッテリー最大容量は81%)は、Togetterを開いて7分でバッテリーを10%減らした。
計測方法:画面の輝度40%くらいで、https://togetter.com/li/2610053 (JR東日本の全ての指定席券売機が...) の画面を開いて放置。51%が50%になった瞬間から、40%になった瞬間まで、当該広告ありだと7分20秒で10%減。その直後に画面下のバナー動画広告枠だけをバツ印で消して、さらに放置。41%が40%になった瞬間から、39%になった瞬間まで、当該広告なしだと34分43秒で1%減※。※バナー動画広告枠を消したら画面の自動ロックなしで放置してもぜんぜん減らないので、10%ではなく1%で計測をやめた。
iPhoneだと、はてなブックマークアプリ内のWeb表示には、Safariに入れてる広告ブロックが効かないのよね。
小さなバツ印を(精確に…)タップすればバナー動画広告枠は消えるので、気になる時は面倒でも消したほうがいいよ。
他のサイトでも起きてるとは思うんだけど、はてブやってるとTogetterをたくさん閲覧しがちなので…。
アプリをやめて、広告ブロックが効くブラウザ版のはてブを使うことも考えたけど、いろいろUIが違うからいまひとつだね。
技術的な話をすると
この広告枠は requestAnimationFrame を毎秒60回呼び出してアニメーション表示させてて、それ自体はまっとうな手法としてありうるんだけど、たぶん呼び出しのたびに余計な処理をしてるからCPUを爆食いしてしまってるんだと思う。なにやってんだか。この手のCPU爆食いはPC向け広告でも氾濫してるので、広告ブロックにはCPUやメモリの消費を抑え、発熱とファンの回転騒音を減らし、バッテリーを長持ちさせる効果もあるのだ。(追記:モバイルでは通信容量の節約もできるね)
追記:
280blockerは入れてるけど、はてブアプリ内のTogetterには効かないんだよね。月額100円/年額900円のプレミアムプランなら効くのかな？効いたという報告https://x.com/yukai_han/status/1685466299064016896 はある。これは280blockerのDNSブロック内のプレミアムプラン向け「アプリ広告専用設定」のことかな。
VPN系の広告ブロック機能だと効くような気もするけど未検証。
追記2:
ブコメ有識者のおかげでブロックできた！280blockerのDNSブロックは、280blockerアプリ内だけでなくiPhoneの設定アプリからも設定が必要https://280blocker.net/ios-dns-settings/ だったんだね…！うおお…！！！
https://b.hatena.ne.jp/entry/s/internet.watch.impress.co.jp/docs/column/horisage_qa/2035773.html
解説::HTTPSなら暗号化されてる？うんうん。でも、だれがどこにアクセスしたかはバレバレなのよ？IPアドレス暗号化してるとか思ってないよね。
エッチなサイト(うふふ)とか証券サイトみてると、フィッシングサイト狙い撃ちしやすいから気を付けようね。
起きること::セッションCookie盗まれたり、偽サイトから攻撃サイトに誘導されて釣られる。
解説::DNSでサイト乗っ取手もHTTPSの証明書エラーで気付く。うんうん。でも、HTTPSをHTTPにダウングレードされたら、あなたのCookie丸見えよ？Scureで大丈夫？サーバーのバグでアウトね。
うんうん。Cookieがダメでも、偽のHTTPサイトでリダイレクト誘導して、攻撃サイトに移動すればセキュアで保護されるので、このフローに警告なんて一切出ないね。
"こちらです"安易に踏んでない？ログインの時にドメインが完全にあってるなんて毎回検証してる？
SSL Strip攻撃といいます。AI曰く、まだまだガバガバみたいよ？
その中でHSTS導入済み: 約31%
HTTPS導入済みかつHSTS未導入: 約54-57%
DNSキャッシュポイズニングの餌食になっていたら口座開設しようとした人はもろに個人情報を盗まれることになる。
IPアドレスを書けばいいのに。サポセンに聞けば教えてくれるか？
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250718165845# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaHn+wAAKCRBwMdsubs4+SF3EAQDd3j8bZ3ULRIab+zLTUpUJIewPcHdwRFh6+KY0VpUnRgEA3f5ZIL7/MnhXiCaq15hatJDpIaVX8zva2NAszLrtxw0==OxMC-----ENDPGP SIGNATURE-----
SBIのような大手は偽サイトがつくられやすいと思うしたとえ公式のパンフレットに書いてあるアドレスもDNSがウイルスでやられちゃってて偽サイトにつながってしまう危険がある。
するとサポセンに電話して「サイトのipアドレス教えてください」って聞くぐらいしか安全な方法が浮かばないが変に思われないだろうか？
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250718010726# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaHn9vAAKCRBwMdsubs4+SETGAQC6R+LLnMOKlL1oqTakmq9DYwExaRYrM9V0k4gpac3ZxgEArGLYlV9wfpKXGh6r0hGUiQ7z5ARgPFs95410z2XsywA==F69W-----ENDPGP SIGNATURE-----
あなたがWebコンテンツの開発に関わっていないような人であれば気にしないでいいよ。みんなが専門家である必要はないのだから。
でもね、他人からお金をもらってWebサイトの公開作業やメールを使えるようにする設定をしているような人だったら、何が悪いのかを理解する努力をしたほうがいいよ。
ここやXなんかで「DNS 浸透」と検索すると「浸透言うな」と言われて反論してる人がいるけど、何で「浸透と言って何が悪いの？」とか言って感情的になる人が多いんだろうね。
こういうこと言っちゃう人は何も分かってないし、何が問題かを考えることすらしないんだよね。なんでだろうね。
最初にも書いたけど素人ならいいよ別に。勉強する必要性がないのだから。でも技術者だったらタイトルに書いた質問に答えられないのはどうかと思うよ。
表現の話じゃないんだよ。浸透の代わりに〇〇と言え、とか技術的に正確に言え、とか言っているわけじゃないんだよ。
DNSの仕組みを全く理解せずにDNSを利用していること自体が問題だって言ってるんだよ。
「浸透してないですね」とか「浸透するまで待つ必要があります」とか言って、無駄に時間を過ごしていることが問題だって言ってるんだよ。
「DNS情報が時差を伴って更新されていく」なんてことはないのよ。何年待っても更新されないんだよ。DNSの仕組み分かってる？
っていうか「更新される」って何が？
何時間か待てば自然と情報が更新されるんだったらそれでも別にいいと思うよ。でもそんな仕組みじゃないんだよDNSは。
それとね、キャッシュされてる情報を即時に更新するような形でDNS情報を変更することはできるんですよ。仕組みを理解してれば誰でもね。
そういうことを理解せずに「浸透するのに何時間も待たなければいけない」とか言っている状況自体が問題だって言ってるんだよ。
「別に技術知ってる人にはキャッシュ切れで更新される云々言えばいいけど」じゃないんだよ。キャッシュ切れを長い時間待つこと自体が間違ってるって言ってるんだよ。
あのさ、英語の表現は正しいっていう思い込みをしている人がいるみたいなんだけど、それやめたほうがいいよ。
DNS Propagation って直訳すると「DNSの伝播」なんだけど、これ「浸透言うな」の指摘に引っかかる表現そのものなんだよ。
「DNSの浸透待ち」とか「Wait forDNS Propagation」とか言わずに勉強しろよっていうのが「浸透言うな」なんだよ。
だから何が悪いかも分からないし、論点のズレた反論をいつまでも言い続けるしかできないんだよ。
・ポートフォリオのためにreact,typescriptでアプリ作成
を帰宅後や休日コツコツやってる26歳男です。現職は旅行代理店。
ビルの喫煙所で一服してたら私服の男性2名が入ってきた。このビルで私服なのはIT系の会社だけ。仮にA社とする。
喫煙所に俺とその2人の3人しか居なかった。だからA社の人達の雑談が耳に入るんだよね。
そしたら断片的だけど「DNSが〜」とか「要件が〜」とかまあ、話していたわけよ。
外部で話したらダメだろということは置いておいて、今勉強している単語たちが断片的に聞こえるわけな。
そしたら「あーならこうすればいいのか」とか「なるほどね」とかどんどん盛り上がって来ていたわけよ。課題が解決したのかな。
ただ、難しい単語だらけ。
そしてたまに聞こえる知っている単語、俺が勉強しても勉強してもよく分からない概念だったりするわけよ。
それをさも当然かのように、まるで簡単かのように話しているわけよ。
見た目は汚いおっさんなんよ。私服もヨレヨレ。無精髭生やしてさ。
けど、その難しい概念を簡単に使いこなし、それでどんどん楽しくなって行ってる(ように見える)
心が折れかけた。なんか、レベルが違いすぎた。
それでも向こうは専門職で何年もやっているだけ。そう思いたい。
そこに、スーツの若い男が入って来た。2人に混ざって雑談開始。多分新卒さんかなあ。若いし、スーツだし。
するとさ、「基本情報簡単でした」みたいなことが聞こえて来たわけよ。
なんかさ、もうさ、怖い。
なんであれが簡単になるのさ。
人種が違いすぎる。
転職、別業種にしようかな。それとも同業種への転職にしようかな。
なんかさ、もうさ、本当にさ、エンジニアさんって凄いんだね。
TLSと何もかも一緒ってわけではなくて、あくまでアナロジーでしょ
信頼の検証方法とかそういう難しい話ではなくて、トポロジー的なこと
TLSの検証の進め方は末端であるリーフ（たとえばhatelabo.jpのサーバ証明書）から中間CA、ルートCAっていう風に下から上に辿る
DNSも同じツリー形式だけど、DNSの場合はルートからリーフに向かって問い合わせをする（.に問い合わせて、jpに問い合わせて、hatelabo.jpに問い合わせる）
戸籍は下方向(子孫)はそもそも既知なことが多いから、上位(祖先)方向へ向かって辿ることが多いよね
身体を壊して先日ちょっと入院していたのだが、病院内ではWiFiが提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。
事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務に必要なサイトとかも禁止されていたので、ここにメモしておく。
通信が禁止されていると思われるサイトに接続すると、ブラウザ側ではタイムアウトのエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらくTCP handshake に失敗していそう。
正常に接続できるサイトの様子を見た範囲では、HTTPS接続の証明書改ざんは行われていないようだったことから、HTTPSの暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり、通信制限は接続先ドメインまたはIPアドレスによる判断で実施している可能性が高い。
また、中間的なサイトも存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。
謎なのは、通信が禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである。
DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動も理解できるのだが、手元のOSのネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。
もしもDNSに対するAレコード(AAAAも？）問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないかと想像するところである。
なお、消灯時間中は全てのリクエストがタイムアウトになる。消灯時間開始直前にHTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。ｽﾏｿ
業務で使う全部のサイトを検証できた訳じゃなくてゴメンね。結局のところ仕事は携帯回線でやっちゃったから。
| ドメイン | サイトの概要 | 接続の様子 |
|---|---|---|
| hatelabo.jp | はてなの実験的サービス置き場 | すんなり |
| anond.hatelabo.jp | 増田 | 禁止 |
| ??????.hatenablog.jp | はてなブログのドメインの一つ、そして増田の中の人のブログ | 遅い |
| console.aws.amazon.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えばanond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見えるclientIP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
ろくに規制も進まないで20年くらい野放図なままなんだから、広告ブロッカーを入れて各自自衛するべきだよというのは暴論ではなく非常に建設的な意見だろう。その意見だけは邪険にしないでくれ。
広告による収益化で多くのWebサービスが支えられてる時代になってしまっているのは現実だが、Webユーザーはそれを望んでるわけでも積極的に歓迎しているわけでもない。
だったらそれを拒否して無力化していく、したたかなユーザーが増えることで、Web広告が稼げない・時代にそぐわないマネタイズであるという認識と実態を広め、より建設的な、広告に依存しないWebのマネタイジング手法への移行を促していく必要があるだろう。
広告の仕組みは、あの手この手で本来顧客になり得ない人間の注意力や関心を奪い、嗜好を刷り込んでいくためにマインドハッキング的表現手法にきわめて近くなる、もともと悪質なものだ。デジタル世界ではその悪質さがより強く出る。
そういう悪質なゴリ押しが最適解になってしまうデジタル広告ではない、より健全なマネタイズをするようになったWebでは、今成り立っていたサービスでも成り立たなくなるケースが多発するだろう。
でもそれでいい。本来成り立っちゃダメな商業化が、Web広告の抱える野蛮さ、ズルさによって、成り立ってしまっている時代を終わらせなきゃいけない。
そのために抵抗が大きくなることは予測できるだろう。でもだからこそ、本当にWebの未来を真剣に考えるネットユーザーなら、Web広告を毅然と拒否しなくちゃいけない。
現実の物理世界を占有する誰かの所有物上の広告とは違い、デジタル世界では、自分の目に映るものを表示している自分が所有するコンピュータのクライアント側の描画内容は、利用者が弄れてしかるべきだろう。
弄るために十分コンピュータに造詣が深い必要はあるし、自分でその操作の責任を負う必要はあるが、そうしている限り、こうした行為は、アナログ的に目を滑らせて広告を無視することと同等の権利だ。
例えるなら、会社ロゴ入りのボールペンをタダで渡してくるのはそっちの自由だし勝手だが、それを私物として使うにあたってロゴを削り落として使う自由も勝手もこちらにある、という観点に近い。
ブロッカーを批判する人は、「そんなことするとロゴペンくれる人が悲しむよ！くれなくなるよ！削り落とさないでって規約に書いてるよ！」というロゴペンばらまき企業に同情的な人だろう。チラシ入りティッシュばらまきでもいいが。
だが、ブロッカーを使う人は、「くれなくなるなら別に構わない、もっといいペンを買うし、全員がロゴに好感を持たないことを見越してもともと迷惑ゴリ押しの自覚アリで宣伝効果を期待しばらまいているのだから、離反者が出るのも自分が離反側になる場合があるのも道理だろう」と考える。
なんらかの財物とペアにすればどんな押しつけも正当化されると考えているなら、それは非常に傲慢な姿勢だろう。宣伝効果が生じない人にまで宣伝をばらまいて不快を生じさせる至らなさの責任を末端ユーザーが背負ったり擁護したりすべきじゃないし、それを当たり前と思うのも加担になる。
ともかくそうした悪しき習慣に過剰適応してしまうインターネットしぐさが、今のWebをこんな宣伝押しつけパラダイスにした。
歩いていると3秒に1度はテッシュ配り人が動線に割り込んでくるがごとき時代に、ティッシュ内のチラシを一瞬で抜き取りペンのロゴを削り落とすテクを教え広めるのは、歪んだ現実に対する許容されるべき抵抗だろう。
ただし、広告ブロックができるソフトウェアというのは、その技術的な仕組み上、表示領域を書き換える大きな権限を持つものだ。
だから本当に信用できるところを選ばなきゃいけない。
過去には有名だった広告ブロッカーが買収され、マルウェア企業に乗っ取られたこともある(Nano Adblockerなど)。それくらい、その類のツールが持つ権限は悪意あるものにとって魅力的だ。
だから広告ブロッカーを使う人は、知らないうちに自分の使ってる拡張機能やアプリケーションの中身や母体が変化していないか、絶えずアンテナを張って情報収集をしている程度の情報リテラシーがないといけない。
営利企業によって開発・リリースされているブロッカーはそういうリスクが高いと言える。
そういう商業の香りがする母体は、ブロッカーでありながら、控えめな広告ならブロックしない方針を徐々に拡大していき、より経済力の強い広告事業者陣営に手籠めにされていくことが考えられる(Adblock Plusなど。)
だが熱心なボランティアによってフィルタ更新が行われていて、利益よりも思想を重視して運営されている、広告ブロックコミュニティにおいて信頼のおける母体もいくつかある。
個人的に2つ挙げるなら、uBlockOriginとAdguardだ。人によってはそこにBraveを加えるかもしれないが、Braveは広告モデルから脱却しているわけではなく、他社が出す広告は徹底的に消すが、Braveが出す広告を代わりに見ると仮想通貨を還元するよというビジネスで、自社で控えめな広告を出していくという点ではAdblock Plusに近い。
もちろんその仮想通貨がらみの機能を無効にして純粋な高性能ブロッカー内蔵Chromium系ブラウザとして使うこともできるが、所々信用ならんムーブをしている節があるので個人的にはおすすめしない。この分野は信用が最重要なので。
ただ、FirefoxのようなWebの理想を重視する陣営も広告に代わる有効な未来を描けているわけではなく、結局Googleにコバンザメしてその収益に依存しているので、現実的な落としどころとしてBraveのやり方を支持するという考えもあり得るだろう。
見据える未来が違うものの、結果的なブロック精度という面では、ブラウザ拡張のuBlockOrigin、スマホ用単体アプリのAdguard、それからuBlockOriginフィルタを使っているブロッカー内蔵ブラウザのBraveが三強であり、広告ブロックを期待する人がこの3つ以外を選ぶメリットはあまりないだろう。
OriginがつかないuBlockという拡張もあるが、運営母体が違い袂を分かったものでいわば偽物なので使ってはいけない。
また、Chromeは巨大デジタル広告企業Googleの息がかかっており、ブロッカーのような権限の大きな拡張機能を弱体化させる変更(Google主導のManifestV3有効化)が入ったので、高精度のブロックを望むのならChromeやEdge上でブロック拡張を使うのはいい判断ではない。uBlockOriginなどもLite版が提供されているが、どうしてもChromeを離れられない人向けの選択肢にとどまるだろう。
結論としては、
PCであればFirefox + uBlockOriginもしくはBrave、スマホのWeb閲覧であればFirefox + uBlockOriginかBrave、スマホのアプリ内広告であればAdguard foriOSやAdGuard for Android(Playストアではなく公式から落とす)でAdguardDNSを有効にすることでブロックできる。
より詳しい実用的な指南情報は、臭いサイト名だがここが一番網羅されている。なんJ AdGuard部 Wiki*
ブロックに関する是非や経緯、選び方を含む概念的・思想的な情報は、ここが参考になる。よくある質問 · Yuki2718/adblock2 Wiki · GitHub
