iOSとmacOSの両方で動作するアプリケーションを開発できるよう、Appleが技術開発を進めているという（GIGAZINE、Bloomberg、Ars Technica）。

このプロジェクトは「Marzipan」と呼ばれており、順調に行けば来年夏の開発者向けイベントWWDCで発表される見込みだという。この技術を利用することで、利用者はMacとiPhone、iPadなどで同じアプリケーションを利用できるようになる。また、iPhone/iPadではマウスやタッチパッドが使えず、逆にMacではマルチタッチが利用できないという課題もあるが、これを解決するような仕組みも導入されるようだ。

Googleは19日、Google Playで新規公開/更新するAndroidアプリについて、2018年の後半から最新APIをターゲットにすることを必須とするなどの変更を発表した(Android Developers Blogの記事、 Ars Technicaの記事)。

Androidの新しいAPIではさまざまなセキュリティの改善が行われているが、アプリのAndroidManifest.xmlで「targetSdkVersion」に指定したAPIレベルよりも新しいAPIの動作はサポートされない。たとえば、Android 6.0(API 23)では実行時パーミッションが導入されているが、「targetSdkVersion」に23以上のAPIレベルを指定しなければ利用できない。逆にAPIレベルを22以下にして実行時パーミッションを使用しないといった方法が紹介されることもある。

変更はアプリのセキュリティやパフォーマンスを改善し、アプリエコシステムの断片化を低減させることが目的だという。まず、2018年8月には新規アプリで、11月には更新アプリでターゲットAPIを26以上にすることが必須となる。2019年以降はAndroidの新しいデザート(メジャーバージョン)のリリースから1年以内に、対応するAPIレベル(またはそれ以降)をターゲットにすることが新規/更新アプリで必須となる。

AppleがApp Store審査ガイドラインを改定し、APIの使用やガチャ(loot box)の提供、テンプレート/アプリ生成サービスを使用して作成したアプリに関する記述を追加したほか、VPNアプリに関する項目を追加している。なお、日本語版のガイドラインにはまだ変更が適用されていない(英語版ガイドライン、 9to5Macの記事)。

利用可能なAPIに関する2.5.1には、HomeKitやHealthKitを例にAPI/フレームワークが意図した用途にのみ使用し、API/フレームワークを統合した旨をアプリの説明に記載すべきだという記述が追加された。App内課金に関する3.1.1にはガチャのような仕組みを提供するアプリは顧客が購入する前に各アイテムが当たる確率を公表する必要があるとの記述が追加されている。

あるAnonymous Coward曰く、

米Microsoftは12月15日（米国時間）から、Excelにプログラミング言語「Python」を搭載するかを検討するため、ユーザー向けにアンケートを実施している。「需要についてよりよく理解するため、情報を集めたい」という（ITmedia）。

2015年11月に提案された「Excelで、スクリプティングやフィールド関数にPythonが使えるようにならないだろうか」という要望には、17年12月18日現在、約4000票が集まっている。デスクトップアプリケーションの要望の中では最も多くのユーザーが支持している。

これを受け、Excelチームは15日に「このトピックについての継続的な熱情に感謝します」として、ExcelがPythonを搭載したら何に使うか、どんな影響があるかなどを問うアンケートを設置した。

Pythonは、機械学習やデータ分析の分野で主に使われるプログラミング言語。ExcelにPythonが搭載されれば、Excelでより高度なデータ分析やビジュアル化が可能になるという見方もある。

ECMAScript（JavaScript）の新規格として提案されているものの1つに「Pipeline operator」がある。これは「|>」という演算子を利用して()を使わずに関数に引数を与える仕組みなのだが、これを利用することで「[」「]」「+」「|」「>」の5文字だけで任意のJavaScriptコードを記述できるという（5文字で書くJavaScript/ Shibuya.XSS techtalk #10）。

今までも「[」「]」「(」「)」「!」「+」の6文字で任意のJavaScriptコードを記述するという手法「JSFuck」があった。今回紹介されている手法はこれの応用で、|>演算子を利用することで使用する文字を5文字にまで減らしたというもの。手法としてはECMAScriptの組み込み型や組み込み関数などから「[」「]」「+」「>」の4文字を使って文字を取り出し、それを結合することで任意の文字列を作り、|>演算子でそれを呼び出す、という流れになっている。

あるAnonymous Coward曰く、

アルファベット小文字だけのパスワードは簡単に推測される可能性があるため危険、というのは昨今では十分広がっていると思うが、いっぽうでサービス・システムごとに利用できる文字種の制限が異なることが多い。ほとんどのシステムではアルファベット大文字・小文字と数字は利用できると思われるが、それ以外の#や@、-、_、\、+、*などの記号については使える場合と使えない場合がまちまちだ。しかし、こういった制限はなぜ行われているのだろうか？

