Tech News

In April this year, Mozilla announced that it would be shutting down its IRC network stating that it creates “unnecessary barriers to participation in the Mozilla project.” Last week, Mike Hoye, the Engineering Community Manager at Mozilla, shared the four final candidates for Mozilla’s community-facing synchronous messaging system: Mattermost, Matrix/Riot.im, Rocket.Chat, and Slack. Mattermost is a flexible, self-hostable, open-source messaging platform that enables secure team collaboration. Riot.im is an open-source instant messaging client that is based on the federated Matrix protocol. Rocket.Chat is also a free and open-source team chat collaboration platform. The only proprietary option in the shortlisted messaging platform list is Slack, which is a widely used team collaboration hub. Read also: Slack stocks surges 49% on the first trading day on the NYSE after direct public offering Explaining how Mozilla shortlisted these messaging systems, Hoye wrote, “These candidates were assessed on a variety of axes, most importantly Community Participation Guideline enforcement and accessibility, but also including team requirements from engineering, organizational-values alignment, usability, utility and cost.” He said that though there were a whole lot of options to choose from these were the ones that best-suited Mozilla’s current institutional needs and organizational goals. Mozilla will soon be launching official test instances of each of the candidates for open testing. After the one month trial period, the team will be taking feedback in dedicated channels on each of those servers. You can also share your feedback in #synchronicity on IRC.mozilla.org and a forum on Mozilla’s community Discourse instance that the team will be creating soon. Mozilla's timeline for transitioning to the finalized messaging system September 12th to October 9th: Mozilla will be running the proof of concept trials and accepting community feedback. October 9th to 30th: It will discuss the feedback, draft a proposed post-IRC plan, and get approval from the stakeholders. December 1st:  The new messaging system will be started. March 1st, 2020: There will be a transition time for support tooling and developers starting from the launch to March 1st, 2020. After this Mozilla’s IRC network will be shut down. Hoye shared that the internal Slack instance will still be running regardless of the result to ensure smooth communication. He wrote, “Internal Slack is not going away; that has never been on the table. Whatever the outcome of this process, if you work at Mozilla your manager will still need to be able to find you on Slack, and that is where internal discussions and critical incident management will take place.” In a discussion on Hacker News, many rooted for Matrix. A user commented, “I am hoping they go with Matrix, least then I will be able to have the choice of having a client appropriate to my needs.” Another user added, “Man, I sure hope they go the route of Matrix! Between the French government and Mozilla, both potentially using Matrix would send a great and strong signal to the world, that matrix can work for everyone! Fingers crossed!” Many also appreciated that Mozilla chose three open-source messaging systems. A user commented, “It's great to see 3/4 of the options are open source! Whatever happens, I really hope the community gets behind the open-source options and don't let more things get eaten up by commercial silos cough slack cough.” Some were not happy that Zulip, an open-source group chat application, was not selected. “I'm sad to see Zulip excluded from the list. It solves the #1 issue with large group chats - proper threading. Nothing worse than waking up to a 1000 message backlog you have to sort through to filter out the information relevant to you. Except for Slack, all of their other choices have very poor threading,” a user commented. Check out the Hoye’s official announcement to know more in detail. Other news in web Firefox 69 allows default blocking of third-party tracking cookies and cryptomining for all users Wasmer’s first Postgres extension to run WebAssembly is here! JavaScript will soon support optional chaining operator as its ECMAScript proposal reaches stage 3

At the end of January, Unity announced the ‘Obstacle Tower Challenge’ to test AI game players. The Obstacle Tower Challenge examines how AI software performs in computer vision, locomotion skills, and high-level planning. The challenge began on 11th February and will run through 24th May. Round 1 ran from 11th Feb till 31st March and the results are just in. For the first round of the challenge, Unity received 2000+ entries from 350+ teams. Now, Unity has announced the launch of the second round of the challenge. Teams who trained an agent in round one and received an average score of five on unseen versions of the tower will advance for round 2. Agents will need to account for a variety of new challenges in Obstacle Tower Environment 2.0 including enemies to dodge, distractions to avoid, and more complicated floor layouts with circling paths. What’s new in the Obstacle Tower Environment 2.0? Unity has expanded the floors in the tower from 25 to 100 with three new visual styles - Industrial, Modern, and Future. The higher floors also contain new challenges apart from the ones already present such as enemies to dodge, distracting TVs to avoid, more complex floor layouts with circling paths, and larger rooms on each floor with additional platforming challenges. Obstacle Tower Environment 2.0 has expanded on the number of available parameters which can be customized when resetting the environment. These include the ability to change things like the lighting, visual theme, floor layouts, and room contents on the floors in the tower. They have also worked on the placement of the reset button in puzzle rooms which, based on feedback from round 1, was unintuitive. So Unity has now separated out the block, goal, and reset button positions in these rooms, to make it less likely that the agent will press the reset button by accident. The Obstacle Tower Environment natively supports the Unity ML-Agents Toolkit. To learn more about the environment, you can go through their research paper. Unity has also released the final list of contestants selected for Round 2. Unity has launched the ‘Obstacle Tower Challenge’ to test AI game players Unity updates its TOS, developers can now use any third party service that integrate into Unity. Improbable says Unity blocked SpatialOS; Unity responds saying it has shut down Improbable and not Spatial OS.

