ハボリテ

胡乱の羅列

Raspberry piのSDカード移行方法

記事内容

  • Raspberry pi 3B+のシステムSDカードを旧(8GB SDHC) => 新(128 GB SDXC)へと移行した時の自分用備忘録
  • 特に大事なシステムでは無いので、稼働しながらサクッとクローンした。普通にダメなので真似しないように。
  • もちろん本来は停止状態でクローンすべき。その場合でもddrescueの実行以降は同じ手順

影響を受けそうなサービスの停止

  • 処理中にddrescueを食らうと破損しそうなサービスを予め停止しておいた
  • 自分の場合は定期的にsqliteに書き込むサービスがあったのでそれを停止

ddrescueで旧SDデータを新SDへとクローン

  1. ddrescueのインストール

     $ sudo apt update
     $ sudo apt install gddrescue
    
  2. SDカードリーダーなどを使って新SDを接続

  3. ボリューム名の確認

     $ sudo fdisk -l
    
------ [中略] ------

Disk /dev/mmcblk0:  7.4 GiB, 7948206080 bytes, 15523840 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x73075489

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        8192    98045    89854 43.9M  c W95 FAT32 (LBA)
/dev/mmcblk0p2       98304 15523839 15425536  7.4G 83 Linux

Disk /dev/sda:119.1 GiB, 127865454592 bytes, 249737216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x73075489

Device    Boot  Start        End    Sectors    Size  Id  Type
/dev/sda1        8192      98045      89854   43.9M   c  W95 FAT32 (LBA)
/dev/sda2       98304  249736328  249638025    119G  83  Linux

今回の場合、/dev/mmcblk0から/dev/sdaへと(ディスクごと)クローンする

  1. ddrescueの実行
$ sudo ddrescue -v /dev/mmcblk0 /dev/sda

所要時間は8 GBで10分くらい

partedで新SDのパーティションサイズ変更

今回は限度いっぱいまでパーティションサイズを拡大する。EugenMayer氏作成のスクリプト(resize.sh)を利用することで楽に行える。

  1. resize.shのダウンロード

     $ cd ~
     $ wget https://raw.githubusercontent.com/EugenMayer/parted-auto-resize/master/resize.sh
     $ chmod +x ~/resize.sh
    
  2. 拡大するパーティションの確認

     sudo fdisk -l
     # 今回は"sda2"が拡大すべきパーティションだった
    
  3. resize.shの実行

     # サンドボックスモードで変更をプレビュー
     sudo ./resize.sh /dev/sda 2
     # プレビューに問題が無ければ実行
     sudo ./resize.sh /dev/sda 2 apply
    

新SDに入れ替えて起動

  1. Raspbianのシャットダウン

     $ sudo shutdown -h 0
    
  2. SDカードの入れ替え・Raspberry pi起動

  3. sshでログインできることを確認

ボリュームのリサイズをOSに反映させる

  1. この時点ではまだOS側にボリュームのリサイズが反映されていない

     # ボリュームサイズは変更されているが......
     $ sudo fdisk -l
     # OSから見た/dev/rootのボリュームサイズは小さいまま
     $ df -h
    
  2. resize2fsを実行してリサイズを反映させる

     $ resize2fs /dev/mmcblk0p2
    
  3. 変更が反映されていることを確認

     $ df -h
    

軽量ネックスピーカーの比較@2020

違いが分かりにくい軽量ネックスピーカー

2020年現在、販売されているネックスピーカーは「音質重視」と「使い勝手重視」のものに大別される。前者ががっつりと音楽を聴くのに特化しているのに対し、後者は「作業中に音楽をながら聞きする」「TVの音声を耳元で聞く」「web会議のヘッドセットとして使う」ような使用を想定した軽量な製品群だ。

「音質重視」のネックスピーカーはメーカーごとに結構個性的で、レビューも多い。一方「使い勝手重視」の方は、どれも似たり寄ったり(後述するが実際同じものも多い)で、今一つ選択基準が分かりにくい。そこで、この記事では、それらの軽量ネックスピーカーの違いについてまとめた

先に断っておくと、筆者が所有しているのはJVC SP-A7WTだけで、実際に他の製品を使って比べてみたわけではない。あくまでも「カタログスペック上の違い」をまとめた記事なので、その点はご了承願いたい。

他サイト様では、以下のような比較記事が参考になる。

ミドルレンジ軽量ネックスピーカーの比較表

軽量ネックスピーカーのボリュームゾーンは9000~15000円のミドルレンジ帯である。メーカーは、SHARP, JVC, Pioneer, KENWOOD, EM-Tech等。マイナーメーカーがひしめくローエンド帯(3000~5000円)はかなりカオスなのでパス。2020年5月現在、ミドルレンジ帯で実売されている軽量ネックスピーカーは、主に以下の5種類である。

軽量ネックスピーカーの比較表

たくさんあるなぁ、と思われるかもしれないが、実質的には以下の3種類しかない

  • 第一世代MY THEATER系(EM-W100, SP-A10BT, CAX-NS1BT, AN-SS1):  → このカテゴリの主力。見た目が微妙に違うだけで、中身は(おそらく)同じOEM兄弟。オリジナルはEM-W100。
  • 第二世代MY THEATER系(SP-A7WT)  → 第一世代MY THEATERの後継機種。「apt-X LL対応」と「サブスピーカー増強」が主な変更点。本家韓国ではEM-W110という機種もあるが、SP-A7WTとは同型機では無いようだ。 
  • 独自系(SE-C9NS)  → 唯一全然出自が違う。

選択を特に厄介なものにしているのが、第一世代MY THEATERの存在。これらのOEM兄弟は「カラーデザイン以外の見た目は完全に同じだが、公式スペック上では重要な違いがあり、ところが実態はやはり同じ中身であるっぽい」という非常にめんどくさい状況になっており、情報が非常に整理しづらい。
とりあえず順番に違いを見ていく。

見た目

まず下位4機種(EM-W100, SP-A10BT, CAX-NS1BT, AN-SS1)はそもそも本体形状が完全に同じ。ロゴや筐体カラーだけが違うが、カラーバリエーションは5色展開のAN-SS1が圧勝。後継モデルであるSP-A7WTはちょっと地味になった。SE-C9NSは先端がメタリックな個性派。

インターフェイス

第一世代MY THEATER4機種は電源がスイッチ式になっていて、ON/OFFが素早く切り替えられると評判が良い。一方上位2機種(SP-A7WT, SE-C9NS)についてはプッシュボタン式なので、電源OFF時に長押しが必要。ハンズフリー通話に出るためのボタンは第一世代MY THEATER系にのみ搭載されている。

重量

どれも軽い。敢えて言うならSE-C9NSがちょっと重いが、あんまり気にしなくても良い気がする。

連続使用時間

どれも長い。敢えて言うならSE-C9NSが長い。消費電力はどのコーデックを使うかにも大きく左右されるので、たぶん第一世代MY THEATER4機種は測定方法に差があるだけだと思う。いずれにせよ14 hあれば十分な気がする。

防水

上位2機種(SP-A7WT, SE-C9NS)のみIPX4対応。アウトドア派の人は押さえておきたいところ。

Bluetooth世代

上位2機種(SP-A7WT, SE-C9NS)のみBluetooth5.0。他は4.1。

対応コーデック

一番重要であると同時に、メーカー公式サイトが全然アテにならないポイント。  もし公式発表を信じるなら、第一世代の中ではaptX/AACに非対応なAN-SS1はバランスが悪く、SP-A10BT, CAX-NS1BTはまぁまぁだが、結局これらの完全上位互換のEM-W100がお得ということになる。しかし、「AN-SS1を実際に使ってみたらaptXに対応していた」という証言がネット上に多数見られ、中にはaptX LLにも対応していたという報告もある。   もし実際には完全に同じ中身であるとすると、上記の評価は逆転し、値段が一番安くカラーバリエーションも豊富なAN-SS1が一番お得で、単に値段が高いだけのEM-W100や、Bluetoothアダプタが付属しないSP-A10BT, CAX-NS1BTは丸損ということになる。というかSHARPの公式説明書を見ると、aptX対応とは一言も書いてないのに、なぜか「aptXはQualcommの商標うんぬん」とかの但し書きは書いてある。ライセンス料とかにも絡む話だと思うんだが、いいのかこんなに雑で。