teratailでの質問についてはいくつかの回答が寄せられているが、回答の1つに全角を許すと入力者が意図せず半角を入力してしまった際にエラーとなり、問い合わせなどが発生してサポートコストが増える可能性がある、というものがあった。これはそれなりに納得できる理由ではあるのだが、半角の一部記号が使えない説明にはなっていない。

もちろん、古いUNIXとの互換性という理由はあるだろうか、今でもそれを引きずる合理的な理由はあるのだろうか？

Microsoftからのアナウンスは特になかったようだが、Windows 10 Fall Creators Updateではベータ版のオプション機能としてOpenSSHが利用可能になっている(STHの記事、 BetaNewsの記事、 Ars Technicaの記事、 Softpediaの記事)。

オプションとして用意されているのはクライアントの「OpenSSH Client (Beta)」とサーバーの「OpenSSH Server (Beta)」で、「設定」アプリの「アプリ→アプリと機能→オプション機能の管理→機能の追加」から追加できる。追加後はコマンドプロンプトやWindows PowerShellなどのコマンドシェル上で実行可能だ。ただし、実行ファイルのインストールパス(%SystemRoot%\System32\OpenSSH)がシステムのPath環境変数に指定されているため、管理者権限でコマンドシェルを起動するか、パスを指定する必要がある。

Microsoftでは2015年6月にSSHのサポート計画を発表し、同年10月にWindows版のOpenSSHをGitHubで公開した。この際、2016年前半にリリースする計画を明らかにしていたが、その後の進捗状況については発表されていなかった。今回、STHが発見したことで各メディアに取り上げられているが、コマンドヘルプ以上の公式な情報は特に出ていない。

headless曰く、

GoogleがAndroid Developersサイトで公開しているプラットフォームバージョンごとのデータによると、Android 6.0 Marshmallowのシェアが30%を割り、メジャーバージョン1位～3位が20%台で並ぶ形になっている。

今回のデータは12月11日までの7日間にGoogle Playアプリが収集したもので、0.1%未満のバージョンは除外されている。1位のMarshmallowは1.2ポイント減の29.7%となり、2月に30%を超えて以来初めての20%台となった。2位のAndroid 5.x Lollipopは0.9ポイント減の26.3%、3位のAndroid 7.x Nougatは2.7ポイント増の23.3%となっている。

LollipopとNougatをバージョン別にみると、Android 5.0 Lollipopは0.3ポイント減の6.1%、Android 5.1 Lollipopは0.6ポイント減の20.2%。Android 7.0 Nougatは1.7ポイント増の19.3%、Android 7.1 Nougatは1.0ポイント増の4%で、Nougatの合計がAndroid 5.1 Lollipopを初めて上回っている。提供開始から3か月半が経過したAndroid 8.0 Oreoは0.2ポイント増の0.5%で、同時期のNougat（0.4%）よりも速いペースでシェアを獲得している。

このほかのバージョンでは変動なしのAndroid 4.3 Jelly Bean（0.9%）とAndroid 4.0.x Ice Cream Sandwich（0.5%）を除き減少している。Android 4.4 KitKatは0.6ポイント減の13.4%、Jelly Bean合計（4.1.x～4.3）は0.3ポイント減の5.9%、Android 2.3.x Gingerbreadは0.1ポイント減の0.4%となった。

Nougatは4月以降毎月2ポイント以上の増加が続いており、年明けにはLollipopを上回る可能性もある。

あるAnonymous Coward 曰く、

京都市の基幹系システム刷新プロジェクトが遅延し、京都市がその原因とされたシステム開発業者のシステムズ社との契約を解除したことは以前報じられていたが、京都市が同社を提訴する方針を固めたようだ（日経ITpro）。

京都市は支払った金額の一部や損害賠償金など合計約8億円の支払い求めるという。いっぽうのシステムズ社はすでに京都市に対し未払い分の約2億円を支払うよう求め提訴しており、訴訟合戦となるようだ。

開発中のシステムについては別の業者に構築を委託するようだが、今回トラブルとなったバッチシステムのマイグレーション作業については難しい点が多く、作業をできるベンダーが少ないことも記事では指摘されている。

あるAnonymous Coward 曰く、

Mirosoftが「Microsoft Quantum Development Kit」を公開した。無償でダウンロードが可能。

量子コンピューティングを行うためのツール集で、専用言語「Q#」や作成したコードの実行やデバッグ、テストを行えるシミュレータ、コード集などあら構成されている。シミュレータはPC上で動作し、約30量子ビット程度までのシミュレートが可能だそうだ。また、Microsoft Azure上でより大規模なシミュレートも提供するという。

headless曰く、

正規のAndroidアプリの署名を維持したまま内容を改変できるというAndroidの脆弱性「Janus」を発見者のGuardSquareが解説している（GuardSquareブログ、BetaNews、Register）。