A few days ago, Amazon announced the general availability of the Windows Container support on  Amazon Elastic Kubernetes Service (EKS). The company announced a preview of the Windows Container support in March this year and also invited customers to try it out and provide their feedback. With the Windows Container Support, development teams can now deploy applications designed to run on Windows Servers, on Kubernetes alongside Linux applications. It will also bring in more consistency in system logging, performance monitoring, and code deployment pipelines. “We are proud to be the first Cloud provider to have General Availability of Windows Containers on Kubernetes and look forward to customers unlocking the business benefits of Kubernetes for both their Windows and Linux workloads,” the official post mentions. A few considerations before deploying the Worker nodes include: Windows workloads are supported with Amazon EKS clusters running Kubernetes version 1.14 or later. Amazon EC2 instance types C3, C4, D2, I2, M4 (excluding m4.16xlarge), and R3 instances are not supported for Windows workloads. Host networking mode is not supported for Windows workloads. Amazon EKS clusters must contain 1 or more Linux worker nodes to run core system pods that only run on Linux, such as coredns and the VPC resource controller. The kubelet and kube-proxy event logs are redirected to the Amazon EKS Windows Event Log and are set to a 200 MB limit. In a demonstration, Martin Beeby, a principal evangelist for Amazon Web Services has created a new Amazon Elastic Kubernetes Service cluster, which works with any cluster that is using Kubernetes version 1.14 and above. He has also added some new Windows nodes and deploys a Windows application. For a complete demonstration and to know more about the Amazon EKS Windows Container Support, read AWS’ official blog post. Amazon EBS snapshots exposed publicly leaking sensitive data in hundreds of thousands, security analyst reveals at DefCon 27 Amazon is being sued for recording children’s voices through Alexa without consent Amazon Managed Streaming for Apache Kafka (Amazon MSK) is now generally available

Yesterday, the Netflix team announced to open-source Metaflow, a Python library that helps scientists and engineers build and manage real-life data science projects. The Netflix team writes, “Over the past two years, Metaflow has been used internally at Netflix to build and manage hundreds of data-science projects from natural language processing to operations research.” Metaflow was developed by Netflix to boost productivity of data scientists who work on a wide variety of projects from classical statistics to deep learning. It provides a unified API to the infrastructure stack required to execute data science projects, from prototype to production. Metaflow integrates with Netflix's data science infrastructure stack Models are only a small part of an end-to-end data science project. Production-grade projects rely on a thick stack of infrastructure. At the minimum, projects need data and a way to perform computation on it. In a business environment like Netflix's typical data science project, the team touches upon all the layers of the stack depicted below: Source: Netflix website Data is accessed from a data warehouse, which can be a folder of files, a database, or a multi-petabyte data lake. The modeling code crunches the data executed in a compute environment and a job scheduler is used to orchestrate multiple units of work. Then the team architects the code to be executed by structuring it as an object hierarchy, Python modules, or packages. They version the code, input data, and produce ML models. After the model has been deployed to production, the team faces pertinent questions about model operations for example; How to keep the code running reliably in production? How to monitor its performance? How to deploy new versions of the code to run in parallel with the previous version? Additionally at the very top of the stack there are other questions like how to produce features for your models, or how to develop models in the first place using off-the-shelf libraries. In this Metaflow provides a unified approach to navigating the stack. Metaflow is more prescriptive about the lower levels of the stack but it is less opinionated about the actual data science at the top of the stack. Developers can use Metaflow with their favorite machine learning or data science libraries, such as PyTorch, Tensorflow, or  SciKit Learn. Metaflow allows you to write models and business logic as idiomatic Python code. Internally, Metaflow leverages existing infrastructure when feasible. The core value proposition of Metaflow is its integrated full-stack, human-centric API, rather than reinventing the stack itself. Metaflow on Amazon Web Services Metaflow is a cloud-native framework which it leverages elasticity of the cloud by design — both for compute and storage. Netflix is one of the largest users of Amazon Web Services (AWS) and have accumulated plenty of operational experience and expertise in dealing with the cloud. For this open-source release, Netflix partnered with AWS to provide a seamless integration between Metaflow and various AWS services. Metaflow comes with built-in capability to snapshot all code and data in Amazon S3 automatically, a key value proposition for the internal Metaflow setup. This provides data science teams with a comprehensive solution for versioning and experiment tracking without any user intervention, core of any production-grade machine learning infrastructure. In addition, Metaflow comes bundled with a high-performance S3 client, which can load data up to 10Gbps. Additionally Metaflow provides a first-class local development experience. It allows data scientists to develop and test code quickly on laptops, similar to any Python script. If the workflow supports parallelism, Metaflow takes advantage of all CPU cores available on the development machine. How is Metaflow different from existing Python frameworks On Hacker News, developers discuss how Metaflow is different than existing tools or workflows. One of them comments, “I don't like to criticise new frameworks / tools without first understanding them, but I like to know what some key differences are without the marketing/PR fluff before giving one a go. For instance, this tutorial example here does not look substantially different to what I could achieve just as easily in R, or other Python data wrangling frameworks. Is the main feature the fact I can quickly put my workflows into the cloud?” Someone from the Metaflow team responds on this thread, “Here are some key features: - Metaflow snapshots your code, data, and dependencies automatically in a content-addressed datastore, which is typically backed by S3, although local filesystem is supported too. This allows you to resume workflows, reproduce past results, and inspect anything about the workflow e.g. in a notebook. This is a core feature of Metaflow. - Metaflow is designed to work well with a cloud backend. We support AWS today but technically other clouds could be supported too. There's quite a bit of engineering that has gone into building this integration. For instance, using the Metaflow's built-in S3 client, you can pull over 10Gbps, which is more than you can get with e.g. aws CLI today easily. - We have spent time and effort in keeping the API surface area clean and highly usable. YMMV but it has been an appealing feature to many users this far.” Developers can find the project home page here and its code at GitHub. Netflix open sources Polynote, an IDE-like polyglot notebook with Scala support, Apache Spark integration, multi-language interoperability, and more Tesla Software Version 10.0 adds Smart Summon, in-car karaoke, Netflix, Hulu, and Spotify streaming Netflix security engineers report several TCP networking vulnerabilities in FreeBSD and Linux kernels  

