ふろしき Blog

コンテンツサービスを科学する株式会社ブートストラップ代表のブログ

Firefox向けWebシステム開発でできること・できないこと

Windows 7時代のWebシステム開発は混沌としています。

IE8を標準ブラウザとしてサポートしてしまったユーザ企業は、IEがシステムのライフサイクルをカバーできるだけのサポート期間を確保できなくなるため、+αの対策無くして開発を行うことができません。
(※参考 : 企業システムの2020年問題 - ふろしき.js )

IE8標準ブラウザとして採用した企業は、今後システム開発時に、以下の選択が求められます。

  1. IEをアップグレードする。
  2. Windows 7の移行日までをシステムのサポート期間とする。
  3. IE8とIE9以上(FireFox/Chrome)で動くように作る。
  4. Firefox/Chromeのみ対応にする。

本記事では、4番の対策のニーズを埋めるため、「Firefox向けWebシステム開発」でできること/できないことについてまとめてみました。

1. サポートライフサイクル→ESR(1年周期)

バージョンアップの多いFirefoxでは、7バージョン刻みでESRと呼ばれる、機能追加/変更の無い、純粋なセキュリティパッチを中心としたサポートが提供されています。現在は、明確に法人向けという位置づけでリリースが行われているようです。

このサービスは以前、OSS感が非常に強くエンタープライズ系の場合に抵抗を感じる方も多かったようですが、24リリースで空気感がガラっと変わっています。加えて、ESRのリリース方法もやや変更された模様です。17以前を評価したことがある方は、確認し直した方が良いかもしれません。ここ最近、本当にびっくりするほどMozillaもビジネス色が強くなりましたね。

>> FirefoxとThenderbirdの法人向け延長サポート

これまでESRは、3.6→10→17→24と刻まれました。ESRのアップデート内容について、例えば24系のESRのリリースノートを覗いてみると、以下のような更新がされています。

▼ 24.1.0 ESR

セキュリティアップデートです。詳細はセキュリティアドバイザリをご覧ください。

▼ 24.1.1 ESR

NSPR が 4.10 から 4.10.2 に更新されました。 (Bug 935568)
NSS のバージョンが 3.15.3 に更新されました。 (Bug 935959)
24.1.0 で翻訳されていなかったユーザインタフェース中の項目が翻訳されました。 (Bug 932310)

▼ 24.2.0 ESR

いくつかのセキュリティ問題が修正されました。

本当にセキュリティが中心ですね。

IEの場合はWin7版がOSと同じライフサイクルを持っているため、1年周期のアップグレードが求められるのは短く感じ、マイナスとも捉えられるかもしれません。しかし、IE8が邪魔してライフサイクル破壊が起こっているケース、新しい機能を使いたいケースでは、リスク保有してでも使いたい場合があるように思えます。

2. ブラウザ設定ファイル配布手段→プロファイル

Firefoxでは、設定情報をプロファイルとして扱い、一つのフォルダに固めて配置します。このアイデアは、Firefoxの非常に優れているところであり、逆にデメリットも作ります。複数のバージョンを一つのOS上で同時に扱えるマルチバージョン化が行えたり、IT管理者がカスタム済みのFirefox設定をシステム利用者の設定を破壊せずに配布することができます。IEのIEAKの代替と呼ぶには自由過ぎとも捉えられます。

f:id:furoshiki0223:20131215084958p:plain

前者のマルチバージョン化について、古いバージョンのものはセキュリティパッチが当たらなくなるため、生かすこと自体がそもそも邪道でしょう。しかし、技術的には可能で、リスクアセスメント上許容される可能性もあるため、選択の一つに加えることは決して間違いではないように思えます。特に、古いバージョンで動かしていたものが新しいバージョンで動かなくなってしまった場合には、動かないシステムだけをブラウザレベルで切り離すという対策が行えたり、しかもそれがOS跨ぎで行えたりと、バージョンの縛りから逃れられるという点ではIEよりも高い柔軟性を発揮しています。複数バージョンを混同させ、それぞれに独立した設定が行えるIEAKというイメージです。

