sudofox's journal

Austin Burk's journal, where I share little snippets of my writing, code, and dreams.

Haiku/New Haiku Information Discord

I have created a Discord. Information and announcements will be provided here in English and, if someone would like to translate, Japanese.
There is a sense of worry about not being able to get in contact, so please feel free to join this place for the interim. It is already organized.
If anyone wants to translate this into Japanese, please feel free to leave a comment.


The Daily Draw is struggling...

I'm a bit disappointed about how the Sudomemo Daily Draw has somewhat faded so far.

I was hoping to bank on the nostalgia factor to attract old Hatena users from the days of Flipnote (うごメモ), but that doesn't seem to have worked too well.

I do seem to be receiving a number of new followers from Japan each day, though I have received no entries from the new subscribers. (Currently: 172 subscribers)

The concept seems pretty simple: a daily drawing prompt, meant to be done as a quick doodle. The winner gets a number of Hatena Stars, gets featured, and gets a Bookmark!

I think it might be popular if Hatena users were interested. I may need to change how I write the articles to indicate that it is indeed open to anyone at all with a Hatena account.

I'm going to keep going. I don't give up on things easily, since good things take hard work to accomplish.

Google is Scanning for (and Crawling) URLs in Your Private YouTube Videos

I was recently uploading an unlisted video to YouTube to demonstrate an XSS vulnerability I stumbled across which I was responsibly disclosing. Part of this involved showing the URL of the script which had been run. After uploading it to YouTube and submitting the vulnerability disclosure, I decided to double-check that nobody had visited the page I was testing on before I had removed the link. As it turns out, somebody had: YouTube. - - [12/Dec/2018:14:23:40 -0500] "GET /js/redacted_1.js HTTP/1.1" 200 125 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:14:23:42 -0500] "GET /js/redacted_1.js HTTP/1.1" 200 125 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:15:24:21 -0500] "GET /redacted_subfolder/redacted_2.png HTTP/1.1" 200 4605 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:15:24:22 -0500] "GET /redacted_subfolder/redacted_3.png HTTP/1.1" 200 5102 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:15:24:23 -0500] "GET /js/redacted_4.js HTTP/1.1" 200 137 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:15:24:24 -0500] "GET /redacted_subfolder/redacted_2.png HTTP/1.1" 200 4605 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:15:24:26 -0500] "GET /redacted_subfolder/redacted_3.png HTTP/1.1" 200 5102 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:15:24:26 -0500] "GET /js/redacted_4.js HTTP/1.1" 200 137 "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)"

I was rather alarmed to see this, as I didn't imagine the links were up long enough to be crawled by Google. It was then that I realized that during the video, those URLs were visible in the address bar. It seemed that YouTube had run OCR (optical character recognition) across my entire video and decided to crawl the links within. But how could I be sure that this was not just a mistake on my part?

Time for an Experiment

I recorded a new video of me accessing a URL that does not exist for the very first time.

Here is the video that I uploaded:

I started another screen recording of me uploading the video, and watching the access logs. A few minutes later, Google took the bait, and sent two requests to the URL: - - [12/Dec/2018:18:42:02 -0500] "GET /nonexistent/url.js HTTP/1.1" 404 - "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)" - - [12/Dec/2018:18:42:04 -0500] "GET /nonexistent/url.js HTTP/1.1" 404 - "-" "Mozilla/5.0 (compatible; Google-Youtube-Links)"

Hook, line, and sinker! I recorded me uploading the video and watching my access logs live (the accesses are around the 5:50 mark):

Why is this concerning?


The purpose for which I uploaded the video was to report a vulnerability. I uploaded it unlisted, so far all intents and purposes, it was meant to remain private. However, our friend Google-Youtube-Links scanned it for an unknown purpose and sent several requests to that URL. A second test as a fully private (not just unlisted) video revealed the same result.

By uploading the videos as unlisted or private, I have the expectation that nobody will see the video or the contained within except for me, or for the people who I explicitly share the links with.

Let's propose a scenario which is in a similar realm to what I was doing:

A security researcher has found a critical vulnerability in a site, and has crafted a URL that will trigger it, causing harmful effects to the website. (e.g a SQL injection vulnerability that will drop the database tables).

During the video, s/he makes mention that they will not visit the URL as it would cause trouble, but it is displayed so that the company they are responsibly disclosing to can remedy it. They upload it as unlisted to YouTube and submit their report. Five minutes later, Google-Youtube-Links comes along and sends two requests to the URL, triggering the SQL injection and rendering the site broken.