同様に、第二世代であるSP-A7WTの評価も変わってくる。公式にはSP-A7WTが唯一のaptX LL対応だが、その分3000円ほど高い。2020年現在において、aptX LLに対応していることの価値はかなり大きいため、この差額なら第二世代を選ぶ人も多いと思うが、実は第一世代も密かに対応していたとなれば話が変わってくる。実は本体の対応状況に差はなく、Bluetoothアダプタ側だけの違いなんじゃないか?というのが筆者の予想。

独自路線がSE-C9NS。aptXに非対応な代わりに、唯一のAAC対応。つまり、iOS相手に高音質なAACコーデックで入出力が出来る。一方、AAC非対応製品相手だとSBCになる。SBCにしろAACにしろ、遅延が大きなコーデックにしか対応していないのは痛い(ただし経験上、iOSでの動画視聴に限っては、AACでも遅延が極端に小さくなる。たぶんOS側で色々調整してるんだろう)。


なお、各コーデックの特徴については、以下のサイトが良くまとまっていて参考になる。情報の変遷が激しい分野だが、2020年現在の方針としては「aptXの対応はマスト。できれば超低遅延コーデックにも対応」となるだろう。iOSの存在によってAACとの兼ね合いが話をややこしくしているが、基本的にaptX系に対応しているとバランスが良い



7. USB形状

SE-C9NSのみUSB type-C。他はmicroB。時代的にはtype-Cにしたいところだが、まぁ流石に他の項目が優先される。

8. 付属Bluetoothアダプタについて

メーカー公式が全然アテにならないポイントその2。 前提知識として、FastStreamやaptX LLのような超低遅延コーデックは、基本的にハードウェア的にエンコーダーを実装する必要があり、かつアンテナの干渉問題からスマホ等に内蔵することがほぼ不可能、という制約がある。したがって、これらのコーデックを使いたければ、「対応するBluetoothアダプタは付属するのか」「そのBluetoothアダプタの仕様はどうなっているのか」が非常に重要である。

 メーカーの説明書を見ると、どうも付属のBluetoothアダプタのUSB-Aコネクタはただの給電部位であり、アナログ音声をネックスピーカーに飛ばすだけの機能があるように見える。

ところが実際に使ってみた人の声によると、普通にUSBオーディオ出力が可能であることが分かっている。つまり、TVだけでなくPCゲーム等もデジアナ変換を介さずに超低遅延で楽しめるということで、割と嬉しいポイントである(逆に言えば、付属しないSP-A10BT, CAX-NS1BTの評価は下がる)。ちなみにOSからはBluetoothドングルではなく、単なるUSBオーディオ(スピーカー)として認識される。

そしてさらにややこしいことに、どうもこのBluetoothアダプタはWindows等のOSから見て、USB音声入力機器(マイク)としても認識されるようだ。筆者が持っているSP-A7WTでは認識されるだけで音は拾えなかったが、AN-SS1のレビューを書いているサイトの中には、Bluetoothアダプタを介したマイクも使えると言っている人もいる。もし本当にそうなら、非常に貴重なA2DPプロファイルヘッドセットとして機能していることになる。

総じて、仕様くらいまともに書いておいてくれという感想……。

9. 実勢価格

上位2機種で数千円高い。次点でEM-W100。最近(2020年5月)は、テレワーク需要により高騰気味。

10. 音質

上にも書いたが、直接比べた訳ではないので伝聞評価・・・。 SP-A7WTとSP-A10BTを実際に聴き比べてみたブログ様や価格.comのレビューによると、SP-A7WTの音質はSP-A10BTと比べてかなり改善しているらしい(特に低音域)。第一世代MY THEATER4機種(EM-W100, SP-A10BT, CAX-NS1BT, AN-SS2)の音質に違いは無いだろうから、SP-A7WTが一歩リードしているという評価で良さそう。実際SP-A7WTは私も使っているが、十分に軽い音楽視聴に堪えると感じる。SE-C9NSは未知数。

