6tag leaks your account data, stores your private videos


Windows Phone developer Rudy Huyn released his unofficial Instagram clone app called 6tag today. And while I would love to take this moment to clear up misconceptions about how the app works and Huyn's involvement (or lack thereof) with Instagram, I must defer to another day. That's because I must, instead, share some important privacy concerns uncovered by Windows Phone developer Travis La Marr this morning.

6tag sends account data in the clear

To support video uploads, 6tag emulates the way Instagram's official apps work. That is, video is uploaded from the device to intermediate servers for transcoding into a compatible format and size, one step before Instagram. But where 6tag differs is that it sends your private account data -- for example, your username and authentication tokens -- in the clear, along with your video, to a black box server in France (presumably under the author's control) in preparation for a future app update. That means, in theory, a determined individual at a Starbucks armed with a sniffer could take over your Instagram account easy peasy.

Update 2 8/22 @ 4:22am PST:  Rudy, via Twitter, has indicated cookies will now be encrypted with a "512-bit key" in a future update.

But wait, there's more... 

6tag servers keep a copy of your public and private videos, for an unspecified amount of time

6tag's transcoding servers understandably keep uploaded video around for a little bit, giving the phone app time to grab a copy. What's concerning, however, is that uploaded video never seems to get deleted. For example, here's a permalink to a video I published on Instagram hours ago. And here's a video Travis published over a week ago. Yikes.

Update 1 8/22 @ 3:46am PST: Rudy, via Twitter, has confirmed that his server does not remove videos after publishing to Instagram, instead relying on an undocumented 48 hour retention policy. When asked about Travis' week old video, he noted that video was uploaded via the beta, implying they're special, and that beta videos will be wiped "in less than 48h". Travis' video went dark soon after.

6tag doesn't have a privacy policy

Against Windows Phone App Certification Policy 2.8, 6tag does not come bundled with a privacy policy, or at least one I could find. This means users have no clue what data is sent to Instagram or black box servers in France, nor an understanding of how private user data is handled, protected, or destroyed. How this got through Windows Phone Store testing is beyond me.

 Update 3 8/23 @ 3:40pm PST:  A new privacy policy is up.

Call to action: Upgrade to


This is a "FAST PUBLISH" article. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time. 

Full disclosure: I was compensated as part of an Instagram API reverse engineering effort for the developer of Instance, a competing app in the Windows Phone Store. This was a one time deal. I do not receive compensation based on the success or failure of Instance, nor care about Instagram in general.

Armchair analysis of AX88772 driver pull


Last week, my Windows 8 Secrets co-author, Paul Thurrott, pinged me about the lack of USB Ethernet device support on Windows RT. (He wrote about it too.) He noted the increasingly noisy rumblings of the continued non-availability of a Windows RT driver for ASIX AX88772 chipsets in USB Ethernet devices (like the Pluggable USB2-E100, $13.95). I suspect the reason this is getting any attention is because the driver was once available and worked on Windows RT 8.0. Microsoft later -- without much explanation -- requested a take down of the driver. And as of the latest preview build of Windows RT 8.1, the driver is blocked from installation.

But why?

I reached out to Microsoft and haven't heard back yet and they declined to comment on the matter. But I pillaged my closet and found a ASIX-based dongle and ran it through some tests (with the driver in question) to determine how well it actually worked on Windows RT 8.0.

Here are my results.

It's not Windows RT certified

It's important to note that despite being signed by Microsoft, the ASIX drivers in question are not officially certified for use on Windows RT. I suspect these drivers were supplied to ASIX for internal development or testing and not meant for production use. Running the drivers through Windows Hardware Certification testing reveals a number of problems that likely led to the take down of the driver set.

Lack of network presence offloading

As part of its Windows 8 and Windows RT device certification requirements, Microsoft requires that wired LAN (Ethernet) devices support network presence offloading when used on Connected Standby (CS) systems. Over simplified, this means the device should support entering a low power state and respond to the usual indirect network chatter (i.e. ARP and NS ads) without waking the PC. This behavior improves power management and efficiency on CS systems (e.g. Surface RT).

Missing wake events

Wired LAN devices are also required, again on Connected Standby systems, to support various wake events -- the connection and disconnection of network media. That is, when a cable is connected or disconnected, the device should wake up and do whatever processing needed as a result.

Missing USB Selective Suspend support

In conjunction with the missing wake events (above), my device did not support entering a suspended state by way of USB Selective Suspend. This feature allows for the suspension of an individual port helping conserve battery power.

Other minor nits

Given work on this device began long ago, it's understandable that its driver contains some legacy code that needs cleaning up. My tests reported other nits that I feel are minor but worthy of documentation nevertheless.

So is Microsoft conspiring to kill Ethernet?


