2013年9月22日日曜日

プライベートなデータはどこでどんな風に保護するか

androidに限らずiosでもというか、ソフトウェア全般は割れるもんです。
割れるというのは、平たく言えば解析が可能ということです。
解析が可能ということは、第3者によるデータの取得ができるということです。
プライベートなデータ(誰からも見られる危険性がない)というのは存在できません。

データをとって全世界にばら撒いて、宣伝して、
自分は御用となっても目的が達成できればおkという人も存在します。
ばら撒かれたデータは使い道がある限り脅威は消えません。
脅威の排除は非現実的な手段をとるなら可能ではありますが、まずできません。

だから厳密に言えば、世で言うセキュリティに願うものというものは存在できません。
常に努力はしてます。しかしながら、それは善も悪もありません。

データアクセスはログイン機能を設けて機密性を高くしていますというのがベター。
もしくはセキュリティとしてログイン機能を利用しています。とかかな。
自動認証ならルート奪取された場合、如何なる責任も負いませんとか。

だから、公開をすることを前提とした設計をおすすめします。
どうやっても保護できねーもん。

とは言え、丸投げではあまりに無責任なので、
どのような機能を設けているのか提示して、納得したら開始するという形がいいと思います。

それは如何なるソフトウェアでもです。
だから、こういう経緯でネットワークアクセスが発生しますとか、ルート奪取されたら云々とか、
漏洩のリスクが高まることはちゃんと列挙して同意を得ましょう。
アプリを開始する際にそういった注意書きを出して、同意したらアプリ開始がベターです。
説明がなかった場合、訴訟になったらかなり旗色が悪いです。
初心者でして、とか言い訳になりません。

利用者は次のことを肝に銘じてください。これは最低限です。
安心はない。
常にデータ漏洩の危険性がある。
パーミッションにネットワークアクセスがないからといって、ネットワークアクセスが発生しないわけではない。
説明文の中にパーミッションがないからと言って、その動作ができないわけではない。

クレカの情報とか入れてる人はご愁傷様。good luck.

2013年9月19日木曜日

というわけでcontentproviderのお話

毒も吐き出した所で本題。

contentproviderは基本的にGlobalを想定して作ったほうがいいと思う。
リファレンスにも書いてあるけど、完全ローカルなら使う必要はありません。

では、なぜ今contentproviderというのが出てきたのか。
もっと柔軟なデータリソースにしませんか?という提案の形だと思う。

もっと言えば、今までにない情報の出し方をしませんか?と言うことだと思う。
すでに存在するデータを使って、じゃあそれを使ってこんなん作ってみましたとか楽しいと思う。
使う側としても色んなところから使える、引っ張り出せるっていうのは魅力的だと思います。

だから僕の作るcontentproviderは基本的にグローバルアクセスだったりする。
もちろん、ローカルで使うデータもあるのでそこはそれとしてローカル仕様にしています。
もちろん何でもかんでも受け入れるようなことはしてません。
手を取り合える状態を用意しておくということです。
ちょろっとコンテンツプロバイダでチェック処理いれてます。
マニフェストではグローバルアクセスです。

もうベンダーでは魅力あるものを作れない。
時代がそうさせない。
あらゆるネガティブな要素の影響がでかすぎる。
逆に言えば、その反動や、作った時間で個人、有志なら魅力あるものを作れると思う。
HowToはたんまり貯まってるんじゃないでしょうか?

だから、手を取り合える環境を「共有」していきませんか?
というcontentproviderのお話でした。

昨今の流行の「共有」と「誰かと繋がっている感」について

ばかじゃねーの。
何を誤訳したらそうなるの?

どっかの誰かさんが共有と誤訳したのをまんま日本語通りで受け取っているから困る。
正しくは、「最低限の存在を認めていること」を指す。
具体的には「そこにある、いる」を表しています。

無愛想な言い方をすると、そこにあるのでいかようにでもお使いください。
少し愛想の良い言い方をすると、これはあなたの力になるものかもしれません。
となる。
無機質な言い方をすると先述通り「そこにある」となる。

この表現の以下でも以上でもない。
日本語の妙と言えばそうなんだけど、もちっと何とかならんのかね~。

「誰かと繋がっている感」について。
残念ながら人はいつまでたってもどこまでいっても一人です。
感という言葉で濁していますが、それってとても都合の良い話だよね。
思いやりがないし、思いやりを受け止められる度量もない。

あなたが今一番つながっていると思わないといけないのは誰ですか?
時間を作って、一生懸命時間を作って、そのためだけに時間を何とか作って、
そうして作った時間を大切にしていますか?
あなたの時間にとってそれは大切な時間ですか?

人付き合いにおいて大事なことは縁を切らぬようにすること。これは最低限。
例え疎遠になったとしても、何かの時に連絡とってみるかーというのも大事でしょう。
こまめにツイッターやメールなどで些細だとしても継続して行うことは大事なことです。
が、気軽に簡単、短時間に「済ます」というのはちょっと違うと思う。