Androidのアプリケーションパッケージ（APK）ファイルはZIPファイルであり、ZIPエントリの外側に任意のデータを挿入できる。しかしJAR署名スキームではZIPエントリのみを使用して署名の整合性を確認するため、ZIPエントリの外にデータが挿入されても署名は有効のままとなる。一方、Dalvik実行可能ファイル（DEX）は末尾に任意のデータを追加できる。そのため、DEXファイルの末尾にAPKファイルをつなげて1つのファイルにすることでDEXファイルとしてもAPKファイルとしても有効なファイルとなり、署名も維持される。

AndroidランタイムはAPKファイルからDEXファイルを抽出して実行するが、ファイルの種類を識別する際にDEXヘッダーを見つけるとDEXファイルとして実行してしまうのだという。Androidでは署名が異なるAPKファイルでインストール済みアプリをアップデートすることはできないが、悪意あるDEXファイルを正規のAPKファイルと組み合わせることで、正規のアップデートとしてインストールさせることが可能となる。こういったAPKファイルがGoogle Playで配布されることはないものの、ユーザーをだましてインストールさせることで、高い権限を持つシステムアプリを置き換えたり、バンキングアプリを偽物に置き換えたりといった攻撃が可能だ。

Android 5.0以降がJanusの影響を受けるが、Android 7.0以降で利用可能なAPK署名スキームv2ではAPKファイル全体が署名の検証対象になるため、v2署名を使用したアプリは影響を受けない。GuardSquareではこの問題を7月31日にGoogleへ報告しており、12月のAndroidセキュリティアップデートでCVE-2017-13156として修正されている。

argon曰く、

政府が天皇陛下の退位日を2019年4月30日とする政令を決定、5月1日より新元号となることが決まりました（朝日新聞、毎日新聞、NHK）。

これに対し、その対応について大手システムベンダーがコメントを出しました（日経ITproの記事1、記事2）。

これによると、NTTデータは「元号改正による修正は限定的」、日立製作所は「平成から新元号への対応は比較的容易」としているいっぽう、富士通は「洗い出しとテストの負荷が大きい」としています。

NTTデータや日立製作所は作業工数が不要だと受け取られそうな不用意なコメントですが、富士通は調査やテストの工数について言及していてさすがだなと思いました。

1月ほど前、Googleは一般ユーザー向けのAndroidアプリでユーザー補助サービスの使用を一切認めない旨の通知をアプリ開発者に送り、30日以内の対処を求めていると報じられたが、この方針が緩和されるようだ(Redditのスレッド、 Ars Technicaの記事)。

Redditユーザーが公表したGoogleからの電子メールによれば、現在Googleではユーザー補助サービスの責任ある革新的な使用について評価を行っており、評価が完了するまで30日間の期限は一時停止するとのこと。また、ユーザー補助機能を必要とするユーザー向け以外の機能で「BIND_ACCESSIBILITY_SERVICE」パーミッションを使用する場合、ユーザーの行動を監視する理由や、ユーザー補助サービスの各機能を必要とするアプリの機能の説明をパーミッション宣言の「android:description」に追加するよう求めている。

さらに、ユーザー補助サービスの責任ある革新的な使用をしていると考えるアプリの開発者に対しては、それがどのようにユーザーの役に立つのかを返信してほしいとも述べている。このようなフィードバックは、Googleがユーザー補助サービスの評価を完了するうえで助けになるとのことだ。

SiriとAlexaがユーザーからのセクハラ質問に毅然とした態度をとるよう、AppleとAmazonにプログラム変更を求めるオンライン署名運動をCare2が実施している(VentureBeatの記事)。

ほとんどのパーソナルデジタルアシスタントはデフォルトで女性の声が使われており、ユーザーのセクハラ質問に遭うことも多いようだ。Quartzの記事ではSiriとAlexa、Cortana、Google Homeを使い、各種セクハラ質問に対する応答内容を調査しているが、セクハラ質問にデジタルアシスタントが毅然とした態度で応答することは少なく、受け流した応答をすることが多かったという。時には喜んでいるかのような応答も聞かれたとのこと。

Care2では実際の人物ではないデジタルアシスタントが傷つくわけではないとしつつ、応答内容はセクハラを受けた現実の女性が仕事を続けるために見せる態度と同じようなものであり、セクハラが許容されている現状を変えるためにはデジタルアシスタントも毅然とした態度で応答すべきだと考えているようだ。目標の署名件数は1万件。9日夜の時点で9千件を超えている。

Androidアプリの開発に使われるIDEやAPKファイルの分析などに使われるツールにおけるXMLパーサーの処理に関連した脆弱性「ParseDroid」について、発見したCheck Point Researchが解説している(Check Point Researchの記事、 The Registerの記事[1]、 [2])。

Check Point Researchでは当初、Apktoolを調査していたという。ApktoolはAndroidのアプリケーションパッケージ(APKファイル)のデコンパイルとビルドが主な機能で、サードパーティアプリのリバースエンジニアリングによく使われるツールだ。ソースコードを調べたところ、XMLパーサーで外部実体参照(XXE)が無効化されておらず、細工したAndroidManifest.xmlを含むAPKファイルを処理させることで攻撃者が任意のファイルを取得できることが判明する。