Look out for this patch and be diligent in implementing it to the machine. Here is one vulnerability (CVE-2017-8620) that has high potential to be of parallel to the WannaCry and NotPetya vulnerabilities -- it is described as 'The Next WannaCry Vulnerability'. Finally, if patching is planned but delayed, Microsoft's recommended temporary mitigation against CVE-2017-8620 should be deployed: disable the WSearch facility within Windows.
Google Chrome is hopeless for reading social media - Preliminary findings below
I am currently undertaking a comparison of 6 Web Browsers which will eventually be turned into an article of my findings - most likely once Microsoft Edge has been reincarnated into the planned Chromium based platform.
In the meantime, thought I'd share a preliminary finding that is quite definitive when reading Social Media - Facebook in particular.
Using Google Chrome on Windows 10 (64-bit) in my case, you may be finding that if browsing Facebook for a while, as you keep scrolling down your feed, it will get slower, and slower, and slower, until the point where is gets so frustratingly slow, that you end up closing Chrome completely, re-opening it and starting again, at which point speed returns to normal.
Sound familiar? Keep reading.
Doing the same tests with the Brave Browser, I have noted none of the noticeable slow downs in performance of Facebook pages when used for the the same amount of time. The same has proven true to some extent on YouTube, though tests on YouTube and other social media platforms have not been as extensive yet.
My preliminary finding is as follows: Dump Chrome for Social Media like Facebook and YouTube and use the Brave browser for that purpose instead. It makes a *huge* difference on my system.
For the sake of completeness, by "quite some time", I'm talking …
SQL Server Management Studio : Windows Authentication from a non-domain-joined computer.
When trying to connect with an Windows integrated account to a domain-joined Microsoft SQL Server 2017 from a non-domain-joined computer or a computer joined to another non-trusted domain, you get a "login failed" on every connection attempts.
The solution (or workaround) is to use the Windows Credential Manager to pre-configure the domain user account to be trusted by SSMS with the following steps:
Open Credential Manager (type Credential Manager from the Start Menu)
Click "Add A Windows Credential"
Populate the network address field with the name and port number of the SQL instance you wish to store credentials. For example: MyMSSQLServer.domain.org:1433 (1433 is the default port, you may need a different port, especially if you are connecting to a named instance).
Populate the "User Name" including the domain name: "DOMAIN\Username"
Enter the "Password"
Done! Restart SSMS, try connecting to the remote SQL Server from your non-domain joined machine and this time your login should work!