What is this nonsense? OpenH264.org Download

Had a brush with some badness named “openh264.org”.

I am sitting in a Starbucks with its own internet access, my very own local shady access point.  When I connect to the access point, there is a popup which requires me to click I ACCEPT THE TERMS etc, and then hit the CONNECT button. This usually goes smoothly, as I have the password stored, and that’s all I have to do. But today I got hit with a pop-up that said such-and-such a site is trying to download(?) a file.  The file was named something like this:

http(s?)://ciscobinary.openh264.org/{LONG-ugly-UID-here}.zip

What do you want to do with this file, open with IE, do something else, [ ] remember this choice, OK/CANCEL.

This popul was the obscured by another that said something like, The following file could not be found:

C:\{long user path}\ciscobinary.openh264.org/{LONG-ugly-UID-here}.zip.part

Clicking OK closed both popups.

I looked around for the openh264 and Cisco wisdom (using my cellphone browser over the TELCO signal), and was not satisfied that this particular download attempt was legit. After all, I am at a public access point.

So I whacked the URL provided by the shady access point from this:

http://local.shady.accespoint?lotasparameters&something=https://msftconnecttest.com%2fredirect%2fmsn.something.something...

which always redirects me to MSN which i despise anway…  to this:

http://local.shady.accespoint?lotasparameters&something=https://drudgereport.com

Why did I do this? Because drudgereport always flushes cache. That site updates every minute or so, and does not want anybody stuck on yesterday’s content. Every access to DR is like the first of the day.  And because I would rather claw my own eyes out than look at MSN.

Well, it worked perfectly. Now I cannot replicate the condition, hence some of the uncertain language here. I could probably let my session time-out on the local shady access point and try again.

But why is this file being pushed to me — by Microsoft? The way I assess the failure is this: MS wanted me to accept that file without even asking, but I have my shields up, so the browser stopped the download and asked me whether to accept the file (thank you, Firefox).  I think that this caused the file-not-found-ness, and that failure caused my validation by “msftconnecttest.com” to bottom out. And that is why I could not connect.

Interestingly, it seems the local shady access point asks for but DOES NOT REQUIRE validation from the Microsoft connection test. This is probably the site which returns the fleeting “Success!” one-word HTML page which precedes the appearance of the execrable MSN page.

Whatever this file is, I don’t want it. And I now have an interesting work-around for non-enforced validation at shady local access points.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *