Designing the least JPG compressible fabric pattern: http://dsp.stackexchange.com/questions/2010/what-is-the-least-jpg-compressible-pattern-camera-shooting-piece-of-cloth-sca …. This is the anti @ericlaw
Just gave the CSP Rule Collector Fiddler extension from @David_Risney a run. This is excellent, highly recommended! https://twitter.com/ericlaw/status/627572451015168000 …
This is profoundly troubling, especially after learning that a recent
mass shooting was executed via such a gun. http://www.wired.com/2015/06/i-made-an-untraceable-ar-15-ghost-gun/ …
Love it: "Never give your parents a hard time about having to teach
them computer stuff. They had to teach you to use a spoon."
Does 'charset=utf8' work anywhere? Or do other browsers fallback to UTF-8 just giving
the appearance? @ericlaw http://wp.me/p60i9o-r
GitHub has spoiled me. We need a pull-request HTTP method and then you can just fix it
for them. https://twitter.com/ericlaw/status/587614039645143040 …
Nice writeup of the attack on GitHub: http://blog.erratasec.com/2015/04/pin-pointing-chinas-attack-against.html#.VRye4mK9KK0 …
For the second time today, I've added a new feature to Fiddler only to
discover it was already there.
I recently got a new Authenticode cert to continue to sign my code. It
wasn't hard-- you should be signing too! http://blogs.msdn.com/b/ieinternals/archive/2015/01/28/authenticode-in-2015-signcode-with-certificate-on-etoken.aspx …
Eric Lawrence
@ericlaw :
Marcus Lewis @mrcslws : Eric Lawrence
@ericlaw :More than 90% of Americans believe that the US government is unduly influenced by money, and the Mayday.US super PAC is raising $5M to fund the election campaigns of politicians who’ll pledge to dismantle super PACs and enact other campaign finance reforms. They raised more than $1M in 30 days last month, and this month, the goal is $5M. It’s the brainchild of Lawrence Lessig, who’s going to run prototype the project by running five electoral campaigns in 2014, and use the lessons of those projects to win enough anti-corruption seats in 2016 to effect real change.
Again, I’m not able to contribute to Mayday.US, because I’m a Canadian and Briton. But I ask my American friends to put in $10, and promise that I’ll put CAD1000 into any comparable Canadian effort and/or £1000 into a comparable UK effort. We all win when countries embrace evidence-based policy guided by doing what’s best for its citizens, rather than lining the pockets of corrupting multinationals.
Please reblog!
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.
RT @PeerProd In Europe, encrypted traffic went from 1.47% to 6.10%, and in Latin America, it increased from 1.8% to 10.37%
http://www.wired.com/2014/05/sandvine-report/ #NSA
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:
Some rights reserved