Developed by GoldFire Studios, Howler.js is an audio library for the modern web that makes working with audio in JavaScript easy and reliable across all platforms. It defaults to Web Audio API and falls back to HTML5 Audio to provide support for all browsers and platforms including IE9 and Cordova. Originally, it was developed for an HTML5 game engine, but it can also be used just as well for any other audio related function in web applications. Features of Howler.js Single API for all audio needs: It provides a simple and consistent API to make it easier to build audio experiences in your application. Audio sprites: For more precise playback and lower resources. you can define and control segments of files with audio sprites. Supports all codecs: It supports all codecs such as MP3, MPEG, OPUS, OGG, OGA, WAV, AAC, CAF, M4A, MP4, WEBA, WEBM, DOLBY, FLAC. Auto-caching for improved performance: It automatically caches loaded sounds that can be reused on subsequent calls for better performance and bandwidth. Modular architecture: Its modular architecture helps you to easily use and extend the library to add custom features. Which browsers does it support? Howler.js is compatible with the following: Google Chrome 7.0+ Internet Explorer 9.0+ Firefox 4.0+ Safari 5.1.4+ Mobile Safari 6.0+ Opera 12.0+ Microsoft Edge Read more about Howler.js on its official website and also check out its GitHub repository. npm at Node+JS Interactive 2018: npm 6, the rise and fall of JavaScript frameworks, and more InfernoJS v6.0.0, a React-like library for building high-performance user interfaces, is now out The Ember project releases version 3.5 of Ember.js, Ember Data, and Ember CLI

On Tuesday, SaltStack, the creators of intelligent automation for IT operations and security teams, announced the general availability of SaltStack Protect. SaltStack Protect is for automated discovery and remediation of security vulnerabilities across web-scale infrastructure. It is a new product available in the SaltStack SecOps family of products and is an addition to SaltStack Comply. SaltStack Comply automates the work of continuous compliance and has been updated with new CIS Benchmark content and a new SDK for the creation of custom security checks. The SaltStack SecOps products provides a collaborative platform for both security and IT operations teams to help customers break down organizational silos, offset security and IT skills gaps and talent shortages. “The massive amount of coordination and work required to actually fix thousands of infrastructure security vulnerabilities as quickly as possible is daunting. Vulnerability assessment and management tools require integrated and automated remediation to close the loop on IT security. SaltStack Protect gives security operations teams the power to control, optimize, and secure the entirety of their IT infrastructure while helping teams collaborate to mitigate risk.” said Marc Chenn, SaltStack CEO. Key features in SaltStack Protect As per the team, SaltStack Protect automates the remediation of vulnerabilities by delivering closed-loop workflows to scan, detect, prioritize, and fix critical security threats. Other capabilities include: Native CVE scanning – SaltStack Protect scans for both on-premise and cloud systems to detect threats based on more than 12,000 CVEs across operating systems and infrastructure. Intelligent vulnerability prioritization – To assess and prioritize threats for remediation, SaltStack collects real-time data on the configuration state of every asset in an environment and combines it with vulnerability information from SaltStack Protect to accurately differentiate vulnerabilities that are exploitable from those that are not. Automated remediation – SaltStack Protect brings the power of automation to SecOps teams with an API-first solution that scans IT systems for vulnerabilities and then provides out-of-the-box automation workflows to remediate them. As per the company, SaltStack SecOps products are built on SaltStack enterprise delivering a single platform for frictionless collaboration between security and IT teams. This resulted in users having a 95% decrease in the time required to find and fix critical vulnerabilities. While traditional security scanning tools report vulnerabilities that operations teams must investigate, prioritize, test, fix, and then report back to security. SaltStack eliminates nearly all the manual steps associated with vulnerability remediation, potentially saving time, resources, and redundant tools to protect against critical vulnerabilities. SaltStack is used by many IT operations, DevOps and site reliability engineering organizations around the world such as IBM Cloud, eBay, and TD Bank. If you are interested to know more about this news, check out their official blog post. Additionally SaltStack Comply and SaltStack Protect are also available via subscription and you can schedule a trial demo too. DevSecOps and the shift left in security: how Semmle is supporting software developers [Podcast] Why do IT teams need to transition from DevOps to DevSecOps? 5 reasons poor communication can sink DevSecOps 2019 Deloitte tech trends predictions: AI-fueled firms, NoOps, DevSecOps, intelligent interfaces, and more Can DevOps promote empathy in software engineering?

The makers of Citra, an emulator for the Nintendo 3DS, have released a new emulator called yuzu. This emulator is made for the Nintendo Switch, which is the 7th major video game console from Nintendo. The journey so far for yuzu Yuzu was initiated as an experimental setup by Citra’s lead developer bunnei after he saw that there were signs of the Switch’s operating system being based on the 3DS’s operating system. yuzu has the same core code as Citra and much of the same OS High-Level Emulation (HLE). The core emulation and memory management of yuzu are based on Citra, albeit modified to work with 64-bit addresses. It also has a loader for the Switch games and Unicorn integration for CPU emulation. Yuzu uses Reverse Engineering process to figure out how games work, and how the Switch GPU works. Switch’s GPU is more advanced than 3DS’ used in Citra and poses multiple challenges to reverse engineer it. However, the RE process of yuzu is essentially the same as Citra. Most of their RE and other development is being done in a trial-and-error manner. OS emulation The Switch’s OS is based Nintendo 3DS’s OS. So the developers used a large part of Citra’s OS HLE code for yuzu OS. The loader and file system service was reused from Citra and modified to support Switch game dump files. The Kernel OS threading, scheduling, and synchronization fixes for yuzu were also ported from Citra’s OS implementation. The save data functionality, which allowed games to read and write files to the save data directory was also taken from 3DS. Switchbrew helped them create libnx, a userland library to write homebrew apps for the Nintendo Switch. (Homebrew is a popular term used for applications that are created and executed on a video game console by hackers, programmers, developers, and consumers.) The Switch IPC (Inter-process communication) process is much more robust and complicated than the 3DS’s. Their system has different command modes, a typical IPC request response, and a Domain to efficiently conduct multiple service calls. Yuzu uses the Nvidia services to configure the video driver to get the graphics output. However, Nintendo re-purposed the Android graphics stack and used it in the Switch for rendering. And so yuzu developers had to implement this even to get homebrew applications to display graphics. The Next Steps Being at a nascent stage, yuzu still has a long way to go. The developers still have to add HID (user input support) such as support for all 9 controllers, rumble, LEDs, layouts etc. Currently, the Audio HLE is in progress, but they still have to implement audio playback. Audio playback, if implemented properly, would be a major breakthrough as most complicated games often hang or go into a deadlock because of this issue. They are also working on resolving minor fixes to help them boot further in games like Super Mario Odyssey, 1-2-Switch, and The Binding of Issac. Be sure to read the entire progress report on the yuzu blog. AI for game developers: 7 ways AI can take your game to the next level AI for Unity game developers: How to emulate real-world senses in your NPC agent behavior Unity 2018.2: Unity release for this year 2nd time in a row!