結論

* 基本的にはSP-A7WTがおすすめ。aptX LL対応&スピーカーの音質改善が差別化ポイント。 * お得感が高いのはEM-W100。OEM4兄弟の最上位。 * 予算が足りない場合は、(1)汎用性重視・音質重視ならSP-A10BTとCAX-NS1BT、(2)超低遅延志向でトランスミッタ使用を前提に出来るならAN-SS1、という棲み分けか。カラフルなものが欲しければAN-SS1一択。 * SE-C9NSはiOS特化型。あとは極限まで電池持ちに拘る場合。 巷の情報を信じるなら、

  • 音質改善・軽量化に魅力を感じるならSP-A7WT。
  • コスパが良いのはAN-SS1。
  • iOS特化型が欲しいならSE-C9NS。

ただしメーカー非公式の情報が含まれていることに注意。

主要画像ファイル形式の簡易解説 - ラスタ画像編

前書き

 画像を扱うフォーマットって、ずいぶんと沢山の種類がありますよね。ラスタ形式に限ってもJPEG, PNG, GIF, TIFF, etc...。全部同じように見えるけど、何がどう違うのか。Wikipediaにも比較表があったりしますが、ぶっちゃけこれ見ても良く分からないんですよね。 というのも、これらはあくまでもフォーマットの「仕様」が備えるスペックであって、扱うソフトが実際にその仕様に対応しているかどうかはまた別問題だからです。

従って、画像フォーマットの性質を知るには、「何ができるか」よりもむしろ「どう使われているか」あるいは「どういうものだと思われているのか」を理解することの方が大事だったりします。

そこで各フォーマットの性格や立ち位置をきわめて主観的かつざっくり解説してみよう、というのがこの記事の試みです。無責任に各フォーマットにキャラ付けをしようというのが目的なので、細かい点に関しては気にしない方向で。

JPEG

  • どう思われているか: 写真とかで使われてるやつ
  • どんなフォーマットか: 有史以来、地球上で最もたくさんのデジタル画像を生み出したフォーマット(当社調べ)。今日も今日とて写真を非可逆パワーでガンガン圧縮してくれる頼もしい奴。実は無圧縮でも保存できるのだが、そんなものは誰も使わない。拡張子の表記ゆれが激しい。
  • 長所: 圧倒的普及率。 圧縮アルゴリズムが古い分、エンコード/デコード負担が少なくてCPUに優しい。 EXIFにも対応しているし、写真との相性は抜群。
  • 短所: 非可逆圧縮なので、当然画質は劣化する。コピーをすればするほど劣化が進行するので、画像編集中にJPEG保存を繰り返すという禁忌を犯すと最後は見るも無残な姿に成り果てるという。 古い技術なので、圧縮率が現代基準でイマイチ。 今時透過にすら対応していない。
  • 将来性: さっさと引退しろと20年近く言われていれながら、幾多のポスト規格を退けて未だに現役。基本的にJPEGファイルが生まれるのは誰かが写真を撮った時なので、カメラを作る側が今後も使いたいと思うかどうかにJPEGの命運が掛かっている。

PNG

  • どう思われているか: イコン画像に使われてるやつ
  • どんなフォーマットか: 彼の名はPing Is Not GIF Portable Network Graphic。その名の通りWebの世界で生まれwebの世界を飛び回ることを至上命題として生まれたフォーマット。兄貴分のGIFと比べて圧倒的な表現力を持っていたために、瞬く間に世界に拡がった。JPEGとは対照的に、輪郭がくっきりとしたデジタル画の圧縮が得意。
  • 長所: 可逆圧縮なので画質の劣化とは無縁。 容量はファットだが仕様はスリムなので、実装が楽で互換性も高い。
  • 短所: Portableとかいう名前に反してファイルサイズがでかい。特に写真のように複雑な画像は大変なことに。 おまけにCMYKをサポートしていないので、印刷との相性は悪い。 要するにディスプレイの外の世界に興味が無い規格。
  • 将来性: PNGの圧縮率は「可逆だしこんなもんだろ」とみんな納得している雰囲気があるので、きっとこれからも安泰だろう。でもいくら使われても、外の世界に出てくることは決して無いだろう。

