アカウント名:
パスワード:
そういう答えをしてはいけません。 将来セキュリティーホールが塞がれて、自分の首を締める事になります。 素直に「仕様上できません」と言うのが吉
# 何とかすればとりあえず動くと言う事を知ったら「やれ」って言うバカが必ずいる
でもそれが悪となると、ユーザが作ったソフトウェアをネットに公開したり、メールで送ったり、そしてインストールしたりできるWindowsもダメって事になりません?
なぜ携帯でだけ自己責任が通らないのか不思議。 もちろん、ユーザ層が違うのは分かるんだけど、きちんとしたサンドボックス内で動かすとかできないもんですか?
# と、部外者は勝手に思うのだった:-)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
にわかな奴ほど語りたがる -- あるハッカー
設計レベルの場合 (スコア:2, 興味深い)
「これはセキュリティホールをついた攻撃でもしなきゃ作れないっすよ」
とか言ってるような気がするんですが、
こういうのの場合、今までだと仕事としては作るしかなかったんですけど、
これからは
Re:設計レベルの場合 (スコア:2, 興味深い)
そういう答えをしてはいけません。
将来セキュリティーホールが塞がれて、自分の首を締める事になります。
素直に「仕様上できません」と言うのが吉
# 何とかすればとりあえず動くと言う事を知ったら「やれ」って言うバカが必ずいる
Re:設計レベルの場合 (スコア:1)
が顧客の場合まだかわいげがあるのですが、
自分の部署のマネージャーだったりするとかなり切ない。
# マネージャーが捕まってもいいのでID。
Re:設計レベルの場合 (スコア:1, 参考になる)
Javaアプリからメモリデータを自由にアクセス出来たりメール送れたり出来る追加仕様を作っておきながら、
ユーザーがJavaアプリを作ってネットに公開したりメールで送ったりできるようにしようとした…。
仕様案を見たときは呆れを通り越して笑いが出たものです。 ( - -)…→トオイメ
#最終的には事業者のチェックを通ったアプリだけがDLできる仕組みに落ち着きましたが。
ヤバすぎAC
Re:設計レベルの場合 (スコア:0)
Re:設計レベルの場合 (スコア:0)
でもそれが悪となると、ユーザが作ったソフトウェアをネットに公開したり、メールで送ったり、そしてインストールしたりできるWindowsもダメって事になりません?
なぜ携帯でだけ自己責任が通らないのか不思議。 もちろん、ユーザ層が違うのは分かるんだけど、きちんとしたサンドボックス内で動かすとかできないもんですか?
Re:設計レベルの場合 (スコア:0)
開発時間/コストに余裕があれば、キャリアの署名入りだったら拡張仕様をアクティベートできて、署名が無ければ無効になるような仕組みにすれば良いんだろうけどね。
# と、部外者は勝手に思うのだった:-)
Re:設計レベルの場合 (スコア:0)