On December 9, WireGuard announced that its secure VPN tunnel kernel code will soon be included in Linux net-next tree. This indicates, “WireGuard will finally reach the mainline kernel with the Linux 5.6 cycle kicking off in late January or early February!”, reports Phoronix. WireGuard is a layer 3 secure networking tunnel made specifically for the kernel, that aims to be much simpler and easier to audit than IPsec. On December 8, Jason Donenfeld, WireGuard’s lead developer sent out patches for the net-next v2 WireGuard. “David Miller has already pulled in WireGuard as the first new feature in net-next that is destined for Linux 5.6 now that the 5.5 merge window is over,” the email thread mentions. While WireGuard was initiated as a Linux project, its Windows, macOS, BSD, iOS, and Android versions are already available. The reason behind the delay for Linux was that Donenfeld disliked Linux’s built-in cryptographic subsystem citing its API is too complex and difficult. Donenfeld had plans to introduce a new cryptographic subsystem — his own Zinc library. However, this didn’t go down well with several developers as they thought that rewriting the cryptographic subsystem was a waste of time. Fortunately for Donenfeld, Linus Torvalds was on his side. Torvalds stated, “I’m 1000% with Jason on this. The crypto/model is hard to use, inefficient, and completely pointless when you know what your cipher or hash algorithm is, and your CPU just does it well directly.” Finally, Donenfeld compromised saying, "WireGuard will get ported to the existing crypto API. So it's probably better that we just fully embrace it, and afterward work evolutionarily to get Zinc into Linux piecemeal." Hence a few Zine elements have been imported into the legacy crypto code in the next Linux 5.5 kernel. WireGuard would become the new standard for Linux VPNs This laid the foundation for WireGuard to finally ship in Linux early next year. WireGuard works by securely encapsulates IP packets over UDP. It's authentication and interface design has more to do with Secure Shell (SSH) than other VPNs. You simply configure the WireGuard interface with your private key and your peers' public keys, and you're ready to securely talk. After the arrival, WireGuard VPN can be expected to become the new standard for Linux VPNs with its key features, namely, tiny code-size, high-speed cryptographic primitives, and in-kernel design. With being super-fast, WireGuard for Linux would be secure too as it supports state-of-the-art cryptography technologies such as the Noise protocol framework, Curve25519, BLAKE2, SipHash24, ChaCha20, Poly1305, and HKD. Donenfeld in the email thread writes, “This is big news and very exciting. Thanks to all the developers, contributors, users, advisers, and mailing list interlocutors who have helped to make this happen. In the coming hours and days, I'll be sending followups on next steps.” ArsTechnica reports, “Although highly speculative, it's also possible that WireGuard could land in-kernel on Ubuntu 20.04 even without the 5.6 kernel—WireGuard founder Jason Donenfeld offered to do the work backporting WireGuard into earlier Ubuntu kernels directly. Donenfeld also stated today that a 1.0 WireGuard release is ‘on the horizon’." To know more about this news in detail, read the official email thread. WireGuard launches an official MacOS app Researchers find a new Linux vulnerability that allows attackers to sniff or hijack VPN connections. NCSC investigates several vulnerabilities in VPN products from Pulse secure, Palo Alto and Fortinet

