2017年1月15日日曜日

20170115時点でのHomebrewのインストール方法

MacにHomebrewをインストールするとき、検索するといろんな記事が出てくる。わざわざ追加するのも意味はないかもしれないが、インストール方法(正確には指定先のURL)がアップデートされているようなので、2017年1月15日でのインストール方法をメモしておく。

駄目な方

$ ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

行ける方 

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" 
今後も変更される可能性はあるので、 http://brew.sh/の「Install Homebrew」を参照するようにしたい。


macOS(OSX)のAppStore/インストール進行状況確認/Command Line Tools for Xcode

Command Line Tools for Xcodeを使うちょっとしたことが発生し、Xcodeをインストールすることになった。2017年1月15日現在、Xcoe V8.2.1は4.55G。AppStoreでXcodeを探し、「入手」をクリックすると「インストール中」となる。


小さいサイズのアプリケーションなら気にならないが、これだけのサイズだと時間がかかる。その後の進行状況はどうやって確認したらいいのか?これが唯一のやり方ではないが、答えは「LaunchPadを立ち上げる」である。


ダウンロード状況が確認できるので、止まっているのではないかといった心配はしなくて済む。なお、LaunchPadは、デフォルト設定のままなら、トラックパッドの「親指と3本の指でピンチイン」のアクションで立ち上がる。


結局、2時間ぐらいかかってインストールは完了した。ダウンロード中がインストール中に変わってからも少し時間はかかるが、我慢である。

最終目的物であったCommand Line Tools for Xcodeは別途インストールする必要があるかと思っていたのだが、メニューのXcode→Preferences...→Locationsで確認すると同時にインストールされるようになったようだ。



2017年1月9日月曜日

Webサイト簡易構築運用サービスでSSLを使う


簡易CMSという分野

Webサイト簡易構築運用サービス(以下:簡易CMS)」という分野がある。JimdoStrikinglyなどがそれにあたる。SaaS型のWebCMSを低価格(年ごと課金が主流)で使えるようにしたものである。機能や特徴の差は様々だが、Web専任の担当者がいないような、主に中小企業向けのWebサイトや、大企業でも単発的に利用する企画サイトなどに適している。変更がすぐに公開されたり、コンテンツ公開の承認ワークフローがなかったりと、大きい組織でルールを守って運用するには力不足だが、小規模組織ならは運用ルールで乗り切れるだろう。

中小企業のWebサイトもSSL対応は必要

ドメイン取得とDNSのサービスも組み込まれていることが多い。もちろん、お名前.comのようなレジストラで取得したドメインも利用可能だ。しかし、簡易CMS全般について言えるのだが、「SSL」での運用ができないという課題があった。中小企業ならWebサイトのSSL対応は不要と言い切りたいところだが、そう言い切るのは難しい理由がふたつある。

Pマーク

ひとつは、Pマークを取得している場合、問い合わせフォームに個人情報を入力する際に、暗号化されていることが望まれるからである。必須というわけではないが、そう指導されることが多い。Pマークなんて不要という考え方もあるが、業務の関係でPマーク取得を余儀なくされるケースも多い。この場合、フォーム無しで行くという選択もあれば、フォームだけ専用サービスとして外部化するという方法もある(フォーム専用サービスの場合、更に共有ドメインのケースとと専用ドメインのケースに分かれる)。しかし、身も蓋もない話をすると、簡易CMSの問合せフォームもフォーム専用サービスも、通知の際にメールが流れることが多く、そこに漏洩の可能性は残る。単に問合せがあったという通知がメールされるだけなら問題ないが、問い合わせ先の個人情報がメールに含まれるとすると、セキュリティ的な観点からはアウトということなのだが…

SEO

ふたつめは、SEO観点で常時SSL化されている状況が必要とGoogleが言い出したからである。実際のところSSL化が必要な理由は、個人情報保護だけではなく、サイト改ざん対策や、リファラー情報の受け渡しを考えるとWeb解析の精度を上げることができるなどの理由があるようだが、いずれにせよ、どこかの時点でWebサイト運用は、SSL前提が当然という時代が来たのである。

簡易CMSでもSSLは利用可能に

このような状況を受けて、業界最大手であるJimdoでは、2016年末にSSL運用対応が始まった。また、自分が愛用しているStrikinglyでも、SSL対応が可能となっている。元々、Strikinglyでは、Strikinglyでドメインを用意した場合にはSSL対応が可能であったが、他のレジストラでとったドメインでもCloudFlareを使って、SSL対応が可能になった。両サービスとも、共有でSSLを実現するためのSNIという仕組みになっているため、SSL証明書を別途購入して組み込むという作業は不要で、無料でSSL化が実現可能となっている。

CloudflareのSNIによるSSLについては、以下の記事が詳しい。
セキュリティの専門家はCloudfrareのSSLなんて危なくて使えないという意見もあるとは思うし、それはある程度正しいと思う。しかし、あまり健全ではないが、以下のような見解もあり得るだろう。

サイトをSSL化させる目的は、いろいろあって、本質的なセキュリティを実現するには無理もあるが、結局はWebサイトの訪問者を「少なくとも表面的に安心させる」ということが重要であり、Webサイトの構築運用業者の観点からは発注側に「SEOや安心させてコンバージョンを増やすというマーケティング観点でもSSL化が重要ですよ」と言えなくてはいけないのだ。それがあまり感心できないセールストークだとしても、である。たぶん、どんな種類のSSLを使っているかは訪問者はほとんど気にしないし、ほとんどの発注者もSSL化されているかどうかを気にするだけだろう。PマークのチェックのときもSSLの証明書の品質をチェックされるようなことはないと思われる。

結論

自社で簡易CMSサービスを使っていても、業者の立場で簡易CMSサービスを使っていても、サイトSSL対応は必須であり、そしてそれは可能になってきたのである。

JimdoとStrinkingly以外の独自ドメインSSL対応状況(2017年1月)