少なくとも僕は、大切な時間のために作った時間をもう少しだけ大きくできないか、
大切な時間を思いっきり楽しんでもらうためにもうちょっと何とかできないか、
そんな風にアプリやシステムの先にいる人のことを思ってがんばっている。

「ゆるいお付き合い」は例え疎遠になってもそれまで作った信頼があるからこそ成り立つ。
「お~久々~!元気にしてた?」とか言えるのがゆるいお付き合い。
即席のお付き合いなんてのはこの世にない。それはお互いを利用している関係だ。

まぁ、世の中にあるgoodとかいいね!とか言うのが気に入らないだけなんですけどね。
早いとこ機能不全であることを認めてこの世から抹消してほしいと切に願ってます。
人の思いはそんなもんで表現なんかできねーんだよ。
本当にいいと思ったらちゃんとレスがつく。そこに書いてあること、文章のタッチが全てだ。

2013年9月17日火曜日

ふと思った

SQLの発行は全部コンテントプロバイダに集約すればいいんじゃね?

なんでかっていうと、コンテントプロバイダは別プロセスの中のとあるスレッドで起動されるから。

集約っていうのは、あるSQLを発行、つまりselectやDMLに関する全てのケースを、
コンテントプロバイダ内で制御するということ。
より具体的にいうと、コンテントプロバイダ内でコーディングしたものだけを発行できる形にするということ。
こうすれば、アプリケーション上からstaticなコンテントプロバイダのオブジェクトを参照して、そのオブジェクトを通してSQLを発行するだけでいい。
ストアドプロシージャみたいな形だね。ついでにゲートキーパーの役割も持つ。

SQLiteのトリガーだと生SQLを発行することになるので、
プレースホルダー機能をもつcontentresolverクラスのメソッドが使えない。
簡単なSQLインジェクションをトリガーで行ってしまう可能性があるということ。
なので、テーブル毎にDMLの制御を作ればいいんじゃないだろうか。
どのテーブルにSQLを投げているかは引数のUriで判定できるし。

満たすべき仕様は以下。
1.常に同じコンテントプロバイダオブジェクトを使うこと。
2.常に同じSQLiteDatabaseオブジェクトを使うこと。
3.順次発行ができているか確認すること。
4.databaseの変更を受け取れるコールバックを実装すること。

これはコンテントプロバイダ内のonCreateでstaticなメンバとして扱えばいいのかな?
というわけでやってみる。

2013年9月13日金曜日

今、一番欲しいもの

3Dで表現できるプレゼン用ソフトウェア。

画像をぐるぐる回したり、コマを進めたりできるもの。

完全に立体として表現ができ、画像への操作ができるもの。

2013年9月10日火曜日

日本は「国」か「地域」か

NHKの世論調査(9月10日18時)で
「日本の未来は明るいか」という問いに対して、
そう思う、どちらかと言えばそう思うが19%前後。
一方、そう思わない、どちらかと言えばそう思わないが47%。