Its that time of year again, time for another Kali Linux release! Quarter #3 – Kali Linux 20202.3. This release has various impressive updates, all of which are ready for immediate download or updating. A quick overview of what’s new since the last release in May 2020: New Shell – Starting the process to switch from “Bash” to “ZSH“ The release of “Win-Kex” – Get ready WSL2 Automating HiDPI support – Easy switching mode Tool Icons – Every default tool now has its own unique icon Bluetooth Arsenal – New set of tools for Kali NetHunter Nokia Support – New devices for Kali NetHunter Setup Process – No more missing network repositories and quicker installs New Shell (Is Coming) Most people who use Kali Linux, (we hope), are very experienced Linux users. As a result, they feel very comfortable around the command line. We understand that “shells” are a very personal and precious thing to everyone (local or remote!), as that is how most people interact with Kali Linux. To the point where lots of experienced users only use a “GUI” to spin up multiple terminals. By default, Kali Linux has always used “bash” (aka “Bourne-Again SHell”) as the default shell, when you open up a terminal or console. Any seasoned Kali user would know the prompt kali@kali:~$ (or root@kali:~# for the older users!) very well! Today, we are announcing the plan to switch over to ZSH shell. This is currently scheduled to be the default shell in 2020.4 (for this 2020.3 release, bash will still be the default). If you have a fresh default install of Kali Linux 2020.3, you should have ZSH already installed (if not, do sudo apt install -y zsh zsh-syntax-highlighting zsh-autosuggestions), ready for a try. However if you installed an earlier version of Kali Linux and have upgraded to 2020.3, your user will be lacking the default ZSH configuration that we cooked with lots of love. So for upgrade users only, make sure to copy the configuration file: kali@kali:~$ cp /etc/skel/.zshrc ~/ kali@kali:~$ Then all you need to do is switch to ZSH: kali@kali:~$ zsh ┌──(kali㉿kali)-[~] └─$ If you like what you see, you can set ZSH as your default (replacing bash) by doing chsh -s /bin/zsh. Which is what we will be doing in 2020.4. We wanted to give the community a notice before this switch happens. This is a very large change (some may argue larger than the Gnome to Xfce switch last year). We are also looking for feedback. We hope we have the right balance of design and functionality, but we know these typically don’t get done perfect the first time. And, we don’t want to overload the default shell with too many features, as lower powered devices will then struggle or it may be hard to on the eyes to read. ZSH has been something we have wanted to do for a long time (even before the switch over to Xfce!). We will be doing extensive testing during this next cycle so we reserve the right to delay the default change, or change direction all together. Again, we encourage you to provide feedback on this process. There is no way we can cover every use case on our own, so your help is important. Q.) Why did you make the switch? What’s wrong with bash? A.) You can do a lot of advanced things with bash, and customize it to do even more, but ZSH allows you to do even more. This was one really large selling point. Q.) Why did you pick ZSH and not fish? A.) In the discussion of switching shells, one of the options that came up is Fish (Friendly Interactive SHell). Fish is a nice shell (probably nicer than ZSH), but realistically it was not a real consideration due to the fact that it is not POSIX compatible. This would cause a lot of issues, as common one-liners just won’t work. Q.) Are you going to use any ZSH frameworks (e.g. Oh-My-ZSH or Prezto)? A.) At this point in time, by default, no. The weight of these would not be workable for lower powered devices. You can still install them yourself afterwards (as many of our team do). Win-KeX Having Kali Linux on “Windows Subsystem for Linux” (WSL) is something we have been taking advantage of since it came out. With the release of WSLv2, the overall functionality and user experience improved dramatically. Today, the experience is improving once more with the introduction of Win-KeX (Windows + Kali Desktop EXperience). After installing it, typing in kex, or clicking on the button, Win-KeX will give you a persistent-session GUI. After getting WSL installed (there’s countless guides online, or you can follow ours), you can install Win-KeX by doing the following: sudo apt update && sudo apt install -y kali-win-kex Afterwards, if you want to make a shortcut, follow our guide, or you can just type in kex! On the subject of WSL (and this is true for Docker and AWS EC2) something we have seen a bit is after getting a desktop environment, people have noticed the tools are not “there”. This is because they are not included by default, to keep the image as small as possible. You either need to manually install them one by one, or grab the default metapackage to get all the tools from out-of-the-box: sudo apt install -y kali-linux-default Please note, Win-KeX does require WSL v2 on x64 as it’s not compatible with WSL v1, or arm64. For more information, please see our documentation page Automating HiDPI HiDPI displays are getting more and more common. Unfortunately, Linux support, out of the box, hasn’t been great (older Linux users may remember a time where this was very common for a lot of hardware changes.). Which means after doing a fresh install, there is a bit of tweaking required to get it working, otherwise the font/text/display may be very small to read. We have had a guide out explaining the process required to get it working, but the process before was a little “fiddly”. We wanted to do better. So we made kali-hidpi-mode. Now, either typing in kali-hidpi-mode or selecting it from the menu (as shown below), should automate switching between HiDPI modes. Tool Icons Over the last few releases, we have been showing the progress on getting more themed icons for tools. We can now say, if you use the default tool listing (kali-linux-default), every tool in the menu (and then a few extra ones!), should have their own icon now. We will be working on adding missing tools to the menu (and creating icons for them) over the next few releases of Kali, as well as expanding into the kali-linux-large metapackage (then kali-tools-everything). We also have plans for these icons, outside of the menu – more information in an upcoming release! Kali NetHunter Bluetooth Arsenal We are proud to introduce Bluetooth Arsenal by yesimxev from the Kali NetHunter team. It combines a set of bluetooth tools in the Kali NetHunter app with some pre-configured workflows and exciting use cases. You can use your external adapter for reconnaissance, spoofing, listening to and injecting audio into various devices, including speakers, headsets, watches, or even cars. Please note that RFCOMM and RFCOMM tty will need to be enabled in kernels from now on to support some of the tools. Kali NetHunter for Nokia Phones Kali NetHunter now supports the Nokia 3.1 and Nokia 6.1 phones, thanks to yesimxev. Images are available on our download site. Please note that those images contain a “minimal Kali rootfs” due to technical reasons but you can easily install all the default tools via sudo apt install -y kali-linux-default. Setup Process The full installer image always had all the packages required for an offline installation but if you installed a Kali Linux system with this image and without disabling the network, the installer would automatically run dist-upgrade during the install. This is done to make sure that you have the latest packages on first boot. And that step can take a very long time, especially after a few months after a release when lots of updates have accumulated. Starting with 2020.3, we disabled the network mirror in the full installer so that you always get the same installation speed, and the same packages and versions for that release – just make sure to update after installing! Whilst we were at it, we fixed another related issue. If you didn’t have network access (either voluntarily or otherwise) during installation, you would get an empty network repository (/etc/apt/sources.list). This means, you would not be able to use apt to install additional packages. While there might be some users who will never have network, we believe that it’s best to actually configure that file in all cases. So that’s what we did. By default, any fresh installs going forward after 2020.3 will have network repositories pre-defined. ARM Device Updates We have (along with the work of Francisco Jose Rodríguez Martos who did a lot of the back end changes) refreshed our build-scripts for our ARM devices. We pre-generated various different ARM images (as of 2020.3 – 19 images) to allow for quick download and deployment, but we have build scripts for more (as of 2020.3 – 39 images). If your device is not one of ones that we release images for, you’ll need to use the scripts to self generate the image. Notable changes in ARM’s 2020.3 release: All of the ARM images come with kali-linux-default metapackage installed, bringing them in line with the rest of our releases, so more tools are available when you first boot We have reduced the size of all our ARM images that are created, so downloads should be smaller. However, you will still need to use at least a 16GB sdcard/USB drive/eMMC Pinebook and Pinebook Pro images can now be used on either sdcard or eMMC The Pinebook image now has the WiFi driver built during image creation, instead of on first boot, this should speed up first boot time massively The Pinebook Pro has a change from the upstream firmware, which changes ccode=DE to ccode=all – this allows access to more 2.4GHz and 5GHz channels The 64-bit RaspberryPi images now have the RaspberryPi userland utilities built during image creation, so vcgencmd and various other utilities that were previously only available on the 32-bit image are now usable on 64-bit as well The ODROID-C2 image now uses the Kali kernel, instead of a vendor provided one. This means in the future, an apt dist-upgrade will get you kernel updates instead of waiting for a new Kali release The /etc/fstab file now includes the root partition via UUID, this should make it easier when trying to use a USB drive instead of sdcard on devices that support it A few things which are work in progress: RaspberryPi images are using 4.19 kernels. We would like to move to 5.4 however, nexmon isn’t working properly with it (as the new kernel requires firmware version => 7.45.202) for which no nexmon patch exists yet There is a new USBArmory Mk2 build script. We don’t have the hardware to test it however, so we are looking for community feedback who is able to test it out Veyron image will be released at a later date to kernel issues that haven’t yet been tracked down Desktop Environment As there has been minor update to Gnome, we have been taking some advantages of the new settings: GNOME’s file manager nautilus has a new theme GNOME’s system-monitor now matches the colors and also has stacked CPU charts Improved the design for “nested headerbars” (example, in the Settings Window, where the left headerbar is joined with the side-navbar) Community Shoutouts A new section in the release notes, community shoutouts. These are people from the public who have helped Kali and the team for the last release. And we want to praise them for their work (we like to give credit where due!): Crash who has been helping the community for some time now, thank you! FrangaL who has been doing some great work with Kali Linux ARM, thank you! Anyone can help out, anyone can get involved! Download Kali Linux 2020.3 Fresh Images So what are you waiting for? Start downloading already! Seasoned Kali Linux users are already aware of this, but for the ones who are not, we do also produce weekly builds that you can use as well. If you can’t wait for our next release and you want the latest packages when you download the image, you can just use the weekly image instead. This way you’ll have fewer updates to do. Just know these are automated builds that we don’t QA like we do our standard release images. But we gladly take bug reports about those images because we want any issues to be fixed before our next release. Existing Upgrades If you already have an existing Kali Linux installation, remember you can always do a quick update: kali@kali:~$ echo "deb http://http.kali.org/kali kali-rolling main non-free contrib" | sudo tee /etc/apt/sources.list kali@kali:~$ kali@kali:~$ sudo apt update && sudo apt -y full-upgrade kali@kali:~$ kali@kali:~$ [ -f /var/run/reboot-required ] && sudo reboot -f kali@kali:~$ You should now be on Kali Linux 2020.3. We can do a quick check by doing: kali@kali:~$ grep VERSION /etc/os-release VERSION="2020.3" VERSION_ID="2020.3" VERSION_CODENAME="kali-rolling" kali@kali:~$ kali@kali:~$ uname -v #1 SMP Debian 5.7.6-1kali2 (2020-07-01) kali@kali:~$ kali@kali:~$ uname -r 5.7.0-kali1-amd64 kali@kali:~$ NOTE: The output of uname -r may be different depending on the system architecture. As always, should you come across any bugs in Kali, please submit a report on our bug tracker. We’ll never be able to fix what we don’t know is broken! And Twitter is not a Bug Tracker!

