"A routine request in Florida for records detailing the use of a surveillance tool known as stingray turned extraordinary Tuesday when the U.S. Marshals Service seized the documents before local police could release them."
Also what about the part where the PD reveals that its been using the stingray a bunch without telling any court and blames that on the manufacturer’s NDA.
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
A physical big red button that is a USB keyboard with a configurable single key. This looks wonderful. I’ll take 26.
RT @codinghorror The Very Serious USB Button https://www.indiegogo.com/projects/very-serious-button/
A reminder that those Doritos you love are trash:
Shortly after Disneyland opened in 1955, the founder of Frito-Lay got permission from Walt Disney to open a restaurant in Frontierland with a Mexican-ish theme. “Casa de Fritos” was, unsurprisingly, all about the Fritos. Customers got free Fritos, and Fritos were incorporated into many of the dishes. Fritos were dispensed by an animatronic vending machine that featured the terrifying “Frito Kid”asking his assistant “Klondike” to bring the bag up from a mineshaft. I guess the conceit is that Fritos were mined by Forty-Niners?
Casa de Fritos contracted their tortilla production to a company called Alex Foods. One of the salesmen from Alex Foods, making a delivery to Casa de Fritos, noticed stale tortillas in the garbage and gave the cook a little tip: fry them and sell them as chips instead of throwing them away. Casa de Fritos began making these fried, seasoned chips to enormous success, but didn’t report this new menu item to the Frito-Lay company.
Eventually Frito-Lay found out what they were doing with the chips, packaged them, and sold them by the truckload. See, dumpster diving works out sometimes!
Clearly the one JS feature we all agree on is ubiquity.
After some experimentation, I discovered that it’s possible to add type safety to JavaScript objects [via ES6 proxies] with just a few lines of code.
'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.
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:TL;DR: Keep your C++ class member declaration order the same as your constructor member initializers order.
C++ guarantees that the member initializers in a constructor are called in order. However the order in which they are called is the order in which the associated members are declared in the class, not the order in which they appear in the member initializer list. For instance, take the following code. I would have thought it would print "three, one, two", but in fact it prints, "one, two, three".
#include "stdafx.h"
#include
class PrintSomething {
public:
PrintSomething(const wchar_t *name) { std::wcout << name << std::endl; }
};
class NoteOrder {
public:
// This order doesn't matter.
NoteOrder() : three(L"three"), one(L"one"), two(L"two") { }
PrintSomething one;
PrintSomething two;
PrintSomething three;
};
int wmain(const int argc, const wchar_t* argv[])
{
NoteOrder note; // Prints one, two, three, not three, one, two!
return 0;
}
A former State Department lawyer has his doubts, and a famous cartoonist predicts jury nullification.
Redmond finally joins Google, Mozilla, by offering cash rewards for security flaws.
Good news everyone! Of course Microsoft employees are not eligible but that’s probably for the best.
The Windows Store supports refunds and as the developer you are responsible for fulfilling those refunds even after Microsoft pays you. That seems reasonable I suppose but there’s no time limit mentioned…
"g. Reconciliation and Offset. You are responsible for all costs and expenses for returns and chargebacks of your app, including the full refund and chargeback amounts paid or credited to customers. Refunds processed after you receive the App Proceeds will be debited against your account. Microsoft may offset any amounts owed to Microsoft (including the refund and chargeback costs described in this paragraph) against amounts Microsoft owes you. Refunds processed by Microsoft can only be initiated by Microsoft; if you wish to offer a customer a refund, directly, you must do so via your own payment processing tools."
Wrote some scripts that produce .cmdtree files. Nice to find this format definition.
Not The Onion subreddit is for real stories that sound like The Onion articles. This is a compilation of those stories into a page that looks like The Onion.
def nextServerCallback(self, data):
parsed_data = json.loads(data)
# Chunk was wrong!
if not parsed_data['success']:
# Defend against timing attacks
remaining_time = self.expectedRemainingTime()
self.log_info('Going to wait %s seconds before responding' %
remaining_time)
reactor.callLater(remaining_time, self.sendResult, False)
return
self.checkNext()
Some very H. P. Lovecraft style redesigns of some classic Win95 UI.
A Slower Speed of Light Official Trailer — MIT Game Lab (by Steven Schirra)
“A Slower Speed of Light is a first-person game in which players navigate a 3D space while picking up orbs that reduce the speed of light in increments. A custom-built, open-source relativistic
graphics engine allows the speed of light in the game to approach the player’s own maximum walking speed. Visual effects of special relativity gradually become apparent to the player, increasing
the challenge of gameplay. These effects, rendered in realtime to vertex accuracy, include the Doppler effect; the searchlight effect; time dilation; Lorentz transformation; and the runtime
effect.
A production of the MIT Game Lab.
Play now for Mac and PC! http://gamelab.mit.edu/games/a-slower-speed-of-light/”
Some rights reserved