Good
Automated WiFi key sharing was always really stupid.
The latest Windows 10 preview has been released by Microsoft, with changes making it more Linux and web-friendly. Gone, however, is automatic Wi-Fi sharing with contacts, with Microsoft citing low uptake over cost of development. Extensions to Edge, Microsoft’s browser alternative to Internet Explorer, in Windows 10 build …
> “The cost of updating the code to keep this feature working combined with low usage and low demand made this not worth further investment. Wi-Fi Sense, if enabled, will continue to get you connected to open Wi-Fi hotspots that it knows about through crowdsourcing.”
Another abandoned legacy security hole then? Didn't Windows already have enough of those?
I'm probably one of the few people who tried to use it. When I'm travelling with the wife I always end up setting the hotel WiFi access up for both of us. Key sharing should in theory have saved me from setting up her access but in practice it took forever for the key to get to her ..... quite possibly because she didn't have network access.
And then there were hotels that restrict the access use of the WiFi password to one MAC address at a time. Best not to share those.
I wont miss is..
WiFi Sense seemed interesting, but I couldn't figure out how it would improve things, especially on desktops. You'd need a connection to download the info... and if you already had a connection then the "Sense" part of it became redundant.
That and it came out first on Windows phones and there were never enough people using them to get some kind of "network effect" to kick in and make it something. On a phone with a cellular data connection it was almost understandable - you could download the login credentials over the network to get a connection to WiFi for data offload. But even that was of questionable value.
Guess I can turn it off on my Winphone8.
I never really got much use out of it as I don't really know that many people with Windows Phones, but you could imagine a more widespread (Android / iOS / cross platform) variant being quite useful. e.g., had a friend visited at the weekend from abroad, and he asked in a couple of bars / cafes we were in for the WiFi password, information already stored on my phone that I couldn't pass on to him. Close friends could have my home WiFi, everyone else just gets the public WiFi I've saved.
"Automated WiFi key sharing was always really stupid."
What worries me is that someone at some point (probably a low level manager or designer trying to make a name for himself) actually came up with it and thought it was a good idea, obviously not even bothering do a cursory security audit of the potential pitfalls and nor did anyone senior either it would seem. You have to wonder whats going on at that company sometimes.
"You have to wonder whats going on at that company sometimes."
You also have to wonder why, having come to their senses and dropped it, they do so on the basis of some waffle about the effort needed to maintain it. They might at least get the brownie points for doing the right thing for the right reason.
"You also have to wonder why, having come to their senses and dropped it, they do so on the basis of some waffle about the effort needed to maintain it. They might at least get the brownie points for doing the right thing for the right reason."
That would be like admitting they were wrong. Not going to happen.
"Because being already connected to the internet, the main risk is from someone using my WiFi, right?"
I thought you might understand. If, like me your main firewall/NATS is your ADSL router but have a sep. wifi access point then the firewalls on all your devices have to be OK if you let anyone connect to your wifi.
"If, like me your main firewall/NATS is your ADSL router but have a sep. wifi access point then the firewalls on all your devices have to be OK if you let anyone connect to your wifi."
ADSL firewalls by default let open ports on your internal devices connect to the internet. No home grade device does anything significantly more than stateful tracking of connections, which stops nothing if the port you want is open anyway. Therefore allowing access via WiFi is little different. Most modern WiFi routers can separate the traffic between an internal DMZ and the WiFi network to provide the same degree of "protection" anyway...
"ADSL firewalls by default let open ports on your internal devices connect to the internet. "
On my NETGEAR router ALL port forwarding was OFF by default. I explicitly had to allow a SSH port forwarding. Whereas my NETGEAR WiFi access point will allow attempts on open ports on the internal network hence most are firewalled AND the WiFi security is as tight as I can make it
WiFi key sharing may well be stupid, but consider this - the rolling Windows 10 updates mean Microsoft are now disabling features on products you own a licence to use.
You're happy now, as it's a feature you weren't keen on, but this implies that anything they can't be arsed with in the future they'll remove, leaving you with no choice but to lose the feature or have an unpatched version of Windows.
Rather ominous... and reminds me of when Sony started removing features from the PS3 (ability to run Linux for example - you had the choice of keeping it, sure, but a non-up-to-date PS3 isn't able to connect to the PSN)
Holy crap, don't get me started on Sony, The One And Only... CD vendor who shipped rootkits on their music CDs... What they did to try and thwart honest hackers who wanted to run Linux on the PS3 was downright anti-consumer.
However, with regards to this Windows feature removal it's a bit different. With the PS3; that's a partially locked down firmware situation and the 1st party trying to keep the money flowing in by making it a games-only device. For Windows you don't have that issue. This is the OS changing, not our BIOS/secure_boot code(the firmware), and in any event some third party devs can now jump in and provide a solution to this removed feature. Not all that big of a problem, just wait a bit and download the community's solution.
"This is the OS changing, not our BIOS/secure_boot code(the firmware), and in any event some third party devs can now jump in and provide a solution to this removed feature"
Perhaps, but consider the option of Microsoft deciding that third party software not supplied via the Windows store is too much of a faff to look after, and removes the "feature" of installing any .exe of your choosing. Basically turning it into a walled garden like the PS3 or an iPhone.
Extreme, perhaps, and an unlikely example, but still a precedent now that Windows 10 isn't a product you buy anymore and expect to work/be supported, but a service that MS can chop and change at will.
"...trying to keep the money flowing in by making it a games-only device."
I always found that sort of thinking to be a bit funny. I'm not a games-console sort of person (I do play PC games often, loving some (very) old classics). I would never be one to buy a console for the use of games.
But, if your hardware is the best price/function match for a job I want done then I'd be likely to buy it for another purpose. If you lock it down so I can't use it, I'll use someone else's hardware and they'll get my money.
That said, due to the CD issue and now the Linux/PS issue, I won't touch Sony products (even avoid their movies). Had they let Linux work on PS I'd have forgiven their other ancient screwup but when they did that.. (I assume the PS still can't run Linux without some faffing around?)
Just a note for others in case they haven't seen this and still use Siteadvisor (I haven't used this machine in a while) :
When I sent my post WebAdvisor (I used to use SiteAdvisor, what happened to that??) popped up a banner warning I'd used the password on another account. I haven't actually, my Reg password is unique to El Reg - but I do find it a little creepy that McAfee was monitoring and storing my used passwords. Now to take WA off the plugins and trust that Avira's one does the job.
HTH someone.
I wish they were actually doing something with the telemetry data - my aged desktop with Win10 crashes all the time apparently due to a bad storage driver. Lots of comments on the internets about similar problems. If they noticed that some machines with X configuration are crashing all_the_time I'd expect some kind of fix...
"You Your guests have to actively tick a box each time you add a network give them access to your WiFi to share them - it's not by default. And some will probably do so without asking if you're okay with that."
FTFY, because that's the real problem - guests.
Luckily I've had no visitors who are using Windows 10 and needed internet access. I'd already decided decided that if I did, I would be changing the password after every such visit.
I didn't know, however, that it was an opt in thing. On that basis, rather than recite the key to them, it would be easier to just grab the computer and enter it oneself, and ensure that option is unset (while at the same time trusting Microsoft not to piss around and change such options*) - but an obvious question is can user re-visit that setting for a particular network and subsequently change it?
* Luckily, though, they have changed it - in a sensible way.
"I found it really handy, but making more home WiFi publically accessible would be a better solution.
For most people locking down their WiFi is of little benefit anyway these days. You should be using HTTPS or similar for any services you care about."
I do hope no-one lets you configure a router. Ever.
"A range of improvements to Bash on Ubuntu sees Symlinks within Windows Subsystem for Linux now work on the mounted Windows directories."
I won't use Linux subsystem under Windows 10 much (my Windows 10 is running in a virtual machine, and I run separate Linux VM too) but I know that symlinks under Windows were always tricky. It is nice to see commitment on the side of Microsoft to this subsystem, with them having implemented support for symlinks (even if only sufficient to make Linux subsystem work).
Not entirely true. Symlinks (junctions) have been in use from Vista onwards to make certain directories appear in multiple locations, and try and rationalise a less than ideal historic directory arrangement.
I use it occasionally, and it's quite useful for installations where the system drive is far too small, yet that's the one all the patches keep mounting up on..
The MKLINK command was introduced in Vista, but the kernel support is older, and you could access it using third-party tools pre-Vista.
BTW, there is a difference between junctions and symlinks, although both are created with MKLINK. Symlinks support linking to files for sure.
Too bad that MKLINK requires administrator privileges. On Linux, any lowly user can create symlinks. I am not sure why this would be considered a security concern on Windows.
Also, annoyingly, the arguments to MKLINK are swapped relative to "ln -s". Never miss up a chance to be incompatible with other systems, I guess.
"Also, annoyingly, the arguments to MKLINK are swapped relative to 'ln -s'. Never miss up a chance to be incompatible with other systems, I guess."
There's the RIGHT way, the WRONG way, the MILITARY way, and the MICROSOFT way.
[guess which way THEY chose?]
what I would like to see is a hard-link to a file that does what you see in POSIX systems; that is, it increases the reference count on the physical storage for the file, allowing you to refer to it from anyplace on that volume, and it appears as if it IS "the file" from any of them, but deleting any of those references doesn't delete the actual file until the actual file has no more references.
So Microsoft's 'junctions' really are like symbolic links, and NOT like hard links at all. When you do a 'dir' listing they show up as 'junction', etc. etc. (though I don't recall if a file alias shows up differently or not). And don't even get me started on attributes like 'hidden' and the security things associated with them... *shudder*.
I should clarify : NTFS has supported junctions for a long time.
They are used in Vista and later as part of the base install, can't remember them being used before then. i.e.
C:\Users>dir /ah
Volume in drive C has no label.
Volume Serial Number is EE29-AD12
Directory of C:\Users
22/08/2013 15:45 <SYMLINKD> All Users [C:\ProgramData]
06/08/2015 20:52 <DIR> Default
22/08/2013 15:45 <JUNCTION> Default User [C:\Users\Default]
See https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365006(v=vs.85).aspx
You're all nearly there with mentions of junctions an mklink. However, they are the equivalent of hard links, not symlinks.
Hard links exist at the filesystem layer. Symlinks happen at a layer on top. Hard links can only ever link files within the same filesystem but symlinks can cross fs boundaries.
The closest windows equivalent to a symlink is a shirtcut. However whereas shortcuts are provided by Explorer, symlink functionality is in the core system libraries and therefore used by everything.
djack, I don't think your assessment is correct, or I am misreading it. You say: However, they [junctions] are the equivalent of hard links, not symlinks. And then you go on to say: Hard links can only ever link files within the same filesystem but symlinks can cross fs boundaries.
While that's true for Linux hard links, I am absolutely certain that NTFS Junctions work across file systems and physical drives, so they don't quite resemble Linux hard links. In fact, to give one example, my user home directory is Junction'ed from another physical drive into the normal C:\Users hierarchy to save space on the system drive, and that works just fine without touching anything else (registry etc) to make it happen.
Windows (or NTFS rather) has proper symlinks in addition to junctions, both are created by using mklink from an elevated command prompt, no external tools required. Junctions are also not the same as hardlinks (mklink can make hardlinks too), and are actually more similar to symlinks but implemented in a different manner (and only work on directories). In NTFS, hardlinks (mklink /H) and symlinks (mklink for files or mklink /D for directories) behave pretty much the same way as on UNIX platforms. NTFS junctions (mklink /J) are an entirely different animal, while the end result is superficially the same as a symlink, they only work on local directories and must use absolute paths (whereas symlinks can point to shares and such). The main user-facing difference between a directory symlink and a junction in NTFS is that deleting a symlink via del will delete the symlink file, whereas attempting to delete a junction via del will forward that request to the directory it's pointing at (thus deleting the files at the target). I believe the most "equivalent" feature to an NTFS junction in unix would be mount --bind.
cmd.exe /k "mklink /?"
Windows 8+ ... yes, 20 years overdue, but finally made it into Windows ... ;-)
I used to run a Java program to create symlinks and junctions ... a simple Java program I wrote, of course, took mere minutes to author - nothing fancy. Probably quicker than to hunt down sysinternals and find the proper executable for the task ...
I do like their process explorer, though, great stuff!!!
So, for argument's sake, let's say your app needs to know where jquery is. Let's say furthermore that you have downloaded jquery.2.1.4 and you keep in a directory or file named jquery.2.1.4. Yeah, yeah, I realize jquery may not be the best example, but it has numerous versions, bear with me.
One great use of symlink is to say: ln -s ./jquery.2.1.4 ./jquery. Your app nicely points to ./jquery, not caring which release it is. If you update ./jquery.2.1.4, then your app "knows" about it too.
Is this something easily achievable with mklink or whatever command Windows 10 uses? Does it cover both directories and files? I confess I never really figured out what the Win 7 command was for this, despite being well aware of the possibilities of Unix symlinks.
I knew linking existed in Windows 7, but it was not very heavily promoted, to say the least. I could never figure out whether it was that the Windows implementation was limited or whether the Windows user/admin culture just wasn't clued in onto the possibilities.
Needing an admin right to do so is no big deal, though annoying.
i.e. what does the actual command line look like? I can do this on the command line, right? i.e. aside from MS "using the wrong order for the command arguments" , as noted elsewhere, is MS's solution actually a capable stand-in for the bsd/linux ln? Regular cmd or Powershell?
This is actually more a question for Windows itself, not so much how well it plays with Linux subsystems.