From years of experience selling, supporting, and installing 900MHz ISM radios, I can tell you this is not the case in many, many places (it describes a greenfield application more or less correctly, though). 900MHz is heavily used in the US and describing the noise as "background" or "random" is disingenuous at best. I'd like to see someone install a LoRa hub on a tower with several other 900MHz radios (common) and see how well it works.
CSS is an analog (continuous frequency function) modulation where the CSS standard specifies that only linear encoding be used while FSK is a digital modulation that can employ pseudo-random keying and operates at discrete frequency keys. Without these restriction imposed by standards, FSK would be a special case of CSS, at least mathematically.
"So, we reverse-engineer the LoRa physical layer using the patents filed by Semtech [27, 57], which is the key LoRa chipset manufacturer. We also use the Semtech 1276 starter kit [10] that provides an interface to transmit LoRa packets with various bitrates and an arbitrary payload. Finally, we analyze the transmissions from the LoRa chipsets on a USRP."
This paper to be presented in ACM SenSys in November actually demonstrates ability to backscatter to distances as high as 3.4 kilometers at 70 microwatts using narrow band FSK transmissions.
LoRa while achieves impressive sensitivity levels, this is for very low bitrates of tens of bps. For any practical data rate the sensitivity levels are similar to FSK.
Modern microcontrollers can be had in the sub-$5 range that support hardware implemented encrypting algorithms. Mostly it's a worthless feature but we aren't far out from it being more or less standard even in the $0.20 guys.
The bigger issue is that the entire point of this system is to remove cost of deployment and maintenance for cheap highly distributed lo-fi systems. The cost of keying all those devices for encryption would defeat the purpose. Also the added data overhead of the encryption would possibly exceed the amount of actual data you are trying to get out of the system. Also, why do you even want to encrypt it in the first place?
HN ate my reply, apparently I was posting too fast, but as a TLDR you can avoid the overhead of encryption and authentication by revisiting the trust framework in the design of your network and simply assuming that you don't trust your sensors. This moves the overhead from the sensors and the network which are heavily constrained to the processing of the central authority where you have a lot more lee-way and moore's law to help. If you are interested in learning more about this sort of system, it is a topic of research in control theory often lumped under robust systems.
The Economist article for the same subject suggested using this in medical devices.
One-time keying may not be as expensive as you think, a simple matter of IC fuses, but you're right that key management and "enrolment" generally for these tiny things will be a pain.
Medical is just an example of the economist not understanding the product vs the buzzline. It is a terrible tech implementation for medical, but I agree that you generally want medical encrypted. However, if you are talking medical, the cost of the sensor device is tiny compared to other costs even for very expensive sensors.
Fuse based programming would have a whole host of issues. You either need a destructive fill device or load at the factory. If you load at the factory you have to trust them to not retain copies, keeping in mind that it will probably me manufactured in China. If you use a fill device you open up for destructive programming (IC fuses) you open up a bunch of liability for accidental damage to the device plus the cost of a technician plus training can quickly swamp out the cost of your low cost sensor network.
Finally, these sorts of networks work best with asynchronous uni-diretional communication applications. This makes good crypto-practices very difficult. If you chose full crypto and handshake protocols, the amount of data you spend just exchanging keys and handshakes will exceed the data the sensors collect.
Since backscatter systems depend on on an RF source, I wonder if work has been done on encrypting the source signal (pseudorandom bit pattern for example), then modulating the random stream at the device and decoding the backscattered signal at the receiver - essentially a streaming XOR cypher.
In this system the RF source you are sending is effectively the IF component for the sensor's Tx chain. Because it is so high power and such a clean pilot tone, the sensor can eliminate it's IF generating oscillator and output amplifier by just mixing the data onto the receive pilot tone and retransmitting it. This is how the sensor is made so cheap and low power. If the pilot tone was cyphered, it wouldn't mean the data was. That is, you could recover the unencrypted data if you recorded a copy of the pilot by mixing. There is also the issue that, because the pilot tone provides the power to the sensor's carrier, any spreading of it's spectrum, which is what random xor encoding does, makes it harder to recover and use as the IF component for the sensor's radio chain. The last issue here is that the CSS standard does not allow this sort of non-linear modulation.
All that said, it's not a fundamentally bad idea. Pseudo-random xor encoding of signals is a technique used all the time to increase orthoganality between signals for a variety of encoding schemes.
And if you really want to dive into the complications of this topic from a broader perspective of energy use, this piece is full of thought-provoking questions, even if you don't necessarily agree with the conclusions:
Disable Javascript for that site and it reads normally. I've found that most news sites become much more readable (and chew through far less of my CPU, and stop autoplaying loud videos, and skip paywalls) with JS disabled.
The Chrome plugin I'm using (Quick Javascript Switcher) disables on a per-domain basis and remembers the setting for each.
I'm a huge fan of SPAs and JS in the browser and yet I'm quickly blocking JS out of large swaths of the internet simply because it improves the browsing experience. I'm not quite sure what this lesson is teaching me.
Just a note that YesScript isn't compatible with my Firefox Nightly now (due to the move to WebExtensions) and will probably stop working with Firefox in general in the future.
Tech like this already exists (look up "UHF RFID") and the picture they've got looks very similar to existing tags (image search for "alien rfid tag").
The interesting thing here is managing to implement LoRa's modulation scheme in a passive tag.
It's not a passive tag. If you only read 3 sentences into the abstract, you find out that it is an active device. This is repeated at the end of the abstract and right at the beginning of page 2 in the introduction.
Is CSS better than FSK than in this respect or..?
Edit: http://www.akermann.bg/files/Semnrs/H2016/Module3.4_100km%20...
Says
"Spreading codes does not improve sensitivity over FSK systems, for usable datarates you get similar sensitivity using standard FSK modulation"