archive - Dave's Blog


Tweet from David_Risney

19 days ago
Missing planet Vulcan predicted by Newtonian physics+Mercury's orbit. Decades of mistaken Vulcan sightings before GR …

Retweet of FTC

24 days ago
Our #StartWithSecurity workshop starts now. Watch live: … Agenda: …

Tweet from David_Risney

Sep 26, 8:47
The Inside Story Behind MS08-067 …. Are we cool talking about this now?

Retweet of simevidas

Jul 26, 8:27
The size of web fonts (per page) quadrupled over the last 2 years: …

Retweet of JustRogDigiTec

Mar 18, 10:48
Xpath in #EdgeHTML using CSS selectors and WGX (Wicked Good XPath) … The tech here is amazing. #ICodeReviewedThat

Tweet from David_Risney

Mar 10, 4:24
VGA Miner on Archive … The OG Minecraft

Retweet of textfiles

Feb 12, 9:15
My boss came out and spoke for five minutes in NYC and mentioning locking the web.... open. …

Tweet from David_Risney

Feb 12, 8:35
Unicode encoding holy wars via Mark Pilgrim / Emo Philips …

Retweet of davemethvin

Feb 5, 9:34
When when the defenders of synchronous AJAX appear for the 14th time … 

Retweet of ericlaw

Jan 27, 11:08
I recently got a new Authenticode cert to continue to sign my code. It wasn't hard-- you should be signing too! …

MotherJones - Meet the people behind the Wayback Machine, one of...

2014 Jun 1, 4:16

MotherJones - Meet the people behind the Wayback Machine, one of our favorite things about the internet

PermalinkCommentstechnical internet-archive

Debugging anecdote - the color transparent black breaks accessibility

2014 May 22, 10:36

Some time back while I was working on getting the Javascript Windows Store app platform running on Windows Phone (now available on the last Windows Phone release!) I had an interesting bug that in retrospect is amusing.

I had just finished a work item to get accessibility working for JS WinPhone apps when I got a new bug: With some set of JS apps, accessibility appeared to be totally broken. At that time in development the only mechanism we had to test accessibility was a test tool that runs on the PC, connects to the phone, and dumps out the accessibility tree of whatever app is running on the phone. In this bug, the tool would spin for a while and then timeout with an error and no accessibility information.

My first thought was this was an issue in my new accessibility code. However, debugging with breakpoints on my code I could see none of my code was run nor the code that should call it. The code that called that code was a more generic messaging system that hit my breakpoints constantly.

Rather than trying to work backward from the failure point, I decided to try and narrow down the repro and work forwards from there. One thing all the apps with the bug had in common was their usage of WinJS, but not all WinJS apps demonstrated the issue. Using a binary search approach on one such app I removed unrelated app code until all that was left was the app's usage of the WinJS AppBar and the bug still occurred. I replaced the WinJS AppBar usage with direct usage of the underlying AppBar WinRT APIs and continued.

Only some calls to the AppBar WinRT object produced the issue:

        var appBar = Windows.UI.WebUI.Core.WebUICommandBar.getForCurrentView(); 
// appBar.opacity = 1;
// appBar.closeDisplayMode = Windows.UI.WebUI.Core.WebUICommandBarClosedDisplayMode.default;
appBar.backgroundColor = Windows.UI.Colors.white; // Bug!
Just setting the background color appeared to cause the issue and I didn't even have to display the AppBar. Through additional trial and error I was blown away to discover that some colors I would set caused the issue and other colors did not. Black wouldn't cause the issue but transparent black would. So would aqua but not white.

I eventually realized that predefined WinRT color values like Windows.UI.Colors.aqua would cause the issue while JS literal based colors didn't cause the issue (Windows.UI.Color is a WinRT struct which projects in JS as a JS literal object with the struct members as JS object properties so its easy to write something like {r: 0, g: 0, b: 0, a: 0} to make a color) and I had been mixing both in my tests without realizing there would be a difference. I debugged into the backgroundColor property setter that consumed the WinRT color struct to see what was different between and {a: 1, r: 0, g: 0, b: 0} and found the two structs to be byte wise exactly the same.

On a hunch I tried my test app with only a reference to the color and otherwise no interaction with the AppBar and not doing anything with the actual reference to the color:;. This too caused the issue. I knew that the implementation for these WinRT const values live in a DLL and guessed that something in the code to create these predefined colors was causing the issue. I debugged in and no luck. Now I also have experienced crusty code that would do exciting things in its DllMain, the function that's called when a DLL is loaded into the process so I tried modifying my C++ code to simply LoadLibrary the DLL containing the WinRT color definition, windows.ui.xaml.dll and found the bug still occurred! A short lived moment of relief as the world seemed to make sense again.

Debugging into DllMain nothing interesting happened. There were interesting calls in there to be sure, but all of them behind conditions that were false. I was again stumped. On another hunch I tried renaming the DLL and only LoadLibrary'ing it and the bug went away. I took a different DLL renamed it windows.ui.xaml.dll and tried LoadLibrary'ing that and the bug came back. Just the name of the DLL was causing the issue.

I searched for the DLL name in our source code index and found hits in the accessibility tool. Grinning I opened the source to find that the accessibility tool's phone side service was trying to determine if a process belonged to a XAML app or not because XAML apps had a different accessibility contract. It did this by checking to see if windows.ui.xaml.dll was loaded in the target process.

