shi3zさんの通信上の圧縮アルゴリズム利用の認識と、big_brosさんによる指摘及び圧縮アルゴリズムの解説

スマホ回線で上位レイヤに対する不可逆圧縮が行われてしまう「通信の最適化」問題 カドカワドワンゴ川上氏を擁護するUEI清水氏の意見と、その誤りについて指摘するプログラマ吉良氏とのやりとり 圧縮アルゴリズムの特性から、通信の最適化の問題点が分かりやすいのでまとめました。 続きを読む
インターネット 通信の最適化 謝ったら死ぬ病 清水亮 天才プログラマー shi3z 圧縮アルゴリズム
196404view 124コメント
168
ツイートまとめ kadongo38氏「日本の通信事業者よりAppleやFacebook, Google の方が問題」 「通信の最適化」でモバイル通信事業者が音声や画像をトランスコード(再圧縮)などする件が話題となっています。 これついて、kawango38氏による高木浩光氏への批判と、同調する意見への批判、及び、それへの反応。 主に、通信の秘密への侵害を問題視する意見への反論。 有益な情報や喧嘩腰な発言など雑多に集めたものです。 kadongo38氏によるshi3z氏のフォローと、それ.. 83991 pv 511 111 users 141

shi3z @shi3z
権力って怖いな。ただそれを持つだけで、まるで技術が何も解ってないようなレッテルを貼られる。川上さんはビットレベルで通信プロトコルをコーディングしてそれを仕事にして成功したわけで。ただ人の実装に難癖を付けて税金もらてる高木先生とその取り巻きのコゾー共に実装の話でケチつけられるとは
shi3z @shi3z
3Dプログラミングバカだった僕が通信を学んだのは川上さんの影響なので、川上さんがこの分野(しかも低層)の技術を分かってないとかいう議論は酷すぎる。おまえらよりよほど解ってるよ
shi3z @shi3z
つうか、通信の最適化がイカン!!とか言ってる脇で帯域が圧迫され、帯域制限を設けないといけないという状況はどうでもいいのか。なんかピュアオーディオを有難がる宗教法人と大差ないので、もういっそ「最適化しません.COM(月額500万円)」とかの別のキャリアを作ればいいのではないかな
shi3z @shi3z
純金のアンテナなのでエラーレートが爆減!!ピクセル等倍鑑賞にも耐えます! みたいなことが好きな人は、それなりの金払えばいいんじゃないの?あとJPEGとかPNGとかZIPとか使うなよ。BMPで鑑賞しろ。ビットが乱れるからな
shi3z @shi3z
圧縮されるとデータが穢れる・・・という思想は、なんか日本人の根底にある差別意識っぽくて怖い。仮にも科学者なら、科学的に考えてもらいたい。まあKDDIの実装がいいのか悪いのかはしらんけど
shi3z @shi3z
JPEG使ってる時点で「綺麗な画像を見せる」ということを諦めてると思ってたんだが、世の中にはいろんな人がいるよな。ひび割れガラス球の人とか関数プログラミングの人とか
吉良理人@ねもい @big_bros
例の青卵が何者であろうと知ったことか。間違ってることは間違ってるし、アホはアホであることに変わりはない。こっちはまさにその「バイナリで会話する」プログラムを作ってるプログラマなんでな。
吉良理人@ねもい @big_bros
誰もんなこと言っとらんだろ。可逆圧縮など通信の両端で寸分違わぬデータが再現されることが担保されるなら全く文句は無いし、データを用意した側が意図をもって圧縮したもの以上の改変を加えたものを受け取らせるなと言っとるんだ。アホか。 twitter.com/shi3z/status/6…
吉良理人@ねもい @big_bros
データを圧縮することそのものの是否ではなく、データを用意した者、受けとる者の預かり知らぬ非可逆な圧縮をかけるなと言われとるわけだが。 twitter.com/shi3z/status/6…
吉良理人@ねもい @big_bros
それが可逆圧縮でありアプリケーション層で意識する必要が無いなら誰も文句言わんわい。 twitter.com/shi3z/status/6…
shi3z @shi3z
へー。僕だったら圧縮によってレイテンシーが増加することが気になりますけどね。 僕をアホというならあなたはバカなんじゃないですか? RT @big_bros: 誰もんなこと言っとらんだろ。ow.ly/2bu2D
吉良理人@ねもい @big_bros
. @shi3z 生憎とブラウザで人間が視認するケースだけを問題とはしていないのですよ。私はゲーム屋ですけども都度通信でレイテンシを気にするよりも、ローカルにキャッシュしてhash値を計算しその比較で更新があった場合のみ再取得するなど「通信頻度そのものを下げる」方法を選びますね。
吉良理人@ねもい @big_bros
. @shi3z その場合、通信の「向こう側」と「こちら側」で求めるhash値に違いがあると困るのです。データに意図しない改変が加えられると hash 値が変わってしまうので、こうした手段さえ取れなくなるのですよ。
吉良理人@ねもい @big_bros
いままで幾度となく呑み込んできた言葉だが、今回だけは言わせてもらう。 「これだからWeb屋は。」
吉良理人@ねもい @big_bros
. @shi3z おっと、もう一つ。可逆圧縮によるレイテンシは気にするのに、非可逆圧縮によるレイテンシは気にならないのですか? まさか非可逆圧縮の計算量が0だとか思ってませんよね?
吉良理人@ねもい @big_bros
俺が知る限り、可逆圧縮よりも非可逆圧縮のほうが計算量大目になりがちなのだけども。
吉良理人@ねもい @big_bros
考えるのを放棄するのは自由だが、それで賛成反対言ってんじゃないよ、という。
吉良理人@ねもい @big_bros
今の非可逆圧縮かましてるレイテンシに満足できているのであれば、それを可逆圧縮に置き換えたところで気にならんだろ。
sicrtkhs(dqx旅芸人) @shin216_bot
疑問が一つ。非可逆圧縮の場合は特定の場合を除きそのままでも問題ないけども、可逆圧縮の方は 圧縮されたデータをダウンロード→解凍は誰がする事になるの? と言う疑問・・・。
吉良理人@ねもい @big_bros
@shin216_bot アプリケーション層より下で行うべきですね。それであればアプリケーションからは生のデータが生のまま届けられたようにしか見えないので。
sicrtkhs(dqx旅芸人) @shin216_bot
@big_bros ですよね。やっぱり。そうじゃないと、色々面倒ですもんね^^
残りを読む(102)