そりゃそうだよね(

僕の仕事は場所を選ばないし、生活するだけのお金もスキルもノウハウもある。
この国いるのはまだ終わってない義理があるからとしか言えない。

日本という国はここ100年くらいで様変わりするだろう。
進む亜熱帯化による農作物の変更。
国債乱発による信用不安。
箱物の占拠による土地の枯渇。
人口の年齢層の一極化。
税収の減少と税率の上昇。
日本市場の極端な縮小。
進まない政治改革。
ひたすら無駄なランニングコスト。
亜熱帯化による豪雨と日本特有の地震による災害増加。

正直、この「国」に未来なんてあるわけない。

だから若い人はどんどん世界に打って出た方が良い。
活躍できるフィールドは「日本という地域」には留まらないはずだ。

そういや、今の初老の方々は目指していた日本は作れたのだろうか。
目指していた将来は掴めたのだろうか。

今、日本が目指してる将来ってどんなもんだろうね。
人が目指してる将来ってどんな環境なんだろうね。

世界は変わる。それに伴い物の価値も変遷していく。そして人も変わる。
とても流動的な時代だ。
この荒波をサーフィンで楽しむくらいの目線は必要かもしれませんね。

どこかで誰かが言ってたけど、「楽しさ(これには非常に多くの意味が含まれる。hopeやinterestedやfineやcuteやchallengeやlook up やsearchやcreate)」=「子供が遊んで楽しかったという感想に含まれる楽しさ」を実行できる力が今必要だなと思う。

斜に構えるのは悪いというのが通例だけど、適当に斜に構えて生きたい。

2013年9月2日月曜日

色々作ったり見たりして思ったandroidのその先

基本的には内部にデータを置かない。

内部に置くべきデータは、デバイスの違いを吸収できるプライベートに強固に維持しなければならない設定。
例えば、web上の情報をそのままAndroid端末で読もうとするとあっさりメモリがいっぱいになるので、情報をしぼったり、情報は情報として置いておいて見せるものを減らすとか、そういったことをフィルタリングする設定ファイル。
アプリケーションの設定ファイルをローカルに置くのではなく、あくまでフィルタリングに必要な設定を置いておくのが内部設定ファイル。

外部に置くデータは、参照に対する権限を明記し、権限が許す限り参照を許可する。写真、音楽、記事、カレンダーなどなど。
こうすることで様々なデバイスから権限さえあればいつでもどこでも参照が可能となる。見せ方はデバイスにあるアプリケーションの設定による。

まーでもこれだとインターネット上で構築した環境がボンッしちゃうと終わるんだけどね(
それとデータを預かる側がやろうと思えば何でもできてしまう。記憶に新しいアメリカの機密情報リークとかまさにこれ。やってんだろうなーとは思ってたけど、まだアメリカしか顔を出してないのが恐いとこっすね。インターネットが自由だ自由だとは言うけれど、結局どこかの誰かさんにデータ預けてるだけなのにね。何でこうも危機意識のないネット環境ができたのか。

データに対して見せる見せないも大事だけど、そのデータの占有権が誰にあるのかそういうことも考えていきたいですね。

2013年9月1日日曜日

ん?Looper使うならry

Looper使うならServiceの意味なくね?

Looperの中のおれおれスレッドでイベントするなら、Service発行しなくてもいいような気がする。

まずはserviceで組んでみて、だめそうならLooperだけでやってみるか。

ふと思った

androidって、
コアプロセスを中心としたプライベートなローカルネットワークみたいな構造にしたいのかな?
外に情報を出したいときはコアプロセスで権限が認められてるものだけ外にいくような。

ローカルな一極集中タイプのサーバクライアント型とも言えるような気がする。
フォルダ構造ではなく、Uriでアクセスしてねってのもそういう意味なのかな。
そうなると外部ストレージとか確かにありえないよね。セキュリィティ的にも。

と、クラスとか構造とかから読み取れるような気がする。

SQLの発行場所と完了を受け取る場所

アプリのプロセスが発生している場所のスレッドプールってどこだろね?

っていうのがLooperというとこだったりする。
なので、そのLooper内で発行と結果を任せればいいのかな。
参考になりそうなクラスがあったりする。それがAsyncQueryHandlerだ。
中身をみると、ほうほうなるほどとなると思う。

もうちょい具体的にすると、
AsyncQueryHandlerというクラスをServiceとしてコアプロセス経由でContentProviderが動けるプロセスに投げる。で、Looper内で発生させたServiceで受け取り、必要があればAppプロセス内に通知する。でもAppプロセスがdeadしてる場合もあるから気をつけないとね。

プロセス間通信≠Service

先に述べたとおり、
ContentResolverを使ったSQLステートメントの実行はBinderを使ったプロセス間通信です。

Appプロセス⇔DB
ではなく、
Appプロセス→コアプロセス→DB→コアプロセス→Appプロセス
です。

これを排他的に非同期にキューイングされた状態を作り、且つプロセス間通信として確立したい。
いや、そんな別に意気込んでやんなくてもいいと思うんですよ。
でもね、どこでどういう方法で何をやっているかを明記するほうが僕はいいと思うんですよ。
流儀の問題だと思います。

まーでも、webにある情報ではだいたいUi上で書いてしまっているのが現状です。
間違った記述であると言わなければいけません。
スレッドに移して書いてる場合もあります。これも間違った記述であると言わなければいけません。

CursorLaoaderの実装を見ると、new ForceLoadContentObserver()というのをしています。
コールバックを内包しているわけですね。
これにより状態を検知しています。

なので、コールバック作りましょう。
それと起動しているActivityのスレッドプールではなく、Activityを起動しているスレッドプールを使いましょう。
そしてプロセス間通信となるサービスを発行してSQLの発行と結果の受け取りを行いましょう。

それいけBinder

ContentProviderはBinderをimportしている。

先の記事でちらっとでてきたかもしれないけど、
ContentProviderはContentProviderNativeをextendsしたTransPortというクラスをもっている。

ContentProviderNativeってのがBinderをextendsしてる。
で、ContentProviderクラスではTransportというクラスで内包している。
class Transport extends ContentProviderNative

はて?Binderってなんだっけ?
Bindっていうservice発行の仕組みはあったと思うけど、Binderではないんだよな。

ちょろっと検索したら以下の記事がありました。
AndroidのBinderによるプロセス間のメソッド呼び出し(メモ)
記事の日時は2011年03月17日なのでもしかしたらAndroid自体の内容が変わっている箇所があるかもしれません。

内容としては、IBinderというインターフェイスでActivityのプロセスが開始されているというものでした。
実行しているコアプロセスとは違うプロセスとしてActivityがスタートされ、IBinderが両プロセス間の通信を実現しているという感じですね。

なるほど。やはりサービス絡みでした。
となると、呼び出したプロセスのスレッドに対してサービスの結果を返してるということになるのかな。

んーとなると、UIスレッドに書けるけど、Activityの影響を受けにくいところに結果を出してあげるべきなのかな。ノーティフィケイションとか使ってね☆ミとSDKのどこかで言われてたような気がする。
でもノーティフィケイションに出すと通知が溜まりまくるような。。。