Of course, there's is going to be an article about the outage. It will come one week after it has been talked about on reddit. And then, there are going to be 15 more dupes about it.
I use a scriptblocking extension which has to be able to interact with every "tab" to be able to actually work.
And script blocking is probably the number 1 feature of Firefox-based browsers (this is technically impossible to achieve on Chrome according to professionnal developers).
So, unlike Google Chrome, it's very likely that either your favorite script blocking extension will eventually work on Mozilla, or you'll find a nice alternative to your taste.
do nothing. Eventually the door will close, but it takes a while. Now repeat experiment, but press the close door button. Door will close predictably sooner (time it if you like).
That used to be the case. But nowadays more and more lifts are produced with the button not even wired.
We are talking about an entirely new field of commerce, which has yet to produce a single product. At this stage, a theft of self-driving research material could easily be valued in the billions.
Or a more cynical person could easily valuate the whole story to exactly ZERO dollars.
(You know, with the entire new field still needing yet to show capability to produce at least one single functional product, one could easily classify the whole thing as "science fiction / fantasy")
Compared to the rest Google doesn't make much by selling phone. They are not harmed by the existence of manufacturer competing with Google's Nexus line.
They make maybe a little bit more by selling Android licenses to manufacturer who choose to have the complete "Google Experience" (including Google Play Store and other such Google apps and service) instead of the free AOSP. In that case, the more manufacturer producing Android phone, the better for Google, no matter which brand.
They make quite some significant money by taking a fee on all transaction to happen on the Play Store. Again, no real threat by "competitors". On the contrary : the more manufacturer making Android phone, the more potential customers who are going to spend to the Play Store.
Finally the biggest chunk of money, they make through ads. They don't even need android phones for that. Even Apple iOS users are potential eyeballs that they can sell to advertisers. They just need to have as many people going online so they can be exposed to ads, no matter *which smartphone* they use to do it. (That's why Google is both *developing* their own Chrome browser AND *financially supporting* Mozilla's effort on Firefox. Firefox isn't a *competitor*, it isn't a product that is "diverting revenue" from Chrome - that would be difficult given that Chrome is free. They are both parallel mean to achieve what Google actually needs : people getting online on the net where Google can profit of them because they are the biggest advertiser).
None of the above will cause Google to see HTC as "competition" that they need to buy.
Some people will try to justify this nonsense by saying, "It's ok, they disclose what they're collecting and sharing!" or the even more idiotic, "It's ok, you can disable some of this data collection and sharing!".
None of that matters!
None of that matters, indeed.
My whole point is that : - even if Mozilla DID NOT disclose it. - even if it was NOT POSSIBLE to disable.
Because the source code of Firefox is accessible, ANALYSTS WOULD STILL be able to notice this. And DEVELOPERS WOULD STILL be able to make fork with possibility to disable.
(see: TorBrowser)
Again, like I said aboe. GPL is NOT "magic pixie dust".
But helps lowering the bar to this kind of control.
He's being realistic. Code review takes time. Proper code review takes even longer. With even small OSes running into the millions of lines of code, and the applications running on top of it having millions more lines of code, it would take years, if not decades,
And again, as I've said starting the thread : access to the source code helps a lot. In this case, because Linux kernel is GPL (and so is most of the GNU userland), it means way much more people can - if they want (and in practice, they do) - investigate to find problematic pieces of code.
Nobody said that the millions of lines of code needs to be investigate one-by-one and that all the decades must happen serially.
So, a Chinook helicopter, then? The kind that's been in use for heavy lifting for, oh, 50 years or so?
Given that these are inspired by drones - i.e.: Quadcopters (or more) it's more appropriate to call them Dual chinook (or more. Beware of the Triple-chinook Hexa-copters !)
But, basically, as the AC wrote above - the "flying cars" aren't anything new once you pay attention to helicopters. It's the "use AI to make a helicopter pilot out of drunken driver Average Joe" part that is going to be a bit more challenging, I think.
{...} only webkit really matters when it comes to standards. Why don't we focus on that {... ?}
Because of Gecko / Servo powering Firefox on most non-iOS platforms including desktop and android (and a few less known, like the Mer-derived SailfishOS by Jolla, like the web engine replacing Microsoft Edge when running Wine, etc.)
Because of Microsoft Edge that the more clueless users still run on their Windows laptops ?
Having battery-packs fully charged at at bus depot and then a system where they can be swapped out quickly for recharged one's.
Battery swapping a fixed points on the route MAKES sense. Specially since you also need to swap the bus driver.
Several jurisdictions, at least here around in Europe, severely limit how much a professional driver can drive in 1 single go and how much time he can total per day. Means that the driver has mandatory breaks that he needs to take on a few set points on the road (e.g.: on the terminus, or at a big station in the middle like the central railway station) and that he also needs to be replaced behind the wheel. All these are breaks that already happen today on a bus route and are perfect opportunity to swap the battery and/or top them up.
(it's already how it is implemented in places that have running electric buses for decades, like Zermatt in Switzerland).
And that's neglecting other current technology, like continuously charging the bus during service, like trolley bus. One could imagine a "hybrid" type of electric bus, that connects to the trolley overhead wires to charge while on the "in-city" part of its route, and disconnects completely when reaching the country-side That's already partially implemented, although at a much smaller scale, with current-day trolley able to disconnect and switch to an alternative power supply (small battery or small diesel generator) in order to circumvent construction works on their usual route.
Until personal cars will have such a system - forget it!
Although the technology DOES exist, it isn't much popular. - in city, you charge the car over night and don't give a damn about swapping batteries. - on a road trip, the driver will need rest (half an hour every 2 hours - strongly recommanded everywhere, and required in some professional contexts) much more frequently than the range ( > 300 km) achieved by current top-of-the-crop cars from several manufacturer
The only drawback with your plan is that you'll need to wait a little bit longer. Apple will probably only "invent" the flying car a decade after they hit production elsewhere.
It's easy to just rename the vehicle and exactly get what you need (a very versatile and compact form of transportation). (The thing that they plan is supposed to by a "drone-inspired flying car" - i.e.: a multi-rotor helicopter.)
The problems come from the one handing the controls. Simply rename the average dangerous idiot behind the wheel as "helicopter pilot" won't magically make him thousands of times more reliable...
Actually, no. Airplanes with broken engines tend to glide (like a not as well optimized gliger). Helicopters with a broken engine tend to autorotate (like a auto-gyro).
But yeah, you can count on cheaply mass produced in China "drone-like flying cars" to not have well tough-out and as safe as possible failure modes.
Yet another argument showing why it is better to favour software with visible source code. Not that the GPL contains "magic pixie dust" in it that miraculously repel this kind of abuse.
But it just makes this kind of analysis a little bit more easy.
Here author manager to get a hang of what the extension is doing, because it's still in javascript (theoretically humean-readable) though still heavily obscured (the analyst provides links to slightly de-obscured files).
If this was a completely opaque closed source binary, analysis would have been much more difficult.
On the other hand, if this was a completely free/libre opensource software, this kind of analysis would have been much easier and could happen much earlier (and you would expect de-spyware-ified forks to pop-up on github at the same time as such disclosure).
My point is that the bashware is a Trojan Horse which installs the WSL, as you described. The average Joe ain't gonna know they don't need WSL, they have to trust the program they are installing, the Trojan Horse.
Which sound a little bit stretching the average Joe's trust, just to click on some attachement. (But on the other hand if the torjan begin its life as a "bloatware" that is co-installed with a big software suite, that sounds more realistic : the joe wants to install a copy of Adobe premiere that he managed to download for free from some website. he IS going to expect a tons of aditionnal platform and libraries to get installed with it. An installation of WSL to get an invisible zombie node of a botnet can very easily smuggle in that case).
If the WSL happens to be deployed after the antivirus was installed, will the ELFs be available to the WSL so they can be started? The Lxss folder is not safely writeable by Windows native applications, file corruption usually occurs. So writing it to the filesystem beforehand is not an option.
If I was a Security Suite developer, the most likely route I would go for : - software reside in a directory accessible to *windows* - typically a subfolder in the antivirus suite's installation folder - main reason: so it is trivial to update through the main update system, and can potentially share the same data files (signatures, etc.) as the main windows anti-virus. - this includes a Linux ELF executable (lifted from the recovery bootdisk) - this includes a small bash script that can : +- mount the Windows data with the proper VFS driver, e.g.: under "/opt/SecuritySuite" +- start the Linux ELF with apropriate options. - the above is launched by *PIPING* it to the stdin of BASH.exe - the stdout of BASH.exe is picked up by the software to display result in the Windows GUI. - this solves the chicken and egg problems of how to handle concurrent WSL installation
Possible improvement : - the API and message passing used by BASH.exe to talk with Linux process under WSL has recently been improved. (e.g.: it's possible since recently to invoke "start" from within WSL to launch windows process outside of WSL)
Also, Linux ELFs sounds like a business or Enterprise feature, not a home use feature.
Currently, it is *ALSO* marketed as a home (power) user feature, mainly as free "Recovery Bootdisk". (In addition to the classical expensive Linux server feature). So how they will market it depends on what they want to achieve : - do they want to cover extensively end users ? (it might also come as a premieum feature) - do they want only to offer it as an extra protection for Business users ?
Just because the standard method of installing an optional service is through a control panel, doesn't mean that is the only way..NET 2, & 3 are optional on Windows 10.
The difference is that.NET is a platform that is extensively used by Windows software. It was designed with this purpose by Microsoft and is distributed widely. It's completely expected that a lot of users will install it, because there are tons of legit use cases for that.
By the time a use clicks on a virus running on.NET, it is pretty expected that.NET will be installed.
WSL is a platform developed by Microsoft that currently only targets developers (so they can test linux code without a VM). There might be a few rare other cases (I mainly think of running some scientific data pre-processing before submitting to the Linux nodes on the HPC for further processing). But there are no practical reason for a clueless user to run WSL. It's not something that is expected to be used by regular everyday software. (At least that's not how Microsoft sees it, and not how it's marketed)
If a clueless click on a bash malware, chances are that he won't have it installed already. And it would sound really weird if, when clicking to view an attachment in an e-mail, suddenly 2 installers pop-up (one for WSL itself, one to install the GNU userland from Ubuntu).
So we are back to Antivirus vendors providing ELFs, and providing a means of automatically installing and registering them, after installation. A means of automatically detecting the install of the WSL, and installing the appropriate ELF.
My entire point : - antivirus need to pack the ELFs (that they already have for servers and for recovery bootdisks) together in their suits. - if WSL happens to be deployed on that machine, they need to start the ELFs.
And all these "WSL hidden from windows app such as antivirus" problems go "poof!".
The hardest part (having antivirus software as linux ELFs) is already done. What is left is merely integration (which is already provided to some point in BASH.exe)
Incorrect. Windows has a VMS security system with tokens since NT evolved from VMS. Unlike Unix a user is not really admin under Windows but rather requests a token to perform and admin task from ACL access control lists
These are implementation details. My main point is that most of the time, Windows users are used to run as adminsitrator. It doesn't matter if that is done by "holding admin level VMS tokens" or "being Unix UID=0, GID=0" is an implementation.
In practice : - Windows user has account flagged as "admin" - Windows user does something and UAC shows up asking authorisation for admin action - Windows user clicks yes by habbit, because that's an entirely normal flow of actions. My point : Windows users are completely used of running as admin.
On linux : - Linux user clicks some begnin-looking attachment - KDESU or any other pops up asking for root password - Linux user : "Why the fuck do I need root to open a picture ? Kill this shit with fire !" My point : Linux users don't normally need to run things as root.
WSL doesn't do shortcuts.
It. Fucking. Does. Read the dozens of article and blog post, some by the Microsoft engineers behind WSL themselves.
The NT kernel was designed by David Cutler...
and was designed in a way that totally sucks at multi-threading and multi-processing. (see any benchmark that compares code running on Linux and code running on Windows while using windows API for multi-threading).
if you take the time to read all the literature that was written around the introduction of WSL, you'll notice that a new functionality called "pico-threads" was introduced to the NT kernel. that is the NT functionality that is used to provide "posix threads" to WSL layer ELFs. because the traditionnal NT functionnality that is usually used to provide threads to.EXE has a subpar performance.
if you read the details, you'll notice that isolation and security is done a little bit lightly - both compared to classic NT threading and to how threads and processes work in Linux.
Isn't blockchain mostly for transactions that will never be modified/reversed or are single well-defined actions at a point in time, like transfers of money or sales?
And in the same vein of "Why?" :
- The whole purpose of blockchain is to have NO central authority, but a distributed public trust. (customer A gives money to company B and no central authority is needed to confirm it, as long as both A and B use the bitcoin protocol)
- The whole point of a Birth registry is TO HAVE a central authority. (in case of doubt, check the *official* birth certificate with authority XyZ)
So it seems even weirder to me. it doesn't seem very useful.
Information about people is complex. What if something about the birth record changes or needs to be corrected?
In theory you could still add "amend" records updating the database in the blockchain. (Just like the "well-defined actions at a point in time transfers of money" can be followed by subsequent further "transfers of money" - e.g.: spending money previously received).
In practice that is going to be problematic, because some of this information is personnal - I would guess sex changes, in some jurisdiction : the person doesn't necessarily want that the history of past sex identities to be publicly known.
In a blockchain technological implementation, all the history NEEDS to be available for the public consensus mecanism to work.
In a authority clasiccal implementation, the authority might only provide the latest official version publicly and keep the access to the history restricted to the person (and medical personnel)
So, what ? You can produce anti-bodies against (and thus basically vaccinate against) nearly anything that has big enough molecules to be recognized by an antibody pouch....
It is caused by metabolic by-products of bacteria
You could in theory try to vaccinate against the bacteria producing them.
bacteria practically living outside the body.
so are antibodies : they can be secreted and thus they too can be found outside of the body.
the current MAIN problem might end up that these bacteria, however problematic at causing cavities, still have an important role to play at training the immune system. you might end up with a slightly increased risk of oral cancers. (I think to remember something like this regarding past attempts. Must mine literature...)
The user doesn't know the Linux subsystem is installed.
WSL isn't installed by default on Windows 10. It's an optional component that you need to explicitly select in the corresponding control-pannel-thingy. (like IIS).
If the user is clueless, chances are high that they don't have WSL installed.
The user doesn't know anything about Linux, and expects their Windows anti-virus to protect them.
(well, if they are running McAffee, they are toasted anyway:-P )
More seriously, it's the "security suite"'s developpers' job to develop a solution. Again there is no technical reason preventing it (even if the current suite happens not to be able to see what happens on the WSL side). Most of the big pro developers (e.g.: Kaspersky) already have Linux ELFs that are currently used on Linux servers, and on recovery bootdisk CD/USBs, they already have the necessary tools to be able to scan on the other side of the WSL fence.
All that is needed is some efforts to add the necessary glue code in the current suites to have them launch these processes inside WSL. No technical limitations.
It is that no existing anti-malware utilities will automatically catch and remove the malware. This is a serious risk.
Well to be more precise :
- currently the WSL subsystem that provides "linux ABI" to original linux ELFs - and the Win32 system usually offered to normal windows userland are too different environment which are kept (on purpose) isolated from each other.
(Just think about it: even if theoretically NTFS can store case-sensitive filenames, absolutely no Win32 userland does handle it. That's just one of the several reasons why both environment should touch eachother's stuff. Another reason is that for performance reason WSL uses an entirely different threading system than Win32 apps - "picothreads", there was a lot of online articles about the benefits of their introduction to NT kernels)
Only some specific forms of message passing are possible. (- Windows' bash.exe can start ELFs in WSL (usual/bin/bash, hence the name) Latest version of WSL can pass a little bit more data around. WSL has a special filesystem driver to be able to safely mount windows' user data in the filesystem tree. And that's about it.).
That mean that you copy of Kaspersky Lab for Microsoft Windows can't directly see anything happening in WSL. ...BUT!... Absolutely nothing prevents you (or security software suites from official providers) to run the "KAV" elf inside WSL to handle the WSL side of security, in collaboration with the Win32 software.
Slashdot Mirror
This is /.
What do you expect ?
Of course, there's is going to be an article about the outage. It will come one week after it has been talked about on reddit.
And then, there are going to be 15 more dupes about it.
I use a scriptblocking extension which has to be able to interact with every "tab" to be able to actually work.
And script blocking is probably the number 1 feature of Firefox-based browsers (this is technically impossible to achieve on Chrome according to professionnal developers).
That's why NoScript is currently in the process of being ported to webextensions.
Or, more precisely, Mozilla is in the process of adapting WebExtensions so that things that formely required XUL like NoScript could be ported.
So, unlike Google Chrome, it's very likely that either your favorite script blocking extension will eventually work on Mozilla, or you'll find a nice alternative to your taste.
I hear that there's an ad blocker around,
uBlock Origin has a release candidate that has been made available for webextensions API.
but I hope that something like RequestPolicy will also exist in the new addon system.
NoScript is Currently in the process of being ported to webextensions. Or, more precisely, Mozilla is in the process of adapting WebExtensions so that things that formely required XUL like NoScript could be ported.
do nothing. Eventually the door will close, but it takes a while. Now repeat experiment, but press the close door button. Door will close predictably sooner (time it if you like).
That used to be the case. But nowadays more and more lifts are produced with the button not even wired.
We are talking about an entirely new field of commerce, which has yet to produce a single product. At this stage, a theft of self-driving research material could easily be valued in the billions.
Or a more cynical person could easily valuate the whole story to exactly ZERO dollars.
(You know, with the entire new field still needing yet to show capability to produce at least one single functional product, one could easily classify the whole thing as "science fiction / fantasy")
The F14 would be a good example.
On the other hand, it's successor the F15 managed to land with only one wing.
(But yeah, overall, fighter jets tend to be optimized for maneuverability, which tend not to emphasis stability.)
"Competing phone" doesn't make much sense.
Compared to the rest Google doesn't make much by selling phone. They are not harmed by the existence of manufacturer competing with Google's Nexus line.
They make maybe a little bit more by selling Android licenses to manufacturer who choose to have the complete "Google Experience" (including Google Play Store and other such Google apps and service) instead of the free AOSP. In that case, the more manufacturer producing Android phone, the better for Google, no matter which brand.
They make quite some significant money by taking a fee on all transaction to happen on the Play Store. Again, no real threat by "competitors". On the contrary : the more manufacturer making Android phone, the more potential customers who are going to spend to the Play Store.
Finally the biggest chunk of money, they make through ads. They don't even need android phones for that. Even Apple iOS users are potential eyeballs that they can sell to advertisers. They just need to have as many people going online so they can be exposed to ads, no matter *which smartphone* they use to do it.
(That's why Google is both *developing* their own Chrome browser AND *financially supporting* Mozilla's effort on Firefox. Firefox isn't a *competitor*, it isn't a product that is "diverting revenue" from Chrome - that would be difficult given that Chrome is free. They are both parallel mean to achieve what Google actually needs : people getting online on the net where Google can profit of them because they are the biggest advertiser).
None of the above will cause Google to see HTC as "competition" that they need to buy.
Some people will try to justify this nonsense by saying, "It's ok, they disclose what they're collecting and sharing!" or the even more idiotic, "It's ok, you can disable some of this data collection and sharing!".
None of that matters!
None of that matters, indeed.
My whole point is that :
- even if Mozilla DID NOT disclose it.
- even if it was NOT POSSIBLE to disable.
Because the source code of Firefox is accessible, ANALYSTS WOULD STILL be able to notice this.
And DEVELOPERS WOULD STILL be able to make fork with possibility to disable.
(see: TorBrowser)
Again, like I said aboe. GPL is NOT "magic pixie dust".
But helps lowering the bar to this kind of control.
That's what Reproducible Builds are for. {...} At a Debian repository near you (and not only there).
Which is the entire point of reproducible builds... :-P
He's being realistic. Code review takes time. Proper code review takes even longer. With even small OSes running into the millions of lines of code, and the applications running on top of it having millions more lines of code, it would take years, if not decades,
And again, as I've said starting the thread :
access to the source code helps a lot.
In this case, because Linux kernel is GPL (and so is most of the GNU userland), it means way much more people can - if they want (and in practice, they do) - investigate to find problematic pieces of code.
Nobody said that the millions of lines of code needs to be investigate one-by-one and that all the decades must happen serially.
So, a Chinook helicopter, then? The kind that's been in use for heavy lifting for, oh, 50 years or so?
Given that these are inspired by drones - i.e.: Quadcopters (or more)
it's more appropriate to call them Dual chinook (or more. Beware of the Triple-chinook Hexa-copters !)
But, basically, as the AC wrote above - the "flying cars" aren't anything new once you pay attention to helicopters.
It's the "use AI to make a helicopter pilot out of drunken driver Average Joe" part that is going to be a bit more challenging, I think.
{...} only webkit really matters when it comes to standards. Why don't we focus on that {... ?}
Because of Gecko / Servo powering Firefox on most non-iOS platforms including desktop and android (and a few less known, like the Mer-derived SailfishOS by Jolla, like the web engine replacing Microsoft Edge when running Wine, etc.)
Because of Microsoft Edge that the more clueless users still run on their Windows laptops ?
Having battery-packs fully charged at at bus depot and then a system where they can be swapped out quickly for recharged one's.
Battery swapping a fixed points on the route MAKES sense.
Specially since you also need to swap the bus driver.
Several jurisdictions, at least here around in Europe, severely limit how much a professional driver can drive in 1 single go and how much time he can total per day.
Means that the driver has mandatory breaks that he needs to take on a few set points on the road (e.g.: on the terminus, or at a big station in the middle like the central railway station) and that he also needs to be replaced behind the wheel.
All these are breaks that already happen today on a bus route and are perfect opportunity to swap the battery and/or top them up.
(it's already how it is implemented in places that have running electric buses for decades, like Zermatt in Switzerland).
And that's neglecting other current technology, like continuously charging the bus during service, like trolley bus.
One could imagine a "hybrid" type of electric bus, that connects to the trolley overhead wires to charge while on the "in-city" part of its route, and disconnects completely when reaching the country-side
That's already partially implemented, although at a much smaller scale, with current-day trolley able to disconnect and switch to an alternative power supply (small battery or small diesel generator) in order to circumvent construction works on their usual route.
Until personal cars will have such a system - forget it!
Although the technology DOES exist, it isn't much popular.
- in city, you charge the car over night and don't give a damn about swapping batteries.
- on a road trip, the driver will need rest (half an hour every 2 hours - strongly recommanded everywhere, and required in some professional contexts) much more frequently than the range ( > 300 km) achieved by current top-of-the-crop cars from several manufacturer
The only drawback with your plan is that you'll need to wait a little bit longer.
Apple will probably only "invent" the flying car a decade after they hit production elsewhere.
Rename helicopters "flying cars" and you're done.
It's easy to just rename the vehicle and exactly get what you need (a very versatile and compact form of transportation).
(The thing that they plan is supposed to by a "drone-inspired flying car" - i.e.: a multi-rotor helicopter.)
The problems come from the one handing the controls.
Simply rename the average dangerous idiot behind the wheel as "helicopter pilot" won't magically make him thousands of times more reliable...
Broken aircraft DROP.
Actually, no.
Airplanes with broken engines tend to glide (like a not as well optimized gliger).
Helicopters with a broken engine tend to autorotate (like a auto-gyro).
But yeah, you can count on cheaply mass produced in China "drone-like flying cars" to not have well tough-out and as safe as possible failure modes.
This is dumbing down science just so that Trump understands it!
Given that he's also the one who is talking about budgets and cuts,
I think you understood wyh the EXTREME vulgarisation of the NASA.
(And with some luck, he might also confuse them with NSA and shower them with money. who knows ?...)
Yet another argument showing why it is better to favour software with visible source code.
Not that the GPL contains "magic pixie dust" in it that miraculously repel this kind of abuse.
But it just makes this kind of analysis a little bit more easy.
Here author manager to get a hang of what the extension is doing, because it's still in javascript (theoretically humean-readable) though still heavily obscured (the analyst provides links to slightly de-obscured files).
If this was a completely opaque closed source binary, analysis would have been much more difficult.
On the other hand, if this was a completely free/libre opensource software, this kind of analysis would have been much easier and could happen much earlier (and you would expect de-spyware-ified forks to pop-up on github at the same time as such disclosure).
My point is that the bashware is a Trojan Horse which installs the WSL, as you described. The average Joe ain't gonna know they don't need WSL, they have to trust the program they are installing, the Trojan Horse.
Which sound a little bit stretching the average Joe's trust, just to click on some attachement.
(But on the other hand if the torjan begin its life as a "bloatware" that is co-installed with a big software suite, that sounds more realistic :
the joe wants to install a copy of Adobe premiere that he managed to download for free from some website. he IS going to expect a tons of aditionnal platform and libraries to get installed with it. An installation of WSL to get an invisible zombie node of a botnet can very easily smuggle in that case).
If the WSL happens to be deployed after the antivirus was installed, will the ELFs be available to the WSL so they can be started? The Lxss folder is not safely writeable by Windows native applications, file corruption usually occurs. So writing it to the filesystem beforehand is not an option.
If I was a Security Suite developer, the most likely route I would go for :
- software reside in a directory accessible to *windows* - typically a subfolder in the antivirus suite's installation folder
- main reason: so it is trivial to update through the main update system, and can potentially share the same data files (signatures, etc.) as the main windows anti-virus.
- this includes a Linux ELF executable (lifted from the recovery bootdisk)
- this includes a small bash script that can :
+- mount the Windows data with the proper VFS driver, e.g.: under "/opt/SecuritySuite"
+- start the Linux ELF with apropriate options.
- the above is launched by *PIPING* it to the stdin of BASH.exe
- the stdout of BASH.exe is picked up by the software to display result in the Windows GUI.
- this solves the chicken and egg problems of how to handle concurrent WSL installation
Possible improvement :
- the API and message passing used by BASH.exe to talk with Linux process under WSL has recently been improved.
(e.g.: it's possible since recently to invoke "start" from within WSL to launch windows process outside of WSL)
Also, Linux ELFs sounds like a business or Enterprise feature, not a home use feature.
Currently, it is *ALSO* marketed as a home (power) user feature, mainly as free "Recovery Bootdisk".
(In addition to the classical expensive Linux server feature).
So how they will market it depends on what they want to achieve :
- do they want to cover extensively end users ? (it might also come as a premieum feature)
- do they want only to offer it as an extra protection for Business users ?
Just because the standard method of installing an optional service is through a control panel, doesn't mean that is the only way. .NET 2, & 3 are optional on Windows 10.
The difference is that .NET is a platform that is extensively used by Windows software.
It was designed with this purpose by Microsoft and is distributed widely.
It's completely expected that a lot of users will install it, because there are tons of legit use cases for that.
By the time a use clicks on a virus running on .NET, it is pretty expected that .NET will be installed.
WSL is a platform developed by Microsoft that currently only targets developers (so they can test linux code without a VM).
There might be a few rare other cases (I mainly think of running some scientific data pre-processing before submitting to the Linux nodes on the HPC for further processing).
But there are no practical reason for a clueless user to run WSL.
It's not something that is expected to be used by regular everyday software.
(At least that's not how Microsoft sees it, and not how it's marketed)
If a clueless click on a bash malware, chances are that he won't have it installed already.
And it would sound really weird if, when clicking to view an attachment in an e-mail, suddenly 2 installers pop-up (one for WSL itself, one to install the GNU userland from Ubuntu).
So we are back to Antivirus vendors providing ELFs, and providing a means of automatically installing and registering them, after installation. A means of automatically detecting the install of the WSL, and installing the appropriate ELF.
My entire point :
- antivirus need to pack the ELFs (that they already have for servers and for recovery bootdisks) together in their suits.
- if WSL happens to be deployed on that machine, they need to start the ELFs.
And all these "WSL hidden from windows app such as antivirus" problems go "poof!".
The hardest part (having antivirus software as linux ELFs) is already done. What is left is merely integration (which is already provided to some point in BASH.exe)
Incorrect. Windows has a VMS security system with tokens since NT evolved from VMS. Unlike Unix a user is not really admin under Windows but rather requests a token to perform and admin task from ACL access control lists
These are implementation details.
My main point is that most of the time, Windows users are used to run as adminsitrator.
It doesn't matter if that is done by "holding admin level VMS tokens" or "being Unix UID=0, GID=0" is an implementation.
In practice :
- Windows user has account flagged as "admin"
- Windows user does something and UAC shows up asking authorisation for admin action
- Windows user clicks yes by habbit, because that's an entirely normal flow of actions.
My point : Windows users are completely used of running as admin.
On linux :
- Linux user clicks some begnin-looking attachment
- KDESU or any other pops up asking for root password
- Linux user : "Why the fuck do I need root to open a picture ? Kill this shit with fire !"
My point : Linux users don't normally need to run things as root.
WSL doesn't do shortcuts.
It. Fucking. Does.
Read the dozens of article and blog post, some by the Microsoft engineers behind WSL themselves.
The NT kernel was designed by David Cutler...
and was designed in a way that totally sucks at multi-threading and multi-processing.
(see any benchmark that compares code running on Linux and code running on Windows while using windows API for multi-threading).
if you take the time to read all the literature that was written around the introduction of WSL, you'll notice that a new functionality called "pico-threads" was introduced to the NT kernel. .EXE has a subpar performance.
that is the NT functionality that is used to provide "posix threads" to WSL layer ELFs.
because the traditionnal NT functionnality that is usually used to provide threads to
if you read the details, you'll notice that isolation and security is done a little bit lightly - both compared to classic NT threading and to how threads and processes work in Linux.
Isn't blockchain mostly for transactions that will never be modified/reversed or are single well-defined actions at a point in time, like transfers of money or sales?
And in the same vein of "Why?" :
- The whole purpose of blockchain is to have NO central authority, but a distributed public trust.
(customer A gives money to company B and no central authority is needed to confirm it, as long as both A and B use the bitcoin protocol)
- The whole point of a Birth registry is TO HAVE a central authority.
(in case of doubt, check the *official* birth certificate with authority XyZ)
So it seems even weirder to me. it doesn't seem very useful.
Information about people is complex. What if something about the birth record changes or needs to be corrected?
In theory you could still add "amend" records updating the database in the blockchain.
(Just like the "well-defined actions at a point in time transfers of money" can be followed by subsequent further "transfers of money" - e.g.: spending money previously received).
In practice that is going to be problematic, because some of this information is personnal - I would guess sex changes, in some jurisdiction : the person doesn't necessarily want that the history of past sex identities to be publicly known.
In a blockchain technological implementation, all the history NEEDS to be available for the public consensus mecanism to work.
In a authority clasiccal implementation, the authority might only provide the latest official version publicly and keep the access to the history restricted to the person (and medical personnel)
isn't caused by a virus.
So, what ? You can produce anti-bodies against (and thus basically vaccinate against) nearly anything that has big enough molecules to be recognized by an antibody pouch....
It is caused by metabolic by-products of bacteria
You could in theory try to vaccinate against the bacteria producing them.
bacteria practically living outside the body.
so are antibodies : they can be secreted and thus they too can be found outside of the body.
the current MAIN problem might end up that these bacteria, however problematic at causing cavities, still have an important role to play at training the immune system.
you might end up with a slightly increased risk of oral cancers.
(I think to remember something like this regarding past attempts. Must mine literature...)
The user doesn't know the Linux subsystem is installed.
WSL isn't installed by default on Windows 10.
It's an optional component that you need to explicitly select in the corresponding control-pannel-thingy.
(like IIS).
If the user is clueless, chances are high that they don't have WSL installed.
The user doesn't know anything about Linux, and expects their Windows anti-virus to protect them.
(well, if they are running McAffee, they are toasted anyway :-P )
More seriously, it's the "security suite"'s developpers' job to develop a solution.
Again there is no technical reason preventing it (even if the current suite happens not to be able to see what happens on the WSL side).
Most of the big pro developers (e.g.: Kaspersky) already have Linux ELFs that are currently used on Linux servers, and on recovery bootdisk CD/USBs, they already have the necessary tools to be able to scan on the other side of the WSL fence.
All that is needed is some efforts to add the necessary glue code in the current suites to have them launch these processes inside WSL.
No technical limitations.
It is that no existing anti-malware utilities will automatically catch and remove the malware. This is a serious risk.
Well to be more precise :
- currently the WSL subsystem that provides "linux ABI" to original linux ELFs
- and the Win32 system usually offered to normal windows userland
are too different environment which are kept (on purpose) isolated from each other.
(Just think about it: even if theoretically NTFS can store case-sensitive filenames, absolutely no Win32 userland does handle it.
That's just one of the several reasons why both environment should touch eachother's stuff.
Another reason is that for performance reason WSL uses an entirely different threading system than Win32 apps - "picothreads", there was a lot of online articles about the benefits of their introduction to NT kernels)
Only some specific forms of message passing are possible. /bin/bash, hence the name)
(- Windows' bash.exe can start ELFs in WSL (usual
Latest version of WSL can pass a little bit more data around.
WSL has a special filesystem driver to be able to safely mount windows' user data in the filesystem tree.
And that's about it.).
That mean that you copy of Kaspersky Lab for Microsoft Windows can't directly see anything happening in WSL.
...BUT!...
Absolutely nothing prevents you (or security software suites from official providers) to run the "KAV" elf inside WSL to handle the WSL side of security, in collaboration with the Win32 software.