コメント

Zetton @zetton_zetton 2015年7月16日
私、撮った写真を上げて、それをみんなに観てもらうサイト作ってるんで、JPEGを等倍鑑賞してもらってますが。写真趣味って等倍鑑賞は想定内ですから。 それと飲み会の地図とか、アナログなお店がイベント告知ポスターをJPEGで投げてくること、あるいは通りがかりがポスターをカメラで撮って「こんなイベントあるそうです」とJPEGで投げてくることがありますが、それって拡大してみないと字が読めないですが。 ってか…そんなこと書いても通じない気がする。
吉良理人@ねもい @big_bros 2015年7月16日
まとめていただきました。ありがとうございます。
sigeharucom @sigeharucom 2015年7月16日
バイナリリソースの同一性をhashで判断ってのは別にいいんだけど、「これだからWeb屋は。」という一文が全くピンと来ない。というか(以下略。@shi3z氏が高校生の頃に書いてたI/Oのびゅんびゅんポリゴンの記事をリアルタイムで貪り読んでたからかもしれないけど。当時は日本中のI/O読者の憧れだった人だし。
3mのパブリックエネミーちくわ @tikuwa_zero 2015年7月16日
他のまとめでもそうだけど、通信経路上の劣化を問題視しているのにjpgガーとか云い出すのは、もうそれだけで何も理解してないバカだってハッキリ判るよね。
angel as ㌵㌤の猫 @angel_p_57 2015年7月16日
@shi3z氏は反面教師を演じてる? それ位アレだ。
BugbearR @BugbearR 2015年7月16日
画質の劣化問題と、バイナリとしての等価性(アプリから見た時に「壊れているかどうか」の判定基準)の話を混同している人がいまだに多くて、ほんと困りものですね。「なぜ例のアプリがエラーを起こして困ったのか」という原因をいまだに理解していないのでは?
めんたろ @mentaro 2015年7月16日
shi3zサンの認識出来てなさが意外だった。
あん @ein_veilchen 2015年7月16日
なんかもう見てて呆れを通り越して可哀想になってきた
フシハラ @Fushihara 2015年7月16日
キャリア「そう、圧縮なんですよ圧縮!(元に戻せない)圧縮なんですよフフフ・・・」
48 @bleu48 2015年7月16日
老害化してる自覚ないんだろうな。きちんと基礎を学んだ方がいい。
3xv @3xv 2015年7月16日
どっちも議論が雑すぎる。 big「web屋に教えてやらぁ」 S3z「実装寄りのゲーム屋で俺の名前知らんとか」 ってお互い思ってんのでは。
きゃっつ(Kats)⊿4/28乃木坂大阪アルバム個別 @grayengineer 2015年7月16日
いくら説明しても理解してもらえなくて苦労してるのが自分だけじゃなくて少しホッとした
かつのり @k5n6 2015年7月16日
au&高木のせいで音を立てて信用が崩れていく清水&川上。発端のSBはしれっと最適化を中断という。やっぱSBは商売上手だわ。
trycatch777 @trycatch777 2015年7月16日
過去どんな偉業があったとしても関係ないですね。
倉瀬美都 @clausemitz 2015年7月16日
辞書圧縮が可逆圧縮だってわかってない時点で、続きを読むのを止めた。なんで、こんなのが天才プログラマー扱いされるんだ? (´Д` )
かつのり @k5n6 2015年7月16日
最後の捨て台詞が余計に痛々しい。問題の本質を理解した上だったらなおさら。
MJ @jaguarsan_jp 2015年7月16日
オンラインゲーでは剥ぎコラやチート防止の為のクライアント改竄チェックなんて当然の処理なんだが時代に取り残されてるんだろうな。
MJ @jaguarsan_jp 2015年7月16日
取引会社各位はshi3zにオンゲー依頼するとチート蔓延するのでやめた方が良いですよ。
とっくん @attoku 2015年7月16日
角川の人に義理があるらしいけど二人共揃ってプライドが無駄に高そうなのはなんなんだろ。IT系経営者の仕様ですかね
研究者「」@ふた学ホビコン主催 @uwemon 2015年7月16日
ホントこの件はバカのリトマス試験紙だな…
かつのり @k5n6 2015年7月16日
shi3zが馬鹿っぽく劣化して見えるのは、キャリアによる最適化のせいです!!PCでみるとまともな事言ってますよ!!
gemgraf @gemgraf 2015年7月16日
こうなったらあかん。こわいこわい。気を付けよう
M.Katsuno@メガ冷房車超党派連合 @Gvo_Tiberius 2015年7月16日
まとめは興味深いのだが、そもそも高木先生の話の主題は技術理論の話ではなくて、技術の絡んだ法律論の話だと思うんだが、清水氏は理解されているのであろうか。
たじま☆☆ @ta1210 2015年7月16日
と言うか想定されている仕様でファイルを待っている側が色々言われなアカンのか?
3mのパブリックエネミーちくわ @tikuwa_zero 2015年7月16日
その前提と結論なら、どう考えてもZIP関係ないやろwww 自分の脳味噌の劣化を自覚できないって怖いですね。オレも気をつけよう。 RT @shi3z:純金のアンテナなのでエラーレートが爆減!!ピクセル等倍鑑賞にも耐えます! みたいなことが好きな人は、それなりの金払えばいいんじゃないの?あとJPEGとかPNGとかZIPとか使うなよ。BMPで鑑賞しろ。ビットが乱れるからな
まどちん● @madscient 2015年7月16日
ひろみちゅ先生が何を問題にしてるかわからない人はNHK高校講座「社会と情報」を履修してきてね! http://www.nhk.or.jp/kokokoza/library/tv/syakaijouhou/
GEN @gent9310 2015年7月16日
作り手だと言えば素人と決めつけ、プロな証拠を出せばその仕事をディスる。老害だゆとりだって話では無く、単に人と話が出来ない人ってことでしょ。
きゃっつ(Kats)⊿4/28乃木坂大阪アルバム個別 @grayengineer 2015年7月16日
『スライド辞書法が可逆で離散コサイン変換が非可逆だってことは小学生でも知ってます。』 いや小学生は知らない。これは断言してもいい
kkitmur @kkitmur 2015年7月16日
big_brosさんが言ってるのは「送り手側と受け手側で同じデータ列じゃないと色々不便よね」というそれだけの話で、内容も「受け手側のデータが正しい(改竄したものや旧バージョンでないか)かどうか確認する」というかなり基礎的な話なんですが、shi3zさんが理解しようとしないのはほんと不思議
みそかつ @misokatu346 2015年7月16日
ぼくは、むずかしいことはわからないけどバカ発見機の性能がよくわかったよ。
BugbearR @BugbearR 2015年7月16日
画像差し替えでゲーム性が変わるということはほとんどないと考えているので、チート問題に対しては画像改竄チェックにはあまり意味がないかなぁと思っています。エロテクスチャに差し替えても、基本的には本人が見るだけだし。どちらかというと、キャッシュに古い画像が残ったままになってゲーム内容と不整合を起こす、みたいな問題の方が大きいですよね。
BugbearR @BugbearR 2015年7月16日
画像差し替えでもしかしたら大きな影響があるかも、というと、FPSで壁の向こうが見えるとかそんなところですかね。
BugbearR @BugbearR 2015年7月16日
画像劣化問題、データとしての完全性(等価性)の問題、通信の秘密という法に関わる情報の閲覧と改竄、という3つの問題があって、それぞれ分けて話さないと混乱するばかりでしょうね。
はりあ~@ワルキュリア @TNaka2011 2015年7月16日
ピクセル等倍鑑賞とか言い出してる時点で何を問題とされてるのか全く理解できていない証拠なんだなw
MJ @jaguarsan_jp 2015年7月16日
BugbearR 自社IP(知的財産)ならともかく、他社のIP借りてるアプリだと厳しいですよ。うっかりユーザーが改竄画像を上げてるのが見つかるとぶっこまれます。
MJ @jaguarsan_jp 2015年7月16日
というか発火元のangel beatsって角川のIPなんだよな… カドンゴは自分とこの問題くらい把握してから口挟めよ
Localio Projects @LocalioProjects 2015年7月16日
バイナリで話すならapplication/x-octet-streamでやれ。Webサーバの設定で手を抜くな。デフォルトインストールのサーバにアップロードされた情報がそのままエンドまで落ちてくるなんてLANぐらいで、途中経路で何があるか分からないのだから盗み見・改ざん・MITMの可能性を含めて対策をしておけ、ってHTTP上で通信するアプリ立ち上げしたWeb屋なら普通ですが。
Briareos@残弾数はいつも────── @briareos 2015年7月16日
制御系に言わせてもらえりゃ「受信したデータが送信されたデータと違う」ってのは、恐怖でしか無いんですけどね・・・
のーそふとばんく(ソフトバンクアンチ猫) @no_softbank 2015年7月16日
big_bros氏の認識は正しい。ちなみにこれは通信の秘密の問題とは別だからね。法律に当てはめるなら著作権法と思われます
るっか@週休7日していこうな! @luccafort 2015年7月16日
これだからWeb屋は!ってのだけ大変遺憾。
のりしあん @noricyan2 2015年7月16日
もう、知識とかそういう話じゃなくて、他人を馬鹿にしない、他人の意見をちゃんと聞くとかそういうことじゃないのかな
高木一郎 @takagiichiro 2015年7月16日
LocalioProjects制御のための最低限の機械的盗み見はさておき、 改ざん・MITM を通信事業者自らが行うことの是非の話ですよ。リスクに応じてHTTPに一定の信頼感を期待する事は間違いではありません。また、octet-streamだけがバイナリではありませんよ。
MJ @jaguarsan_jp 2015年7月16日
LocalioProjects 全くそのとおりですね。その思想に基づいて経路で画像が破損していた場合に取得し直すロジックが動かなくなってしまったんですよね。
きゃっつ(Kats)⊿4/28乃木坂大阪アルバム個別 @grayengineer 2015年7月16日
窃盗は犯罪ですよ、という話に対して、防犯対策やれよ、っていうのはトンチンカンな答だと思う
CV-15 Randolph @RandolphCarter 2015年7月16日
「人の話を聞きましょう」って通知簿に書かれてたタイプ
smw @Shi_MeiWo 2015年7月16日
この人は負荷逆圧縮と可逆圧縮の違いが分かってないようだなぁ。「ああああいいいいいいうう」を「あ=4い=6う=2」にするのが可逆圧縮(元に戻したときにまったく同じ=完全性がある)。2と6と4の平均は4だからなんとなく「あいう=4」にするのが不可逆圧縮(元に戻したときにまったく同じにならない=完全性がない)。で、完全性を求める場合や、よりデータを詰めるのを求める場合で、圧縮方法を使い分けるってだけの話でしょ。
qyen @9yen 2015年7月16日
「受け手が受信したデータについて正しいか検証するすべが無い」って言ってもまだ問題無いと言える技術者って一体何なんだ。
cocoon @cocoonP 2015年7月16日
Web屋に勤めてるインフラエンジニアですけど、「これだからWeb屋は。」には強く賛同いたします。
ぐらばく☪ @Grabacr07 2015年7月16日
最後の「ピクセル等倍鑑賞」で膝から崩れ落ちた
ITDOREIKUN @wtpgjmwtpgjm 2015年7月16日
君は本当にばかなんだなぁ
cocoon @cocoonP 2015年7月16日
ただ、ひろみちゅ先生も非可逆圧縮は圧縮とは言わないとか技術的に詳しくないAUのサポートにねじこんだりしててかなりおかしいことを言ってたし手段が目的化してたりしてたので今回の騒動はほんと発端からおかしい。上のレイヤでペイロードをいじくるんじゃねえよってこと自体は大賛成なんだけども。
BugbearR @BugbearR 2015年7月16日
あぁ、著作権法の同一性保持権の問題もありますね。画質の劣化、バイナリ等価を、著作権法上の同一性の問題として捉えてよいのかというのはあるかも知れませんが。
Localio Projects @LocalioProjects 2015年7月16日
grayengineer 「ここは窃盗が頻発しているのでやればすぐできる簡単な防犯対策してください!」に「窃盗は犯罪なのでノーガード戦法で!」がトンチンカンなのと同じ話ですね。犯罪の有無に関係なく、手抜きはただの手抜きですし、HTTP通信はけっこう昔から魑魅魍魎が跋扈している世界です。送信者が送信したデータに変更不可指定がついていないから付けろ、って難しいことでしょうか。
Localio Projects @LocalioProjects 2015年7月16日
画面表示用データとファイル保存用データの区別がヘッダで付く以上、自分が委任した相手(au)が画面表示用の画像データを端末(SHF31 Androidガラホ)の寸法に合わせて加工する分にはまったく気にしない(契約時にも見落としはしていない)。てか、自分で合法的に実装できるものを業者に委託した途端に犯罪とか言われたら反乱ものですよ。
かえでこ @KaedekoSakura 2015年7月16日
たぶんこれ、著作権だの改変だの混じったからおかしくなってるんで、単純に「アプリ層でデータの同一性が保障できない」って話にすれば良いと思うんだけど。バイナリレベルで「違う」ことが当然となった場合、途中の経路で何かされたとき、それがキャリアの仕事なのか、悪意ある第三者なのか、アプリ層で判断できない。
Chack'n @Chackn 2015年7月16日
「これだからWeb屋は。」は今年の流行語候補(ならないな
cocoon @cocoonP 2015年7月16日
「実際にソシャゲで問題が起きたから騒ぎになったのだ」ということを知らずに首を突っ込み、「『土管屋風情が観念的におかしいと騒いでんじゃねー』みたいにWeb屋がタカをくくってる」という構図なんだよねこれ。大手町と渋谷の対立は根強い。
クマ @Strike__Noir 2015年7月16日
擁護してる方は自分の立場が惜しいから、わざと論点をずらしてるのか、ホントに○○だから、理解してないのか。 学校でちょっとかじった程度で、本職ですらない自分でも、おかしいのは分かる。 キャリア側の言い分も分からんではないが、少なくともバイナリレベルでの同一性が保証されるのが本来だと思う。
CV-15 Randolph @RandolphCarter 2015年7月16日
最後の一言が完全に笑わせに来てて卑怯。
scribe @scribe_is_here 2015年7月16日
著作権関連の指摘が上がってるように、Web屋こそこんな「最適化」されたら憤死するとこ出ますよいやマジで。
きゃっつ(Kats)⊿4/28乃木坂大阪アルバム個別 @grayengineer 2015年7月16日
対策するなと言ってる人、だれかいました?
なちゃ @nachakey 2015年7月16日
んーそもそもコンテントタイプがJPEGならデータを変えていいとかいう決まりってあるんだっけ? httpで通信内容を不可逆に変えてもいいという決まりとか。
うにら @riafeed 2015年7月16日
k5n6 え???中断どころか最適化は必要でかつ正当業務行為であり、利用者でon/offできる仕様にはなっていないと明確に返答してるようですけど、7月序盤にあったらしい中断は設備のメンテナンスではないかという話ですね http://togetter.com/li/847657 http://news.livedoor.com/article/detail/10351449/
なちゃ @nachakey 2015年7月16日
あとコンテントタイプのJPEGは閲覧用で保存ファイル用ではないなんて決まりは聞いたことがない。 ファイル保存したいならコンテントタイプJPEGは使ってはいけないの?
かつのり @k5n6 2015年7月16日
なーんだ、ただのメンテだったのか・・・。
なちゃ @nachakey 2015年7月16日
清水氏についてはね、たぶんこの人技術的に本当に理解できてないわけ無いと思うよ、そんな素人ではない。 まあ、パフォーマンスだろうね。 正直失敗してる気がするけども。
うにら @riafeed 2015年7月16日
nachakey httpの仕様は読んでないのでアレだけど多分変えるなとも変えていいとも書いてないんじゃないかなぁ。というか仮にあったとしてもただのプロトコルなので拘束力がないし(httpの仕様に反してはいけないという法律があるならともかく)通信が成立してる以上(あの件だって通信に関しては成立していると解釈されるはず)httpどうこうという話で攻めるのは難しいんじゃないかなぁ。
なちゃ @nachakey 2015年7月16日
riafeed 私も確認してないけど書いてないんじゃないかという気がしてて、でも書いてないならそれは常識的に変えていいわけがないから、と思うのよね… 変えていいなら書いてあるはず。
なちゃ @nachakey 2015年7月16日
清水氏に話が通じないのは、むしろ技術的には理解してるからだと思うよ。まともに乗るとその方向では反論できなくなるから。
なちゃ @nachakey 2015年7月16日
まあ確かにhttpレベルでどうという話ではないかな、ちょっと判断つかないですね。
猿田彦 @saru_ta_hiko 2015年7月16日
懐かしなぁ。昔、自然画像用の可逆圧縮特許を取ったけど誰も使ってくれずにお蔵入りしてるおいらが通りますよ。とほほ。
kamm @kammjp 2015年7月16日
「これだからWeb屋は。」には全然腹が立たないなあ。むしろ同感しちゃう
まさゃん(17) @DrFaust 2015年7月16日
清水さんこれは恥ずかしいなぁ。問題の捉え違いしてますよ。
[。╹◡╹。]@シロ組🐬🍁🍀🎶@まがつ待機 @epuboro 2015年7月16日
まとめ方に悪意を感じる、これじゃあ清水氏が完全に池沼じゃん
Briareos@残弾数はいつも────── @briareos 2015年7月16日
「テータを送受信するとその完全性が保証されない(可能性が高い)回線」ってのは、システム構築あるいはアプリ実装をする側から見ると、品質レベルどころじゃないんですがねぇ・・・ まぁ清水某氏の視点は「その後」にあるようなので、回線がどうのなんてどうでもいいじゃん的なお考えをお持ちなのでしょうが
近藤 和宏 @kondoujp 2015年7月16日
epuboro この件に関してはかなりとんちんかんな事を言っているので、その辺が入っていない分かなり好意的なまとめだと思いますよ。
MISSION QUEST @mission_quest 2015年7月16日
素朴な疑問。 この問題って「運送屋が人から『輸送してくれ』と預かった荷物を途中で壊したのに受け取り主が気付かなきゃいいやと素知らぬふりして渡してた(しかも運送量もらってた)」事が問題になってるのに、「途中で壊されてもいいじゃん」なんて言いだす擁護者が後から後から湧いてきてる。 何故? 自分の荷物じゃないから気にしてない?
和泉 @IZUMI162i6 2015年7月16日
c2031844 で、対策したスマホアプリが動かなくなって(MITM攻撃を受けてるので処理されないのが正常な動作)攻撃者=キャリアがけしからんって話したら、MITMを想定してない方が悪いみたいな話になっててワケワカメ。
うにら @riafeed 2015年7月16日
briareos さすがにキャリアの最適化が正しいかどうかとは全く関係なくアプリ実装者がキャリアの最適化(画像等の不可逆再圧縮)を技術的に回避できません(する方法がわかりません)って本気で言ってるような状態だったら技術力を疑っちゃいますが。
なちゃ @nachakey 2015年7月16日
そもそも最適化の仕様が公開されてないので確実な回避方法はないんじゃないの?とか、例えば技術的に回避できるブラウザアプリケーションて作れる?とか色々あるよね… 出来ないじゃなくて、本来不要なそんなことをしなければならなかったり、条件によって技術的にも回避不能だったりするから問題なんだと思うけどね。
なちゃ @nachakey 2015年7月16日
あと、変更不可マークがついてないから変更されてもいい、変更不可マークつければいいって言ってるけど、変更不可マークってなんだろう… httpやmimeにそんな仕様あったっけ?変更不可マークがなければ変更していいなんて仕様あったっけ?
かつのり @k5n6 2015年7月16日
事の発端のtogetterにも書いたけど、自分もCRC32チェックで弾かれるトラブルがあって、色々と対策しました。 簡単に言うとZIPファイルと同じ4バイトのヘッダをファイルの先頭に付けて、application/octet-streamで送るようにしました。
かつのり @k5n6 2015年7月16日
このファイルは何?というソリューションの場合、大抵はヘッダかmime-typeのチェックです。なので確実にZIPファイルとしか見えないと思います。実際に勝手にgzip圧縮もされませんし画像圧縮もされませんでした。 サーバ側は特定のURLパラメータが含まれる場合、nginxのconcatモジュールでZIPのヘッダのみのファイルを先頭にマージして返すようにし、クライアントは特定のURLを付与した上で4バイトスキップしてダウンロードです。
かつのり @k5n6 2015年7月16日
こんなことしなくても、一番手っ取り早いのはSSLを使うことですが・・・
高木一郎 @takagiichiro 2015年7月16日
普段問題解決にいろいろ工夫をこらしている習慣かもしれませんが、下位レイヤが信用出来ないために上位レイヤで工夫をしなければならない時点で間違っているんですよ…。キャリアが通信の最適化をするならば、上位のアプリに影響を与えないようにするべきで、それは上位レイヤでは両端で1ビットも変化しないことが大前提です。
うにら @riafeed 2015年7月17日
takagiichiro 今回の件や通信に限らず下位レイヤーを信用しすぎて痛い目を見るのはよくあることです、間違ってるかと言われれば間違ってるんだろうけど言ったところですぐに直るわけではありませんから工夫を凝らすしかないんですよね…
tgt @tgtanm 2015年7月17日
通信容量の削減の為に画像の再圧縮なんてAirH"の時代から普通にキャリアによく使われてる手法だし、確かに多少画質が劣化はするが騒ぎになる前は誰も気にしてない上に、糞デザイナがq=95とかで生成したどうでもいい背景画像などを適切な容量に節約してくれて素晴らしい機能なんだが。むしろ、それをキャリアレベルでリアルタイムで行う困難さから、過去のairH"時代なんかは有料Optionだった気さえする。
tgt @tgtanm 2015年7月17日
それよりも、問題になったゲーム製作者がhash値がずれて困るという主張はわかるものの、ゲームの画像cache(おそらく大量の数をDLするであろうもの)をhttpで律儀に1ファイルずつgetしてる設計のほうにセンスの悪さがにじみ出てる。httpのオーバーヘッドが無駄すぎるし、packして署名なりhash計算してたらそもそも画像最適化の対象外になるだろ。 shi3zは好きじゃないが、これはさすがにかわいそうだ。
2chmate @2chmate_ 2015年7月17日
気に入るとか気に入らないとかじゃなくて「違法」だって話なのに
tgt @tgtanm 2015年7月17日
「違法」って騒いでるやつが多いだけで実際に「違法」って判断はされてないよね。形式上の同意はあるわけだし。
高木一郎 @takagiichiro 2015年7月17日
riafeed はい。そうですね。しかたなくそうするというのはよくわかります。甘んじて受け入れず同時にクレームも言う。特に、これまで正しかったものを誤った変更をされそうなときには、強くクレームしてやめさせるべきだということですね。中間での書き換えが何時何時発生するかわからない状況になるのでは、平文TCP全体の信頼が地に落ちて使い物にならない。漠現在の適用範囲もいつ変わるかわかりませんし。
高木一郎 @takagiichiro 2015年7月17日
tgtanm 困難さではなくて、上位層のデータ変更は上位層で扱う原則に従った素直な実装で、そのほうが正しいからでしょう。
高木一郎 @takagiichiro 2015年7月17日
tgtanm 実装の詳細は公開されていないのではないですか。独自クライアントなのでmultipartで送ってる可能性も考えられますし、一部ファイルがそうなだけな可能性もあります。設計が悪いと断定できるような情報が公開されていたのでしょうか。いずれにしてもサーバーで創出したものと同じファイルが届くことをHTTP期待する実装自体は悪くないでしょう。すくなくともこれまでの常識では。
近藤 和宏 @kondoujp 2015年7月17日
tgtanm どちらかというと、その「形式上の同意」が「個別的かつ明示的な同意に当たる」かどうかの判断の方が出ていない、だと思いますが。
MarriageTheorem @MarriageTheorem 2015年7月17日
滅茶苦茶言ってる技術者(に限らず専門職の人間)が「分かっているけど立場上そう言えない」のか「本当に分かっていない」のか判断できない場合、「本当に分かっていない」と扱って差し上げるのが流儀では。それが嫌ならポジショントークを止めて見に徹すればよいのだし。
なちゃ @nachakey 2015年7月17日
tgtanm どう見てもわら人形だし意味ないと思う。 個別にリクエストしても問題ない数かも知れないし、パイプラインでやってるかもしれんし、仮にセンス無かったとしても、センスがないから正常に動かなくても文句言うななんて無茶苦茶だわな。
なちゃ @nachakey 2015年7月17日
目的によって、まっとうに制御可能なオプション機能ならここまで文句言われんしうまく使えば便利ってのは事実だけと、なぜか養護する人はアプリ実装側の技術力がどうとかセンスがどうとか、変な方向に行くよね。
NO NAME @ytkumasan 2015年7月17日
これをみてて…9月のLet’s Encryptの一般リリースにいろいろ殺到する悪寒が強くなりました。 https://letsencrypt.org/
きゃっつ(Kats)⊿4/28乃木坂大阪アルバム個別 @grayengineer 2015年7月17日
こちらに、このコメント欄で指摘されているような問題も含めて細かく順序立てて説明されています →  「通信の最適化」に関する高木浩光氏の見解 http://togetter.com/li/848342
うにら @riafeed 2015年7月17日
nachakey アプリ実装側の技術力云々の話はそう言われるだろうと思ったから「最適化が正しいかどうかとは全く関係なく」って前置きしたのに擁護したことになっちゃうんですね。
うにら @riafeed 2015年7月17日
回避できるのだからキャリアの最適化にクレームをつけるなと言ったつもりはないしそういうスタンスでもないのでじゃんじゃん文句言えばいいと思いますよ。筋違いっぽいクレームは逆効果だからやめたほうがいいとは思いますけど。
Briareos@残弾数はいつも────── @briareos 2015年7月17日
riafeed その「回避方法」が「今後もずっと使える」のならいいのですけど、実際には回線業者が任意に仕掛けた仕組みなので、事業者側が任意のタイミングで勝手に変更されることもあるわけで、そういう業者って信用に足るんだろうか?という疑念しかないんですね。またこれと平行して法律的にどうのこうとのとか各自の視点とかいろんな要素があるんで、一層話がややこしい(だからこそ紛糾するんでしょうが
なちゃ @nachakey 2015年7月17日
riafeed すみません、擁護と書いたのは思い違いでした。ただ、正直これは技術的に回避できるとは言い難いと思う。そもそもどうしようもないパターンがある時点で回避できてない。
kkitmur @kkitmur 2015年7月18日
「これは正しい行為か」という話において「こういう技術的問題が発生する(発生した)から正しくない」としているのに対して「回避できる問題である」という対処可能性の話をするのはズレを感じますね
うにら @riafeed 2015年7月18日
nachakey 現在わかってる範囲では「技術的には」不可逆圧縮の対象ではないデータに見せかければ概ね回避できるはずですしSSLで通信すれば間違いなく回避できるはずなんですがどうしようもないパターンとは具体的にどういうものなのでしょうか?
なちゃ @nachakey 2015年7月19日
アプリって別にサーバもクライアントも自分で好きにできるものに限定されるもんじゃないわけで。 きちんと元の画像を表示できるブラウザアプリを作りたい→作れない。 画像をきちんとダウンロードするアプリを作りたい→作れない。 自分の管理範囲のサーバ前提だということでしょうけど、前提作ってる時点でつまりそういうことよねということです。
deepskyblue99 @deepskyblue99 2015年7月19日
画像中の文字列 「@shi3z」 が圧縮経路を通すと 「@shi3z(アホ)」 に見えるような魔法のような画像を用意できたら完全勝利なんじゃないすかね
うにら @riafeed 2015年7月19日
nachakey サーバー側で一切対応できないなら事前に画像ファイルには見えない形にエンコードしたファイルをアップロードすればいいですし(特定の形式以外アップロードを認めないレンタルサーバも誤魔化しようはあるので)、ブラウザアプリもデコードした上でそのdata-uriをcanvasなりimg要素なりにJavascriptで流し込めばIE8以下以外の今時のブラウザは対応できるはず(base64で送ってしまうのが一番手間が省けるかな)どこまでするかは個々の状況によるけど。
なちゃ @nachakey 2015年7月19日
いやいや自分でアップロードしたファイルしか使わないって前提すらないわけで。 自分の管理外のファイルをダウンロードすることは普通にあるわけで、そういう場合にクライアント側だけでは対処不能なわけで。 そういう場合を除くなら、あくまで除けば回避できるという前提つきでしかないという話ですよ。 自分の管理範囲のファイルしか扱わないものしかアプリと呼ばないとかなら知りませんが。
なちゃ @nachakey 2015年7月19日
技術的に回避できるかという話なのでいろんな回避策出てますけど(それ自体はそういう話をしているわけで別に文句あるわけではないのですが)、でも率直にこんな回避策を使うってあほですよね。 BASE64で送るとかなったら、もう無駄な通信とかどこいったのって話。 単にこういう方法もあるっていう話なのは分かっているので、馬鹿にしているのではありません。
高木一郎 @takagiichiro 2015年7月19日
「概ね回避できるはず」概ねじゃダメでしょう…。
うにら @riafeed 2015年7月21日
nachakey でも率直にこんな回避策を使うってあほですよね>どうしても回避したいのにクレーム付けるだけ付けていつ行われるのか全くわからない最適化をやめるのを待つ(別にクレーム付けるなといってるわけではない)なんてのはありえないんですけどね。
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2015年7月21日
riafeed 急場しのぎのクイックハックは当然やるにしても、それでは問題の解決にならないという話では。
うにら @riafeed 2015年7月21日
mtoaki なにをもって問題解決かにもよりますけどキャリアが最適化の撤回をすることが問題の解決とするなら結局クレーム付けてキャリアが対応するまで急場しのぎするしかないですよね(どうしても最適化が許容できないのなら)
うにら @riafeed 2015年7月21日
nachakey そこまでいくと管理する人と交渉するしかないですね(一応間にProxyをかまして中継する手もあるにはあるけど)、まぁそれすらできないレベルで管理外としたら技術的には全く関係ない方向で問題が発生するんじゃないかなと思いますけど。
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2015年7月21日
riafeed そこはもう議論するまでもない事だから誰も問題にしてないのでは。
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2015年7月21日
じっさい問題発覚の契機になったゲームは原因を特定してすぐに対策したわけだし。
うにら @riafeed 2015年7月21日
mtoaki 元々「技術的に」そういった急場しのぎが出来ない(する方法がわからない)って本気で言っちゃう人がいたら技術力疑っちゃうなーって話なのでそれに異論がないのなら別に何も問題ないです。
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 2015年7月21日
riafeed 利用者の大半は技術のない一般人だから、大半の人は急場しのぎもできないと思いますけど。
うにら @riafeed 2015年7月21日
mtoaki あぁ、それはアプリ実装者に向けた話です、アプリ制作に関係ない一般の方には言っていません。誤解を招いてしまって申し訳ないです。
まどちん● @madscient 2015年7月25日
riafeed エンドポイントでは技術的に「キャリアによる通信の最適化」なのか「中間者攻撃による改竄」なのかって見分ける方法は無いよ。
ゆるまき( ・ㅂ・)و ̑̑ツイ減? @jasminheimatlos 2015年8月3日
徹頭徹尾ハッシュの話が通じない壁…
u1ρ ⛅ @u1p 2016年12月6日
「お友達が苛められてる!! 僕が助けなきゃ!!」的なマヌケな擁護をするのは、この人の習性なのかな?w http://anond.hatelabo.jp/20161203120714
齊藤明紀 @a_saitoh 5月6日
tgtanm AirH”の圧縮は無料だったような記憶があるのですが、 ぼくの覚え違いかなぁ?Windows用の常駐プログラムで圧縮率が選べましたね。スピード重視なら、見て分かるほど劣化するほどの圧縮も選べた。
ログインして広告を非表示にする
ログインして広告を非表示にする