後者のカスタム済みFirefox設定の配布について、IEの機能領域は殆どと言って良いほどカバーできていませんが、IEとはまた違った意味でのカスタム化が行えます。Windows特化の領域はIEが勝り、OSレイヤーに依存しない領域はFirefoxが勝るという状況です。また、複数のプロファイルを切り替えて動かすこともできます。設定を上書きするのでなく、混在できるIEAKというイメージです。

そもそもですが、Firefoxにはプラグインだけでなくアドオンという文化があり、ユーザ側でのカスタマイズ性の高さはIEの比にならないでしょう。IT管理者から見ると、このカスタマイズ性の高さにセキュリティリスクという壁を作ってしまいます。ただ、Firefoxの場合はそもそもプロファイルレベルでなく、GeckoエンジンそのものをFirefoxの箱から切り離してしまおうというアイデアがあり、IEAKよりもガチガチなカスタマイズ(むしろ改造というレベル)はこちらのアイデアが使えるように思えます。(→詳しくは次章へ)

プロファイルについては、このページがわかりやすく説明されています。
>> プロファイルの管理 - Mozilla Support
>> 設定情報のバックアップ - Mozilla Support

3. カスタマイズ→XULRunner

Firefoxの自由過ぎるカスタマイズ性については前章で説明しましたが、IT管理者としてはやはり頭が痛くなる問題です。しかし、道がないわけではありません。Firefoxはこのようなニーズに対しては、レンダリングエンジンレベルでどうこうしてしまおうという考え方のようです。しかも、IE6時代には多かったいかにもネイティブみたいな開発、例えば「戻るボタン」の封印など、ブラウザ側の機能制限というタブーを、Firefoxは正攻法として実現できてしまうという、開発者・IT管理者的に歓迎される強い制限を与える柔軟なカスタマイズ性を持ちます。それを、手っ取り早く簡単に作り込めるのが、XUL Runnerです。

f:id:furoshiki0223:20131215064331p:plain

XULRunnerは、Geckoエンジンを入れる箱の部分(ウィンドウやGeckoの制御)の開発を楽にしてくれるツールです。カスタムブラウザのようなものを作るのには、それなりに充実した機能を提供しています。

また、XULは本来デスクトップアプリを作るためのものであるため、Webシステムのフロントエンド部分のソースコードをローカル内に配置して、.NETみたいにオフライン動作させてしまうことも可能です。(※ Firefoxが比較的、ローカルHTMLファイルに対するファイルアクセスのセキュリティが低いのは、これが理由な気がします。)

XULと言うと、MicrosoftのSAMLのような雰囲気を感じますが、だいたいその認識で合っています。ただ、Microsoft側はこの手の技術でいかにもWeb技術っぽい呼び名を頻繁に使うのに、MozillaはXUL Runnerという独自っぽい呼び名を使っているのは、かなり損しているような気がします。XUL Runnerという名前ですが、エンジンはGeckoなのでHTML/CSS/JSは普通に動くという点で勘違いしない方が良いかと思います。

XULRunnerについては、以下のページで説明しています。
>> XULRunner - ふろしき.js

XULRunnerではGeckoエンジンをパラメータレベルではそれなりにグリグリといじれ、ブラウザっぽい動作を奪うことが可能ですが、Firefoxの見た目そのままで少しだけ変更というのは難しいでしょう。そもそもですが、CUIベースな設定を必要とし、GUI慣れした人には取っ付きにくいという問題を持ちます。明らかにXULRunnerを用いたカスタマイズには、知識のある開発者の力が必要です。

4. IT管理者による集中管理→Active Directory

Active Directory連携のエクステンションがサードパーティで出ているようですが、以前試した時動くとこまで行かなかったため、未検証です。情報あれば、よろしくお願いします。

村地氏(@hebikuzure)のこの辺りの記事が参考になるかもしれません。

5. レガシーIE向けシステムの維持手段→無し