Yesterday, Syrus Akbary, the founder and CEO of Wasmer, introduced WebAssembly interfaces. It provides a convenient s-expression (symbolic expression) text format that can be used to validate the imports and exports of a Wasm module. Why WebAssembly Interfaces are needed? The Wasmer runtime initially supported only running Emscripten-generated modules and later on added support for other ABIs including WASI and Wascap. WebAssembly runtimes like Wasmer have to do a lot of checks before starting an instance. It does that to ensure a WebAssembly module is compliant with a certain Application Binary Interface (Emscripten or WASI). It checks whether the module imports and exports are what the runtime expects, namely the function signatures and global types match. These checks are important for: Making sure a module is going to work with a certain runtime. Assuring a module is compatible with a certain ABI. Creating a plugin ecosystem for any program that uses WebAssembly as part of its plugin system. The team behind Wasmer introduced WebAssembly Interfaces to ease this process by providing a way to validate imports and exports are as expected. This is how a WebAssembly Interface for WASI looks like: Source: Wasmer WebAssembly Interfaces allow you to run various programs with each ABI, such as Nginx (Emscripten) and Cowsay (WASI). When used together with WAPM (WebAssembly Package Manager), you will also be able to make use of the entire WAPM ecosystem to create, verify, and distribute plugins. They have also proposed it as a standard for defining a specific set of imports and exports that a module must have, in a way that is statically analyzable. Read the official announcement by Wasmer. Fastly CTO Tyler McMullen on Lucet and the future of WebAssembly and Rust [Interview] LLVM WebAssembly backend will soon become Emscripten’s default backend, V8 announces Qt 5.13 releases with a fully-supported WebAssembly module, Chromium 73 support, and more

