【Windows 10】ログイン時に2回もパスワード入力させられる

Fall Creators UpdateにしてからWindowsサインイン時にパスワードを2度要求さる問題について
私の端末だけだろうと思っていたら実家でも同様な事象が起きていて対応するために調べてみた。

毎回2回入力するのは確かにストレスだしねぇ〜

WindowsのフォーラムWindows10 Fall Creators Updateでログインパスワードを2回要求される【Ver1709】に書かれていることを実施

設定変更

「Windowsの設定」→[アカウント]→[サインインオプション]をクリックします。

[更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了する」の項目を[オフ]にします。

“【Windows 10】ログイン時に2回もパスワード入力させられる” の続きを読む

ブログ記事を音声化してみる

Twitterを眺めていたら

なんて流れてきた。
VUI(Voice User Interface)は流行ると思うし、スマートスピーカーも興味あるし。実際試してみた。

でもこのタイミングなら「【 AWS 新リージョン】 AWS 大阪ローカルリージョンが本日より利用可能になりました」に飛びついて確認すべきだとは思うけどまぁいいや^^;;

AWS 大阪ローカルリージョンをご利用いただくためには、申し込みおよび審査が必要です。

なんて書かれているから一般利用が出来るのはまだ先のことかな。

ご利用の WordPress ブログに新しい Amazon Polly の声を通りにしたら普通に使えます。

IAM コンソールに移動して、新しいポリシーを作成します。

必要なポリシーはamazon-polly-wordpress-pluginの通りに設定しました。

AWS側でPolicyとユーザの作成

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “Permissions1”,
“Effect”: “Allow”,
“Action”: [
“s3:HeadBucket”,
“polly:SynthesizeSpeech”,
“polly:DescribeVoices”
],
“Resource”: “*”
},
{
“Sid”: “Permissions2”,
“Effect”: “Allow”,
“Action”: [
“s3:ListBucket”,
“s3:GetBucketAcl”,
“s3:GetBucketPolicy”,
“s3:PutObject”,
“s3:DeleteObject”,
“s3:CreateBucket”,
“s3:PutObjectAcl”
],
“Resource”: “arn:aws:s3:::audio_for_wordpress*”
}
]
}

“ブログ記事を音声化してみる” の続きを読む

HTTPS Onlyな世界になるのかー

High Sierraの10.13.4 Developer Beta2が出ていたのでインストール。

【重要】WordPress手動更新のお願いで手動更新しようかと思いとあるWordPressの管理画面に行くとこんな画面になった・・・

Webサイトは安全ではありませんHTTPでの入力は確かにダメだよねぇ〜だからといって・・・

うーん素直にHTTPS化すればいいだけなんだけど色々と思う訳ですよ。

入力さえなければ暗号化する必要あるの?という疑問もあるんだよなぁ。
HTTP/2対応で高速化するとしても

“HTTPS Onlyな世界になるのかー” の続きを読む

DNS Over HTTPSを試してみる

第100回IETF Meeting(シンガポール)報告を読むと

doh WGの設立
過去のDNS関連WGやアプリケーション関連エリアにおける議論で、DNSの通信をHTTPSの通信路で実現することの必要性が認識されました。それを受け、2017年9月15日にdoh WGが設立され、標準化作業を進めることとなりました。dohはDNS over HTTPSに由来しています。

DNS over HTTPSは来るのかなぁ〜と期待している。

mozaic.fmのep31 IETFででもITEFの話が出ていたのでIETFのページをみるとDNS Over HTTPS (doh)のWG(Working Group)の話がありますね。

MLのArchiveを覗くと・・・わからん^^;;

DNS Over HTTPSとは

Google Public DNS over HTTPS を試すによると

従来の UDP/TCP ベースの DNS プロトコルの代わりに DNS-over-HTTPS を使う理由は何でしょうか。それはずばりセキュリティです。インターネット上の通信内容の大部分を占めるウェブの通信は、HTTP から HTTPS (TLS) に移行することで盗み見や改竄への危険に対処してきました。しかし HTTPS 通信を開始する前の段階で発生する DNS の通信は、いまだに暗号化されておらず、なりすましにも脆弱です。 DNS-over-HTTPS は HTTPS (TLS) という安全性が良く知られたプロトコルを DNS に適用することでこの問題の解決を試みています。

DNS周りのセキュリティって最近個人的に興味あり
ISP内のDNSを利用しないとNetflixとかのキャッシュサーバとの距離が遠くなったりしないのだろうか?

