If you follow me on Twitter, you probably saw a heated exchange of words between myself, Nokia Principal Engineer Justin Angel, and Microsoft ASP.NET Program Manager Erik Porter. (He made Rowi, a nice Windows Phone twitter client.) The argument at its core is that Rowi users don’t have exacting control over how Rowi accesses location data. Let me show you what I mean.
Normal tweet flow, without automatic location access.
The figure above shows a fresh tweet screen in Rowi. You can tap the add current location link to opt into Location API access and geo-tag a tweet. That part is okay. But after sending this tweet, Rowi “remembers” the decision and in new tweets automatically pulls your location data with no way to turn this off. So if you decide that Rowi is to no longer have access to your location data, you cannot opt-out. The only way to disable this behavior is to start a new tweet, tap the clear link after it pulls your location data, then send a tweet out to save your settings to disk.
Tweet flow after you send one geo-tagged tweet.
Note the location data was pre-populated.
This behavior is not aligned with Windows Phone Application policies, specifically 2.7.3 which clearly states:
Your application must provide in-application settings that allow the user to enable and disable your application’s access to and use of location from the Location Service API.
And when brought to Erik’s attention, he dismissed the issue claiming that tapping the clear link offers users the ability to send tweets without location data and that he “worked with marketplace team already on this exact issue” implying they OK’ed it. But what Erik fails to realize — or is choosing to ignore — is that I can’t hit the clear link until it runs its fingers through my location data. Against my will.
… but maybe he’s right. Things get a little muddied when you put this in the perspective of the app. The location data on the new tweet page isn’t being transmitted to Twitter at that time, therefore a case could be made around the fact that opt-in consent is not required per policy 2.7.4:
If your application publishes or makes available location data obtained from the Location Service API to any other service or other person (including advertising networks), your application must implement a method to obtain opt-in consent. [...]
Confused yet?
Now let’s be honest — there’s no real impact here. Rowi is a very trustworthy application and has a clear and succinct privacy policy. But I strongly believe something is wrong here. The user should have the final say in what privileges an application has and what rules they must follow. So I think Rowi needs a Location API master switch.
What do you think?
So, back in July of last year, Bing temporarily rolled out a version of their homepage featuring live tiles. Well, guess what — it’s back. The new style seems cleaner and features three distinct “live tiles” — Videos, Images, Trends — that update throughout the day. A fourth static tile, Search History, serves as a convenient area to view and repeat searches you’ve run in the past.
For those that prefer to stay with the simpler text-based bar, you can close the new Taskbar by clicking a simple arrow — just like minimizing, say, the Windows Explorer Ribbon in Windows 8.
Last week, a reader – “Windows Fan” – tipped me off to an article on Vishal Guptas blog indicating how to customize the new WinX menu in Windows 8. (You know, the menu that appears when you right-click the lower-left Start tip.) Not happy with hacking core system files and peeling back file system security, I dug a little deeper to understand what’s going on and came up with a simpler solution.
So let’s start at the top. The WinX menu is a simple context menu that appears when you right-click the Start tip that appears when you squish the mouse into the lower-left corner of the screen. The purpose of the menu is not to act as a Start Menu replacement but rather as a springboard to perform advanced system functions that are slightly out of reach. For example, if you’re trying to kill a runaway system process, you will probably need quick access to Task Manager, an elevated Command Prompt, and perhaps Programs and Features to uninstall the culprit app. Launching those applications in succession via the Start Screen would be a pain in the rump.
The entries on the menu are driven by shortcut (.lnk) files present in each Group folder located at %LocalAppData%\Microsoft\Windows\WinX. But you can’t manipulate the shortcuts within or add new ones. That’s because at first invocation (e.g. a fresh boot), the menu scans for and only adds approved shortcuts. Why? Again, Microsoft doesn’t want this becoming another Start Menu or, worse, an icon landfill for installers a la Quick Launch back in Windows Vista.
But an argument could be made for that small sliver of folks who genuinely want to lightly extend the menu, perhaps with utilities such as Process Monitor and DebugView. So let’s talk about what makes an approved shortcut.
An approved shortcut – a moniker I made up – is a .lnk file that has the appropriate markings to indicate to Windows “Hey, I’m special.” The marking is a simple 4-byte hash of several pieces of information. From the .lnk itself, two points are collected:
- The link’s target application path/file (e.g. C:\Games\Minecraft.exe)
- The link’s target application arguments (e.g. –windowed)
The third ingredient is simply a hard-coded chunk of text, or a salt if you will, to keep things interesting. That string is, literally, “Do not prehash links. This should only be done by the user.”
With these three strings in hand, Windows then glues them together, lowercases everything, and runs them through the HashData function. But you’re probably wondering at this point, what does it compare to?
Let’s shift our focus to .lnk files. We know them as shortcuts to things. But they’re officially called Shell Links and can store a lot of information on other data objects in Windows. More specifically, they support storing a structure of data called a PropertyStoreDataBlock that acts as a container for arbitrary string or numeric key/value pairs. Yep, the “WinX hash” is stored in here. If you’re curious, the key can be defined as such:
DEFINE_PROPERTYKEY(PKEY_WINX_HASH,
0xFB8D2D7B, 0x90D1, 0x4E34, 0xBF, 0×60, 0x6E, 0xAC, 0×09, 0×92, 0x2B, 0xBF, 0×02);
So to tie it all together, Windows – the Shell specifically – iterates through the .lnk files in each GroupN folder; opens them up; pulls out and concatenates the target path, args, and an arbitrary string; then finally hashes the result. This hash is then compared with the one stored in the .lnk to determine if it’s approved. Rinse and repeat.
If you’re interested in stuffing items into that menu, I wrote a tool to mark your shortcuts as approved. (The source code is on Github, if you’re interested.)
NOTE: The WinX menu doesn’t seem to handle architecture-dependent environment string expansion very well, so shortcuts to %ProgramFiles% may not work (e.g. Internet Explorer 64-bit). I suspect this is a WONTFIX given it’s not designed to work with your own shortcuts.
Update: I replaced the executable with a VS2010 compiled copy, sorry. The previous one would not execute on Windows 8 machines w/o Visual Studio 11 installed. (We don’t have a VC11 runtime redist. kit yet.)
So I was on Skype with Paul Paliath this evening and he was having a tough time with Adobe Photoshop on Windows 8. I inquired for details and he read off the error he was seeing. “Error: LoadLibrary failed with error 126: The specified module could not be found.”
Sound familiar? Yep. I had the same problem last week with Minecraft. The error isn’t specific to Minecraft or Photoshop. It’s simply a quirk with the latest AMD preview drivers and all OpenGL applications. If you, too, are having this issue download my simple .reg file and you’ll be error free.