GIF

  • どう思われているか: おもしろアニメーション
  • どんなフォーマットか: インターネット黎明期はJPEGと世界を二分していた老舗フォーマット。権利問題だのFLASHの隆盛だので21世紀初頭に絶滅したとされていたが、ジョブズFLASHを殲滅したことで奇跡のV字回復を遂げた。近年では数秒で笑えるパラパラ漫画を再生するのが主なお仕事。でも別にアニメーション用規格ではない。
  • 長所: 色が少なくて輪郭がはっきりした画像(ロゴとか)に関しては、PNGよりもファイルサイズが軽く、JPEGよりもキレイにできる。 世界一簡単にパラパラ漫画を作れる。
  • 短所: 最大256色という、およそ現代的とは思えない貧弱な表現能力を誇る。 アニメーション規格として普及しているが、ちょっと複雑な絵になると途端に激重になる。フレーム補完とかも一切ない。
  • 将来性: 再び衰退に向かう運命。実際LINEのうごくスタンプの座はアニメーションPNG(APNG)に取られたし、WebPも控えている。それでもおもしろGIF画像はおもしろGIF画像であり続けるだろう。

TIFF

  • どう思われているか: なんか難しそうな人が難しそうな場面で使ってる
  • どんなフォーマットか: 「サイズがデカい」「画質がいいらしい」という噂(正しくない)から、PNGとどう違うの?と思われがちな画像形式。その実態は画像プレビュー機能付き巨大コンテナとでも言うべきもので、むしろPDFのようなベクタイメージ勢と比べる方が筋が良い。シンプル・イズ・ベストなPNGとは対極の存在。
  • 長所: メタデータも色々入るし、マルチページにも対応しているし、したけりゃ圧縮もできるし、異なる形式の複数の画像データを中に格納しても良いし、とにかくなんでもアリ。 情報が落ちにくいので、「これから編集される/解析される」であろう画像に適している。 印刷・カメラ・科学分析機器あたりのアナログでドロドロした業界と相性が良い。
  • 短所: 規格の自由度が高すぎる上に度重なる改訂でカオスと化している。 たまに「古くから使われているので互換性が高い」みたいな説明を見かけるが、むしろソフトによる実装差が激しいので、画像ファイルとしては一番「ちゃんと開けるかどうか分からん」形式である。なのでPNGみたいにwebを飛び回ったりするよりは、決められた用途でどっしり構えて使うのが正しい。
  • 将来性: 印刷分野ではPDFやAdobe勢に押されているが、まだまだ現役。 そもそも人目に付きにくい場所が主戦場なので、生きてるのか死んでるのかが傍目に分かりづらい。いつか世界がHEICで覆われたとしても、地下でひっそりと生き残っているのはTIFFな気がする。

HEIF/HEIC

  • どう思われているか: あいふぉんの写真
  • どんなフォーマットか: 2017年頃からAppleが猛プッシュを始めた新進気鋭フォーマット。デビュー以来「iPhoneで撮った写真が家のパソコンで開けない!」という新たなユーザーエクスペリエンスを世界に提供し続けている。コンテナ規格であるHEIFと圧縮規格であるHEVCを分けて考える必要があり、HEVCでエンコードされた画像をHEIFに格納した時のみ特別にHEICと呼ばれる(ややこしい)。
  • 長所: 動画コーデック技術HEVC(H.265)を採用することで、ファイルサイズがJPEGの約半分に!(大本営発表) 複数画像や音声も埋め込めるので、従来の枠を超えた新たなエンターテイメント経験が可能に!(大本営発表) とりあえず現代的な規格として抑えるべきスペック(透過・アニメ・可逆/非可逆両対応・色んなメタデータ・etc...)は大体押さえている。
  • 短所: HEVCがパテントフリーではないので、対応にはライセンス料が必要。 その上、権利関係で関連企業の折り合いがつかずに泥仕合の様相を呈していて、色々と面倒くさそう。そのせいでサードパーティソフトの対応が遅れ気味。
  • 将来性: 数多の規格を駆逐して唯一至高の画像フォーマットとなる・・・という野望を果たすためには、まずは権利関係がどうにかならないとどうしようもない。本家の動画フォーマットがロイヤリティフリーのAV1に脅かされつつある現状で、果たしてどうなるか。

