回答編集履歴
1
コメントへの回答を誤記したのでその旨表記して内容を削除
test
CHANGED
@@ -1,129 +1 @@
|
|
1
|
-
> 最後以外はすべて個人情報流出や、問い合わせフォームが届かなかった場合の
|
2
|
-
|
3
|
-
損害賠償があるのでしょうね。
|
4
|
-
|
5
|
-
|
6
|
-
|
7
|
-
一般的には、請負契約以外ではよほどの重過失や故意によるバグの作り込みが無い限りは結果に対する損害賠償請求は難しいと思いますよ。
|
8
|
-
|
9
|
-
請負契約でも瑕疵担保期間や検収条件を明記して、責任範囲が無制限にならない様にします。
|
10
|
-
|
11
|
-
|
12
|
-
|
13
|
-
|
14
|
-
|
15
|
-
> ただその場合も契約で、いただいた料金以上の損害賠償は出来ません。
|
16
|
-
|
17
|
-
> と記載しておけば、法律上これ以上つまり数百万を払わないといけないようなことは、
|
18
|
-
|
19
|
-
> ないと考えてよいでしょうか?
|
20
|
-
|
21
|
-
|
22
|
-
|
23
|
-
*法律については専門家では無いので話半分で聞いてくださいね。
|
24
|
-
|
25
|
-
どちらかが一方的に有利になるような契約は裁判で無効になるケースもありますし、
|
26
|
-
|
27
|
-
専門家としての善管注意義務は発生するはずですが、
|
28
|
-
|
29
|
-
対価と釣り合っていれば、一般的にはYESとなるはずです。
|
30
|
-
|
31
|
-
|
32
|
-
|
33
|
-
|
34
|
-
|
35
|
-
> また、自分でWEBサービスを作った場合も、例えば有料にするとユーザーから、
|
36
|
-
|
37
|
-
> 使えない日があった、などで訴えられる可能性があるのですね。
|
38
|
-
|
39
|
-
> それだと、契約欄に払っていただいた料金以上の賠償で出来ませんと記載しておかないと、
|
40
|
-
|
41
|
-
> いけないのでしょうね。
|
42
|
-
|
43
|
-
> このように記載しておけば、制作と違って、何百万も賠償することはないでしょうが。
|
44
|
-
|
45
|
-
|
46
|
-
|
47
|
-
そうですね。
|
48
|
-
|
49
|
-
基本的にはそうですが、訴えられた場合は裁判によって決められます。
|
50
|
-
|
51
|
-
|
52
|
-
|
53
|
-
> ただ、認証をツイッターなどのAPIで行えば一切個人情報を預からずに出来るので、
|
54
|
-
|
55
|
-
> この形のみにすれば、サイトを改ざんされてウイルスに感染でもしないかぎり、
|
56
|
-
|
57
|
-
> 損害賠償請求されることはなさそうですね。
|
58
|
-
|
59
|
-
|
60
|
-
|
61
|
-
|
1
|
+
コメントへの回答を誤記したのでコメントに移動します。
|
62
|
-
|
63
|
-
|
64
|
-
|
65
|
-
|
66
|
-
|
67
|
-
> このあたりは、サービス作成時の契約のひな形などがサイト上にあるので、
|
68
|
-
|
69
|
-
> それをコピペして、上記を追加すれば、制作と違ってまず何十万も損害賠償をされることはない
|
70
|
-
|
71
|
-
> と考えてよいでしょうか?
|
72
|
-
|
73
|
-
|
74
|
-
|
75
|
-
基本的にはそうですが、
|
76
|
-
|
77
|
-
問題があっても雛形を誰かが責任を持って配布している訳ではないので
|
78
|
-
|
79
|
-
(配布サイトにもその旨記述があるはずです)
|
80
|
-
|
81
|
-
個人的には最初くらいはお金を払って法律の専門家に相談すべき内容だと思います。
|
82
|
-
|
83
|
-
|
84
|
-
|
85
|
-
> それを気を付けるためには、最低限生のPHPで作ったソースを、ここなどでどこか問題なさそうか見ていただくか、
|
86
|
-
|
87
|
-
> できればlaravelを使って、そこに自分のオリジナルのコードを自分で一切記載しないしかないでしょうか?
|
88
|
-
|
89
|
-
> もちろん勉強はします。
|
90
|
-
|
91
|
-
|
92
|
-
|
93
|
-
Laravelやフレームワークを使ったとしても、脆弱性を作り込むことは簡単に出来てしまいますし、teratailで質問したところで誰も責任は取ってくれないので、根本的な解決にはなりません。
|
94
|
-
|
95
|
-
また、サーバ設定が問題でセキュリティに問題が発生することもよくあります。
|
96
|
-
|
97
|
-
|
98
|
-
|
99
|
-
(契約論的な部分は前述の通りなので置いておくとして)
|
100
|
-
|
101
|
-
対価を支払って信頼出来るエンジニアに添削してもらうとか、
|
102
|
-
|
103
|
-
脆弱性診断サービスやツールを使ってみるとか、
|
104
|
-
|
105
|
-
先述のIPAのチェックシートでチェックしてみるとか、
|
106
|
-
|
107
|
-
そういう方向性かなと思います。
|
108
|
-
|
109
|
-
|
110
|
-
|
111
|
-
方向性は違いますが、WAFを導入してインプットの時点で攻撃を防ぐというのも一つの有効な手段ですね。
|
112
|
-
|
113
|
-
|
114
|
-
|
115
|
-
|
116
|
-
|
117
|
-
> jsの方はphpとちがい中小零細企業はほとんど、jqueryか生なんですね。
|
118
|
-
|
119
|
-
> phpはなぜか中小零細企業でも生ではなく、cakiphp何ですね。
|
120
|
-
|
121
|
-
|
122
|
-
|
123
|
-
中小零細企業で実際にCakePHPの仕事が多いかどうかは知らないのですが、
|
124
|
-
|
125
|
-
javascriptのフレームワークとPHPのフレームワークでは単純に歴史的経緯や、
|
126
|
-
|
127
|
-
担当する役割が違い、導入コストや扱える技術者の数も違うので
|
128
|
-
|
129
|
-
普及度合いが違うのは自然なことだと思いますよ。
|