  |
はてなキーワード:サブドメインとは
これについてもう少し詳しく調べてみましたが、sandbox化されたiframe内でパスワードマネージャがautofillする問題は2023年頃に脆弱性として報告されており、主要なパスワードマネージャでは修正されているようでした。
https://demonslayervietsub.graphy.com/
https://demonslayervietsub.graphy.com/courses/DemonSlayerKimetsuVietsub-68ac88af00a1d50ef4518995
https://demonslayervietsub.graphy.com/products/Thanh-Gươm-Diệt-Quỷ-Vô-Hạn-Thành-Vietsub-Full-HD-68ac86d6b3f6723996ddeb1d
https://cccv.to/xemdemonslayer
完全に別ドメインにした方がやはり安全ではありますが、これに関して言えばサブドメインでも即危険な状態になるわけではなさそうです。
問題2:ちょっとセンシティブなデータに投稿者がアクセスできる
上記の対策を行い、サービス上の認証の関わる部分にはアクセスができなくなったとしても、投稿者は自身がホスティングするサイトにリクエストが飛ぶようなコードを1文書けば、リクエストログからプレイヤーのIPアドレスやUser-Agentを見ることができます。
💡対策:プライバシーポリシーに書いておく
これは「サービスとして許容範囲」という判断をすることになると思います。プライバシーポリシーに「投稿者や第三者がIPアドレス等の情報にアクセスできる可能性がある」と明記しておくとトラブルが起きにくいはずです。
これについてもう少し詳しく調べてみましたが、sandbox化されたiframe内でパスワードマネージャがautofillする問題は2023年頃に脆弱性として報告されており、主要なパスワードマネージャでは修正されているようでした。
https://www.passes.com/mangmedibovietsubhd
https://www.passes.com/xemmangmedibothuyetminh
https://www.passes.com/conanvietsub
https://www.passes.com/culpatuyaizle
https://www.passes.com/siccin8fullizle
https://band.link/spermageddonespanol
完全に別ドメインにした方がやはり安全ではありますが、これに関して言えばサブドメインでも即危険な状態になるわけではなさそうです。
問題2:ちょっとセンシティブなデータに投稿者がアクセスできる
上記の対策を行い、サービス上の認証の関わる部分にはアクセスができなくなったとしても、投稿者は自身がホスティングするサイトにリクエストが飛ぶようなコードを1文書けば、リクエストログからプレイヤーのIPアドレスやUser-Agentを見ることができます。
💡対策:プライバシーポリシーに書いておく
これは「サービスとして許容範囲」という判断をすることになると思います。プライバシーポリシーに「投稿者や第三者がIPアドレス等の情報にアクセスできる可能性がある」と明記しておくとトラブルが起きにくいはずです。
これについてもう少し詳しく調べてみましたが、sandbox化されたiframe内でパスワードマネージャがautofillする問題は2023年頃に脆弱性として報告されており、主要なパスワードマネージャでは修正されているようでした。
https://www.passes.com/demonslayercastlearc
https://www.passes.com/kimetsunoyaibathai
https://www.passes.com/xemphimmuado
https://www.passes.com/phimmuadovietsub1080
https://www.passes.com/muadofullhd2025
https://www.passes.com/xemmangmedibo1080
完全に別ドメインにした方がやはり安全ではありますが、これに関して言えばサブドメインでも即危険な状態になるわけではなさそうです。
問題2:ちょっとセンシティブなデータに投稿者がアクセスできる
上記の対策を行い、サービス上の認証の関わる部分にはアクセスができなくなったとしても、投稿者は自身がホスティングするサイトにリクエストが飛ぶようなコードを1文書けば、リクエストログからプレイヤーのIPアドレスやUser-Agentを見ることができます。
💡対策:プライバシーポリシーに書いておく
これは「サービスとして許容範囲」という判断をすることになると思います。プライバシーポリシーに「投稿者や第三者がIPアドレス等の情報にアクセスできる可能性がある」と明記しておくとトラブルが起きにくいはずです。
これについてもう少し詳しく調べてみましたが、sandbox化されたiframe内でパスワードマネージャがautofillする問題は2023年頃に脆弱性として報告されており、主要なパスワードマネージャでは修正されているようでした。
https://www.passes.com/phimdemonslayer
https://www.passes.com/demonslayervietsub2025
https://www.passes.com/thanhguomdie
https://www.passes.com/xemphimmotchill
https://www.passes.com/demonslayerinfinitycastsubthai
https://www.passes.com/kimetsunoyaibathemovieinfinity
完全に別ドメインにした方がやはり安全ではありますが、これに関して言えばサブドメインでも即危険な状態になるわけではなさそうです。
問題2:ちょっとセンシティブなデータに投稿者がアクセスできる
上記の対策を行い、サービス上の認証の関わる部分にはアクセスができなくなったとしても、投稿者は自身がホスティングするサイトにリクエストが飛ぶようなコードを1文書けば、リクエストログからプレイヤーのIPアドレスやUser-Agentを見ることができます。
💡対策:プライバシーポリシーに書いておく
これは「サービスとして許容範囲」という判断をすることになると思います。プライバシーポリシーに「投稿者や第三者がIPアドレス等の情報にアクセスできる可能性がある」と明記しておくとトラブルが起きにくいはずです。
身体を壊して先日ちょっと入院していたのだが、病院内では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管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
NHK「選挙報道の在り方検討」 兵庫知事選受け稲葉会長 ｜共同通信
https://b.hatena.ne.jp/entry/s/nordot.app/1231906104544346810
？？？なんでnordot.appとかいう怪しいサイトを経由してる！！？
調べてみると、どうやら共同通信とヤフーが共同出資してるサービスらしい。
ニュースサイトがノアドットに記事を出し、キュレーターという人が記事を広め、それぞれにお金が行く仕組みらしい。
さっきのリンクで言えば、KAI-YOUの元記事が ↓ になるんだが、リンクや注釈が増えてるし。
https://kai-you.net/article/90811
共同通信の方は元記事が無かった。ノアドットがそもそも子会社だからだろうか。
間に入ったこのノアドットや、「キュレーター」という第三者に俺のアクセス履歴が共有されてるって事じゃん？
やってることはYahooニュースと同じなんだけど、あれはちゃんとひと目でそうだって分かる作りになってて、タイトルにもYahoo!ニュースって入ってるから筋は通してると思う。
でもこのノアドットの方は全然そうと分からせないようにしてるし、コソコソしてて気分悪いわ。
それにこれがはてブに出てくるって事ははてブ使ってキュレーターが金儲けしてるってことじゃん。
はてなはそれでええんか？
それともお前らがキュレーターなんか？それもユーザーから分からんよな。気持ち悪いわー。
例えばAmazonのアフィリエイトリンクなら「tag=〇〇〇-22」というクエリパラメータが付いてて明確だから良いけど、ノアドットの場合はパラメータもサブドメインも無いからなんも分からん。
ドメインの更新が来て見たところ、既にさくらインターネットとは25年以上、四半世紀以上の付き合いである事が分かった。
契約したのが16歳の時、アルバイトを始めた時に独自ドメインをとって、レンサバを借りたのがはじまりである。平日の6時間バイトで9万円弱の賃金。貯金と家に6万円入れて残り2万円のうち、その1割をレンサバ代に宛てていた計算になる。
その独自ドメインは維持し続けていて、ずっと自分の大切な連絡先になっている。
当時、ケータイのメルアドも、番号ポータビリティも始まってなくて、元々は「独自ドメインを取っておけば、一生使える連絡先になる」と思って、何も考えず.comの4文字ドメインを取得して使っている。
結果、ドメインもサーバも変更することなく今に至る。色々なサービスを使い、それぞれにサブドメインを切ったり、新しいドメインを作ったりしているが、メインはずっとさくらインターネットだ。
長年ずーっと同じプランを使っている。何年か前に新バージョンというのができた時に、契約を増やしてプライベート契約と請け負って管理しているサーバを分離したぐらいだ。
シンプルで安定していて、ほっといても管理してくれるのはありがたいことだ。しかし20何年も基本メンテナンスフリーでずっと動いてくれているのはありがたいことである。
URI（Uniform Resource Identifier）
URL（Uniform Resource Locator）
大雑把にはそんな感じ
よく、「URIって呼べよ恥かしい」みたいな人いるけど、そっちが恥ずかしいです
例えば、下記のようなURLがあったとして
https://test:testpw@hogehogefugafuga.jp/index.html:8080
①スキーム
//test:testpw@hogehogefugafuga.jp/index.html:8080
ポート ：8080
hogehogefugafuga.jp にアクセスしますよぉ、提示した情報でというもの
インターネットを作った人は全世界の人が使うようになる前提で、ややこしいhttp://を決めたのかなぁ？
こんなに使われることになるくらいならもっとシンプルなものにしてた可能性が高かったんじゃないかなと技術脳ゼロの自分は思ってしまうわけです。
すげぇシンプルです
これ以上シンプルにするって逆にどうやるの？
例えばメールサーバーには、「mx」や「mail」などのサブドメインが付きます
これに対して、webサーバーを示すサブドメインとして「www」を使ったわけです
すげぇシンプルです
利用規約にあった
問い合わせてみるといいかもしれない
(13)プライバシーに関する意見・苦情・異議申立/登録個人情報の開示
1.プライバシーに関する意見・苦情・異議申立、およびご自身の登録個人情報の開示を請求される際には、cs@hatena.ne.jpまでお問い合わせください。内容を確認後、折り返しメールでのご連絡をした後、適切な処理ができるよう努めます。
2. お問い合わせが満足に対応されなかった場合は下記のいずれかの窓口までご連絡ください。
1.TRUSTe（受付対象範囲はhatena.ne.jpドメイン（サブドメインも含む）で運営されるサービスのみです）
ウォッチドッグプログラムhttps://www.truste.or.jp/hssl/watchdog/
ここの結論を先にいうと，神奈川県公立高等学校入学者選抜インターネット出願システムなんだからドメインは shutugan.pref.kanagawa.jp か shutugan.pref.kanagawa.lg.jp などの地域型JPドメインか属性型JPドメインを使う設定をするべきであった．
これは最近問題になっているいわゆる行政サイト使い捨てドメイン問題とも関連あるし，（１次ソースにするには怪しいとしても総合的にみると載っている情報は正しそうな）カナガクhttps://kanagaku.com/archives/69495 によれば，なんと shutsugankanagawa.jp shutsugan-kanagawa.jp nyuushi-kanagawa.jp の三つとも本番環境として使われているようなのであり( nyushi-kanagawa.jp は違う)，その状況だけ見ても本物に混じって偽物がスパムやフィッシングを行っていてもほぼ見分けが付かないのである．
Googleから見ても，取得が容易なjpドメインで最近取得したドメイン，似たようなドメイン，似たようなメール，が送られてくるのである．ユーザの受信ボックス・迷惑メール・ゴミ箱に大量に届く懸念がある以上，ブロックするのが定石である．
仮にブロックせず受信ボックス・迷惑メール・ゴミ箱に届けた場合，大量送信によってユーザの使用量を圧迫し 15GB 到達すると，そのユーザは新規のメールを受信できなくなり本当に必要なメールを取りこぼす可能性がでてきてしまう（容量空ければ受信できなかったメールを受信し始めるわけではない）．
なので，大量送信SPAM 判定したメールはできる限りブロックする選択が，Gmail にとってある意味最善手なのである．
なお，神奈川県は令和 4 年度までは @pref.kanagawa.jp をメールで使っていたが令和 4 年度以降から @pref.kanagawa.lg.jp に切り替えているので，ベストは shutugan.pref.kanagawa.lg.jp であったと思われる．
サブドメイン毎にドメインレピュレーションが分かれているためあまり深い意味はないが，少なくともpref.kanagawa.lg.jp は 2007/04/16 に登録され有効なドメインなので，新規登録に比べて信頼性が高いと判断される．
なお，kanagawa.jp とkanagawa.lg.jp の切り替えもいろいろと謎はあるが，それはまた別の問題．
※webページはkanagawa.jp の方だし他方 e-kanagawa.lg.jp なんてのもあり……ちなみに e-kanagawa.jp は株式会社つくばマルチメディア登録ドメインで行政は関係ない．
少なくとも動き始めにはDKIM / DMARC が設定されておらず，問題になってから設定し始めてもそれはSPAMを頑張る業者と行動様式が似るので無駄なあがきとなっている可能性が高い．
SPF は2006年，DKIM は2011年，DMARC は2016年に出てきた対SPAM技術である．DNS 弄ったりメールサーバー建てるような人でないならこれらの設定方法は知らなくてもしかたない．
だがそれらを生業としている側の人間なら， 2024 年現在， 13 年前に提案されたDKIM すらちゃんと設定できないというのは，iPhone 4 やInternet Explorer 9 向けの開発しかわかりませんとか，スマホアプリでLINE 聞いたことないというのを2024年に言っているのと同じレベルなのである．
そのぐらい前の時代に提案された迷惑メール対策・認証系の機能を未実装で本番環境動かすというのは，語弊のある誇張表現をするならWindows Update やapt upgrade を 13年間しないで通信を試みるようなもので，自殺行為に等しい．
もちろん，その通信を受ける側はこいつヤバいやつだってすぐわかるので，かなり辛口で評価することになり，ちょっとでもSPAM の雰囲気出してきたらブロックするのは定石．
そしてブロックされたSPAM 側はあの手この手でおかまいなしにSPAM 送ろうとするので似たような内容やドメインでしつこく送ろうとするので，似たようなものもどんどんブロックするのである．
なので初手でヤバいやつ認定されないのが極めて重要にもかかわらず，そこを怠っていたのである．
実際に，2024 年 1 月12 日時点の mail.shutsugankanagawa.jp はどうなっていたかというとDKIM 設定がないまま本番環境を動かしていたようである． https://archive.md/qykwX
ここで実際いろいろ正常化しても，それはSPAM業者があの手この手でなんとしてでもSPAM 送り届けようと頑張っている様子と一緒なので，ある意味無駄なあがきなのであるどころか，SPAM認定を加速させた可能性も否定できない．
Gmail もSPAM対 策は馬鹿じゃないので，送信ドメインを変えても文面があまり変わっていないならSPAM とするし，送信元のIP とかも見てSPAM とするので，AmazonSES 使いつづけたり新IP で何回も試行するとうまくいかないし，送信元信頼性の高い送信サーバーサービス経由で送れたりするようになっても，SPAM扱いされることもよくある．
ちょっと送信に成功しだしてまたいっぱい送り出してSPAM業者扱いされるのはやっていることがSPAM業者と同じことというか，その辺の今時のSPAM業者よりSPAM業者っぽい挙動をしているのである．
今でもたまにGoogle anti-SPAM/phishing 網をくぐり抜けてくるえきねっと のフィッシングメールもびっくりするほどであろう．
Gmailユーザーへの送信ガイドラインみたいな文章は，最近の DMARC騒動で見る人が多いこのページが一番詳しいhttps://support.google.com/a/answer/81126?hl=ja .今はその騒動に応じてかなり加筆されているが，このページは開発中はどうであったのだろうか．
まず開発スケジュールについては，この開発は神奈川県の調達情報によると，調達案件番号 0001450060020230089R業務名『神奈川県公立高等学校入学者選抜統合型WEB出願システム構築及び運用・保守業務委託』で間違いないと思われ，開札日が令和5年3月31日だからプロジェクトの始動はその後だろう．
※税金使途への意識高い県民はご存じの通り，ここから誰でも調べられる https://nyusatsu-joho.e-kanagawa.lg.jp/DENTYO/P6515_10
ちょうどその頃のWeb Archive がたまたまあって 2023/03/07 時点ではこうなっていたhttps://web.archive.org/web/20230307005024/https://support.google.com/a/answer/81126?hl=ja
冒頭では
重要: 2022 年11 月より、GoogleGmailアカウントにメールを送信する新規の送信者はSPF またはDKIM の設定が必須になりました。
とさらっとメールを送信する新規の送信者はSPF 「または」DKIM の設定が必須である一方，『ドメインのメール認証を設定する（必須）』の重要のところをよく読むと，
重要: 2022 年11 月より、個人用Gmailアカウントにメールを送信する新規の送信者は、SPF またはDKIM を設定する必要があります。Google では、新規の送信者から個人用Gmailアカウント宛てのメールをランダムにチェックして、認証されたメールであることを確認します。認証方法が一つも設定されていないメールは拒否されるか、迷惑メールに分類されます。この要件は、すでに送信者である場合は適用されません。ただし、組織のメールを保護し、今後の認証要件をサポートするために、必ずSPF とDKIM を設定することをおすすめします。
のようになっていて，「今後の認証要件をサポートするために、必ずSPF とDKIM を設定することをおすすめ」など，やんわりと新規の送信者は認証しっかり 必ずSPF とDKIM を設定することをおすすめ しているのである．
こういう書かれ方しても，個人のメールサーバーとかならSPF かDKIM どっちかで運用してみてドメインを駄目にしても笑い話になるけど，自治体で運用するシステムであえて，博打に挑戦する必要あるのだろうか．
まぁ本来発注側の要件定義書とかにちゃんとSPF /DKIM を設定することなどと書いておくべき案件だったかなとは思う（たぶん書かれていなかったんだろう）．
とにかく今は全世界の3割弱がGmail と言われている中で，本当にGmail が謎仕様のブラックボックスで届かないことが多発していたら国内外もっと騒ぎになるのでGmail 側に今回の件で大きな瑕疵があったとはいいがたい．
設定不備およびその後の作業内容で地雷原を突き進んで自爆しているのだろう．
アホらしいけどアホに一番わかりやすくいえばGoogle Workspace /Gmail 同士ではIPメールサーバーのレピュテーションと無縁になれて，世界中の他の宛先にもだいたい問題なく送れるので，SPF /DKIM / DMARC の設定だけ気にすればよく，かなりシンプルなのである．
AmazonSES 使えていたんだからGoogle Workspace も不可ではないはず（ISMAPにGoogle Workspace もいるので，あとは要件しだいだけど）．
今日は花金で午後暇になったのでざっと調べて書き出したけど，去年（おそらく最小限の修正などで運用するための発注） 3,600,000円 だったシステムを，今年は全面刷新して 138,600,000 円かけたわけだけど，ちょっとさすがに値段の割にお粗末な印象がある．
まぁ入札調書の開札日付が「平成」のままになっていたりしているの見ると教育委員会側も事務方スタッフが発注前から既に疲れてるんだろうなとも思うなど，ただそういう大人の事情はともかく受験生の心情を考えると，本来あるはずのない余計なストレスを掛ける結果に，大人の一員として恐縮してしまう．
一つ思うのはこれ「一般競争入札（技術審査型）」だけど本当にちゃんと技術審査したのかね？する能力あった？安い方に安易に決めてないだろうな？？と，突っ込んでいった方が今後の神奈川県の教育環境のために遠からずなるかなと思ったけど，よく考えたら私は神奈川県民じゃなかったわ
2022-07-19
無料じゃねーの
そう頼まれてワクチン接種の予約サイトを見るが、予約に必要な「接種券番号」らしき番号が葉書にない。
如何にも作業管理用みたいな番号があるぐらいで、これでは通らなかった。
ググったら辛うじて
・「接種券と葉書は別」
・「葉書には接種権番号は書かれてない」
・「というか葉書は予約できる時期の案内だけで基本的に予約にも接種にも不要」
ということが、公式サイトとTwitterの愚痴とで理解できた。
はっきりと
「予約にに必要なのは接種券とそこに記載されている接種権番号。葉書は通知だけで予約自体には必要ない。なお接種券はコレ！（画像例）」
と明記されているところは、葉書本体・予約サイト・自治体のサイトにも一切なし
（辛うじて、ググれば自治体サイトからDL出来る予約サイトのマニュアルPDFには葉書のこと以外は記載されてた）
…… 本格的に馬鹿なんじゃないの？
他の地域でもこんな感じ？
あと(株)両備システムズが管理してるらしきhttps://v-yoyaku.jp/ のサブドメイン以下で登録するんだけど、これ、自治体による随契？
もしそうでなかったら念のため通報しておいた方がいいのかな?
アイデア料俺にくれ！
しかし今の情勢から言って、すんなりと開催に至ることはもはや不可能だろう。中止にするか、なんとしてもやるか、それぞれの派閥がバチバチになって、ポストコロナ時代にも悲しい世代間軋轢が残るだろう。
そこでだ！今のうちに祭りを「オンラインでやる仕組み」を構築して(PaaS型がいいだろう)、いざ夏の準備だ！と意気込む老若男女が祭りのことで喧嘩の果てに妥協案として「じゃあリモート開催で！」と言うときに駆け込める場所を作ってやって、ついでに金儲けもしてやろうじゃないか！
機能的には
・出店(物理的なもんは事前注文で宅配式がいいだろう！オンラインでしかできない商品なんて出れば最高だな！)
・音頭中継(ユーザーがライブで踊ってる様をシェアしてウィンドウを分割して一定時間ごとにラウンドロビンで切り替え表示できれば最高だな！)
・画面は日照を考慮した色合いに
・最後は〆のオンライン花火！(ここにイカした工夫ができれば最高だな！)
って感じか！
祭りの運営者は登録・ログインして、上記をオリジナルに差し替えも可能なテンプレートとして選択や作成していき「我が町祭りオンライン」を作成する！
各祭りのURLはサブドメインに分けて、それぞれの町祭り用のURLとする！初期版は祭り参加者のログイン機能は難しいだろう、全町の祭りにURL経由でアクセスできるようにしよう！のちのちアクセス制御したくなるだろう、ただし公共良俗を保つのが難しいかもしれないので、トレードオフの認識は必要だ！
アクセス数ランキングの後日発表はあってもいいが、イイねランキングやリアルタイムランキングはやらない！イイねやらスターはクソだ！ショボい祭りも盛大な祭りもバカにされずにドンとこいにしてぇ！そこにイイねは邪魔だぜ！
時間もねえしオープンソースだ！後ろも前も得意な奴がやろうぜ！CI/CDは詳しくねぇしドメインやらデータソースの置場所も考えなきゃなんねぇが、俺はそういう面倒はごめんだ！得意な奴やってくれよな！
個人開発記事とか見てると大体お名前.comとかでてくるけど、
ドメインって安くても維持費が1つにつき年間数百円から数千円発生するんだよね
サーバだったら最悪VPS借りて相乗りさせれば何個サービス開発しても1台分以上は料金かからなかったりするけど
人生かけてるサービスだったり一発起業目指して開発したサービスだったらともかく、
開発したサービスが当たるか当たらないかなんて予測は無理なわけで、
ドメインを取得してしまうと1年経つごとにドメイン維持費を払うか維持費をケチって潰すかの選択を迫られることになる
ユーザー投稿型のサービスで廃墟化してるなら潰す選択肢はありかもしれないけど、
クローラでデータ収集する感じのサービスやDBがなくても稼働するようなサービスだとマネタイズできてなくても小さな需要はあるかもしれなくてドメインのために潰すのもアレだし、
