  |
はてなキーワード: ハッシュとは
ロックに条件持たせる
やりたいことはできてるように見えるが、うーんしんどい
# Entity Relation Diagram
# ```mermaid
# ---
# title: Rental Office example
# ---
# erDiagram
# OFFICE ||--|{ ROOM : x
# OFFICE {
# number office_id
# }
# ROOM {
# number office_id
# number room_id
# }
# ROOM ||--|{ SCHEDULE : x
# SCHEDULE {
# number room_id
# datetime start_at
# datetime end_at
# }
# OFFICE ||--|{ BUSINESS_HOUR : x
# BUSINESS_HOUR {
# number office_id
# enum week_of_day
# datetime start_at
# datetime end_at
# }
# ```
# Directed Acyclic Graph
#
# ```mermaid
# graph LR
# A[OFFICE] --> B[ROOM]
# B --> C[SCHEDULE]
# A[OFFICE] --> D[BUSINESS_HOUR]
# D --> C
# A --> C
# ```
# 基底クラス: EntityLock
class EntityLock
attr_accessor :entity_name, :entity_locked, :attribute_locks
def initialize(entity_name)
@entity_name = entity_name
@entity_locked = false # エンティティ全体のロック状態を保持
@attribute_locks = {} # IDに対するロックを管理するハッシュ
end
def lock_entity
@entity_locked = true
puts "Entity '#{@entity_name}' is now locked."
end
def unlock_entity
@entity_locked = false
puts "Entity '#{@entity_name}' is now unlocked."
end
def lock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && !@attribute_locks[entity_id]
@attribute_locks[entity_id] = true
puts "#{@entity_name} with ID '#{entity_id}' is now locked."
end
end
def unlock(attributes)
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
@attribute_locks.delete(entity_id)
puts "#{@entity_name} with ID '#{entity_id}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定のIDがロックされているかチェック
entity_id = attributes["#{@entity_name.downcase}_id"]
if entity_id && @attribute_locks[entity_id]
return true
end
# ロックされていなければfalseを返す
false
end
end
# 子クラス: OfficeLock, RoomLock, ScheduleLock
class OfficeLock < EntityLock
def initialize
super("Office")
end
end
class RoomLock < EntityLock
def initialize
super("Room")
end
end
class ScheduleLock < EntityLock
def initialize
super("Schedule")
end
end
# 子クラス: BusinessHourLock
class BusinessHourLock < EntityLock
def initialize
super("BusinessHour")
@attribute_locks = [] # BusinessHour用のロックを配列で管理
end
def lock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks << [start_at, end_at]
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now locked."
end
end
def unlock(attributes)
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if @attribute_locks.include?([start_at, end_at])
@attribute_locks.delete([start_at, end_at])
puts "BusinessHour from '#{start_at}' to '#{end_at}' is now unlocked."
end
end
def locked?(attributes)
# まずエンティティ全体がロックされているかチェック
return true if @entity_locked
# 次に特定の時間範囲がロックされているかチェック
start_at = attributes["start_at"]
end_at = attributes["end_at"]
if start_at && end_at
@attribute_locks.each do |(locked_start, locked_end)|
if locked_start <= start_at && end_at <= locked_end
return true
end
end
end
# ロックされていなければfalseを返す
false
end
end
# TreeNodeクラス
class TreeNode
attr_accessor :name, :children, :parents, :lock
def initialize(name, lock)
@name = name
@children = []
@parents = [] # 複数の親ノードを保持する配列
@lock = lock # TreeNodeにロックを持たせる
end
def add_child(child_node)
child_node.parents << self # 子ノードにこのノードを親として追加
@children << child_node
end
def display(level = 0)
indent = " " * (level * 4)
puts "#{indent}#{@name}"
@children.each { |child| child.display(level + 1) }
end
def has_dependency
return false if @parents.empty?
@parents.each do |parent|
puts "#{@name} is dependent on #{parent.name}"
return true
end
@parents.any?(&:has_dependency)
end
def locked?(attributes = {})
# 自身がロックされているか確認
return true if @lock.locked?(attributes)
# 親ノードがロックされているか再帰的に確認
@parents.any? { |parent| parent.locked?(attributes) }
end
end
# 木構造の組み立て
# ロックオブジェクトの作成
office_lock = OfficeLock.new
room_lock = RoomLock.new
schedule_lock = ScheduleLock.new
business_hour_lock = BusinessHourLock.new
# ノードの作成
office_node = TreeNode.new("Office", office_lock)
room_node = TreeNode.new("Room", room_lock)
schedule_node = TreeNode.new("Schedule", schedule_lock)
business_hour_node = TreeNode.new("BusinessHour", business_hour_lock)
# ノード間の依存関係の設定
office_node.add_child(room_node) # Office -> Room
room_node.add_child(schedule_node) # Room -> Schedule
office_node.add_child(business_hour_node) # Office -> BusinessHour
business_hour_node.add_child(schedule_node) # BusinessHour -> Schedule
# 木構造の表示
office_node.display
# ロックの確認
puts "Case 1. Office全体がロックされた場合"
puts "Is office_node locked? #{office_node.locked?({})}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # false
office_lock.lock_entity
puts "Is office_node locked? #{office_node.locked?({})}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({})}" # true
office_lock.unlock_entity
puts "Case 2. Room id:1 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.lock({ "room_id" => 1 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 2 })}" # false
room_lock.unlock({ "room_id" => 1 })
puts "Case 3. BusinessHour start_at:0 end_at:5 がロックされた場合"
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # false
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.lock({ "start_at" => 0, "end_at" => 5 })
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 0, "end_at" => 5 })}" # true
puts "Is schedule_node locked? #{schedule_node.locked?({ "room_id" => 1, "start_at" => 5, "end_at" => 10 })}" # false
business_hour_lock.unlock({ "start_at" => 0, "end_at" => 5 })
まぁ、パスキー(FIDO認証)でパスワードレスの流れじゃないですかね
ビックテックが下記みたいに言ってるので
MSはご希望の個人と企業にはパスワードレスを提供してるよね(大企業は本当に大丈夫か要件と運用確認した方がいい)
ショッピングサイトはAmazonくらいしかパッと思い浮かばないけど、それを追う形になるんじゃないですかね
https://forest.watch.impress.co.jp/docs/news/1540281.html
暗号化どうたらは複合ではなく出来るのは推測
システムのログファイルにパスワードが平文で記録されているとか愉快な作りではない限り、管理者もわかりません
あれだけのプレビュー捌けるエンジニアは基本的にジャガイモではないので、基本的なセキュリティ周りでどうこうは無いと思うんですけど、
えらい人がありがたい発言をたくさんしていることでも知られてますし、面接で面接者の評価に気さくな言葉を残したりしそうな、陽気なひとたちというイメージがあると思います
例えば、カスタマー対応してる時に、ユーザーからパスワードを直接聞き出し、それをメモに残しちゃったら、ハッシュ化ガーやソルト化ガーの意味ないですよね
ハッシュ化してるから～とか言ってるけどあれは理想であって現実じゃないんよ
その手の業界で働いたらわかる
そうなってないところなんて山ほどある
特に企業相手だと一般ユーザーとは違うレベルで丁寧なサポートが必要になる
本番でそんなのいらんだろって思うレベルで全部ログを全部出してたりする
通信ログでサーバーとクライアントのやりとりを全部保持してたりするし中にはパスワードとかが入ってることだってある
そもそもハッシュ化せず生で保存していて、画面で今のパスワードが確認できる必要があるシステムだってある
以前見たものではログインできないの調査依頼に「DBにはabcというパスワードが保存されてましたがユーザーはABCというパスワードで試行してました」とかもあった
世の中そんなもんよ
安心せずに変えておいたほうがいい
ニコニコ自体はウェブ系のところである程度しっかりしてるのかなって思うこともあるけど、カドカワ関係してるし
私はプロではないのでわからないので、間違っているのは当たり前だと思って読んでください。
個々人のエンジニアの能力がとかクレジットカードがとかは基本関係ないという話です。
（関係なくてもパスワードを使い回している場合は、同じパスワードを使っているサービスのパスワードはすぐ変えるの推奨）
私は長年社内システムの奴隷をやって参りました。現在のクラウドになる前のサーバも触って参りましたので、その辺りからお話しをさせてください。
サーバーというのは、簡単に言うとシステムを提供しているコンピュータです。
貴方が触っているコンピュータシステムのネットワークの向こう側にいます。この増田も増田のサーバーというのがいて、私たちにサービスを提供してくれています。
しかし、このサーバ、どんなイメージを持っていますか？ でっかい黒い冷蔵庫？ちかちか光るロッカー？ それともバーチャルのネットワークで画面上に写されるものでしょうか。
サーバーといっても、実４形態ぐらいあるのです。私もチョットワカルぐらいなので間違っていると思いますが、まずは理解する為に簡単に説明させてください。
と言う段階があります。
ニコニコ動画のサービスはどうかというと、色々な情報を得ると、④を使いながら③にする途中で、まだ②が残っている、ということのようですね。
これらの使い分けについてですが、最近は自社でサーバを持っていると自分たちで管理しなければならなかったりして大変なので、できるだけ②から③、できたら④に持っていきたいと言うのが世の中の流れです。それでも②はのこりますが、最小限にしていく方向。
現在は、②のシステムがだけがやられたように、セキュリティ的にも預けた方が望ましいと言われています。
今回も、自社で管理している部分が攻撃されました。特にクレジットカード情報が漏れていないと何度も言われているのは、そこを自社で管理せずに専門業者に任せていたことが大きいわけです。
この流れをまずは頭に入れましょう。
さて、メールを扱ってるサーバーと、売れた商品をバーコードでピッとして管理するシステムは全く別でどちらかがハッキングされたからといってもう一つもされるこことはありません。これは何故かと言うと、それぞれを細かくたくさんのシステムや仮想サーバに別けた独立なシステムになっているからです。
さらにKADOKAWAのようにサービスを外部に展開してる会社の場合、外部向けのシステムと内部向けのもの（バックオフィス）で必要な機能が異なるので、部署が異なるのと同じように違う仕組みになっているはずです。ただし、物理的にどこにサーバがあるかなどはあまり関係がありません。
しかし、こうなると小さなサーバがたくさんたくさんあると言う状態になって管理が大変です。
利用者の視点にしても、システムごとにログインするための情報が別々だと非常に使いづらいですよね。会社で部屋ごとに別々の鍵がついていて、じゃらじゃら鍵束を持って歩くような状態は面倒です。
すると、どうするかというと、これらをまとめて管理するシステムというものが作られます。
これを「システム管理ソフト」と「認証システム」といいます。これらが全体に対してユーザ認証や、サーバが正常に動いているかどうかの管理を提供する事で、たくさんのシステムの管理を効率化するのです。
企業の警備室に機能を集約するようなものです。ですが、ここが要になっていて、破られると全ての鍵が流出してしまうということになるわけです。
出てきた情報から見ると、この管理するシステムと認証するシステムがやられたと思われます。
また、その前の前段はVPNと言う仕組み（ネットワークを暗号化して安全に隔離するもの）が攻撃されて破られたのではないかと推測しています。
これは近頃猛威を振るっている攻撃で、業務用で多く使われているVPN装置の脆弱性（弱点）が狙われて、多数の問題が起きています。当然脆弱性を修正したプログラムは適用されていると思いますが、次から次へと新たなセキュリティホールが見つかる状況であり、匿名のアングラネットでは脆弱性情報が取引されているため、訂正版のプログラムが出る前の攻撃情報が用いられた可能性があります。（これをゼロデイ攻撃といいます） あくまでも推測ではありますが。
個々のシステムは独立しています。ですが、こうなってくると、今回はシステム全体が影響を受け、さらにどこまで影響が及んでいるかの分析が困難なレベルだと言われています。
ここまで広範囲に影響するとすると、管理と認証とVPNが攻撃を受けてやられたとみるべきでしょう。
また、ここが破られていると、クラウドシステムにも影響が及ぶケースがあります。
一時期「クラウド」というとストレージの事を言うぐらい、クラウドストレージが当たり前になって、自社運用ファイルサーバは減りました。これは今では危険と認識されているほかに、こちらの方が安く利便性も高いからです。
それ故に、クラウドストレージ、たとえばSharePoint OnlineやGoogleDrive、Boxなど外部のシステムに置くようになっています。
オンプレミスの認証サーバが破られているので、その認証情報を利用してクラウドにアクセスできてしまったものだと思われます。言わば、鍵を集めて保管してあった金庫がやぶられるようなもの。
通常、クラウドシステムはそんなに甘い認証にはなっていません。例えば多要素認証といってスマホなどから追加で認証すると言うような仕組みがあります。貸金庫に入るとき、自称するだけでは入れず、身分証明書とパスワードの両方が必要なうなものです。
また、日本企業なのに突然ロシアからアクセスされたりすると警報をだして遮断する仕組みがあります。
とはいえ、いちいちクラウドにアクセスする度に追加認証をしていると大変で、面倒クサいと言う声が上がりがちです。
そんなときに行われてしまうのは、自社のネットワークからアクセスするときは、認証を甘くすると言う仕組みです。
つまり、ネットワークは安全だという仮定の下においてしまうわけですね。自社の作業着を着ている人なら合い言葉だけで、本人確認なしで出入り自由としてしまうようなものです。
ところが今回は、ここが破られてしまって被害を受けている可能性があります。自社の作業着が盗まれているので、それを着られてしまったので簡単に入れてしまったようなもの。
また、社内システムからデータを窃盗するには、どのシステムが重要かを判断しなければなりませんが、クラウドサービスだと世界共通であるため、一度入られてしまうと慣れ親しんだ様子で好きなようにデータを窃盗されてしまうわけです。
上記のことを踏まえて、KADOKAWAの展開してるサービス自体や、そこに登録しているクレジットカードは「おそらく」大丈夫です。パスワードも「ハッシュ化」という処置を経て通常は記録されていません。
ただ、パスワードを使い回している方は、その事実とは別にそもそも危険です。パスワード変更をおすすめします。さらに、ハッシュ化をされていても、時間をかければ色々な方法でパスワードを抜き出す事も不可能では無いことも忘れずに覚えておきましょう。
しかし、単なるユーザー、お客さんではなく、KADOKAWAと会社として関わってる人や従業員、取引先で色々な書類等出した人は、既に情報が窃盗されていて、そこから今後も追加で情報が出回る可能性があります。
一方で、分かりやすい場所に保存されていたわけではない情報（システムのデータベース上にだけ入っていたものなど）は、センセーショナルな形で流出したりはしないのではないかと予想しています。
犯人が本当に金が理由だとするならば、データを分析するような無駄な事に労力を割かないためです。
腹いせで全てのデータを流して、暇人が解析する可能性はあります。
ありますが、犯人はコストを回収しようとするので、これらの情報を販売しようとします。売り物になる可能性のものをただ単に流したりもしづらいのではないかと思っています。
もちろん、油断はするべきではありませんし、購入者が現れるとすると購入者は具体的な利用目的で購入するため、より深刻な被害に繋がる可能性も残されています。
犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
また、周到にソーシャルハッキング（オレオレ詐欺のようになりすまして情報を搾取するなどの方法）や、このために温存したゼロデイ攻撃（まだ誰も報告していない不具合を利用した攻撃）を駆使され、標的型攻撃（不特定多数ではなく、名指して攻撃すること）をされると、全くの無傷でいられる企業や団体は、恐らく世界中どこにも存在しません。
それは大前提とした上で、敢えて言うならば、どちらかというと、経営判断が大きいと思われます。
ニコニコ系のサービスと、KADOKAWAの業務システムと2つに別けて話しをしましょう。
ニコニコ系のサービスは、現在、クラウドにシステムをリフトアップしている最中だったと思われます。先日のAWS（クラウドサービスの大手企業）の講演会で発表があったようにです。
ですが、この動きは、ニコニコのようにITサービスを専門にする企業としては少し遅めであると言わざるを得ません。
これは何故かと言うと、ニコニコ動画というサービスが、日本国内でも有数の巨大なサービスだったからだと思われます。特殊すぎてそれを受け入れられるクラウドサービスが育つまで待つ必要があったと思われます。
それが可能になったのはようやく最近で、動画配信系はクラウドに揚げて、残りを開発している最中だったわですが、そこを狙われたという状態ですね。
ただ、厳しい見方をするのであれば、その前に、クラウドに移行する前に自社オンプレのセキュリティ対策を行っておくべきだったと思います。結果論ですが。
それをせずに一足飛びでクラウドに移行しようとしたというのだとは思います。確かに一気に行けてしまえば、自社オンプレに施した対策は無駄になります。コストを考えると、私が経営者でもそう言う判断をしたかも知れません。
KADOKAWAの業務システムですが、これはITを専門としない企業であれば、オンプレミス運用（②番）が多く残るのは普通です。
何故かと言うとシステムとは投資と費用なので、一度購入したら4年間は使わないといけないからです。そして自社向けであればそれぐらいのサイクルで動かしても問題はありません。
しかし、それ故に内部的なセキュリテ対策の投資はしておくべきだったと思います。
以上の様にエンジニアのレベルととかは関係ありません。基本的には経営者の経営判断の問題です。エンジニアに責任があるとすれば、経営者に対して問題点を説明し、セキュリティを確保させる事ができなかったと言う所にあるでしょう。
ですが、パソコンのことﾁｮｯﾄﾜｶﾙ私として、想像するのです。彼らの立場だったら…自社グループに経験豊富なエンジニアがいて、一足飛びにクラウドへリフトアップができそうなら、既存の自社サービスのセキュリティ変更に投資はしないと思います。
逆に、パソコンに詳しくなく、自社部門だけでは対応が難しく、SIerの支援を受けつつやらなければならないと言うのならば、SIerは固いセキュリティの仕組みを付けるでしょうし、システムごとにSIerが異なることから自然とシステムは分離されていたでしょう。
そして減価償却が終わった者から徐々にになるので時間がかかることから、昨今の事情により、セキュリティ変更に投資をしてからスタートしたかも知れません。
ただし、繰り返しになりますが、犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
（おそらくは）社内のシステム管理を、自社でできるからと言って一本化して弱点を作ってしまったのは不味かったと思います。
先ほど述べたように、高度化していく手口でシステムへの侵入は防ぐことが出来ません。
なので、システムは必ず破られると考えて、それ以上被害を広げないこと、一つのシステムが破られたからと言って他のシステムに波及しないようにすることなどを意識する必要がありました。
これは物理的な話しではなくて、論理的な話です。例えば物理的に集約されていてもちゃんと別けていれば問題ないし、物理的に分散していても理論的に繋がっていたら同じです。
すごく簡単に言えば、管理するグループを何個かに分けておけば、どれか一つが破られても残りは無事だった可能性があります。
とりあえず今まで出てきた内容からするとニコニコとかその他のKADOKAWAの外部的なサービスは人員的にも予算的にも全然関係ない感じ
ただ、それより前は動画見るのにログイン必要だったこともあって一部のみたいものを見るために一時的にアカ作ったかもしれないレベル
ただニコニコ初期の頃の時代はほとんど全部同じパスワードだったからアカ作ってたら危ないかもなと思うが一時的な捨て垢みたいのだったらいつものパスワードを使わなかったかもしれない
それに仮にいつものだったとしても当時使ってた他のサービスとか覚えてないからパスワード変更して回るのも難しい
パスワード漏れてるんだとして、ニコニコ初期の時代じゃハッシュ化するもそこまで当たり前じゃなかったと思うし初期の頃から変更してないユーザーは生のままで保存されてたりするんだろうか
既知のCSAMについてはハッシュ化したうえでデータベース化し、疑いのある画像とマッチングするという手法が広くとられています。
perceptual hash‐based detection
LAIONによって確度0.995以上でunsafeと判定されているサンプルを全て抽出し、画像URLをPhotoDNAで検証
マッチしたサンプルをProject Arachnid Shield APIを通してC3P (Canadian Centre for Child Protection)に検証してもらう
CSAM判定されたCLIP特徴を記録
cryptographic hash‐based detection
NCMECの保有するMD5データベースを用いてLAION-5Bに含まれるCSAMを検出
この手法は既にリンク切れになってCSAMか判別できないサンプルに対しても一定の検出を行うことができます。LAIONは各画像のMD5をまとめたものをlaion2B‐multi‐md5, laion2B‐en‐md5, laion1B‐nolang‐md5といった形で公開しており、このMD5をNCMECの保有するデータベースと突き合わせることができます。このcryptographic hash-based手法はrecallが低くなるものの、MD5の一致を見るだけで良いので50億全てのサンプルを走査することができます。
記録したCLIP特徴でk近傍法を行い、データセット全体から類似画像を検索
PhotoDNAで検証
PhotoDNAでは分からなかった画像をダウンロードし、Thornの提供するCSAM分類器で判定
あらたに認定されたCSAM画像のCLIP特徴からk近傍法を行い、上のステップを繰り返す
この類似度検索によってunsafe値に依らない検出を行うことができ、さらにPhotoDNAでマッチしない未知のCSAMも検出することができます。しかしながらC3Pでの検証は人力であり、類似画像をすべて投げるわけにはいきません。そこでThornの分類器によるフィルタリングを挟んでいます。
みつかったCSAMの特徴
あまり詳しい統計は載っていないのですが、Reddit, Twitter, Blogspot, WordPressといったCDNや、XHamster, XVideosといったアダルトサイトのドメインが含まれているようです。またサイトの特徴として"teen models"やヌード、日本の"junior idol"コンテンツが多くヒットしているとしています。
https://qiita.com/__dAi00/items/90521cc333924196a7ba
原文読んでないからそのつもりで
ビットコインマイニングは、ビットコインネットワークのトランザクションを確認し、新たなビットコインを生成するプロセスである。
これは数学的な問題を解くことによって行われる。具体的には、以下のようなステップが含まれる：
1. 新しいブロックの作成： マイナーは未確認のトランザクションから新しいブロックを作成。
2. ハッシュの計算： マイナーは新しいブロックのハッシュを計算。ハッシュ関数は、任意の長さのデータを固定長のハッシュ値に変換。ビットコインでは、SHA-256というハッシュ関数が使用される。
3. 難易度ターゲットの比較： 計算されたハッシュが難易度ターゲット以下であるかどうかを確認。難易度ターゲットは、ネットワーク全体のマイニングパワーに基づいて調整される。
4. ブロックの追加： ハッシュが難易度ターゲット以下であれば、そのブロックは有効とされ、ブロックチェーンに追加される。そして、そのブロックを作成したマイナーは新たなビットコイン（ブロック報酬）とトランザクション手数料を受け取る。
これらのステップを繰り返すことで、ビットコインマイニングは行われる。
このプロセスは競争的であり、最初に問題を解いたマイナーだけが報酬を受け取ることができる。
現代のAIはモデルって呼ばれてる奴は重みが調整された巨大なデータ構造です。
データ構造は多分ニューラルネット的なやつが一般的なのでは。知らんけど。あ、私素人ですので、あまり真面目に聞かないでください。
そんでこのモデルは入力に応じて出力が変わります。LLMなら猫っていれたら、猫について語りだして猫この特徴や可愛らしさや、猫にまつわる人間の感情についての文章が出力されるだろうし、画像生成なら猫の画像が出てきます。
モデルは多くの場合関数として振る舞うので、出力方向からこの出力結果を入力すると(お尻にバイブを刺すのと一緒です。)元の入力データが復元できます。猫にまつわる説明文を後ろから入力したら「猫」って言葉が出るし、猫の画像を後ろから入力したら「猫」って言葉が取り出せます。
画像認識AIがやっていたことが全く同じことで、画像認識AIと画像生成AIは裏表の関係になっています。
ところで人間の場合は多くの人が、猫を識別できるにも関わらず、猫の絵を描くことが出来ません。
人間の脳は、これらAIが獲得している何かの機能を削ぎ落としているようです。
なんかそのへんが一方向性ハッシュっぽさあるよなーって思った。この辺のアイディアを組み合わせたらなにか、劇的にAIの計算コストを下げれそうよね。
あとは発話とかの人類共通の計算をハードウェアにしてしまうとか、世界モデルのベースをハードウェアに落とし込むとか色々計算効率化はありそうな気がしている。
人力イラストは、目から入ってハッシュ化され脳に記録されたデータ、もしくは頑張ってハッシュを行わずに保存されてるデータからの手を使った画像復元処理って感じだろうか。
アニメとか漫画のイラストとか絵を見るとき脳の効率を使わずに気分良く見れるのは、脳内の削ぎ落とされたデータに近い形での表現だからだろうなって思いました。
こうなってくるとハッシュはいいすぎててたんに情報量を落としたデータだな。
ぐぐったら、別人のXの投稿がでてきたんだが、どういうことだ
soraもすごいと思うけどズームもパースも狂った動画を大量の計算で15秒捻出するより
Gemini 1.5がアホみたいにデカいハッシュ長を振り返って参照し類推できる技術が将来的にプロンプトの精度を高めるのも確実なわけで
方向性が異なるものを同じハコに入れてどっちが上とかいう意味はないと思うんやが— 火鍋チャンネル（ヨッピー本人） (@hinabe_ch) February 19, 2024
山本一郎（Ichiro Yamamoto） @kirik.bsky.social · soraもすごいと思うけどズームもパースも狂った動画を大量の計算で15秒捻出するより Gemini 1.5がアホみたいにデカいハッシュ長を振り返って参照し類推できる技術が将来的にプロンプトの精度を高めるのも確実なわけで 方向性が異なるものを同じハコに入れてどっちが上とかいう意味はないと思うんやが
GPT-3.5のハルシネーションでももっと意味のわかる文章生成するのに、こいつやばすぎだろ……
でかいハッシュ長って何語？参照し類推って何？プロンプト精度を高めるって何？
むかぁしむかし、2ちゃんねるにはVIPというものがあって、これはVIP待遇とかそんなものではなくて単なる掲示板の分類のひとつなんじゃが、そこにはコテハンというものがおった。
（注・今もあると思うが自分が離れて現在の状況が分からんので過去形で書いています）
トリップという、ハッシュを付けたあとに特定文字を繋げることで生成される固有IDのようなものを名前欄に入れた「固定ハンドル」、通常「コテハン」がVIPでは闊歩しており、ここまで書けば理解ると思うがワシもそのコテハンの1人じゃった。
コテハンには様々な個性があり、今で言うぶいちゅうばあのはしりとも言えるんじゃあないかと思う。
コテハン同士で論破論破したり、名無しの人生相談に乗ったり、他の掲示板に「VIPからきますた」したりなど、暇で平和で自由な世界じゃった。年末年始は積雪した駅のライブカメラアドレスを載せたスレッドを保守したり、名前欄でomikuji!したり…
（書き続けるのがだるくなったので文章はここで終わっている）
ネット投票が出来るようになったら
「はーいみんな俺の部屋に集まれ、俺の目の前で投票しろ、ふざけた真似するなよ？」
ってみんなやるよね？やらない？
他国ではそれの対策のため、後で投票し直せるようになってるらしいが、どういう仕組みなんだろ？
単純に考えると、以前の投票を取り消せるって事は誰が何に投票したかを観測できるって事でもある。
それはマズい。
マイナンバーと選挙用の秘密のパスワードのハッシュをとって、選挙専用アカウントIDとする。
しかし選挙専用アカウントを大量生産されてしまうか、あるいはパスワードを忘れたら永遠に参政権を失うかの
どちらかに転びそうでもある。
ここで考えるの面倒くさくなっちゃった。ゼロ知識とか何とかよく知らんしあーめんどくせ。stable diffusionのドスケベ絵で抜いて寝る。