At this point I got to fix my main issue and open several new bugs for the variety of problems I had just run into. This is a how to on writing software that is difficult to debug.

PermalinkCommentsbug debug javascript JS technical windows winrt

Internet Archive lets you play one of the earliest computer...

2014 Apr 28, 9:39

Internet Archive lets you play one of the earliest computer games Space War! emulated in JavaScript in the browser.

This entry covers the historical context of Space War!, and instructions for working with our in-browser emulator. The system doesn’t require installed plugins (although a more powerful machine and recent browser version is suggested).

The JSMESS emulator (a conversion of the larger MESS project) also contains a real-time portrayal of the lights and switches of a Digital PDP-1, as well as links to documentation and manuals for this $800,000 (2014 dollars) minicomputer.

PermalinkCommentscomputer-game game video-game history internet-archive

theatlantic: Victorian Trolling: How Con Artists Spammed in a...

2013 Oct 29, 7:42


Victorian Trolling: How Con Artists Spammed in a Time Before Email

The main difference between 21st-century scams and those of centuries past is one of delivery method.

Read more. [Image: Wikimedia Commons/Benjamin Breen]

PermalinkCommentshistory spam technical humor internet

theatlantic: 'Please Contact Us': It's Been a Tough Week for...

2013 Oct 11, 9:25


'Please Contact Us': It's Been a Tough Week for the Nobel Prize's Twitter Feed

Tales of temporary rejection from an organization not used to being ignored.

Read more.

PermalinkCommentshumor nobelprize twitter

Considerate MessagePort Usage

2013 Aug 7, 7:14
Sharing by leezie5. Two squirrels sharing food hanging from a bird feeder. Used under Creative Commons license Attribution-NonCommercial-NoDerivs 2.0 Generic.When writing a JavaScript library that uses postMessage and the message event, I must be considerate of other JS code that will be running along side my library. I shouldn't assume I'm the only sender and receiver on a caller provided MessagePort object. This means obviously I should use addEventListener("message" rather than the onmessage property (see related What if two programs did this?). But considering the actual messages traveling over the message channel I have the issue of accidentally processing another libraries messages and having another library accidentally process my own message. I have a few options for playing nice in this regard:
Require a caller provided unique MessagePort
This solves the problem but puts a lot of work on the caller who may not notice nor follow this requirement.
Uniquely mark my messages
To ensure I'm acting upon my own messages and not messages that happen to have similar properties as my own, I place a 'type' property on my postMessage data with a value of a URN unique to me and my JS library. Usually because its easy I use a UUID URN. There's no way someone will coincidentally produce this same URN. With this I can be sure I'm not processing someone else's messages. Of course there's no way to modify my postMessage data to prevent another library from accidentally processing my messages as their own. I can only hope they take similar steps as this and see that my messages are not their own.
Use caller provided MessagePort only to upgrade to new unique MessagePort
I can also make my own unique MessagePort for which only my library will have the end points. This does still require the caller to provide an initial message channel over which I can communicate my new unique MessagePort which means I still have the problems above. However it clearly reduces the surface area of the problem since I only need once message to communicate the new MessagePort.
The best solution is likely all of the above.
Photo is Sharing by leezie5. Two squirrels sharing food hanging from a bird feeder. Used under Creative Commons license Attribution-NonCommercial-NoDerivs 2.0 Generic.
PermalinkCommentsDOM html javascript messagechannel postMessage programming technical

theatlantic: How the 8.5” x 11” Piece of Paper Got Its...

2012 Sep 19, 6:37


How the 8.5” x 11” Piece of Paper Got Its Size

Why do we use a paper size that is so unfriendly for the basic task of reading? According to a very interesting post by Paul Stanley, the rough dimensions of office paper evolved to accommodate handwriting and typewriters with monospaced fonts, both of which rendered many fewer characters per line. “Typewriters,” he explains, “produced 10 or 12 characters per inch: so on (say) 8.5 inch wide paper, with 1 inch margins, you had 6.5 inches of type, giving … around 65 to 78 characters.” This, he says, is “pretty close to ideal.”

Read more. [Image: Picsfive/Shutterstock]

PermalinkCommentstechnical paper history

When they went to the Moon, they received the same per diem...

2012 Aug 28, 4:38

When they went to the Moon, they received the same per diem compensation as they would have for being away from base in Bakersfield: eight dollars a day, before various deductions (like for accommodation, because the government was providing the bed in the spaceship).


Apollo 11’s Astronauts Received an $8 Per Diem for the Mission to the Moon

The astronauts of Apollo 11: Intrepid explorers. Inspirational heroes. Government employees.

Read more. [Image: Reuters]

PermalinkCommentshumor space nasa moon government

SkullSecurity » Blog Archive » Stuffing Javascript into DNS names

2012 Aug 27, 4:25

dnsxss tool helps you inject via DNS

…what it does is, essentially, respond to DNS requests for CNAME, MX, TXT, and NS records with Javascript code. … how about SQL injection?

PermalinkCommentssecurity technical javascript dns sql

Alexandria 2.0: One Millionaire's Quest to Build the Biggest Library on Earth | Threat Level |

2012 Aug 21, 7:00

Brief history and scope of the Internet Archive.

PermalinkCommentsinternet-archive history
Older Entries Creative Commons License Some rights reserved.