WebP

  • どう思われているか: 何それ?
  • どんなフォーマットか: Googleが主導する次世代画像フォーマットにしてHEIFの対抗馬・・・と言われがちだが、実は2010年には登場していたので一応こっちが先輩。HEICと同じように、動画コーデック技術(VP8)と画像コンテナ(RIFF)の組み合わせ。名前がダサい。
  • 長所: HEICと同じく、高機能性と高圧縮率を売りにしている(大本営ry)。 HEICと違って完全にオープン&ロイヤリティフリー。 主要3ブラウザ(Chrome, Firefox, Edge)が対応している。もちろんSafariは対応していない。Safariも2021年に対応した。
  • 短所: 圧縮率ではHEICに勝てないと専らの噂。
  • 将来性: ウェブ対応に関してはHEICよりも先んじている一方で、ユーザーへの認知度は遥かに下。 Google自体がさらなる後継規格であるAVIFにシフトするのではという噂もあり、このまま影の薄い規格として消えていく可能性も無きにしも非ず。

BMP

  • どう思われているか: ペイントのアレ
  • どんなフォーマットか: OS2とかMS-DOSとかが跋扈していた神話の時代に生まれた太古の画像形式。「ビットマップ画像」という言葉の意味をあやふやにした張本人。現代においては知名度の割に低い使用率で知られる。オワコン
  • 長所: 無圧縮なので画質の劣化とは無縁。Windowsにベッタリな仕様なので、COMとかのMS独自技術と相性が良い(でもCOM自体が・・・)。
  • 短所: サイズがクソでかい。透過もない。 実は仕様上は圧縮も透過も定義されているのだが、生みの親にすら実装してもらえない悲しみ。
  • 将来性: 時折Windowsの片隅で見かける程度であり、ユーザーレベルでは既に死んでいる。 でもペイントを初めて触ったあの日の感動は、みんなの心の中に生きているよ。

Blue MailとかTypeAppって使って大丈夫なの?という話

※筆者はインターネットセキュリティ・アプリ開発については素人であり、以下の内容は憶測を多分に含みます。悪しからず。

Androidのメールアプリにおいて、Google Playの上位に出てくる人気アプリの中に「Blue Mail」「TypeApp(旧Type Mail)」というメールアプリがあります。この二つのアプリ、名前こそ違いますが中身は瓜二つ、というかほぼ完全に同じです(確かにちょこちょこデザインは違いますが、もはや間違い探しレベル)。
  
いずれにせよ洗練されたデザインと多彩な機能で人気を博しており、インストール数は二つ合わせると600万超。これは、かの老舗メーラーの雄「K-9 Mail」をも凌ぐ多さです。

私も一時期愛用していたのですが、なんとなく気になることがあり・・・というかぶっちゃけ「怪しくね?」と思う部分があり、その点つらつら述べさせて頂きたい次第です。

運営体制が不明瞭

冒頭で述べた通り、恐ろしくクリソツな「Blue Mail」と「TypeApp」。しかし、Google Playでは開発元はそれぞれ「Blue Mail Inc.」「TypeApp Inc.」となっており、一見異なる会社が運営しているように見えます。ホームページも別。
https://bluemail.info/
TypeApp | Home
しかしながら、↓のブログによるとやはり同じ会社が管理している様子。
TypeMail と BlueMail (2)|ぼな日記
というか、TypeApp社のホームページにはちょこちょこ表記ゆれのような形で「Blue Mail」という表記が紛れ込んでおり、完全に同じ会社ですね。いや別に1つの会社が2つ同じようなアプリを作っても何も悪いことは無いんですが、なんだか意図的に別会社による別アプリだと認識させようとしている節があり、薄気味悪さを感じるんですよね。TypeAppの方が単なる後継ということであれば別にいいんですが、その割には2つとも頻繁に更新されているし。

会社の所在地が怪しい

