はてなキーワード: ポータビリティとは
PSDや.ai(illustrator形式)とかいうポータビリティもなくデータ確認手段がほぼアドビ製品一択になるような業界構造を形成して行ったうえで、年間ライセンス制をやり出したのもまあ不満が溜まりまくってたわけですよ
(金が高いという点もあるにはあるが、ちょっとした確認でいちいち重たいソフト開くのも大変だし、ファイル形式のバイナリがどうなってんのかいまいち不明瞭でデータサイズがデカい)
AIの話と混ぜたくないんだけど、ビックテックどもが軒並みああいう姿勢を取り出すと流石に「じゃあお前ら今度からリリースソフト全部BSDかMITライセンスで配布しろや」って気持ちにはなる
NTTも、電力系も、NUROも、おそらく3カ月以上待つらしい。
NTT西なので例のトラブルに巻き込まれるし、NUROは評判だと半年待つ必要があるし、電力系だとNTTの電柱の許可取るだけで2カ月かかると聞いた。
ソフトバンクのおうちのでんわだと一回アナログ戻しが必要になるらしい。最悪。
加入権ありの番号ポータビリティはだいたいできるようになってると聞いてたのに、ソフバン系の電話にしてるとアナログ戻しが必要なんだと。なんだそりゃ。
そして光回線は料金が高い。
NTTの接続料半額くらいに下がったとニュースで聞いたんだが、どこがマージン取ってるんだ?
携帯電話の料金は下がった。
光回線はどうにかならんのか。
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策(不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス)を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる(スキャン自体は1日1回のみ可能)
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
noteの売上金の有効期限が180日になるようです。180日を超えると自動的にAmazonギフト券に交換されるらしい。
これまでのnoteの不誠実な対応(IPアドレス等個人情報漏洩(事故そのものよりもそれへの広報がムッとなった)や、cakesの各種炎上)があるし、データポータビリティへの意識の低さ、などの印象があり非常に心証が悪かったが、ユーザーの売上をできる限り消滅させないという姿勢は良しとするものの、もっと前段での問題があると思うので、うううーんという気持ちになっている。具体的には、noteの投げ銭(サポート機能)の扱いは資金決済法に関連した問題をはらんでいると思う。
正面切って「我社の投げ銭機能は合法です!」と言い張れる投げ銭機能はほぼない、という立場をとったとしても、noteの投げ銭機能は法的には黒なんじゃないかと思っている。この辺り結構ややこしいが、以下の3点がポイントになるだろうと思う。
まず現金化できることが問題のトリガーになる。これが例えばアマゾンギフト券交換だけなら問題ない。なぜなら為替取引ではなくなるので。上で触れた資金決済法に抵触しないのであれば問題は一切ないと言える。
コンテンツ販売収益をユーザーに還元するスキームは、収納代行と考えられる。noteはあくまでユーザー間の取引を安全に行うための場を提供するだけであり、資金の移動は「コンテンツの販売」という役務の提供に付随するものなので、このような収納代行スキームは昨今の流れからも問題のないものと考えられる(すでに一般的な取引と思われている収納代行(メルカリ等)も為替取引なのでは?という議論が行われるくらい慎重に進められているので、こういう大丈夫じゃないっすかね表現になる)。
有効期限を180日に設定したのも、収納代行スキームにおいては受け取った代金を必要以上に残しておいてはいけない(資金決済法の趣旨は利用者の保護である。収納代行では前払式支払証票などによる供託金による資産の保全義務がない。そのため、必要以上の期間支払金をプールしておくことが法の趣旨に反する)ということにようやく気がついた、ということだろうと思う(個人的には180日でも長すぎると思う、メルカリはこの問題で90日に変更した)。
しかし、投げ銭については疑義がある。noteの想定スキームは、「投げ銭とともに投稿者にメッセージを送れる」「サポートのアイコンを表示できる」などの役務を提供している、ということだろうと推測している。しかしながら、「投げ銭の価格を自由に設定できる」ので、そもそも役務に対する正当な価格が定められていない、ということになる。対価に対応した役務が提供されていないにもかかわらず(経費を控除した上で)全額為替として受け取ることができるのは、脱法的、というよりもはっきりと資金移動に当たるんじゃないか?と思う。
また、上記のような性質の違いがあるにも関わらず、コンテンツ販売収益と投げ銭収益を一緒くたに取り扱っていることもポイントであると思う。note的には実装上の楽をし、合法的な収納代行のスキームに投げ銭機能を潜り込ませることで、グレーな感じを演出しているのじゃないかなー。
投げ銭の現金化について違法性があったので取りやめて、今後Amazonギフト券交換に限定したとしても、まだ問題はある。投げ銭によりプールされたポイントは、未使用の前払式支払証票となり、投げ銭の売上は自家型の前払式支払手段と判断されるだろう。noteは資金決済法的な対応は一切していないのだ。
自家型の場合、未使用残高が1000万円以下が適用除外になり、法的な対応は必要なくなる。ただ、noteの場合、これまでずっと有効期限なしで投げ銭を受け続けており、かつ振込手数料あるので、換金せずに貯めてるユーザー多いのではないかな…本当に未使用残高1000万超えてないのかな…というのは疑問。超えてて資金決済法の対応を行わず、かつ利用規約の変更で有効期限を6ヶ月以下に設定し(有効期限が6ヶ月以下の前払式支払手段は法の適用対象外になる)、法の適用対象から逃れようとするの、めちゃくちゃずるくないか?と思ってしまう。いや、まあ未使用残高が1000万円を超えているかは外野からはわかんないので、下衆の勘繰りといえばそうだねという感じではあるよ…。まあ、この辺もうちょっと説明したほうが良くないか、とも思う。
いい記事にいいフィードバックが還るのは尊いと思うので、機能が提供されているのはいい。が、法を無視して進んでいくと利用者は法で定められる保護が受けられなくなるし、善良な企業が馬鹿を見るので、良くねえと思っているよ。
公取委が個人情報保護委員会とは別にオンラインサービス規制を提案して、「サービスの対価として自らに関連するデータを提供する消費者」とか言い出してるけど、EUでも似たようなことが起きてたらしい。
欧州委員会がオンラインサービス規制のための新しい指令を起草して、そこで「消費者がサービスの対価を個人データで支払う……」とか書いてしまった。これに対し、欧州データ保護監督機関が「何すんじゃワレェ!」したのが以下の見解である。
https://edps.europa.eu/sites/edp/files/publication/17-03-14_opinion_digital_content_en.pdf
EDPSはデータ駆動経済について、EUの成長のために重要であること、デジタル単一市場戦略として唱道されるデジタル環境において抜きんでていることを認めております。消費者法とデータ保護法とが共同し相補しあう関係にあることは私たちが一貫して論じてきたところであります。ですから、「デジタル商品」の提供を受ける条件としてデータを差し出すことを要求される消費者の保護を強化するために、デジタルコンテンツの供給にかかる契約に関する特有の側面にかかる2015年12月の委員会指令プロポーザルの意図しているところを、私たちは支持しております。
しかしながら、この指令のある側面は問題をはらむものです。というのも、これが適用可能なのは、デジタルコンテンツのために価額が支払われる場合だけではなく、デジタルコンテンツが金銭以外の個人データその他何らかのデータの形での反対給付と引き換えに供給される場合にも適用可能だからです。EDPSは、人々が金銭を支払うのと同じように自分達のデータを支払えるという考え方を導入するような規定を新たに定めることのないよう警告いたします。個人データの保護を受ける権利のような基本権は、単なる消費者利益に縮められるものではありませんし、単なるお値打ち品のように個人データを捉えることはできません。
最近採択されたデータ保護フレームワーク(以下「GDPR」といいます)は、未だ完全には適用可能でなく、新しい e-Privacy 制度は今も審議中でございます。ですから、EUとしては、立法者が協議されている入念なバランスをひっくり返すようなプロポーザルは、何であれ避けるべきものです。イニシアティブの重複は、デジタル単一市場の統一性を意図せずとも損ない、規制の断片化と法的不確実性をもたらすことになりかねません。デジタル経済における個人データの使用を規制する措置として、EUがGDPRを適用することをEDPSは推奨いたします。
「反対給付としてのデータ」という概念……このプロポーザルでは未定義のままです……は、所与のトランザクションにおけるデータの正しい機能について混乱を引き起こす恐れがございます。この点で供給者から明瞭な情報がないため、さらに難しいことになるでしょう。それゆえ私たちは、この問題を解決する一助として、EU競争法におけるサービスの定義を一考することをお勧めしますが、その地域範囲を定義するうえでGDPRの用いている規定が役立つかもしれません。
本見解では、このプロポーザルがGDPRとどのように影響し合うことになりうるかを検証いたします。
第一に、データ保護制度に基づく「個人データ」の定義が広範であるため、その効果により、この提案指令の対象となるデータが全て GDPRに基づく「個人データ」とみなされることは十分にありえます。
第二に、(個人データの)取扱いが発生する厳密な条件はGDPRで指定済みであり、この提案指令に基づく修正や追加を必要としておりません。このプロポーザルは反対給付としてデータを用いることを正当とみなしているようですが、GDPRでは、例えば、(本人の)同意の有効性を検査し、デジタル取引の文脈において(同意が)自由意思に基づくとみなしうるか決定するための、新たな条件を一式用意してございます。
最後に、消費者に与えるものとして提案されている契約終了時に供給者からデータを取得する権利と供給者がデータ使用を控える義務は、GDPRに基づくアクセス及びポータビリティ権やデータコントローラのデータ使用を控える義務とオーバーラップしている可能性があります。このことで、適用する制度について意図しない混乱をもたらすことになりえます。
https://edps.europa.eu/sites/edp/files/publication/18-10-05_opinion_consumer_law_en.pdf
本見解は、EU消費者保護規則のより良い執行と近代化に関する指令のプロポーザルと、消費者の集団的利益の保護のための代表訴訟に関する指令のプロポーザルからなる「消費者のための新しい取引」と題する立法パッケージに関するEDPSの立ち位置を概説しています。
EDPSは、目標において最近近代化されたデータ保護フレームワークと密接した領域で、既存の規則を近代化しようという同委員会の意図を歓迎します。EDPSは、個人データの大規模な収集と収益化、およびターゲットコンテンツを介した人々の注意の操作に依存するデジタルサービスの主要なビジネスモデルが提す課題に対応するために、現在の消費者法におけるギャップを埋める必要性を認識しています。 これは、消費者法を改善して、個人とデジタル市場の強力な企業との間で拡大している不均衡と不公平を是正する、またとない機会です。
特にEDPSは、指令2011/83 / EUの範囲を拡大して、金銭的な価格にて提供されないサービスを受ける消費者が、同指令が提供する保護フレームワークの恩恵を受けることができるようにする意図を支持いたしますが、それはこのようなサービスが今日の経済的な現実とニーズを反映しているからです。
このプロポーザルでは、EDPS Opinion 4/2017の推奨事項を考慮して、「反対給付」という用語の使用や、消費者によるデジタルコンテンツのサプライヤーへのデータ提供が「積極的」か「受動的」か区別することを控えています。ただしEDPSは、プロポーザルで想定されている新しい定義により、消費者がお金で支払うのではなく、個人データで「支払う」ことができるデジタルコンテンツまたはデジタルサービスの提供に関する契約の概念が導入されることに懸念を示しています。この新しいアプローチは、「反対給付」という用語を使用したり、個人データの提供と価格の支払いを類推したりすることで生ずる問題を解決していません。特に、このアプローチは、個人データを単なる経済的資産とみなしているために、データ保護の基本権としての性格を十分に考慮していないものとなっています。
GDPRでは既に、デジタル環境にて個人データの処理が行われ得る状況に関するバランスを既に定めています。 このプロポーザルで、GDPRで定める個人データを完全に保護するとのEUのコミットメントと矛盾するやり方で解釈される可能性のあるアプローチを促すようなことは避けるべきです。データ保護法の原則を損なう危険を冒すことなく幅広い消費者保護を提供するために、電子商取引指令における「サービス」の広範な定義や、GDPRの地域範囲を定義する規定、もしくデジタルコンテンツ・プロポーザルに関する理事会一般アプローチの第3条(1)などに基づくアプローチで代替することが考えられます。
したがいまして、EDPSは、「有形媒体では提供されないデジタルコンテンツの供給に関する契約」や「デジタルサービス契約」の定義にて個人データを参照することを何であれ控えていただくことを推奨し、その代わりとして、次のような契約の考え方に依拠することを提案します。 それは、「消費者への支払いが必要かどうかに関係なく」特定のデジタルコンテンツまたはデジタルサービスを売り手が消費者に提供または提供することを約束するというものです。
きちんと追えていないが、「EU消費者保護規則のより良い執行と近代化に関する指令」は、昨月末に採択されたようで、前文に「digital services provided in exchange for personal data」という表現が残ったものの、個人データについては「GDPRに従う」とのことで落ち着いた様である。
http://mixi.jp/release_info.pl
「mixi Platformの開放」においては、まず、2008年12月11日(木)より mixi アプリのパートナー向けβ版の提供を開始し、2009年春には正式版を公開する予定です。
2008年12月10日(水)より、15-17歳の方々が『mixi』をご利用出来るように年齢制限を引き下げることになりました。
株式会社ミクシィ | PRESS RELEASE
http://mixi.co.jp/press_08/1127.html
概要図
お知らせ「より開かれた SNS を目指して」
http://mixi.jp/guide_openmixi.pl
従来のSNSは閉じたものが多く、FaceBookなど開かれたものであっても、SNS間の連係がとりにくい(データ・ポータビリティや認証の問題)
という意味では閉じている点が多かった。
でも、今後は(今回のmixiの革命に合わせて)連係がとりやすいようなSNSが広まっていって、検索・閲覧も透過的に行えるようになっていく、という流れなんだろうね。
某自動車会社はデザイン開発に女性を大量投入して細かい所の設計をやらせたら
車の売れ行きが大幅にあがったんだと。
女性を投入することによって
・乗り物として、より空間としてどう心地よくすごすのか(室内のミラーの場所やら小物入れの場所の設置やらドアのデザインやら。)
・助手席に必要なアメニティ
等今まで考慮に入れてなかった点を考慮し始めたのが功をなしたらしい。
車を買うのは男性が多いが、どの車を買うかの決定については男性の配偶者や家族の意見が如実に現れる。つまりカミさんの意見。
決定権を握るカミさんは女性だから、女性の意見を数多く引き出して、それを反映した物を作れば当然売れ行きは上がるよね。
これは車だけじゃなくて何でもそうなのだけど、男性はどれだけ高機能かについては興味は示すけどどんなデザインであるかとか使い勝手のよさ、分かりやすさには購買思慮の重点を置かないのにたいして女性は機能に含めて(機能も使い勝手が悪ければ排される場合あり。)配色、デザイン、ポータビリティなど機能を使用していない時でも心地よい気分でいられるもの対して購買思慮の重点を置く傾向が高い。(これは自分の意見じゃなくて本の受け売りね。)
更にいうと、既婚男性は家族の意見を聞いて購入する傾向が高いけれど女性は独断で購入する場合も多い。
だから、マーケティングを考える時その次の年の女性のニーズをリサーチしてつかむのは重要、ってのは習ったよ。会社で。実践で。
2008年09月28日 ocs 増田 LLFutureでも語られてたけど、RoRは進歩が早すぎるという暗黒面があるらしい。http://www.ey-office.net/public/LLFuture2008.pdf
進歩するのはいいんだけど、互換性が軽視されてるってのはどうなんだろう。リンク先読むと、互換性はない、古いバージョンはメンテされない、サーバーのリブートは毎日と書いてある。要するに枯れるまで触らない方が安全ってことか。
2008年09月28日 ezookojo 特定の記事が書かれた当時の手順のままで動作しなければならないRailsかわいそうです / とか言ってるとオフィシャルのREADMEやガイドページだったりする
一人ツッコミやってるので、補足するのもなんだけど。ダイアログの手順が少々変わったくらいでうろたえている訳じゃなくて、指定されたサイトから最新のパッケージをダウンロードして、そのパッケージにとって正しいと思われる手順を実行したら、動かなかった。
2008年09月28日 dbfireball 増田 Railsすごいよ!って言ってた去年あたりだったら、マジで10分でした。そこから色々アップデートされてその通りにやってもできないっていう状況。
参考にしたのは10分で作るRailsアプリfor Windows。やっぱり互換性がなくなってるんだ。
2008年09月28日 takeshiketa takeshiketa RoRラブな俺だけど、同意。RoRは導入コストで語るんじゃなくて、手になじんだ後の生産性で語るべき
うーん。ラブな方も現状については同じ意見。手になじんだ後の生産性ってのは一見わかる気もするけど。作った後のメンテナンスは誰がやるんだろう。導入コストは低くないと言ってるみたいだけど、互換性軽視の開発が続く中で、デベロッパの手をなじませ続けるラニングコストはどうなんだろう。
2008年09月28日 FTTH # |ω・)…… ハイハイハイ俺も云いたいです!! RoRの機構使うよりSQLベタ書きの方がポータビリティもメンテナンス性も良いと思います! バックエンド意識しないでいいようなアプリなんてどうせその程度です!!
ポータビリティもメンテ性もべた書きより劣るフレームワークって…。
幸いITのプロじゃないので他人ごとなんだけど、RoRで業務サイトを構築している人が居るってのは、少々寒気がする。肝が据わってるのか、想像力がないのか、それとも俺が思っているよりずっと人月って金がかからないのか。