レガシーIEに含まれているActiveXオブジェクトですが、Firefoxでも動作させるという裏ワザ的手段が提供されています。

>> ff-activex-host(Firefox plugin)

ただ、Firefoxも一時は空気を読んで(恐らく嫌々)IEの独自動作に合わせた所もあったようですが、レガシーIE向けWebシステムの最大の懸念点である、独自実装API「attachEvent」を頑として拒否し続けてきました。Operaも昔はサポートしましたが、現在はWebKitになったため諦めなくてはいけないでしょう。

IE11から削除されたattachEventは、やはりというか当然と言うべきか、Firefoxも救ってはくれないようです。ActiveX以前に、この方向性のソリューションとしてのFirefoxは、諦めた方が良いように思えます。

6. ベンダーサポート→サードパーティ

窓口サポートも、以前はアシスト社ぐらいしかイメージがありませんでしたが、今はかなり多くの企業が参入してきており、Firefoxというブランドを活かしたフランチャイズ的ビジネスが出来上がっているように見えます。

サポートメニューとしては公式には4種類に分類していますが、内容を要約すると以下の3種類に見えます。

  • テクニカルサポート
    • トレーニングメニュー。システム利用者向けカスタマーセンターとしても機能する模様。
  • Web コンテンツの修正・標準化
    • IE特化の部分を削除し、長いライフサイクルが保証された標準準拠型Webシステム開発/移行の支援。
  • 製品開発
    • プラグインを作ったり、企業特化のカスタマイズブラウザの開発。

企業サポートについては、以下のページで説明しています。
>> 法人向けサポートのご案内 - Mozilla

最後に

Firefoxは、オープン系という特性を活かしたエンタープライズ向けのサービスを別の方向から取り込んでいたり、Firefoxだからこそできることがあったりと、なんだかんだ言ってもエンタープライズという世界では、IEとはガチで戦えるほどのポテンシャルを得ているようにも思えます。IEもFirefoxも、レンダリングエンジンという世界では平坦化が進みましたが、付随する機能・エコシステムは実に個性的です。

コスト最適化に何かしらの道を見出した企業、サービスの特性上現状維持でなく変化が求められてしまう企業では、スポットであれ完全であれ、何かしらのやり方で広がりを見せているようですね。Windows 7時代の混沌としたWebシステム開発の時代には、より注目を集めるかもしれません。

このブログの筆者について

川田 寛

コンテンツサービスの開発や運営代行を専門とする集団「株式会社ブートストラップ」の社長です。ネットではふろしきと呼ばれています。

2009年にNTTグループへ新卒入社し、ITエンジニアとしてクラウド技術・Web技術の研究開発と技術コンサルティングに従事。2015年よりピクシブに入社し、エンジニアリングマネージャー・事業責任者・執行役員CCOなど、様々な立場からコンテンツサービスの事業づくりに関わりました。2021年にメディアドゥへVPoEとしてジョインし出版関係の事業に関わったのち、2023年に独立しています。

関わってきたインターネット事業としては、ECサービスのBOOTH、UGCプラットフォームのpixiv(主に海外展開)、制作ツールのpixiv Sketch、VR・VTuber関連ではVRoid、Wikiサービスのピクシブ百科事典など、10を超える多様なCtoCコンテンツサービス。また、NTTドコモのすご得コンテンツ、メディアドゥのWeb3サービスであるFanTopなど、いくつかのBtoCコンテンツサービスにも関わってきました。

幸運なことに、私はコンテンツに関係する幅広いインターネットサービスのテクノロジー&ビジネスの知識を得ることができました。これを日本のコンテンツ発展に役立てたいと思い、株式会社ブートストラップを創業しました。

このブログでは現在、出版社やIPホルダー、ライセンサーといったコンテンツに関わる人々に向けて、インターネット事業に関するTipsや業界内のトレンドなどの情報を発信しています。私と話をしてみたいという方は、以下のフォームより気軽にご連絡ください。

お問い合わせフォーム