Bitdefender Antivirus — the free edition, at least — appears to be interfering with Remote Desktop Protocol (RDP) connections on Windows. Affected users may receive the following error when they try to log on to a remote PC or server with Network Level Authentication (NLA) enabled:
An authentication error has occurred.
The Local Security Authority cannot be contacted.
This could be due to an expired password.
While an expired password or a server-side misconfiguration can cause this error, it may also indicate a client-side issue. In this case, the error appears to be caused by Bitdefender Antivirus replacing the remote computer’s certificate in order to inspect encrypted RDP traffic. This process breaks Network Level Authentication and causes the connection to fail.
One workaround is to add file-level exclusions in Bitdefender for both the 64-bit and 32-bit versions of the Windows RDP client:
This is not an ideal solution, but the free version of Bitdefender Antivirus has a limited control panel and does not provide alternative workarounds.
On Windows and macOS, Stata can be configured to check for updates automatically with the set update_query command. However, there are a few drawbacks to this approach.
For one, this feature isn’t present on the Linux version of Stata. For two, this command doesn’t actually update Stata — it just enables update notifications. Stata will still need to be manually updated by someone with the permission to do so.
If you’re running Stata on a standalone Linux server or an HPC cluster, you may be interested in having Stata update itself without any user interaction. This is especially useful if Stata users do not have permission to update the software themselves, as is often the case on shared Linux systems.
We can enable true automatic updates with a cron job and a Stata batch mode hack:
Zoom’s meteoric rise to the top of the video conferencing market makes sense when you consider that their platform is, in fact, fairly good. So far, Zoom has managed to avoid many of the pain points that plague other video conferencing solutions:
No account is required to join a call, and calls can be joined from any platform (even from Android, iOS, and Linux).
Call quality is excellent, even on slow Internet connections.
The platform can be used for free by anyone and it’s easy to create an account.
Zoom is a standalone product with a singular focus rather than an add-on feature like Microsoft Teams or Google Hangouts.
Additionally, Zoom’s user experience is good, especially when it comes to joining a meeting. It’s hard to simplify that process much further than “here, click this link”. Overall, Zoom is easy enough to use, and it manages to keep its myriad of advanced features from getting in the way of hosting simple meetings.
UX Versus UI
With that said, Zoom is still far from perfect. While Zoom’s user experience (UX) is relatively frictionless, I’m still surprised by inconsistencies that exist in its user interface (UI). In my opinion, Zoom struggles with two main UI issues: consistency and clarity.
For one, the website shares none of the design cues of the desktop and mobile apps. Buttons don’t even share the same names: the blue “Host a Meeting” link on the website competes with a large orange “New Meeting” button in the app. The meanings of both buttons are clear upon inspection, but this means that users have to become familiar with two separate interfaces before feeling comfortable using Zoom.
Some website features don’t appear in the app, and vice versa. For example, the “Previous Meetings” tab on the website doesn’t map back to anything in the “Meetings” section of the app. Similarly, the links in the navigation bar at the top of the app (Home/Chat/Meetings/Contacts) don’t match anything on the website.
Most frustratingly, the “Schedule a Meeting” interface on the website is substantially different from the one in the app. While the website prompts you to choose a start time and duration (and only allows you to adjust those times in half hour increments), the app asks for a start time and end time. The form options themselves are labeled differently: the start time is listed as “When” on the website and as “Date” in the app. At the bottom of the form, the advanced meeting options aren’t even presented in a consistent order between the two interfaces.
Finally, weird things occasionally happen while using Zoom. For example, when I went to unmute someone in a recent meeting, the participant list started arbitrarily reordering itself every few seconds. This made it almost impossible to choose the right person, as someone else would jump under my mouse cursor before I clicked. I’m still not sure if this was an intended feature, but it doesn’t make sense that it would be.
On the clarity side, some of the buttons in the app aren’t immediately recognizable as buttons. The Join Audio/Share Screen/Invite Others trio is the most notable example of this issue:
I’ve been using Zoom for a while now, and every time I launch a meeting I have to remind myself that those three pieces of clip art are actually clickable. Additionally, since the introductory screen vanishes once other participants join, these buttons can’t be relied upon throughout the duration of a meeting.
Zoom’s UI does get one thing right: every button is clearly labeled with a description of what it does. While this may not be the most aesthetically pleasing choice, it makes it easy for untrained users to get started with Zoom. For that reason alone, I appreciate Zoom’s simple and unglamorous UI, but it’s still important that it isn’t so simplistic and inconsistent that it detracts from the user experience.
Update 2/12/2020:Microsoft has reversed their decision to automatically install the Microsoft Search in Bing extension. The extension will still be made available but will not be automatically deployed with Office 365 ProPlus. The original post continues below:
Starting next month, Microsoft plans to use Office 365 ProPlus to push a browser extension for Google Chrome that will change users’ default search engines to Bing. Version 2002 of Office 365 ProPlus will forcibly install the Microsoft Search in Bing extension for all Chrome users who do not already use Bing as their default search engine.
At this point, only businesses that have deployed Office 365 ProPlus are affected. Depending on the organization’s Office 365 license, ProPlus is the version of Office delivered to end-users when they install Office from the office.com portal. According to Microsoft, not all Office 365 plans include the ProPlus version of Office:
This extension is included only with Office 365 ProPlus. It isn’t included with Office 365 Business, which is the version of Office that comes with certain business plans, such as the Microsoft 365 Business plan and the Office 365 Business Premium plan.
Firefox Is Next
According to Microsoft, a similar extension for Firefox is also on the way:
Support for the Firefox web browser is planned for a later date. We will keep you informed about support for Firefox through the Microsoft 365 Admin Center and this article.
Removing The Extension
By making the extension an opt-out feature, Microsoft is putting the onus on system administrators to deploy a method for blocking its installation. While there are official ways to prevent the extension from being installed, there is no easy Microsoft-supported method for removing the extension once it has already been deployed. Instead, Microsoft recommends running the following command as an administrator on each affected machine using a script:
It should also be possible to blacklist the extension with the 3rd party Group Policy templates for Chrome and Firefox provided by Google and Mozilla.
Unfortunately, Group Policy and other enterprise management tools do not always apply to BYOD devices, leaving users who install Office on their personal machines with little recourse except to notice and remove the extension on their own if they find it undesirable.
If you saw a headline earlier this week about a critical security flaw in VLC media player, you may not have gotten the whole story. In fact, the issue is not nearly as serious as it originally seemed.
About a month ago, a user opened a bug report for a crash in VLC caused by a specifically crafted mp4 file. With the cause of the crash still undetermined, MITRE assigned the bug a CVE identifier and gave it a “critical” score of 9.8.
With the bug’s true cause and impact still undetermined, Germany’s CERT-Bund issued an alert of their own warning of a critical flaw in VLC. Worse, because the now several-week-old VLC bug report did not list any significant progress by the VideoLAN team, CERT-Bund announced that no patch was available. The alert kicked off a flurry of other news articles that culminated in a misguided warning from Gizmodo to completely uninstall VLC.
Not a VLC Bug
The only problem was that there was never anything wrong with VLC in the first place. The crash described in the bug report was the result of a vulnerability in libEBML, a third-party library that VLC depends on. However, according to a thread on Twitter from the VideoLAN team, a patched version of libEBML has been shipped with VLC for over a year. It appears the bug report was generated from a Linux system with an older, vulnerable version of libEBML installed.
With that in mind, the CVE score was lowered to “medium” and the report in the VLC bug tracker was closed. Ubuntu released an update for libEBML, and Gizmodo withdrew their doomsday-level announcement. In the end, no patch for VLC is currently required, though some Linux distributions may need to make an updated version of libEBML available.
Julia, the fast-moving and popular open source programming language for scientific computing, allows for the usage of multiple BLAS implementations. Pre-built Julia binaries ship with OpenBLAS due to licensing restrictions surrounding the Intel Math Kernel Library, but by building Julia from source you can replace OpenBLAS with a free copy of MKL obtained from Intel’s Yum or Apt repositories. As of the time of writing, there are instructions for this process on the Julia GitHub repository.
Determining the BLAS Vendor
Regardless of which BLAS implementation you choose, it is nice to check that Julia is actually using the one you want, especially if you are building Julia from source. In recent versions of Julia, you can run the following two commands in the Julia REPL to find your BLAS vendor:
julia> using LinearAlgebra
The second command should output a string indicating which BLAS implementation your Julia installation is currently built with.