I believe one way is to generate a frequency similar to female wingbeat frequency that attracts male mosquitoes and separate them that way. I am unsure if there is a difference in the frequency between genders.
This is how the photo fence from intellectual ventures detects and destroys female mosquitoes.Unfortunately they never released that tech as open source
Here's the reason for anyone wondering:
_Thread_local is reserved in C99, so we don't need a -pedantic warning.
(Quoting the standard: "All identifiers that begin with an underscore and
either an uppercase letter or another underscore are always reserved for any
use.")
Which I don't really understand.. I mean, you don't need to warn about anything, that's what "warning" means, and having no way of warning that I'm using things from C11 seems weird to me, given how many other warnings exist.
> * The classic, full version of Skype for Windows sometimes flips the order of a few messages, so that if you send two messages, the first one appears below the second one.
This is most likely due to one computer's time being out of sync then re-syncing
It is disconcerting. I do take some heart in the fact that there's thousands of safe operational hours on the flight computers in question. That said, I'd hope that behind the scenes, there's some engineers pouring over data and test units to find exactly why it happened and what needs to be fixed to ensure it can never happen again.
They did that for the investigation and couldn't find any probable cause. At some point you have to admit defeat and accept that the cause will not be found.
We don't know for sure what caused the ADIRU to start outputting the current altitude numbers but tagged as angle of attack values but this shouldn't have caused an in-flight upset. A spike in AOA from 2.1 degrees to 50.625 degrees and back in 3 seconds is not physically possible, and indeed, the flight computers are capable of detecting and ignoring such flagrantly erroneous data, even if the ADIRU's built-in-test-equipment hasn't announced an ADIRU failure. However, the code that detected anomalous changes in ADIRU data output was a simplistic filter that was vulnerable to a very specific timing of erroneous spikes. It could not handle spikes that were 1.2 seconds (an arbitrary parameter of the filter) apart, and, well, this specific ADIRU failure happened to send erroneous data with that exact timing. The flight computer thus thought that 50.625 degrees was a valid AOA measurement, and reacted accordingly -- by commanding a pitch down with the elevators to avoid the "stall" it thought it was experiencing.
The only issue that hasn't been addressed in the report (which is good reading, https://www.atsb.gov.au/media/3532398/ao2008070.pdf) is that the angle-of-attack value is not directly displayed to the pilots on their flight displays. AOA is measured by the 3 ADIRUs and is one of the most crucial measurements used by the flight computers and their control laws -- after all, whether the wing is stalled or not is a direct function of AOA! AOA value is also critical to upset / loss-of-control / stall recovery but without an AoA instrument, the pilot needs to infer it from other instrument values -- which is nontrivial and also depends on instruments that might be malfunctioning.
Hiding the most crucial air data parameter from the pilots (who are expected to take over when the computers or the air data sensors act up) is a bad design decision. Sullenberger agrees, "We have to infer angle of attack indirectly by referencing speed. That makes stall recognition and recovery that much more difficult. For more than half a century, we've had the capability to display Angle of Attack in the cockpits of most jet transports, one of the most critical parameters, yet we choose not to do it.": http://www.safetyinengineering.com/FileUploads/Situation%20a... . This was a recommendation in the AF447 report as well, " It is essential in order to ensure flight safety to reduce the angle of attack when a stall is imminent. Only a direct readout of the angle of attack could enable crews to rapidly identify the aerodynamic situation of the aeroplane and take the actions that may be required."
Displaying AOA in the flight displays might have helped in this incident as well. Had the pilots seen indicated AOA values spiking immediately preceding the uncommanded pitch-downs, diagnosis and corrective action (which might have included disabling the offending ADIRU) would have been much easier.
Respectfully, why would they? The goal here is to find exploits in ME and use them to make Intel chips more end-user friendly.
When we were rooting Android devices we sat on a lot of exploits that we believed we could use to give end-users freedom. There were a handful that were bad enough to warrant disclosure [1], but we still offered them as ways for users to control their own devices with a few layers of obfuscation on top.
Publishing a blog post isn't exactly sitting on a vuln. I would understand if they kept it to themselves and I would understand if they reported to Intel, but this?
I'm not entirely sure the same "responsible disclosure" arguments for software apply to hardware.
With software, a patch release is a common enough thing that it's a solid argument that letting companies like Microsoft or Apple or Google or others who've demonstrated they'll actually fix security bugs (so, maybe not Oracle, for example), or any of the hundreds or thousands of widely-used OSS projects - I'm _much_ less convinced that any company like Intel will ever manage to get even a single digit percentage of their users to reflash CPU firmware - if that's even possible - and I've never heard of a hardware company freely replacing all user's CPUs where remote exploits are known.
Where the option of "give them 90 days to get a patch out - possibly give them an extension if they ask and explain why, but otherwise sit on the bug with the vendor until it's fixed or being actively exploited in the wild" à la Google Zero & Tavis seems to work reasonably well enough of the time for software bugs - it seems to me unlikely to be as beneficial for hardware bugs which are much much harder to get fixes to end users - and early disclosure giving the opportunity to mitigate with firewalls or unplugging the device seems more likely to be the better choice.
Isn't the whole purpose of this IME to facilitate remote updates and management of systems? As for patching hardware, Intel does have the ability to apply microcode patches. At the least they are able to disable features that are buggy.
Sure - it's _possible_ to patch the microcode - but can your dentist's receptionist do it? Or your mom? Unless there's a tool that automatically applies security microcode updates as easily and as widespread as automatic Windows updates - it's really only of use to enterprise/corporate networks... I've never bumped into a small or medium sized business that runs remote management for all the machines on their office networks...
First: mmastrac was explicitly talking about rooting Android devices via an exploit. Since as far as I know there are Android devices available that can be rooted on your own, buying one where an exploit is necessary is a conscious decision by people who don't care about such rooting. So your argument is off my point.
This said: To my knowledge for some mobile phones using a TI Calypso chip, one can flash a free firmware (OsmocomBB):
Even if it was exploitable, it's not like Intel can fix it as they have no mechanism to revoke the old version.
Sure, they could release a new version with the bug fixed, but the attacker doesn't have to use the new version, they can deliberately use the old flawed version in their modified version of the bios.
Hopefully this is true. Though we really don't know what all the components in the Intel ME can do. They might be able to remotely update all chips so long as they have connected to a network that still exists. But I think (hope) this is unlikely and you are right.
Isn't the only way to mutate to avoid CRISPR to change your genes enough that CRISPR can't identify you? If so, doesn't that mean we just find the new genetic signature and generate a variation that targets it?
I see CRISPR as grepping through memory for running instruction code. Sure, the code can change, but if you see the behavior, then it's a matter of finding the new code signature manually and generating a new CRISPR variant target it. If that's accurate, the similarities to anti-malware are pretty cool. Just keep updating your virus DB.
Well, as CRISPR was originally found as a kind of immune system, there do exist a number of anti-anti-Cas9 systems against that evolved alongside it. There are a number of small inhibitors of Cas9 [1] (which themselves could be used to tune Cas9 in therapeutics). However up-taking such a defense is admittedly an unlike route for a virus like HIV to take to evolve resistance to a CRISPR-based therapy.
More practically, HIV has such a high mutation rate, that it's likely very difficult to target every HIV sequence with a sequence-specific Cas9 therapy. If the Cas9 guide sequence is too generic it'll take out stuff besides HIV (stuff you need). And if the guide sequence is too specific it won't get all the viral inserts because many are degenerate. As with all things though, 95% success with viral excision via CRISPR, in conjunction with 95% success via immunotherapy [2], and 95% from standard anti-retrovirals [3], get's you pretty good 99.9999% coverage.
That's the power of convergent technologies. It's an interesting slice through a number of modern therapeutic technologies all applied to one of the most challenging of tailored foes. You see convergence of small molecule biochemistry along with immunotherapy, along gene therapy, along with cutting edge synthetic biology - all approaching the problem from different angles.
"More practically, HIV has such a high mutation rate, that it's likely very difficult to target every HIV sequence with a sequence-specific Cas9 therapy. If the Cas9 guide sequence is too generic it'll take out stuff besides HIV (stuff you need). "
Unless I'm grossly misunderstanding how CRISPR works, there's no conceptual reason why you couldn't target multiple sequences at the same time, with a cocktail method. That is, rather than trying a single overly broad match, you could go for (say) ten highly-specific targets at the same time. A particular HIV virion would then have to differ in all ten regions to avoid getting chopped up.
Just spitballing here:
Google tells me that HIV has a mutation rate of about 4E-3 per base.
Let's say you choose target sequences ten bases long (I don't know what the maximum practical length for the technology is, nor the minimum length you'd need to reliably tell HIV from human, and Google isn't any immediate help there).
The probability that there will be a mutation in that sequence is then about 0.04. However, if you target ten sequences simultaneously, the probability that all ten would be mutated is (0.04)^10 ~= 1e-14.
That's likely more than good enough to assure that there weren't any resistant mutants around (if by some chance there are...lather, rinse, repeat).
This is hand-waving, to be sure. If you have better numbers, plug them in.
I think ∼3E−5 per base per replication. Might be a more useful number [1].
If you use 10mers, that only gives you 1048576. I'd be almost certain that >90% of those sequences also exist in the human genome. So your target isn't specific enough (take out stuff you need as the parent suggested).
So you need to use a longer sequence, perhaps 25bp. Maybe there's a stable region or set of regions you can target (in which case the high overall mutation rate doesn't matter). Or a cocktail of sequences, specific to the global HIV population (I doubt this, HIV mutates more in a single individual than Flu does in the global population).
But if not, then you first need to figure out what the viral population in this individual looks like. So you sequence a subset of population, and come up with a 25mer or set of 25mers that target this population.
That might be a lot of sequences (significant problem). Which you then need to get synthesized (will take weeks).
Now. It's taken days to run your sequencing experiment, and weeks to get your CRISPR stuff synthesized. In this time the viral population has been generating 10E11 new virions per day. You're population has moved on, and almost certainly contains members which don't have your previous cocktail of 25mers in them and will survive the treatment.
Because HIV mutates so much, there was some interesting work I saw a while back on guiding the evolution of the population. You'd use drugs which don't wipe out the infection, but push the population toward specific genotypes. Specifically those which you have good treatments for, in the hope that you can wipe out most of the population at once.
"Maybe there's a stable region or set of regions you can target (in which case the high overall mutation rate doesn't matter). Or a cocktail of sequences, specific to the global HIV population (I doubt this, HIV mutates more in a single individual than Flu does in the global population)."
Hmm... I would bet that there is a cocktail of sequences such that if they are not conserved, the virus effectively becomes no longer HIV (no longer infectious, no longer capable of producing symptoms...).
HIV is obviously not a human being, right? Find every sequence where it differs, target them all. :-)
> As with all things though, 95% success with viral excision via CRISPR, in conjunction with 95% success via immunotherapy [2], and 95% from standard anti-retrovirals [3], get's you pretty good 99.9999% coverage.
I wonder if several narrow CRISPR payloads simultaneously would achieve the same effect since any survivors would need n many mutations simultaneously.
It seems this would be the question when using CRISPR against any virus. Right now one would have to use gene drive to 'amplify' CRISPR and apply it in a living, adult organism (as I understand it). Perhaps some "similar" feedback machanism could be used against quickly mutating viral pathogens?
