  |
チェックデジット理解してる？ チェックデジットは善意のユーザが一桁ないしは隣り合う数字をtypoしたときに誤りであると計算で判定できるだけで、悪意のユーザを防ぐ性質のものではないよ。誤登録の防止にはなるが、悪戯での架空番号の登録を防止できるものではない。
接種券番号の有効性確認せず何でも受け付ける以上は、Luhnアルゴだろうがdamm法だろうがチェックデジットを悪意のユーザ側で算出して付加すればいいんだから。
接種券番号の採番及び管理の運用の誤りは既に散々指摘されており、ひろみちゅ先生が言うとおり一年前の自治体での接種業務のフローを厚労省が検討する際に原因はある(ただそのタイミングでは各自治体での接種が原則で、それに基づく業務フローを決めていたので、防げたかというと怪しい)ので、システムの問題と言うより業務フローの問題。
実際は開発会社と防衛省が契約したのは2月で、そこから3か月開発期間があったわけだ スクラッチで作っても10人月レベルのシステムだが、3か月何やってたんだろうね ご機嫌取りに2か月...
むちゃいうな 学生レベルじゃないから 普通は３ヶ月だとかなりベテランじゃないと無理
それこそ ＄SQL＝＄i+$target+$hoge. exec($sql) みたいな、キモいレベルのプログラムをそうぞうしていかねない $sql=select * from table where param=xxx; レベルとかな
そのtableが存在していたりすぐに作れるなら、こんな簡単な云々の指摘は最もなんだが、それが存在しないし作るのに膨大な負荷を要するのでこんなことになってるんだよなぁ(だからひ...
立命館大の上原教授が提言してたが、個人情報突合せシステム作るよりも、予約番号をチェックデジット方式にすればかなりの悪戯や架空番号登録は防げた 政府の各省庁にもノウハウは...
チェックデジット理解してる？ チェックデジットは善意のユーザが一桁ないしは隣り合う数字をtypoしたときに誤りであると計算で判定できるだけで、悪意のユーザを防ぐ性質のもので...
根本的に各自治体に散らばってるデータを持ってないと判断できないことが多いし そんなデータを調達する時間もないって話よな
接種券番号の採番のタイミングも自治体次第(既に採番されてるのか、接種券発行時に採番なのか)なので、一回データの提供を受けて作ったところでデータの信頼性は一時的なものだし、...
まずこのレベルで、カラム数１億 １億人がざっくりターゲット ふつうPCじゃうごかないから、クラスター組むレベル かんたんにかんがえてみてそういうこと
レコード数かすまん
ダウト まずは東京都の高齢者がターゲットだからせいぜい数百万だ
レベルで見ると 開発人数は1人2人レベルで実制作期間2週間3週間レベル コーダーは高卒2年目 とかそんなあたりだろう
21
