On the other hand stuff made from plants is, well... made from plants. And there are only so many that you can grow at the same time.
If you produce bio-fuels by finding a new use for waste (e.g.: fermenting *plants waste* into ethanol, as done is some countries), then that's not a problem. In fact it's an advantage, now you can get even more value from the plants that you grow.
If you produce bio-fuels by growing specific plants for that (e.g: I might remember that in the US you tend to do that ?), then your fuel production if going to compete with your food production. Will you plant crops that you will use to sell food ? Will you plant crops that you will use to produce fuel ?
Bio fuel production in the latter case can have a bad impact on food production, even more so if the bio-fuels are exported for a premium to much richer countries, whereas the already starving population can barely buy enough to feed themselves : the local population won't be able to afford food a higher price to increase the incentive to produce more food, while the other richer countries will be able to pay slightly more money to make sure they'll receive the fuel they crave.
Yeah right, because MITM is impossible, correct? Wrong. Because even Kaspersky AV and most AV software is doing MITM on browsers
Because, as part of the installation of the software, you installed their certificate and decided to trust it. You are actually deciding that you won't consider your AV software maker as a "man in the middle", but as a trusted source.
(Also note that some certificate pinning systems actually prevent this type of changes : your browser will notice that suddenly the signing of a website changed from your bank to AV vendor)
You cannot have it both way. You cannot both decide to trust a company (you invite their certificate) and to try to shield your self from them.
Just for discussion, what happens if a company is providing there own hardware, like router, NAS, switches, firewall etc... That company would have physical access to these devices before delivery to customers and you know what happens once there is PHYSICAL ACCESS in the equation I suppose.
If you've correctly though out the way you handle sensitive data : nothing much will happen. Nothing more than what happens already due to the tons of relay out there that are already compromised (that's why you encrypt traffic) and server that get hacked (that's why you end-to-end so only your correspondent can decrypt).
For any proper security planning, you need to start by considering that you can't trust any machine that you don't control directly. You might consider your laptop trusty (though IntelME and co seem to be bent on destroying that). You should not consider trust worthy any 3rd party network element to which you plug said equipment.
No matter if the manufacturer of your router is Chinese, USAmerican or Russian, you should not trust with high level state secrets it if you don't controll it yourself (if you didn't install a trusted spin of OpenWRT/LEDE yourself). Same applies to any software that you install on that laptop, including security certificates.
If you're worried about *an infrastructure provider* putting your state secret at risk, then there's a high chance that you're doing encryption wrong.
- use server encryption (communication between you and the server are over sopme form of SSL like HTTPS, nobody else along the line can access them) - use end-to-end encryption (you encrypt your message before sending it, the recipient decrypts it after receiving, even the server doesn't have any idea what you're saying) - use onion routing (hard for an external observer to guess who is communicating with whom).
But you’re a fool if you think Twitter and co. are doing any of that implicitly, when their entire shtick is public message exchange.
Twitter's entire business is built around public broadcasting of short messages (micro-blogging), so indeed, one would not expect them to care implementing secure private messaging, "direct messages" are more an after-though bolted-on.
But, all the other actors : Microsoft's Skype, Google's Talk/Hangout/whatever they'll call it in the next beta cycle. Facebook's Messenger, Facebook's WhatsApp... are all about direct message between people, about having one-to-one conversations.
Of them, only WhatsApp (and to some extent upcoming in some future Messenger) makes any attempt at end-to-end encryption (Axolotl) which is anyway happening inside an opaque blob (so you can't even audit it they are implementing it correctly, or whether they don't upload back the cleartext to Facebook).
So most of the tool commonly used for one-to-one communication nowadays offer very few guarantees that indeed the communication stays between you.
There is manufacturing capacity outside of China (I might be wrong, but I think that Sony Mobile still has some manufacturing capability in Japan. India has significant manufacturing capability - used among other by Intex, if I'm not wrong. Samsung is obviously manufacturing partly in South Korea)
Though to be honest most of these use chipsets - e.g. Qualcomm - with dubious ogranisation (Seriously ? The *modem* functionning as the SoC's Northbridge? If that doesn't smell like potential backdooring). So even if China happens to not be installing backdoors, that doesn't save you from all the other bad actors.
When used together, they are very close to perfect.
There's a reason why the current advices given by doctors (e.g.: because the girl is on a teratogenic medication) is to combine TWO contraceptive.
If one fails (e.g.: condom badly handled ends up torn), chances are low that the second fails at the exact same time (e.g.: forgotten pill).
The only 100% ones I know of are abstinence....
Hahaha.... very funny.
We're a specie that got where we are currently mostly by sexual reproduction. We have strong instinct inciting us to do it (those who weren't interested in sex, didn't reproduce and where removed from the gene pool). We actually are getting around quite a lot (we're tropical-originating animals, we do it all year long, compared to other animals that only have fixed mating seasons).
Good luck hoping that with all the above, humans will successfully restrain themselves to do what they were basically build for.
I suspect that the 99% figure is the complement of the Pearl score (i.e.: a pearl score of 1%).
i.e.: if 100 women use it (perfectly) after 1 year you'll witness 1 pregnancy.
Now imagine :
- The users aren't applying the method perfectly (actual real-world pearl score is higher).
- According to the Google Play Store page, there are WAY more than 100 women using it.
So you're bound to see quite a few pregnancies.
That's why, in the medical field, when you DEFINITELY want to see NO pregnancies (e.g.: because a female patient is on a medical treatment that happens to be horribly teratogenic), you always advise the patient to combine *TWO* different(*) contraception methods.
---
(*), No putting two condoms doesn't count. And is actually a pretty stupid idea (hint word: rubbing).
Technically speaking, if you use a decent end-to-end encryption, e.g.: using Pidgin/Adium, using OTR encryption plugin, and using one of the libpurple plugins (you need a plugin using Facebook's JSON API, as they've shut down their XMPP Gateway)
then there isn't that much that Facebook can spy.
They can see that you *are* chatting. They can see *whom* you're chatting, and that's about it. Given that you use OTR, they might deduce you're probably more on the nerd/geek side of things, but it's near(*) impossible for them to guess *WHAT* your chat messages contain.
Same applies to Skype (using the SkypeWeb plugin that uses the same XML/JSON api as the new beta Linux application and as the web.skype.com website). Same applies to Google Talk (using the buil-in XMPP plug-in, but you're limited to what's supported on Google's XMPP gateway, so no full Google Hangout feature-set, and no server-to-server XMPP/Jabber).
And if there's a useful Twitter libpurple plugin that allows private messages, you would get similar privacy too.
The main advantage is that OTR is pretty simple and mostly works out-of-the-box (as far as I know it's even pre-installed with Adium, and if both end points have OTR, it automatically kicks in).
The main disadvantage is that nowadays, most people tend to prefer web-apps instead of stand alone clients, and there getting encryption requires special plugins to work (Mailveloppe is such a plugin, to do GPG on webmail's TEXTAREA boxes).
So instead most people send clear text message over web apps, and that's something that's trivial for company to read (and therefore mine for advertising profits).
---
(*): the thing is that the length of the encrypted result is partially influenced by the clear-text input. So Facebook might guess if you're giving a short reply (e.g.: "Yes/No") or writing a long story.
grep for operations that copy memory, then laugh at their complete failure when doing what should be simple arithmetic. mem corruption and memory leaks everwhere (read: code execution).
Fine, and did you send them a patch to fix the problems ? or at least submit an issue on their tracker ?
using cash for everything I possibly can? {...} For all in-person purchases possible I use cash.
Great idea, except that's going to be hard in a world where nearly all transaction with significant amount are done online.
At least where I live, most of the time in-person cash purchase are only used for transaction like buying coffee from the corner shop. Want to pay rent ? e-banking money transfer. Want to buy some big piece of equipment ? Credit-card, paypal or money-transfer. VERY few of the online shop send actual bill that you can pay at the post-office counter. etc.
The next step in my overall strategy will be to find a prepaid debit card (i.e. not linked to any of my accounts) that I can recharge when I need to make online purchases. Put just enough money in it to do what I need to do.
...which is the way most decent credit cards work here around. (Europe). They either prepaid (but the issuing bank usually takes a nice cut on each recharge). Or just entirely different banking accounts (it doesn't tap into your normal salary account, if it maxes out, it's just *that* separate account getting maxed out).
Also speaking about decent credit cards : what you even more definitely need is some form of 2-factors authentication / out-of-band transation confirmation. e.g.: One of my cards provider has an app that I install on my smartphone. Whenever I do any significant transaction (either single big amount, or several small transaction), I need to confirm it with the app. If the credit cards gets compromised: well, good luck doing anything with it (I'll certainly NOT authorise your transaction, though you might manage to get away with the 2 first coffees you pay contact less).
An enormous amount of modern phone are using SoC in a configuration where the baseband modem acts like the northbridge of the smartphone (e.g.: nearly every thing with built-in 3G/4G by Qualcomm). It can autonomously access RAM, other peripherals (including GSM), whitout any interraction from the main ARM cpu cores and the Linux/Android running on it.
By standard (because it's a licensed frequency) you don't get a say on what that modem runs as a software, only licensee can decide.
So in practice that modem runs parts of code which are defined in closed BLOB, and parts of code which are sent as over-the-air upgrades usually by the service provider (again, nearly completely outside the control of the main OS. On some phone, the main OS could even be shut down).
It's like Intel ME, but on steroid.
All it takes for a government/state-level attacker is to force a service provider to beam a specially crafted blob to the modem, and it will happily start broadcasting your GPS coordinates, what it listense on the mic, etc.
In other words, if you have a smartphone in your pocket, you're already toast.
So why again adding a small check box "Do you want to send your current GPS coordinate along with the audio/video feed of this call ?" and corresponding ITU standard to make this possible represent any increase in threat ?
Seriously, contact all the major TV and radio stations in the area first.
Which should take some time, unlike sending a tweet on an account already owned by the emergency center.
Also, the contacting of TV and Radio station might be hampered by people actually attempting to follow the instruction of the previous wrong alert.
Though most TV and Radio crew might wonder how come there's an alert about a missile attack on their *phones* while, at the same time they do not receive a full list of information that they have to broadcast immediately to the population while interrupting the normal programming.
So, while the HEMA guys are heading for the simplest thing to do to communicate information (blasting it on accounts that they actually own, like Twitter), the TV and Radio station should be the one trying to contact HEMA to understand why they weren't asked to broadcast any emergency information (it might have been an error like in this case. Or in the alternative case of an actual live attack, the general population might be missing critical information that the Radio should have been broadcasting and that got stuck somewhere in the process).
Unlike FM, DAB is buried under a patent pool which requires licensing.
It might surprise you, but actually FM *is* licensed. Not the technology per se.
But the actual frequency bands used by FM, DAB, TV, DVB, etc. are all subject of heavy licensing. You are not allowed to through whatever you want on any frequency. Some are reserved, and that's the case with those used by public broadcast (radio, television). (Though some European region like UK tend to have lots or "pirate" unlicensed radios).
Currently, the licensing is a big part of the cost of operating a small radio. And FM bandwidth is very congested all over Europe - which increases the bid for frequencies. By grouping lots of mid/low bandwidth radios in a single DAB emitter, DAB is actually *reducing* the costs of lots of small-scale radios. Lots of them have publicly mentioned being happy to do the switch, there are example of small regional radio who where about to lose their FM license, but still managed to keep on air thanks to DAB.
The only radio actually suffering from the FM to DAB switch are the "pirate" unlicensed radios. Once you remove the cost of bandwidth license, equipment is the next big cost, and currently emitting a unlicensed DAB radio requires a tiny bit more equipment than an unlicensed FM radio (but even that is changing, there are opensource project for SDR to emit DAB). There have been (very low-power) public "happenings" emitting locally DAB in public places.
Regarding the patent pool:
We're speaking about DAB and DVB. i.e.: about things happening in Europe, not in the US. In lots of local jurisdiction 100% pure software patents are a no-no. (e.g.: France doesn't recognize pure software patents, but only recognize patents that cover software as part of the implementation of an actual physical invention. - i.e.: you cannot patent AAC in France, only make a patent for a hardware codec module that a radio station will screw into their rack).
As far as I know, the only patented bit is the AAC codec that's available on DAB+. (and as a pure software patent, not something easily enforceable in most European countries).
Also, there are actual experiment of bringing OPUS to DAB. It's not something that is actually part of any official standard, but it's experiments going on, due to absence of patents and overall better audio quality.
They also seem hell bent on obsoleting it periodically so new receivers have to be purchased.
Technically, not much has changed since the introduction of the first DAB variants. The latest DAB+ is still more or less the same signal. Even the OPUS based experiment mentioned above are STILL the same signal.
The only difference is the audio-stream used by the radio channels. Older DAB used MPEG Audio Layer II (i.e.: MP3's grand-dad), current DAB+ adds the possibility to use AAC.
Any receiver is actually able to receive both. The problem is lots receiver were done in a very stupid manner (to diminish the costs) using single chip solution. And although the media system in your car is actually already able to decompress and play an AAC audio stream (e.g.: when reading a file from a USB drive, when using a digital connection to an Apple iPhone/iPod, etc.) the radio part is done stupidly and not future proof - i.e.: it doesn't send a digital stream to the media player to decode, but the DAB receiver decodes the sound it self on the fly and send the audio. So when the compression format on the DAB gets upgraded (to something that the media player component supports already any way), instead of just changing the decompression, you need to throw away and rebuy the whole DAB receiver.
That's as stupid as being forced to upgrade your laser printer just because you upgraded your word processing software.
If OPUS ever gets accepted into an actual official standard (DAB++ ?), you'll be sure to see the same shitshow (device which actually can play OPUS
Digital is a trap to set you up for subscription services and to monitor you.
Fun fact : - digitial isn't a requirement for encryption, Analog signals used to be encrypted too (though they proved to be easier to crack). - encryption isn't an obligation on digital signal : in lot of countries (e.g.: in europe), DAB is broadcast the exact same way as FM - freely for anyone to catch. No subscription, DRM or whatever. And public channels (those paid by public funds, like taxes or via a separate non-government taxation system - e.g.: in CH) never air advertisement. The "free for all to catch" also applies to digital TV : at least in Europe modern DVB-T / TNT is as available for anyone to listen to as our grand parent's PAL/SECAM. You don't need to subscribe to some cable procvider if you need TV.
It's on your side of the atlantic pond that every single technology evolution is seen as a giant excuse to monetise the shit out of it.
It has been a while since I studied them but I think the ITAR regulations only apply if the GPS receiver is exported as with cryptography.
According to the Wikipedia segment I've linked, it's indeed an import/export rule. So in theory an pure 100% all-USAmerican chip manufacturer (do such thing still exist ?) can legally flash a non limited firmware as long as the device never cross US' border during production, is only sold in-land, and is clearly market "not for export". Also means that the usual asian chip manufacturer only need to flash such firmware on thing clearly sold elsewhere but not in the US (nor the few other countries which follow these rules). They could still flash non-limited firmware for other market as long as they mark them "not for export to US and XyZ countries" (i.e.: only sell them on the less obvious corners of Ali Baba)
If this is an issue for SpaceX, then they should have no trouble getting a licensed exception and I assume some of the ASIC manufacturers produce a custom firmware without the civilian ITAR restrictions
Yup, very likely that SpaceX will easily get the proper licensing, given their field of work. (It's a completely legit use, and the AirForce is on this with them anyway).
Still, they're probably the first US civlian company to be able to basically get a GPS on a giant Missile-like device. (Until then, US civilian use has been restricted by the export regulation).
And teaching poeple how not to fall to obvious snake oil salesmen and ovious trolls is how you should handle it.
Not blocking the free speech on reasons of "idiots speaking".
---
(It's sad that this is coming from the French president, as they are one of the few countries to actually teach "media" in school and having pilot programs to teach kids how to spot urban myths/click bait/fake news/etc.)
Intel processors Speculative execution is NOT working correctly because it can LEAK protected Kernel mode data.
There's two different things.
The "executing past a conditional" stuff that every single CPU with speculative execution is susceptible to, is still speculative execution working as it should. It was well established that it might need to reading stuff outside bound from the first time it was introduced (back in mid 90s), it just happens that only now some researcher though a way to abuse this.
And there's the Intel-specific attacks : Meltdown (and an obscure variant of speculative execution which is also called Spectre).
Meltdown is Intel CPU not properly doing access rights checks (doing them too late in the pipeline at a time when the memory has been already accessed, and some measurable side effect like cache prefetch have happened) where any other CPU has the correct behavior (do access rights check before anything else, even if that means a bigger performance penalty).
Because of that the fundamental protection provided by memory protection doesn't hold true anymore.
That is Intel CPU being broken.
And the Spectre variant is about abusing the way some specific Intel CPU trying to be too clever to predict where a yet-unkown jump might land and get things mixed up. CPU learns that usually instruction A will jump to point B. CPU sees a completely unrelated instruction C, but gets its things confused, and wrongly guess that it jump to B too.
The general "all CPUs are affected" Spectre is still CPU working their speculative execution as expected and still processes accessing data that they already have access too.
The Intel-specific stuff, Meltdown (and an extremely specific variant of Spectre), is Intel CPUs doing stuff that should never be happening to begin with, and is broken CPUs.
The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.
Okay, to go into more details : there are two things that are call spectre, which are both based around speculative execution.
The first one, which gets around software check, to which every single deeply-pipelined/out-of-order CPU that does speculative execution (lots of vendors, some as long back as mid 90s), and which is basically still "speculative execution working as intended", is the one I've described in my post.
That the one to which every piece of software running on nearly any CPU (except perhaps older Intel Atoms, Intel Xeon Phis, and older ARM 32bits as those don't do speculative execution, because as a matter of fact they have way to short pipelines) is susceptible, but which in practice isn't very concerning because it basically targets software which has "please exploit me!" design flaws written all-over it.
The second things which is called "spectre", also uses speculative execution, but is an extremely specific stuff that only targets specific CPUs : only specific Intel CPUs are concerned, only in extremely specific circumstances. AMD CPUs are not affected. And that's expected because each CPU uses an entirely different strategy to predict branches.
Just like with Meltdown, it against boils down to Intel CPU trying to be way too much clever, trading security to shave a few performance points. It boils down to an address (here a jump target) to even being known at the time when instruction start to pour into the pipeline. Some CPUs may try to guesstimate where the execution would go next. The way some specific Intel CPU store their estimations means there's a risk of aliasing/confusion (CPU has learned that instruction A usually jumps to point B, but when the CPU sees instruction C it get things mixed up and think that there's a high chance it will also jump to point B and start speculatively executing there, even if that ends up not being the case and C actually jumps to a different point B).
By knowing the specific make of affected Intel CPUs, and by knowing the exact way in which this aliasing and confusion happens in that specific Intel CPUs, and by allocating a shit ton of memory (so you end up with an address that can actually be confused/aliased with your target) and by the way knowing in advance the foreign address you're trageting (because, you know, ASLR gets in the way) and spending around half an hour doing stuff (according to the Google demo) in order to get the exact thing you need so that specific Intel CPU confuses the thing exactly the way you need, then you can have the CPU guess wrong and jumping speculatively to the completely random address you've asked it to jump to (until it notice it's wrong, throws nearly everything out - except the already prefetched cache - and jumps back to the actual correct execution).
This is not something that affects every speculatively executing CPU in existence, this is not a CPU still working as it should (unlike the other exploit).
This is some specific CPU (happens to be by Intel) that each take wild guesses - way too much wild guesses - and if you know exactly how this CPU takes its too wild guesses, you can abuse to make it guess wrong. No other CPU will be affect.
Given the complexity of the taks, this is not something that you're going to see a lot in the wild and automated (not in drive-by Javascript attacks). This is something that is going to be specially crafted manually, for some very specific attacks (an attacker want to break the specific hyper visor in which it's currently staying).
These runtime checks is exactly what Spectre is trying to circumvent : due to speculative execution, some instruction after the check might start to get processed, and by the time the check fails, even if the CPU throws the work away and doesn't actually write anything into memory, some measurable side effect could have happened already (like fetching a page into cache).
So it could definitely be doable in Rust (it's even proven in JIT-ed Javascript).
But it doesn't leak anything that the current process didn't already have access to (so actual real-world useful exploit are limited to badly designed software, or dangerous kernel options, that keep sensitive data in the same process as arbitrary code).
Slashdot Mirror
Stuff made from plants is renewable.
On the other hand stuff made from plants is, well... made from plants.
And there are only so many that you can grow at the same time.
If you produce bio-fuels by finding a new use for waste (e.g.: fermenting *plants waste* into ethanol, as done is some countries), then that's not a problem. In fact it's an advantage, now you can get even more value from the plants that you grow.
If you produce bio-fuels by growing specific plants for that (e.g: I might remember that in the US you tend to do that ?), then your fuel production if going to compete with your food production.
Will you plant crops that you will use to sell food ? Will you plant crops that you will use to produce fuel ?
Bio fuel production in the latter case can have a bad impact on food production, even more so if the bio-fuels are exported for a premium to much richer countries, whereas the already starving population can barely buy enough to feed themselves : the local population won't be able to afford food a higher price to increase the incentive to produce more food, while the other richer countries will be able to pay slightly more money to make sure they'll receive the fuel they crave.
Yeah right, because MITM is impossible, correct? Wrong. Because even Kaspersky AV and most AV software is doing MITM on browsers
Because, as part of the installation of the software, you installed their certificate and decided to trust it.
You are actually deciding that you won't consider your AV software maker as a "man in the middle", but as a trusted source.
(Also note that some certificate pinning systems actually prevent this type of changes : your browser will notice that suddenly the signing of a website changed from your bank to AV vendor)
You cannot have it both way. You cannot both decide to trust a company (you invite their certificate) and to try to shield your self from them.
Just for discussion, what happens if a company is providing there own hardware, like router, NAS, switches, firewall etc... That company would have physical access to these devices before delivery to customers and you know what happens once there is PHYSICAL ACCESS in the equation I suppose.
If you've correctly though out the way you handle sensitive data : nothing much will happen.
Nothing more than what happens already due to the tons of relay out there that are already compromised (that's why you encrypt traffic) and server that get hacked (that's why you end-to-end so only your correspondent can decrypt).
For any proper security planning, you need to start by considering that you can't trust any machine that you don't control directly.
You might consider your laptop trusty (though IntelME and co seem to be bent on destroying that).
You should not consider trust worthy any 3rd party network element to which you plug said equipment.
No matter if the manufacturer of your router is Chinese, USAmerican or Russian, you should not trust with high level state secrets it if you don't controll it yourself (if you didn't install a trusted spin of OpenWRT/LEDE yourself).
Same applies to any software that you install on that laptop, including security certificates.
If you're worried about *an infrastructure provider* putting your state secret at risk, then there's a high chance that you're doing encryption wrong.
- use server encryption (communication between you and the server are over sopme form of SSL like HTTPS, nobody else along the line can access them)
- use end-to-end encryption (you encrypt your message before sending it, the recipient decrypts it after receiving, even the server doesn't have any idea what you're saying)
- use onion routing (hard for an external observer to guess who is communicating with whom).
Combin those depending on the needed protection.
But you’re a fool if you think Twitter and co. are doing any of that implicitly, when their entire shtick is public message exchange.
Twitter's entire business is built around public broadcasting of short messages (micro-blogging), so indeed, one would not expect them to care implementing secure private messaging, "direct messages" are more an after-though bolted-on.
But, all the other actors : Microsoft's Skype, Google's Talk/Hangout/whatever they'll call it in the next beta cycle. Facebook's Messenger, Facebook's WhatsApp... are all about direct message between people, about having one-to-one conversations.
Of them, only WhatsApp (and to some extent upcoming in some future Messenger) makes any attempt at end-to-end encryption (Axolotl) which is anyway happening inside an opaque blob (so you can't even audit it they are implementing it correctly, or whether they don't upload back the cleartext to Facebook).
So most of the tool commonly used for one-to-one communication nowadays offer very few guarantees that indeed the communication stays between you.
There is manufacturing capacity outside of China
(I might be wrong, but I think that Sony Mobile still has some manufacturing capability in Japan.
India has significant manufacturing capability - used among other by Intex, if I'm not wrong.
Samsung is obviously manufacturing partly in South Korea)
Though to be honest most of these use chipsets - e.g. Qualcomm - with dubious ogranisation (Seriously ? The *modem* functionning as the SoC's Northbridge? If that doesn't smell like potential backdooring).
So even if China happens to not be installing backdoors, that doesn't save you from all the other bad actors.
The pill and condoms are nowhere near.
When used together, they are very close to perfect.
There's a reason why the current advices given by doctors (e.g.: because the girl is on a teratogenic medication) is to combine TWO contraceptive.
If one fails (e.g.: condom badly handled ends up torn), chances are low that the second fails at the exact same time (e.g.: forgotten pill).
The only 100% ones I know of are abstinence ....
Hahaha.... very funny.
We're a specie that got where we are currently mostly by sexual reproduction. We have strong instinct inciting us to do it (those who weren't interested in sex, didn't reproduce and where removed from the gene pool). We actually are getting around quite a lot (we're tropical-originating animals, we do it all year long, compared to other animals that only have fixed mating seasons).
Good luck hoping that with all the above, humans will successfully restrain themselves to do what they were basically build for.
I suspect that the 99% figure is the complement of the Pearl score (i.e.: a pearl score of 1%).
i.e.: if 100 women use it (perfectly) after 1 year you'll witness 1 pregnancy.
Now imagine :
- The users aren't applying the method perfectly (actual real-world pearl score is higher).
- According to the Google Play Store page, there are WAY more than 100 women using it.
So you're bound to see quite a few pregnancies.
That's why, in the medical field, when you DEFINITELY want to see NO pregnancies (e.g.: because a female patient is on a medical treatment that happens to be horribly teratogenic), you always advise the patient to combine *TWO* different(*) contraception methods.
---
(*), No putting two condoms doesn't count. And is actually a pretty stupid idea (hint word: rubbing).
The Google Play Store pages mentions between 100'000 and 500'000 installs, and there are around 6'000 evaluation.
As it's a method with a non-zero failure rate, and given the significantly huge number of women using it, *pregnancy are bound to happen*.
Duh.
(Also note that the 99% is if the method is used always perfectly. Actual real-world result are going to be worse due to mis-use)
Technically speaking, if you use a decent end-to-end encryption,
e.g.: using Pidgin/Adium, using OTR encryption plugin, and using one of the libpurple plugins (you need a plugin using Facebook's JSON API, as they've shut down their XMPP Gateway)
then there isn't that much that Facebook can spy.
They can see that you *are* chatting. They can see *whom* you're chatting, and that's about it.
Given that you use OTR, they might deduce you're probably more on the nerd/geek side of things,
but it's near(*) impossible for them to guess *WHAT* your chat messages contain.
Same applies to Skype (using the SkypeWeb plugin that uses the same XML/JSON api as the new beta Linux application and as the web.skype.com website).
Same applies to Google Talk (using the buil-in XMPP plug-in, but you're limited to what's supported on Google's XMPP gateway, so no full Google Hangout feature-set, and no server-to-server XMPP/Jabber).
And if there's a useful Twitter libpurple plugin that allows private messages, you would get similar privacy too.
The main advantage is that OTR is pretty simple and mostly works out-of-the-box (as far as I know it's even pre-installed with Adium, and if both end points have OTR, it automatically kicks in).
The main disadvantage is that nowadays, most people tend to prefer web-apps instead of stand alone clients, and there getting encryption requires special plugins to work (Mailveloppe is such a plugin, to do GPG on webmail's TEXTAREA boxes).
So instead most people send clear text message over web apps, and that's something that's trivial for company to read (and therefore mine for advertising profits).
---
(*): the thing is that the length of the encrypted result is partially influenced by the clear-text input.
So Facebook might guess if you're giving a short reply (e.g.: "Yes/No") or writing a long story.
Is the data on their servers? Do they have access to their own servers?
Which is yet again an example of why you should only use end-to-end encryption for personal communications.
Everything else will eventually get read.
Wait until somebody gets matched to L'Origine du Monde (by Gustave Courbet)
grep for operations that copy memory, then laugh at their complete failure when doing what should be simple arithmetic. mem corruption and memory leaks everwhere (read: code execution).
Fine, and did you send them a patch to fix the problems ? or at least submit an issue on their tracker ?
using cash for everything I possibly can? {...} For all in-person purchases possible I use cash.
Great idea, except that's going to be hard in a world where nearly all transaction with significant amount are done online.
At least where I live, most of the time in-person cash purchase are only used for transaction like buying coffee from the corner shop.
Want to pay rent ? e-banking money transfer.
Want to buy some big piece of equipment ? Credit-card, paypal or money-transfer. VERY few of the online shop send actual bill that you can pay at the post-office counter.
etc.
The next step in my overall strategy will be to find a prepaid debit card (i.e. not linked to any of my accounts) that I can recharge when I need to make online purchases. Put just enough money in it to do what I need to do.
...which is the way most decent credit cards work here around. (Europe).
They either prepaid (but the issuing bank usually takes a nice cut on each recharge).
Or just entirely different banking accounts (it doesn't tap into your normal salary account, if it maxes out, it's just *that* separate account getting maxed out).
Also speaking about decent credit cards : what you even more definitely need is some form of 2-factors authentication / out-of-band transation confirmation.
e.g.: One of my cards provider has an app that I install on my smartphone. Whenever I do any significant transaction (either single big amount, or several small transaction), I need to confirm it with the app.
If the credit cards gets compromised: well, good luck doing anything with it (I'll certainly NOT authorise your transaction, though you might manage to get away with the 2 first coffees you pay contact less).
An enormous amount of modern phone are using SoC in a configuration where the baseband modem acts like the northbridge of the smartphone (e.g.: nearly every thing with built-in 3G/4G by Qualcomm).
It can autonomously access RAM, other peripherals (including GSM), whitout any interraction from the main ARM cpu cores and the Linux/Android running on it.
By standard (because it's a licensed frequency) you don't get a say on what that modem runs as a software, only licensee can decide.
So in practice that modem runs parts of code which are defined in closed BLOB, and parts of code which are sent as over-the-air upgrades usually by the service provider (again, nearly completely outside the control of the main OS. On some phone, the main OS could even be shut down).
It's like Intel ME, but on steroid.
All it takes for a government/state-level attacker is to force a service provider to beam a specially crafted blob to the modem, and it will happily start broadcasting your GPS coordinates, what it listense on the mic, etc.
In other words, if you have a smartphone in your pocket, you're already toast.
So why again adding a small check box "Do you want to send your current GPS coordinate along with the audio/video feed of this call ?" and corresponding ITU standard to make this possible represent any increase in threat ?
Seriously, contact all the major TV and radio stations in the area first.
Which should take some time, unlike sending a tweet on an account already owned by the emergency center.
Also, the contacting of TV and Radio station might be hampered by people actually attempting to follow the instruction of the previous wrong alert.
Though most TV and Radio crew might wonder how come there's an alert about a missile attack on their *phones* while, at the same time they do not receive a full list of information that they have to broadcast immediately to the population while interrupting the normal programming.
So, while the HEMA guys are heading for the simplest thing to do to communicate information (blasting it on accounts that they actually own, like Twitter), the TV and Radio station should be the one trying to contact HEMA to understand why they weren't asked to broadcast any emergency information (it might have been an error like in this case. Or in the alternative case of an actual live attack, the general population might be missing critical information that the Radio should have been broadcasting and that got stuck somewhere in the process).
Remember, Mozilla was bribed to cripple noscript on Firefox.
Huh?
Giorgio Maone *did* successfully port NoScript to the WebExtension engine. I'm using it right now.
What are you complaining about ?
(and the other "internet condoms" like uBlock Origin, Privacy Badger, etc. are also all available as WebExtensions as well)
Unlike FM, DAB is buried under a patent pool which requires licensing.
It might surprise you, but actually FM *is* licensed.
Not the technology per se.
But the actual frequency bands used by FM, DAB, TV, DVB, etc. are all subject of heavy licensing.
You are not allowed to through whatever you want on any frequency. Some are reserved, and that's the case with those used by public broadcast (radio, television).
(Though some European region like UK tend to have lots or "pirate" unlicensed radios).
Currently, the licensing is a big part of the cost of operating a small radio. And FM bandwidth is very congested all over Europe - which increases the bid for frequencies.
By grouping lots of mid/low bandwidth radios in a single DAB emitter, DAB is actually *reducing* the costs of lots of small-scale radios. Lots of them have publicly mentioned being happy to do the switch, there are example of small regional radio who where about to lose their FM license, but still managed to keep on air thanks to DAB.
The only radio actually suffering from the FM to DAB switch are the "pirate" unlicensed radios.
Once you remove the cost of bandwidth license, equipment is the next big cost, and currently emitting a unlicensed DAB radio requires a tiny bit more equipment than an unlicensed FM radio (but even that is changing, there are opensource project for SDR to emit DAB). There have been (very low-power) public "happenings" emitting locally DAB in public places.
Regarding the patent pool :
We're speaking about DAB and DVB. i.e.: about things happening in Europe, not in the US.
In lots of local jurisdiction 100% pure software patents are a no-no. (e.g.: France doesn't recognize pure software patents, but only recognize patents that cover software as part of the implementation of an actual physical invention. - i.e.: you cannot patent AAC in France, only make a patent for a hardware codec module that a radio station will screw into their rack).
As far as I know, the only patented bit is the AAC codec that's available on DAB+.
(and as a pure software patent, not something easily enforceable in most European countries).
Also, there are actual experiment of bringing OPUS to DAB.
It's not something that is actually part of any official standard, but it's experiments going on, due to absence of patents and overall better audio quality.
They also seem hell bent on obsoleting it periodically so new receivers have to be purchased.
Technically, not much has changed since the introduction of the first DAB variants.
The latest DAB+ is still more or less the same signal.
Even the OPUS based experiment mentioned above are STILL the same signal.
The only difference is the audio-stream used by the radio channels.
Older DAB used MPEG Audio Layer II (i.e.: MP3's grand-dad), current DAB+ adds the possibility to use AAC.
Any receiver is actually able to receive both.
The problem is lots receiver were done in a very stupid manner (to diminish the costs) using single chip solution.
And although the media system in your car is actually already able to decompress and play an AAC audio stream (e.g.: when reading a file from a USB drive, when using a digital connection to an Apple iPhone/iPod, etc.) the radio part is done stupidly and not future proof - i.e.: it doesn't send a digital stream to the media player to decode, but the DAB receiver decodes the sound it self on the fly and send the audio.
So when the compression format on the DAB gets upgraded (to something that the media player component supports already any way), instead of just changing the decompression, you need to throw away and rebuy the whole DAB receiver.
That's as stupid as being forced to upgrade your laser printer just because you upgraded your word processing software.
If OPUS ever gets accepted into an actual official standard (DAB++ ?), you'll be sure to see the same shitshow (device which actually can play OPUS
Digital is a trap to set you up for subscription services and to monitor you.
Fun fact :
- digitial isn't a requirement for encryption, Analog signals used to be encrypted too (though they proved to be easier to crack).
- encryption isn't an obligation on digital signal : in lot of countries (e.g.: in europe), DAB is broadcast the exact same way as FM - freely for anyone to catch. No subscription, DRM or whatever. And public channels (those paid by public funds, like taxes or via a separate non-government taxation system - e.g.: in CH) never air advertisement.
The "free for all to catch" also applies to digital TV : at least in Europe modern DVB-T / TNT is as available for anyone to listen to as our grand parent's PAL/SECAM. You don't need to subscribe to some cable procvider if you need TV.
It's on your side of the atlantic pond that every single technology evolution is seen as a giant excuse to monetise the shit out of it.
It has been a while since I studied them but I think the ITAR regulations only apply if the GPS receiver is exported as with cryptography.
According to the Wikipedia segment I've linked, it's indeed an import/export rule.
So in theory an pure 100% all-USAmerican chip manufacturer (do such thing still exist ?) can legally flash a non limited firmware as long as the device never cross US' border during production, is only sold in-land, and is clearly market "not for export".
Also means that the usual asian chip manufacturer only need to flash such firmware on thing clearly sold elsewhere but not in the US (nor the few other countries which follow these rules). They could still flash non-limited firmware for other market as long as they mark them "not for export to US and XyZ countries" (i.e.: only sell them on the less obvious corners of Ali Baba)
If this is an issue for SpaceX, then they should have no trouble getting a licensed exception and I assume some of the ASIC manufacturers produce a custom firmware without the civilian ITAR restrictions
Yup, very likely that SpaceX will easily get the proper licensing, given their field of work. (It's a completely legit use, and the AirForce is on this with them anyway).
Still, they're probably the first US civlian company to be able to basically get a GPS on a giant Missile-like device.
(Until then, US civilian use has been restricted by the export regulation).
And teaching poeple how not to fall to obvious snake oil salesmen and ovious trolls is how you should handle it.
Not blocking the free speech on reasons of "idiots speaking".
---
(It's sad that this is coming from the French president, as they are one of the few countries to actually teach "media" in school and having pilot programs to teach kids how to spot urban myths/click bait/fake news/etc.)
I don't know. GPS was never supposed to be used for anything like this.
*Civilian* GPS was not supposed to be used like this and got limitations (speed, altitude *) to avoid being usable like this.
The military had guiding missile in this way in their mind from day one.
---
*: normal GPS chips will refuse to give a precise answer above a certain speed (~500 m/s) and altitude (18km).
Intel processors Speculative execution is NOT working correctly because it can LEAK protected Kernel mode data.
There's two different things.
The "executing past a conditional" stuff that every single CPU with speculative execution is susceptible to, is still speculative execution working as it should.
It was well established that it might need to reading stuff outside bound from the first time it was introduced (back in mid 90s), it just happens that only now some researcher though a way to abuse this.
And there's the Intel-specific attacks : Meltdown (and an obscure variant of speculative execution which is also called Spectre).
Meltdown is Intel CPU not properly doing access rights checks (doing them too late in the pipeline at a time when the memory has been already accessed, and some measurable side effect like cache prefetch have happened) where any other CPU has the correct behavior (do access rights check before anything else, even if that means a bigger performance penalty).
Because of that the fundamental protection provided by memory protection doesn't hold true anymore.
That is Intel CPU being broken.
And the Spectre variant is about abusing the way some specific Intel CPU trying to be too clever to predict where a yet-unkown jump might land and get things mixed up. CPU learns that usually instruction A will jump to point B. CPU sees a completely unrelated instruction C, but gets its things confused, and wrongly guess that it jump to B too.
The general "all CPUs are affected" Spectre is still CPU working their speculative execution as expected and still processes accessing data that they already have access too.
The Intel-specific stuff, Meltdown (and an extremely specific variant of Spectre), is Intel CPUs doing stuff that should never be happening to begin with, and is broken CPUs.
Sigh, did anyone actually read the spectre paper;
Exploiting Indirect Branches.
The bit about execution beyond software checks is explaining a specific detail about memory side effects. The above section builds on that concept to show that you can induce these memory side effects by tricking the branch predictor to execute existing code in an unexpected way.
Okay, to go into more details :
there are two things that are call spectre, which are both based around speculative execution.
The first one, which gets around software check, to which every single deeply-pipelined/out-of-order CPU that does speculative execution (lots of vendors, some as long back as mid 90s), and which is basically still "speculative execution working as intended", is the one I've described in my post.
That the one to which every piece of software running on nearly any CPU (except perhaps older Intel Atoms, Intel Xeon Phis, and older ARM 32bits as those don't do speculative execution, because as a matter of fact they have way to short pipelines) is susceptible, but which in practice isn't very concerning because it basically targets software which has "please exploit me!" design flaws written all-over it.
The second things which is called "spectre", also uses speculative execution, but is an extremely specific stuff that only targets specific CPUs :
only specific Intel CPUs are concerned, only in extremely specific circumstances. AMD CPUs are not affected. And that's expected because each CPU uses an entirely different strategy to predict branches.
Just like with Meltdown, it against boils down to Intel CPU trying to be way too much clever, trading security to shave a few performance points.
It boils down to an address (here a jump target) to even being known at the time when instruction start to pour into the pipeline. Some CPUs may try to guesstimate where the execution would go next.
The way some specific Intel CPU store their estimations means there's a risk of aliasing/confusion (CPU has learned that instruction A usually jumps to point B, but when the CPU sees instruction C it get things mixed up and think that there's a high chance it will also jump to point B and start speculatively executing there, even if that ends up not being the case and C actually jumps to a different point B).
By knowing the specific make of affected Intel CPUs, and by knowing the exact way in which this aliasing and confusion happens in that specific Intel CPUs, and by allocating a shit ton of memory (so you end up with an address that can actually be confused/aliased with your target) and by the way knowing in advance the foreign address you're trageting (because, you know, ASLR gets in the way) and spending around half an hour doing stuff (according to the Google demo) in order to get the exact thing you need so that specific Intel CPU confuses the thing exactly the way you need, then you can have the CPU guess wrong and jumping speculatively to the completely random address you've asked it to jump to (until it notice it's wrong, throws nearly everything out - except the already prefetched cache - and jumps back to the actual correct execution).
This is not something that affects every speculatively executing CPU in existence, this is not a CPU still working as it should (unlike the other exploit).
This is some specific CPU (happens to be by Intel) that each take wild guesses - way too much wild guesses - and if you know exactly how this CPU takes its too wild guesses, you can abuse to make it guess wrong. No other CPU will be affect.
Given the complexity of the taks, this is not something that you're going to see a lot in the wild and automated (not in drive-by Javascript attacks). This is something that is going to be specially crafted manually, for some very specific attacks (an attacker want to break the specific hyper visor in which it's currently staying).
Well given that even Mozilla didn't manage to break by switching from XUL to WebExtensions~~
(obviously I'm joking)
These runtime checks is exactly what Spectre is trying to circumvent :
due to speculative execution, some instruction after the check might start to get processed, and by the time the check fails, even if the CPU throws the work away and doesn't actually write anything into memory, some measurable side effect could have happened already (like fetching a page into cache).
So it could definitely be doable in Rust (it's even proven in JIT-ed Javascript).
But it doesn't leak anything that the current process didn't already have access to (so actual real-world useful exploit are limited to badly designed software, or dangerous kernel options, that keep sensitive data in the same process as arbitrary code).