No, I'm kidding. Let's be realistic here.

Obviously this driver isn't up to code. Neither Microsoft or its partners want this driver circulating the Internet and causing battery (and possibly stability) chaos on Windows RT. While a beta driver is commonly welcomed over no driver, the release of such would incur costs -- time and money -- for what amounts to a niche audience of RT enthusiasts. Instead, let's just exercise a bit more patience and wait for Microsoft or ASIX to publish updated drivers. (If that doesn't happen though, you do have the option of never upgrading to Windows RT 8.1...)

Windows 8.1 features Miracast wireless display tech, and it works well


For me, there was very little more frustrating than trying to get moving pictures from my PC to the TV. What should have been easy always turned into a nightmare of mismatching codec support (PlayTo), missing cables and adapters, and fumbling of FAT32 USB sticks (which can't even hold your typical H.264 encoded movie). But that was then. Windows 8.1 is now. And we now have wireless display capabilities baked right into the OS.

Miracast is here! 

To be more specific, Windows 8.1 (preview) ships with an implementation of the Miracast standard. This standard shipped a little under a year ago and defines a protocol that devices can use to share their "screen" with each other. That is, you can now do the things you wanted but failed to do with a TV companion, like show off a PowerPoint slide deck or stream a chick flick on date night.

The Miracast specification requires that devices transmit H.264 encoded video and at least 2-channel Linear Pulse-Code Modulation (LPCM) encoded audio. Devices can upgrade the latter support as needed (e.g. Dolby Advanced Codec 3) but otherwise that's it. There's not a lot room for OEMs to screw up here.

But does it work?

My set up consisted of a Surface Pro and an up-to-date Netgear Push2TV (PTV3000-100NAS, $59.99 Amazon) connected to a generic LG TV. The TV isn't important here as the adapter acts as a Miracast bridge, connecting to the TV via HDMI (and optionally USB for power). With just a few flicks and taps on the Surface, I was able to effortlessly stream its screen to the TV. Woot!

What about my xxx PC and yyy TV?

Of course you'll probably want to set this up using hardware different than mine. Here are the key features your Windows PC needs for success:

  • Wi-Fi. If you're thinking about streaming from the desktop, you may want to pick up a wireless adapter. But make sure it's...

  • A wireless device that supports Virtual Wi-Fi (introduced in NDIS 6.2) and Wi-Fi Direct (introduced in NDIS 6.3). You should see this in newer wireless devices that ship with Windows 8 support. (Most newer PCs have this so you're probably okay.) To print the NDIS version of your network devices, open Powershell and issue this one liner: Get-NetAdapter | Select Name, NdisVersion

  • A display driver specifically for Windows 8.1 (i.e. WDDM 1.3) with Miracast support. Both NVIDIA and AMD have preview code up but neither appear to support Miracast at this time. Microsoft is providing Miracast-supported Intel drivers ( inbox for select chipsets though.

(Based on preliminary code and findings. This list could change, beware.)

Walk me through this, please.

First, ensure you meet the requirements for connecting to a wireless display (see above).

Where can I read more? What if I need help?

There isn't a lot of Windows 8.1 wireless display information up just yet. But if you're a Windows driver developer, check out [Wireless Display (Miracast) Structures and Enumerations] on MSDN. Or the Miracast specification [Wi-Fi CERTIFIED Miracastâ„¢] on Wi-Fi Alliance's website.

If you run into snags and met the hardware requirements above, feel free to tweet or email me. But please be cognizant of the fact that this stuff is undocumented and bleeding edge. Adjust your expectations accordingly.

Device compatibility list

(Last updated October 21, 2013)


  • Surface RT: Not supported. Microsoft has confirmed support will not be coming to the Surface RT. (Surface 2 and Surface Pro 2 will though.)

  • Samsung ATIV Smart PC Pro: Working. [Thanks David A.]

  • PCs with Intel HD Graphics 3000 or lower: Not supported.

  • PCs with Intel HD Graphics 4000, Iris Pro (5200), or P4### variants: Working in Windows 8.1 Preview (inbox drivers). Windows 8.1 RTM untested.

  • PCs with NVIDIA graphics: Not (yet?) supported as of GeForce driver set 331.40. Oddly, these drivers do support a home-grown version of Miracast for S.H.I.E.L.D. scenarios.


  • Netgear Push2TV PTV3000  ($59.99): Working. (Make sure you're on firmware 2.4.3 or higher, it smooths out a lot of pairing bugs.)

  • Panasonic DMP-BDT230  ($109.99): Prompts for button press to complete WPS Push Button pairing, but device doesn't have a button. [Thanks @davidkozera]
  • Belkin Screencast ($119.99): Working (firmware [Thanks David K.]

  • D-Link DHD-131 ($99.99): Working. [Thanks David A.]

  • Actiontec ScreenBeam Pro ($69.99) : Working. Supports everything you throw at it -- Intel WiDi, Miracast, and legacy devices (with a USB dongle).

  • Rocketfish Miracast Video Receiver ($79.99): Working with devices supporting 2.0 firmware (allows you to workaround WPS button press bug.) 

Windows 8.1, PowerShell 4.0, and new cmdlets


When new builds of Windows leak, most people focus on easily accessible features such as the user interface or file system. While those are certainly important areas, I feel changes to the underpinnings of Windows, such as its APIs and related developer tools, often go unseen (and are, frankly, more interesting). So today, I'm switching gears and sharing my notes on Windows PowerShell cmdlets and changes coming in Windows 8.1 "Blue" (as of leaked build 9374).

VPN Configuration

Windows 8.1 features shiny new VPN configuration cmdlets to replace your aging rasdial and route-based batch files.


Windows Defender

Finer control of Windows Defender across the enterprise is now possible with these new cmdlets. (Strangely, the Windows Defender team opted to shorten the WindowsDefender prefix, breaking the usual cmdlet naming guidance/pattern. I suspect we'll see them right the ship here, so be careful if you're writing scripts around these cmdlets.)


Start Screen

These cmdlets make customization of the Start Screen way easier than previous methods.



The Deployment Image Servicing and Management tool in Windows has always been an odd PowerShell cmdlet wanna-be, with its similar but frustratingly different command syntax. Wrapping that functionality, however, are new cmdlets, and they couldn't come quickly enough.



Funny enough, Paul Thurrott and I just wrote about Kiosk Mode in Windows 8.1. These cmdlets make managing Kiosk Mode even easier.


NAT Mangement

These cmdlets appear to pertain to Network Address Translation (NAT) components in the Routing and Remote Access feature present in Windows Server, not the NAT on your home network.



A few handy Trusted Platform Module cmdlets that would otherwise require digging through the TPM Management console or TPM Base Services API.



It's always nice to see improvements to the way we access the blackbox that is Windows Management Instrumentation.




I'm not familiar with the concept of network "compartments", so can't offer much here. I suspect this is a Server "Blue" -specific addition that will make sense in the future.


Systems Management

New Physical Computer System View (PCSV) cmdlets ready Windows for next generation systems management in the enterprise.



I suspect the storage tier cmdlets are used to manage storage-related roles in Server "Blue" that I'm not familiar with. The Storage Pool cmdlet however can be used to interact with Storage Pools present in both client and server SKUs.



Little doodad cmdlets that will probably only be used by a niche group of admins out there.



We're seeing the beginnings of what's clearly an effort to wrap Systems Management Bus (SMB) API here.



I don't think we're getting a sneak peak of some next-generation Near Field Communications (NFC) printer technology here. I suspect these cmdlets are to aid in enterprise printer asset tracking. We'll undoubtedly learn more when Windows Server "Blue" hits.


PowerShell 4.0?

A screenshot of PowerShell registry data in Windows 8.1 build 9379, courtesy of WinClub.pl

As of writing, a screenshot of an even newer build of Windows 8.1 (9379) is making rounds. Assuming the screenshot is accurate, PowerShell will be seeing a bump to 4.0, suggesting language changes may be coming. When more details become available, I'll let you know.

Blue's Clues: Enabling Kiosk Mode

Over the weekend, a newer build (9374) of Windows 8.1 -- Microsoft's incremental update to Windows 8 -- leaked. One of the new features that surfaced in this build is something called "Kiosk mode".

Kiosk mode, in a nutshell, is a mode that, when turned on, keeps a single "Metro" application on the foreground at all times. (This application is run in a limited user context for obvious security reasons.) It's unclear if we'll see desktop application support -- my guess is no, given desktop apps have a much richer set of (uncontrolled) APIs available to them. For more, check out Paul Thurrott's "Blue's Clues: Kiosk Mode" article.

A cursory examination of Kiosk mode would lead you (like many tech bloggers) to believe the feature is broken in this build of Windows. But this is not the case. In fact, enabling Kiosk mode is easy but admittedly non-intuitive. Here's how:

  1. Create a limited user. You can do this PC Settings, Users, User accounts, then Add a user. (I recommend a Local Account but you can use a Microsoft account.)

  2. Log in as the limited user. You can switch to the newly created user by clicking your Start Screen user tile. (You'll have to sit through the welcome tour again, sorry.)
  3. Log out of the limited user.
  4. Switch back to your normal account and configure Kiosk mode with the new account and preferred foreground app -- Bing is a good one.
  5. Log in as your limited user. Your app should load immediately.