Graphql is nice but there are all sorts of weird attacks and edge cases because you don't actually control the queries that a client can send. This allows a malicious client to craft really time expensive queries.
So you end up having to put depth and quantity limits, or calculating the cost of every incoming query before allowing it. Another approach I'm aware of is whitelisting but that seems to defeat the entire point.
I use rest for new projects, I wouldn't say never to graphql, but it brings a lot of initial complexity.
I don't understand why you consider this to be a burden. The gateway will calculate the depth / quantities of any query for you, so you're just setting a config option. When you create a REST API, you're making similar kinds of decisions, except you're baking them bespokely into each API.
Query whitelisting makes sense when you're building an API for your own clients (whom you tightly control). This is the original and most common usecase for graphql, though my personal experience is with using it to provide 3rd party APIs.
It's true that you can't expect to do everything identically to how you would have done it with REST (authz will also be different), but that's kind of the point.
A malicious user who had the knowledge and ability to craft expensive GraphQL queries could just as easily use that knowledge to tie your REST API in knots by flooding it with fake requests. Some kind of per-user quota system is going to be required either way.
By this logic an American state should remit the sales tax they collect on imported cars back to Germany. The Germans would probably love this, twice as many German products are sold in the US as US products sold in Germany.
Sales Tax, Value Added Tax, Goods and Services Tax, are all taxes on consumption. They are paid by the consumer at the location of the consumption. They aren't a tax on production or producers.
AMR (adaptive multi-rate audio codec) can get down to 4.75 kbit/s when there's low bandwidth available, which is typically what people complain about as being terrible quality.
The speech codecs are complex and fascinating, very different from just doing a frequency filter and compressing.
The base is linear predictive coding, which encodes the voice based on a simple model of the human mouth and throat. Huge compression but it sounds terrible. Then you take the error between the original signal and the LPC encoded signal, this waveform is compressed heavily but more conventionally and transmitted along with the LPC signal.
Phones also layer on voice activity detection, when you aren't talking the system just transmits noise parameters and the other end hears some tailored white noise. As phone calls typically have one person speaking at a time and there are frequent pauses in speech this is a huge win. But it also makes mistakes, especially in noisy environments (like call centers, voice calls are the business, why are they so bad?). When this happens the system becomes unintelligible because it isn't even trying to encode the voice.
The implications of weaponising a lithium battery, which seems like what was done, are potentially really significant.
Lithium batteries are everywhere, most of them significantly larger than the one in a small pager. This includes secure environments like military/intelligence facilities and aircraft.
Proof that a lithium battery pack can be weaponised as a bomb, in a way that avoids easy detection, should be a significant concern to anyone who tries to maintain the security of those spaces.
> I would imagine the rewards of silent surveillance (tracking, audio) would be of much higher value than this kind of attack where 3 out of 1000s targets were killed.
The reason they were using pagers, as opposed to phones, was to avoid exactly this kind of potential attack.
Pagers are (typically) a broadcast technology, the pager has no transmission capability. A page is broadcast from every tower, it has no idea where the receiver is. A targeted page is done by the receiver filtering out and ignoring pages that it isn't the recipient for (eavesdropping all pages is trivial).
The pager device is simple, it doesn't contain a GPS or have any concept of it's own location. No microphone or audio capability, very little processing capability. And adding such capability with something like a bug would be reasonably apparent to anyone opening one up and inspecting it.
A puncture causes runaway/explosion in seconds. Overcharging takes 13 minutes. There's not good data on a dead short (because it's unlikely during normal operation), but it's going to be between those on the faster end. From personal experience a shorts cause things to get noticeably hot after about 10 seconds, the graphs show that once you hit 60C things rapidly get worse.
A relay may have been required to hold the short as the battery stops supplying voltage.
reply