Last week, the US, UK, and Australian governments wrote an open letter to Facebook urging it to drop end-to-end encryption from WhatsApp and halt its plans to implement end-to-end encryption across its other messaging platforms. The three governments asked the company to ensure “there is no reduction to user safety” and include “a means for lawful access to the content of communications to protect our citizens.” The open letter is addressed to Mark Zuckerberg, Facebook’s CEO and co-signed by US Attorney General William Barr, Acting Homeland Security Secretary Kevin McAleenan, United Kingdom Home Secretary Priti Patel, and Australia’s Minister for Home Affairs Peter Dutton. This open letter to Facebook comes after the launch of a new “UK-US Bilateral Data Access Agreement.” This agreement aims to speed up electronic data access requests by their respective law enforcement agencies. This replaces the current process called Mutual Legal Assistance that requires law enforcement agencies to submit a request and get it approved by central governments, which can often take months or even years. The new process will only take a few weeks or even days. Why the US, UK, and Australian governments are against end-to-end encryption The three governments stated that though they realize the importance of strong encryption in processing services such as banking and commerce, end-to-end encryption would hinder the investigation of serious crimes. The letter reads, “We must find a way to balance the need to secure data with public safety and the need for law enforcement to access the information they need to safeguard the public, investigate crimes, and prevent future criminal activity.” The letter does praise Facebook of reporting 16.8 million cases to the US National Center for Missing & Exploited Children (NCMEC), which was more than 90% of the 18.4 million total reports in 2018. It further states that Facebook’s own safety systems were able to identify the 99% of the content Facebook takes action against, both for child sexual exploitation and terrorism. However, the governments believe that “the mere numbers cannot capture the significance of the harm to children.” This is not the first time government officials have shown their dislike with end-to-end encryption. In 2017, Amber Rudd, the UK's home secretary said after WhatsApp added end-to-end encryption, “We need to make sure that organizations like WhatsApp, and there are plenty of others like that, don't provide a secret place for terrorists to communicate with each other.” In December 2018, the Australian government passed a controversial anti-encryption law that allows law enforcement agencies to compel tech companies to hand over encrypted messaging data. Read also: “Five Eyes” call for backdoor access to end-to-end encryption to tackle ‘emerging threats’ despite warnings from cybersecurity and civil rights communities The government has listed the following steps for Facebook and other similar companies: The system should be designed in such a way that the companies behind them are able to effectively act against any illegal content without hampering the safety of others. Allow law enforcement to get lawful access to content in a readable and usable format. Engage in consultation with governments and let those consultations influence companies’ design decisions. The proposed changes should not be implemented until the safety of users is fully ensured by tested and operational systems. What privacy experts and users think about this open letter to Facebook Electronic Frontier Foundation (EFF), a non-profit that supports civil liberties and other legal issues pertaining to digital rights, called this act a “staggering attempt to undermine the security and privacy of communications tools used by billions of people." It said, "Facebook should not comply.” The organization further said that the three governments failed to take into account the “severe risks” associated with introducing backdoors. https://twitter.com/EFF/status/1180978792052998145 The open letter to Facebook also did not sit well with several users. In a discussion on Hacker News users expressed that it would be wrong to undermine the security for millions of law-abiding users in order to investigate the wrongdoers. A user commented, “Privacy isn't a trade-off against security, it's a necessary component of having security.” Another user added, “Criminal activities are exacerbated by the internet it would be a lie to say no. But just like with cars, scooters, or any tech that's sufficiently democratized. They need a permit for a car? Why not just steal it? I need an identity to do shady stuff on the internet? Why not steal it? We cannot reason with malevolent forces, there is always going to be away. And by that time, we compiled the data of everyone, centralized it all, and let govs that don't understand the implication collect those as if it was mere petrol or gold. We are putting everyone's lives at risk doing so, just wait until it leaks out or it starts getting sold. (ahem, oh wait !)” Read the open letter to Facebook for more details. DoorDash data breach leaks personal details of 4.9 million customers, workers, and merchants Google Project Zero discloses a zero-day Android exploit in Pixel, Huawei, Xiaomi and Samsung devices How has ethical hacking benefited the software industry Cryptographic key of Facebook’s Free Basics app has been compromised Facebook must face privacy class action lawsuit, loses facial recognition appeal, U.S. Court of Appeals rules

Text-to-speech synthesis has been a booming research area, with Google, Facebook, Deepmind, and other tech giants showcasing their interesting research and trying to build better TTS models. Now Baidu has stolen the show with ClariNet, the first fully end-to-end TTS model, that directly converts text to a speech waveform in a single neural network. Classical TTS models such as Deepmind’s Wavenet usually have a separately text-to-spectrogram and waveform synthesis models. Having two models may result in suboptimal performance. ClariNet combines the two models into one fully convolutional single neural network. Not only that, their text-to-wave model significantly outperforms the previous separate TTS models, they claim. Baidu’s ClariNet consists of four components: Encoder, which encodes textual features into an internal hidden representation. Decoder, which decodes the encoder representation into the log-mel spectrogram in an autoregressive manner. Bridge-net: An intermediate processing block, which processes the hidden representation from the decoder and predicts log-linear spectrogram. It also upsamples the hidden representation from frame-level to sample-level. Vocoder: A Gaussian autoregressive WaveNet to synthesize the waveform. It is conditioned on the upsampled hidden representation from the bridge-net. ClariNet’s Architecture Baidu has also proposed a new parallel wave generation method based on the Gaussian inverse autoregressive flow (IAF).  This mechanism generates all samples of an audio waveform in parallel, speeding up waveform synthesis dramatically as compared to traditional autoregressive methods. To teach a parallel waveform synthesizer, they use a Gaussian autoregressive WaveNet as the teacher-net and the Gaussian IAF as the student-net. Their Gaussian autoregressive WaveNet is trained with maximum likelihood estimation (MLE). The Gaussian IAF is distilled from the autoregressive WaveNet by minimizing KL divergence between their peaked output distributions, stabilizing the training process. For more details on ClariNet, you can check out Baidu’s paper and audio samples. How Deep Neural Networks can improve Speech Recognition and generation AI learns to talk naturally with Google’s Tacotron 2

