Surface Pro gets new wireless drivers for Windows 8.1

Marvell_Avastar_88W8797_SoC.jpg

A keen-eyed buddy of mine, George Roberts, tweeted this morning about new Marvel 88W8797 drivers on Windows Update today. The newer drivers (14.69.24040.136) feature full Windows 8.1 (post-preview) support (i.e. NDIS 6.4) and the required high throughput/low latency improvements needed to properly support scenarios such as wireless display and Skype.

Speaking of wireless display -- some of you may have noticed the feature stopped working on Surface Pro after upgrading from Windows 8.1 Preview to RTM. Well, it's time to turn that frown upside down because after installing these drivers, it's back.

Thanks for the heads up George! 

Outlook.com supports simpler "+" email aliases too

outlook.png

Outlook.com's email aliases are handy extensions of your core email account and can be used for outbound account consolidation or inbound mail categorization. Sounds complicated and hard to set up, but it's not. Paul Thurrott has some tips on setting it up and answers any questions you may have.

But if you're looking to create a cheap and easy inbound-only alias, or want an alias tied to your custom domain name, here's a quick tip: Outlook.com also supports Gmail's "+" aliasing.

For example, mail sent to rafael+pogs@withinwindows.com lands in my inbox at rafael@withinwindows.com without any additional configuration. It just works. And you can of course set up rules to put these emails into separate folders or delete on sight. (You can replace everything after the + with anything you'd like, as long as it's well formed.)

Neat!

6tag leaks your account data, stores your private videos

6tag_header.png

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 1.0.1.0

 

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

hkc_mgr.png

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?

Absolutely.

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

IMG_3072_cropped.jpg

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 (9.18.10.3200) 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)

Sources

  • 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.

Targets

  • 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 4.0.18.0 ($119.99): Working (firmware 3.5.42.0) [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.)