back to article Windows 10 build 14342: No more friendly Wi-Fi sharing

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 …

Page:

  1. John Robson Silver badge

    Good

    Automated WiFi key sharing was always really stupid.

    1. Bronek Kozicki
      Coat

      Re: Good

      Yes, seeing the back of this "feature" is a nice surprise.

      1. Richard Jones 1

        Re: Good

        WiFi Sense was always nonsense to me. It took boring work to disable its folly.

      2. Mikel

        Re: Good

        > “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?

    2. Andy france Silver badge
      FAIL

      Re: Good

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

    3. Timo

      Re: Good

      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.

      1. Andy Nugent

        Re: Good

        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.

    4. Anonymous Coward
      Anonymous Coward

      Re: Good

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

      1. Doctor Syntax Silver badge

        Re: Good

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

        1. VinceH

          Re: Good

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

      2. TheVogon

        Re: Good

        "actually came up with it and thought it was a good idea, obviously not even bothering do a cursory security audit"

        It doesn't let you share keys on corporate type WiFi setups - only home / public ones. In general it's no big deal if someone can use your internet connection.

        1. Anonymous Coward
          Anonymous Coward

          Re: Good

          "In general it's no big deal if someone can use your internet connection."

          Hope your device firewalls are in good shape !

          1. TheVogon

            Re: Good

            "Hope your device firewalls are in good shape !"

            Because being already connected to the internet, the main risk is from someone using my WiFi, right?

            1. Anonymous Coward
              Anonymous Coward

              Re: Good

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

              1. TheVogon

                Re: Good

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

                1. Anonymous Coward
                  Anonymous Coward

                  Re: Good

                  "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

    5. Annihilator
      Black Helicopters

      Re: Good

      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)

      1. Dadmin

        Re: Good

        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.

        1. Annihilator

          Re: Good

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

        2. Kiwi
          Linux

          Re: Good

          "...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?)

          1. Kiwi
            Black Helicopters

            Re: Good

            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.

    6. Anonymous Coward
      Facepalm

      Re: Good

      Unfortunately the automatic telemetry sharing with Microsoft is still very much present.

      1. Timo

        Re: Good

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

      2. joed

        Re: Good

        too many complained about this one and MS listens to praises only

    7. Kraggy

      Re: Good

      Totally agree, but what I find bemusing is the excuse they gave for killing it .. just how hard is it to write this code so that it works without the need to, as the justification alludes to, continually fiddle with it?

    8. N2

      Re: Good

      Its worrying that someone signed off on that

      Or do MS just wing it these days?

    9. Anonymous Coward
      Anonymous Coward

      Re: Good

      I wonder how many of the 300m windows 10 users know they were sharing their WiFi keys with people by default??

      The low uptake claim is a smokescreen.

      1. Jedit Silver badge
        Black Helicopters

        "how many of the 300m windows 10 users know they were sharing their WiFi keys?"

        How many of the 300 million Windows 10 users knew they were using Windows 10?

      2. TheVogon

        Re: Good

        "know they were sharing their WiFi keys with people by default??"

        You have to actively tick a box each time you add a network to share them - it's not by default.

        1. VinceH

          Re: Good

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

          1. TheVogon

            Re: Good

            "And some will probably do so without asking if you're okay with that.""

            They can do that via notepad and share them anyway - I always keep a record of wifi passwords I get given.

    10. Anonymous Coward
      Anonymous Coward

      Re: Good

      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.

      1. Naselus

        Re: Good

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

  2. Bronek Kozicki

    symlink support for Linux subsystem

    "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).

    1. petur
      Meh

      Re: symlink support for Linux subsystem

      The weird thing is that NTFS has always had support for links, but they never did anything with it (in fact, I think the only tools that allowed you to work on them were from sysinternals)

      1. BinkyTheMagicPaperclip Silver badge

        Re: symlink support for Linux subsystem

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

        1. petur

          Re: symlink support for Linux subsystem

          No, not vista onwards... I remember using it on NT. Might explain why I mentioned sysinternals because back then there were no other cmd line tools buildin

          1. stephanh

            Re: symlink support for Linux subsystem

            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.

            1. bombastic bob Silver badge

              Re: symlink support for Linux subsystem

              "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*.

          2. BinkyTheMagicPaperclip Silver badge

            Re: symlink support for Linux subsystem

            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

        2. Mage Silver badge

          Re: symlink support for Linux subsystem

          Existed in NT3.5x if not always in NT.

          Mysteriously the user interface changed or something on later versions. Not new for Vista.

          1. Anonymous Coward
            Linux

            Re: symlink support for Linux subsystem

            Funny, but not surprising, to see Microsoft still struggling with something Unix got right in the early 80s.

      2. Electron Shepherd
        Boffin

        Re: symlink support for Linux subsystem

        Windows support for symbolic links is built in - no need for external tools.

        Use the MKLINK command line program.

        1. djack

          Re: symlink support for Linux subsystem

          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.

          1. sysconfig

            @djack Re: symlink support for Linux subsystem

            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.

            1. Bronek Kozicki

              Re: @djack symlink support for Linux subsystem

              junctions do not work on files (only on directories), IIRC

            2. djack

              Re: @djack symlink support for Linux subsystem

              @sysconfig

              "While that's true for Linux hard links, I am absolutely certain that NTFS Junctions work across file systems and physical drives"

              I stand corrected, thanks.

          2. skizzerz
            Boffin

            Re: symlink support for Linux subsystem

            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.

      3. Hans 1
        Facepalm

        Re: symlink support for Linux subsystem

        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!!!

    2. JLV

      Re: symlink support for Linux subsystem

      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.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like