The Illusion of Privacy 

Here is Google's explanation of privacy settings:

What this does not include, however, is any mention that your video will be scanned for anything resembling URLs, and have these crawled.

What Google has to say about it

So what does Google have to say about this practice? Actually, nothing at all. Searching for the user-agent gives no relevant results save for one: a locked thread from a curious webmaster with no answer, back on March 27th, 2018. The thread was not resolved.!topic/webmasters/Ov_ODO8l2cU

This means that we are left with no explanation of why this is occuring, or disclosure that content uploaded as private to YouTube will be scanned with OCR and have any links within crawled by Google.

Honestly, I find this rather unsettling - especially for using private or unlisted YouTube videos as a way to quickly upload a video to disclose a vulnerability. I'm sure you can think of other scenarios in which this would be undesired, especially as we don't know why it's taking place or where those URLs will end up.

Let me know what you think of this development.

Questions or concerns?

If you have any questions or concerns, feel free to leave them below, or reach out to me at If you are a Hatena user, feel free to leave a star!


In English: Hatena Haiku Anti-Spam - austinburk's blog







ハイクその他のサービスに投稿されるスパムは性質が非常に一貫しています。私は現在Webホスティング管理の会社に勤務し、ベイズフィルターと、Apache SpamAssassinという正規表現ベースのフィルタリングエンジンの組み合わせに関する経験があります。そこで、SpamAssassinにはてなハイクの投稿のフィルタリング機能を付け加え、より快適にサービスを使用できるようにしようと思い立ちました。





Received: by (Sudofix)
        id 81807923680507219; Fri, 08 Jun 2018 09:12:22 -0400 (EDT)
From: (Sudofox)
Subject: 食べた
Content-Type: text/plain; charset=UTF-8
Message-Id: <>
Date:Fri, 08 Jun 2018 09:12:22 -0400 (EDT)

食べた=That looks AMAZING QoQ 


ヘッダーには、spamd (SpamAssassinのバックグラウンドで実行されるサービス)の解析の対象となる最小限の内容と、X-Hatena-Fan-Countが含まれています。


ここにuser_prefsファイルがあります。"Begin Sudofox config"の後をご覧になるとわかるとおり、Eメール関連のすべてのチェック(たとえばSPF、RBL、DKIM)を無効化するなどの変更をルールに加えて、ハイクからのメッセージのフィルタリングへの適合性を高めています。それ以外に、ハイクのプライマリユーザーベースにより適合させるための変更("Begin Sudofox config"の上にありますが注釈はしていません)も加えています。 



header		SUDO_HATENA_ZERO_FANS X-Hatena-Fan-Count =~ /^0$/
describe	SUDO_HATENA_ZERO_FANS User has no fans

header		SUDO_HATENA_FEW_FANS X-Hatena-Fan-Count =~ /^([1-9]{1})$/
describe	SUDO_HATENA_FEW_FANS User has 1-9 fans - spam less likely

header		SUDO_HATENA_10_PLUS_FANS X-Hatena-Fan-Count =~ /^([0-9]{2})$/
score		SUDO_HATENA_10_PLUS_FANS -2.0
describe	SUDO_HATENA_10_PLUS_FANS User has 10-99 fans - spam unlikely

header		SUDO_HATENA_100_PLUS_FANS X-Hatena-Fan-Count =~ /^([0-9]{3,})$/
score		SUDO_HATENA_100_PLUS_FANS -10.0
describe	SUDO_HATENA_100_PLUS_FANS User has 100+ fans - prob legitimate




































- 分類に使用する投稿の格納方法

- データベース: 現在は、ポータブルであるためSQLiteを使用していますが、時間の経過に伴い、適切にスケーリングできなくなる可能性があります。ハイクスパム対策にはすでに時折タイムラグが見られます(APIでは結果をキャッシュし、ユーザーのリクエストとは独立して更新を実行するため、タイムラグは発生しません)。アプリケーションをMySQLに移行することを計画しています。

- ハイクスパム対策バックエンドとサイトマージ: 現在、GitHub上のコードはバックエンド向けのもののみとなり、サイトのフロントエンド向けのものはありません。MySQLへの移行が完了し、サービスに関与するファイルへの直接アクセスや直接のパスを除去したら、Webサイトの部分もGitHubに配置することを計画しています。


Thank you to id:PlumAdmin for the translation of the original article. I am very grateful.