今からちゃんと流行ってくる仕様だと思っているから凡人の私が心配することはないはず。

DNS Over HTTPSを試してみる

ブラウザで確認する方法とターミナルで確認する方法があります。

DNS Over HTTPSをブラウザで試してみる

ブラウザだとhttps://dns.google.com/にアクセスしてから入力

こんな感じで表示されます。
ブラウザなのでAAAとかMXとかポチポチするだけで表示される。

DNS Over HTTPSをTerminalで試してみる

ターミナルからだと下記コマンドを投入

curl -k “https://dns.google.com/resolve?name=www.barasu.org&type=A”

こんなコマンドでさくっと引けてJSONで返ってきます。JSONは人間が読む形式ではないと思っている私ですがとりあえず見やすく改行すると下記の通り

{
“Status”: 0,
“TC”: false,
“RD”: true,
“RA”: true,
“AD”: false,
“CD”: false,
“Question”: [
{
“name”: “www.barasu.org.”,
“type”: 1
}
],
“Answer”: [
{
“name”: “www.barasu.org.”,
“type”: 5,
“TTL”: 59,
“data”: “d2sd2g0g8zuks.cloudfront.net.”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.227”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.62”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.151”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.208”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.187”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.90”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.71”
},
{
“name”: “d2sd2g0g8zuks.cloudfront.net.”,
“type”: 1,
“TTL”: 59,
“data”: “52.222.201.182”
}
],
“Comment”: “Response from ns-134.awsdns-16.com.(205.251.197.147).”
}

引数のtype=AをAAAAに変更したらAAAAが返ってきます。

詳しくはGoogleの公式ページGoogle Public DNS (DNS-over-HTTPS)をご覧ください。

結果

DNS Over HTTPSを試してみたけど何に使えるかがまだわかってない^^;;
クライアントでDNS Over HTTPSを試す方法あるのかなぁ〜

あるタイミングでSSLサーバー証明書無効化

Facebookで世界30%のSSL証明書が3月と10月に強制無効化!? あなたのサイトが大丈夫か確認する3ステップなんて記事が流れてきたので目を通してみた。

Google vs Symantecって確かにあって、SymantecがSSL証明書発行の部分を売ったんだよねーぐらいだったけど

下記の証明書発行元の証明書が無効化されるらしい

  • Symantec
  • GeoTrust
  • RapidSSL
  • Thawte

そろそろちゃんとしないと今年の秋には信頼されなくなる可能性が高いのね。
ChromeやFirefox以外のブラウザでの扱いが決まっていないけど
ページにかかれているように確認してみる。

“あるタイミングでSSLサーバー証明書無効化” の続きを読む

chromebookは仕事で使えるのか?

Chromebookを利用しはじめた理由

なんて書いたら貸していただける方がいらっしゃった^^;;

SNSすごい。

Chromebook

お借りしたのはacer chromebook C720

スペックは下記の通り

CPUCeleron 2955U
Memory4G
SSD16GB
バッテリー駆動時間8.5時間
画面サイズ11.6インチ
重量約1.25kg

見た目ではChromebookなのかWindowsPCなのかは区別つきにくいんじゃないかなぁ。
天板にChromeのロゴがあるぐらい

使ってみた感想

  • 当然だけど起動がチョッパヤ
  • ブラウザだけでできることって予想以上に多い
  • キータッチがいい感じ
  • キー配列がもうちょっと・・・
  • 電池の持ちがいい
  • 軽い

C720の少し残念なこと

  • 充電形状が特殊(USB Type-Cでの充電希望)
  • タッチパネルではない
  • 画面解像度がもう少し欲しい

すごく不満ではなく、機種によってはたぶん可能だと思われる

“chromebookは仕事で使えるのか?” の続きを読む

mobile率が高いのは普及したから?

久しぶりにblogを書いてGoogle Analyticsを眺めていたらふと気がついた
mobileデバイス率が高すぎるぞ・・・

ここ1ヶ月の数値は下記の通り

Device
desktop1,387(49.91%)
mobile1,208(43.47%)
tablet184(6.62%)

43.47%がMobileのアクセス数なのか。まだ普通に30%弱ぐらいかなと勝手に思い込んでいたのにこんな数値が出ているなんて
恐るべしMobile Device

“mobile率が高いのは普及したから?” の続きを読む

子供が家庭利用するデバイスを楽に安全に使うためにしている方法2017年編

