browser support? "no clue" "I do not understand the point of
this type. Neither do browsers." http://quirksmode.org/html5/inputs/mobile.html …
Jacob Rossi
@jacobrossi :Live coding in VR with the Oculus Rift, Firefox WebVR, JavaScript and Three.js
“I built a live-coding web app for the Oculus Rift where you code in JavaScript using Three.js and watch the world change around you in real-time.”
Quadrilateral Cowboy gameplay video
“Quadrilateral Cowboy is a game we’ve been watching with great interest ever since Thirty Flights Of Loving creator Brendon Chung first debuted it last year. It’s about hacking, but not via irritating minigames or jargon-your-problems-away Hollywood magic. Instead, you learn basic (albeit fictional) code and take down everything from laser grids to gun emplacements with a twitch of your fingers and a wriggle of your brain. It’s already an extremely clever game, and it’s quite empowering despite the fact that you play as someone who probably couldn’t even heft an assault rifle - let alone fire one. Basically, it’s a wonderfully novel idea - more Neuromancer than Deus Ex - but words only do it so much justice. Thus, I’ve decided to play it for your enrichment, in hopes that you will understand why Quadrilateral should be driving your radar haywire.”
From Inside Edward Snowden’s Life as a Robot:
Wizner had to jump on a phone call during a meeting with his whistleblower client. When he got off the phone, he found that Snowden had rolled the bot into civil liberties lawyer Jameel Jaffer’s office and was discussing the 702 provision of the Foreign Intelligence Surveillance Act. “It was kind of cool,” Wizner says.
It is neat but they’re marketing video is at times strangely terrifying. Put different music on when the Susan-bot comes up behind the unknowing Mark and this could be a horror movie trailer.
On exploiting security issues in botnet C&C software:
Hackers “are learning that it’s not so easy to write secure code,” Toro says. “Most of us in the business of securing our applications and systems know that bulletproofing software is an extremely expensive and exhaustive undertaking. Malware creators who have to look to their own defences would have to slow down the production of new attacks.”
FYI, if you want to know what it looks like when you hack a hacker, look no further than the seminal 1995 film Hackers.
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!
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 Windows.UI.Colors.black 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:
Windows.UI.Colors.black;. 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.
"The Flexbox Layout (Flexible Box) module (currently a W3C Candidate Recommendation) aims at providing a more efficient way to lay out, align and…"
Great diagrams showing the use of the various flex css properties. I can never keep them straight so this is perfect for me.
@youtube - How DNA Changed the World of Forensics | Retro Report | The New York Times
YouTube - Dead Man’s Bones (Dance)
Nathan Barnatt has some great videos
The game is to figure out what constrained modifications you must make to beat the game.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"Fitbit Connect.exe"=dword:000022b8
Some rights reserved