Today Baidu released a continual natural language processing framework ERNIE 2.0. ERNIE stands for Enhanced Representation through kNowledge IntEgration. Baidu claims in its research paper that ERNIE 2.0 outperforms BERT and the recent XLNet in 16 NLP tasks in Chinese and English. Additionally, Baidu has open sourced ERNIE 2.0 model. In March Baidu had announced the release of ERNIE 1.0, its pre-trained model based on PaddlePaddle, Baidu’s deep learning open platform. According to Baidu, ERNIE 1.0 outperformed BERT in all Chinese language understanding tasks. Pre-training procedures of the models such as BERT, XLNet and ERNIE 1.0 are mainly based on a few simple tasks modeling co-occurrence of words or sentences, highlights the paper. For example, BERT constructed a bidirectional language model task and the next sentence prediction task to capture the co-occurrence information of words and sentences; XLNet constructed a permutation language model task to capture the co-occurrence information of words. But besides co-occurring information, there are much richer lexical, syntactic and semantic information in training corpora. For example, named entities, such as person names, place names, and organization names, contain concept information; Sentence order and sentence proximity information can enable the models to learn structure-aware representations; Semantic similarity at the document level or discourse relations among sentences can enable the models to learn semantic-aware representations. So is it possible to further improve the performance if the model was trained to learn more kinds of tasks constantly? Source: ERNIE 2.0 research paper Based on this idea, Baidu has proposed a continual pre-training framework for language understanding in which pre-training tasks can be incrementally built and learned through multi-task learning in a continual way. According to Baidu, in this framework, different customized tasks can be incrementally introduced at any time and these tasks are trained through multi-task learning, which enables the encoding of lexical, syntactic and semantic information across tasks. And whenever a new task arrives, this framework can incrementally train the distributed representations without forgetting the previously trained parameters. The Structure of Released ERNIE 2.0 Model Source: ERNIE 2.0 research paper ERNIE is a continual pre-training framework which provides a feasible scheme for developers to build their own NLP models. The fine-tuning source codes of ERNIE 2.0 and pre-trained English version models can be downloaded from the GitHub page. The team at Baidu compared the performance of ERNIE 2.0 model with the existing  pre-training models on the English dataset GLUE and 9 popular Chinese datasets separately. The results show that ERNIE 2.0 model outperforms BERT and XLNet on 7 GLUE language understanding tasks and outperforms BERT on all of the 9 Chinese NLP tasks, such as DuReader Machine Reading Comprehension, Sentiment Analysis and Question Answering.  Specifically, according to the experimental results on GLUE datasets, ERNIE 2.0 model almost comprehensively outperforms BERT and XLNET on English tasks, whether it is a base model or the large model. Furthermore, the research paper shows that ERNIE 2.0 large model achieves the best performance and creates new results on the Chinese NLP tasks. Source: ERNIE 2.0 research paper To know more about ERNIE 2.0, read the research paper and check out their official blog on Baidu’s website. DeepMind’s AI uses reinforcement learning to defeat humans in multiplayer games CMU and Google researchers present XLNet: a new pre-training method for language modeling that outperforms BERT on 20 tasks Transformer-XL: A Google architecture with 80% longer dependency than RNNs  

Google has just open-sourced Filament, their physically based rendering (PBR) engine for Android. It can also be used in Windows, Linux, and macOS. Filament provides a set of tools and APIs for Android developers to help them easily create high-quality 2D and 3D rendering. Filament is currently being used in the Sceneform library both at runtime on Android devices and as the renderer inside the Android Studio plugin. Apart from Filament, Google has also open sourced Materials, the full reference documentation for their material system. They have also made available Material Properties which is a reference sheet for the standard material model. Google’s Filament comes packed with the following features: The rendering system is able to perform efficiently on mobile platforms. The primary target is OpenGL ES 3.x class GPUs. The rendering system emphasizes overall picture quality. Artists are able to iterate often and quickly on their assets and the rendering system allows them to do so instinctively. The physically based approach of the system also allows developers to create visually believable materials even if they don’t understand the theory behind the implementation. The system relies on as few parameters as possible to reduce trial and error and allows users to quickly master the material model. The system uses physical units everywhere possible: distances in meters or centimeters, color temperatures in Kelvin, light units in lumens or candelas, etc. The rendering library is as small as possible so any application can bundle it without increasing the binary to unwanted sizes. Filament APIs There are two major APIs used. Native C++ API for Android, Linux, macOS, and Windows Java/JNI API for Android, Linux, macOS, and Windows Backends OpenGL 4.1+ for Linux, macOS, and Windows OpenGL ES 3.0+ for Android Vulkan 1.0 for Android, Linux, macOS (with MoltenVk) and Windows A sample material rendered with Filament. Source: Github You can check out the Filament Documentation, for an in-depth explanation of real-time PBR, the graphics capabilities and implementation of Filament. Google open sources Seurat to bring high precision graphics to Mobile VR Google releases Android Things library for Google Cloud IoT Core Google updates biometric authentication for Android P, introduces BiometricPrompt API

GitHub has finally finished removing the JQuery dependency from its frontend code. This was a result of gradual decoupling from JQuery which began back in at least 2 years ago. They have chosen not to replace JQuery with yet another framework. Instead, they were able to make this transition with the help of polyfills that allowed them to use standard browser features such as, EventListener, fetch, Array.from, and more. Why GitHub chose JQuery in the beginning? Simple: GitHub started using JQuery 1.2.1 as a dependency in 2007. This enabled its web developers to create more modern and dynamic user experience. JQuery 1.2.1 allowed developers to simplify the process of DOM manipulations, define animations, and make AJAX requests. Its simple interface gave GitHub developers a base to craft extension libraries such as, pjax and facebox, which later became the building blocks for the rest of GitHub frontend. Consistent: Unlike the XMLHttpRequest interface, JQuery was consistent across browsers. GitHub in its early days chose JQuery as it allowed their small development team to quickly prototype and release new features without having to adjust code specifically for each web browser. Why they decided to remove JQuery dependency? After comparing JQuery with the rapid evolution of supported web standards in modern browsers, they observed that: CSS classname switching can be achieved using Element.classList. Visual animations can be created using CSS stylesheets without writing any JavaScript code. The addEventListeners method, which is used to attach an event handler to the document, is now stable enough for cross-platform use. $.ajax requests can be performed using the Fetch Standard. With the evolution of JavaScript, some syntactic sugar that jQuery provides has become redundant. The chaining syntax of JQuery didn’t satisfy how GitHub wanted to write code going forward. According to this announcement, this step of decoupling from jquery will allow them to: Rely on web standards more Have MDN web docs as their default documentation to refer Maintain more resilient code in future Speeding up page load times and JavaScript execution time Which technology is it using now? GitHub has moved from JQuery to vanilla JS (plain JavaScript). It is now using querySelectorAll, fetch for ajax, and delegated-events for event handling; polyfills for standard DOM manipulations, and Custom Elements. The adoption of Custom Elements is on the rise. It is a component library native to the browser, which means that users do not have to download, parse, and compile additional bytes of a framework. With the release of Web Components v1 in 2017, GitHub started to adopt Custom Elements on a wider scale. In future they are also planning to use Shadow DOM. To read more about how GitHub made this transition to using standard browser features, check out their official announcement. Github introduces Project Paper Cuts for developers to fix small workflow problems, iterate on UI/UX, and find other ways to make quick improvements Why Golang is the fastest growing language on GitHub