★この記事は、「子供/保護者/学校」×「情報リテラシー」 Advent Calendar 2017 の16日目の記事です。

attention

我が家の場合を書いてます。他の家庭の参考になるかは不明です^^;;

自己紹介

    • 子供3人(中学生♂、小学生♀、幼稚園♂)の父親
  • PTAへは人並みに参加しているつもり
  • 教育にはちょっと興味あり
  • 仕事は自称エンジニア

我が家の現状

家庭内のICT(Information and Communication Technology)機器ってどんなんのがあるのだろうか?我が家の場合はApple TV、iPhone × 3、iPad Pro × 1、ゲーム機(Switch)×1、スマートスピーカーがメインで動いています。
基本スタンスはOSは最新版を適用すべし、ApplicationもUpdateを必ず行うこと。

子供がiPhoneを使うときのルールは最初に決めて運用しています(もちろん運用変更する可能性はあり)

  • 眠るときに寝室にはiPhoneは持って入らない
  • パスコードは必須(親にも教えない)、親の指紋も登録しておく
  • OSやアプリケーションは最新版を入れる

Androidは詳しくありません、iOSデバイスだけなのは管理コストを下げるため&親のスキル不足&ファミリー共有のメリットのためです。

ファミリー共有

ファミリー共有を利用することで6名までの購入コンテンツの共有、Apple Music ファミリープラン利用、iPhoneを探すで場所の把握等が利用出来ます。

“子供が家庭利用するデバイスを楽に安全に使うためにしている方法2017年編” の続きを読む

CloudFrontでキャッシュされている?

AWSの料金(2017/11)で書いたような金額なんだけどCloudFrontってちゃんとキャッシュされているか確認していなかった^^;;

  • 本当にキャッシュされている?
  • Hit率ってどれぐらい?
  • どれぐらいの容量を捌いている?

もろもろが気になったので調べてみた。
使ってはいるけど確認はしていなかったというやつ^^;;

キャッシュの有無

レスポンスヘッダのx-cacheを見たらキャッシュされているかわかります。

コマンドは

curl -svo /dev/null https://www.barasu.org/

これでOKです。

1回目(キャッシュなし)

curl -svo /dev/null https://www.barasu.org/
* Trying 54.230.108.126...
* TCP_NODELAY set
* Connected to www.barasu.org (54.230.108.126) port 443 (#0)
(略)
< cache-control: max-age=604800
< x-cache: Miss from cloudfront
< via: 1.1 7727d44fd16a7a76bb8fa7045a2983b0.cloudfront.net (CloudFront)
(略)
* Connection #0 to host www.barasu.org left intact

2回目(キャッシュあり)

curl -svo /dev/null https://www.barasu.org/
* Trying 54.230.108.126...
* TCP_NODELAY set
* Connected to www.barasu.org (54.230.108.48) port 443 (#0)
(略)
< cache-control: max-age=604800
< x-cache: Hit from cloudfront
< via: 1.1 7727d44fd16a7a76bb8fa7045a2983b0.cloudfront.net (CloudFront)
(略)
* Connection #0 to host www.barasu.org left intact

キャッシュにHitしている場合にはx-cache: Hit from cloudfrontって表示されるのね。

2回目からはキャッシュされるのがわかる。
これはExpireは1dayだったはず。

容量確認

どれぐらいの容量をEdge Locationから配っているかはAWS CloudFront Managementから確認できます。

“CloudFrontでキャッシュされている?” の続きを読む

CloudFront経由にしたらWordPressでビジュアルエディタが使えない

しばらく前からWordPressのビジュアルエディタが使えない状態でした。サーバ側の設定が悪いんだろうと思ってスルーしてました。私1人用のBlogなのであまり気にもしていなかった。

そしたらWordPressでビジュアルエディタが使えない問題の解決策まとめなんて記事を見つけた。
ズバリ書いてありました。CloudFrontが悪さをしてました。
User-agentによってビジュアルエディタを出す、出さないの判断していたのかー

User-agentを確認するPHPをサーバに置いてブラウザでアクセスしてみます。
PHPのCodeは下記の通り

<?php
$ua = $_SERVER[“HTTP_USER_AGENT”];
echo “$ua”;
?>

ビジュアルエディタが見えないパターン

Amazon CloudFront

希望する結果

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

“CloudFront経由にしたらWordPressでビジュアルエディタが使えない” の続きを読む