TypeApp社のホームぺージには、会社の所在地についても記載があります。
TypeApps | Contact Us
それによると、拠点は「1540 Market Street, San Francisco CA 94102」とこと。この場所をGoogleストリートビューで見てみると、以下の通り。

この右手にある建物がそうらしいのですが、明らかにオフィスらしき外見ではない。調べてみると、この建物はアーティスト団体のスタジオとして使われているっぽい。
https://hoodline.com/2015/06/artspan-secures-market-street-studio-space-for-25-local-artists
いや、ホントにここで開発してるかもしれませんが・・・、ホントか?

騒がれた過去がある

まぁこれが一番気になる点ですね。
Dieser Artikel ist nicht mehr online - mobilsicher.de
HPには「your passwords are never stored on our servers」と記述されているのですが、専門家がテストを行ったところ、実際にはユーザーのパスワードをBlue Mail Inc. 社のサーバーに送信する挙動が確認されたとのこと(ハッシュ化されておらず、単に暗号化されたもの)。メールサービス提供側の体制がどうであれ、ユーザーのパスワードが(復号可能な形で)メーラーのサーバーに保存される必要性は全く無く、悪意ある挙動と言われても仕方ありません。他にも送信元・送信先とメールの内容についてもBlue Mail側に送信されている、との記述がありました。一応Blue Mail社は「not true and misleading」であるとして反論しており、このテストが公開された後のアップデートによって本挙動は削除されたとのことですが、個人的には今後も信頼することは難しい気がします。ちなみに、このテストによれば「myMail」や「Mail.Ru」など他の人気メールアプリの中にも同様の挙動を示すものがあったとのことです・・・。

Privacy Policyが不穏

これも正しく読めているか自信は無いのですが・・・。Blue MailのHPには、個人情報の取り扱いについて以下のように記載されています。

"Blue Mail is designed to help you manage your email account with other providers, like Gmail. When you link your email accounts (provided by third parties) to Blue Mail, you give Blue Mail permission to securely access your information contained in or associated with those accounts. If you link your third party account to Blue Mail, that third party may also pass certain information along about your use of its service. While Blue Mail usually does not store your password to these email accounts, the service may securely store some emails on a temporary basis in order to deliver them to you as quickly as possible and keep track of your deferred messages."

"Blue Mailは、Gmail等の他のプロバイダの電子メールアカウントの管理を支援するように設計されています。 Blue Mailにあなたの電子メールアカウントをリンクすると、あなたのアカウントに含まれている、およびあなたのアカウントに関連した情報に安全にアクセスする権限をBlue Mailに与えることになります。 電子メールアカウントをBlue Mailにリンクする場合、その電子メールサービスの提供元はあなたのアカウントに関する情報をBlue Mailに渡すことがあります。 通常、Blue Mailはこれらの電子メールアカウントにパスワードを保存しませんが、できるだけ迅速に配信し、遅延メッセージを追跡するために、電子メールを一時的に安全に保存することがあります。"

いや、なんか権限強くない?たぶんユーザーがメールアプリに与えたい権限は、メールの送受信を代行することだけであって、「アカウントに含まれている、および関連した情報にアクセスする」というのはやりすぎな気がするのですが。
例えばK-9 mailの場合、Privacy Policyには以下のように記述されています。

"Sensitive user information is only used to perform the basic functionality of the app, sending and receiving email. K-9 Mail does not automatically collect and send data to the developers of the app or any third party.

"ユーザーの機密情報は、電子メールの送受信に際してのアプリの基本機能を実行するためだけに使用されます。 K-9 Mailが自動的にデータを収集して、本アプリの開発者や第三者に内容を送信することはありません。 "



・・・
以上のように、結構気になる点があったので、駄文を垂れ流した次第です。この問題、英語サイトだと結構話題になっているんですが、日本語のサイトでこの問題について扱っているサイトがあまり見当たらなかったので。
ただ、Blue Mail, TypeApp固有の問題ではなさそうですし、冒頭で述べた通り、あくまでも素人の憶測が多分に含まれているので、詳しい方がいればぜひ見解を伺えれば幸いです。