eniehackとの議論10

そういう選択をすることに自覚的であって、docsにもちゃんと書くなら良いと思う

• セキュリティに関しては妥協するか否かを選択できるようにしたいという認識……？

• 「フィルタつけたらいいじゃ〜ん eval(open('filter.lua'))！w」というのはダメだよねと思っていて、eval的なものを使うのであればできるだけ対策して、利用者にも「このプログラム上では任意のコードが動いちゃうし、sandboxも完璧ではないから気をつけてね」と警告したかった
  • インフォームド・コンセント
  • 知ってればコンテナに入れたり、権限を絞ったユーザで実行したり、多重防御に手間をかけてくれるだろうという期待
• 妥協してbinchotanを使うか、妥協せずbinchotanを使わないかという選択ともいえる

単にシステムの情報が雑に扱われたらやだなーと思った.

• システムが悪意を持って操作されるとかそういう感じでいいのかな……？

• backendを共有する場合、悪意のあるユーザーにbackend経由でサーバをhackされる懸念がある

とりあえず仕様と現状の確認、とかできるとよさそう

• しましょう
• 一旦まとめます
• binchotan仕様

API keyってアカウントに対して発行されるんじゃなかったけか

• その通り
• 開発者のアカウントに対して(API key, secret)が一組、利用者に対してはそれぞれのAPI Keyについて(Access Token, Refresh Token)が必要に応じて発行される

アカウント新設したほうがいいのかな？

• API Keyはbackendを動かす人が自分で取得して、環境変数に入れることを想定していた
• もしかして今っていろいろとりづらかったりする？
  • 自分は過去に（まだTwitterのメニューバーが黒かった時代に）いくつか登録していたので、それを引きずり回してる