Schneier on Security

Clive Robinson • December 7, 2013 6:18 PM

@ Kashmarek,

@Skeptical: By the way, IBM (and perhaps others) have programs out there that "infer" crimes about to be committed (juveniles in Florida if I remember correctly)

There are a couple of different systems one of which has some basis in science the other does not.

One system uses previous crime data to predict the likelyhood of a crime occuring in a particular small area at an aproximate time. You send a squad car to that area at some time prior to that and give the uniformed officers instructions to make lots of noise and light to make sure that they are extreamly conspicuous. The idea is it acts as a disinsentive to certain types of fairly predictable criminals. Apparently there have in deed been a decrease in crime however as with all "deffence spending" it's extreamly difficult to say if a "non-event" is real and if so what was the actual cause of making it a "non-event".

The second system makes predictions about individuals committing a crime and thus you "pre-crime" arrest them. This is non scientific in nature. The reason being it assumes that the individuals actions are "pre-ordained" and thus they have no "free will". Now if this no free will is true then even if they commit a crime the person cannot be guilty as they had no choice, it's like saying that the bullet that kills you is guilty of murder and ignore the "controlling mind" that caused the finger on the trigger to squease. If however you say there is the free will of a controling mind then the crime is not pre-ordained, and to arrest a person prior to them comitting a crime is a crime it's self...

But such niceties have never stopped a certain type of police officer detaining some one for "stop-n-search" or a lot worse simply because the officer thinks a person looks guilty / suspicious as the only "probable cause". In the UK we have in the past had police officers "fit up" individuals for crimes they did not commit simply because the officer beleived it was "their turn" or justifiable because "they must have committed some other criminal act they have not been caught for".

This second type of system tries to give such arbitary actions the appearance of science thus justic, where as the reality is it does not even rate as faux science and is the tyrany of "justice being seen to be done, even though it's injustice".

Clive Robinson • December 8, 2013 8:23 PM

@ Adjuvant,

: this hardware password safe project may also strike your fancy. Taking shape on the qi-hardware mailing list, it's known as Anelok

I've not looked at the Anelok, my main interest over on qi-hardware has been the Ben nanonote running 4th, to do a prototype for financial transaction protocol. Which all things considered is a harder problem for various reasons @Nick P, myself and others have discussed in the past.

From a quick lookover it appears as Nick P has indicated above to be a "good ideas melting pot" project not one with specific aims and objectives with a clearly defined and reviewed threat model and subsiquent specification cast in that light and forged from previous experiance. Thats not to say it's not interesting but the direction is a little fuzzy.

Another issue is "connections" there is much talk of USB / RF / NFC as far as I'm concerned that is a non starter from a security aspect as the device ceases to be an out of band device and becomes an inband device with no realistic security over sight by the device owner. The first rule of security is if it's going to be "in the loop" then it's through the humans eyes and fingers only as anyother "connection" is open to malware (as we are currently finding out the USB stack is far from secure against state level opponents, the same is true for all radio interface stacks).

There is also a further issues with electrical connections, the first is connectors have an inherantly short life time many manufactures only give a guarentee for 50 operations. Which generaly means they will start to be flaky around 5-10 times that as most mobile phone users will verify (those very expensive manufacturer branded cables get some of their high price from the connector quality not just markup). Connectors are also fragile in other ways and this device is going to be in pockets with fluff, grit and other contact ruining detritus, then ther's the likes of graphite dust from pencils, metal flakes from plating on keys and plastics as well as all sorts of other conducting junk just wanting to get in the connector to short contacts and at the very least shorten the battery life directly (through contact) or indirectly due to "protection mechanisms". Then there are "in use" issues like "soft drinks" and the faff of locating cables etc (why do you think "dropin chargers" are so popular). All of which causes significant cost in terms of PCB, Connectors, case and engineering/manufacturing.

Likewise battery type and replacment are significant issues, and need to be considered carefully (thing how many "TV remote control" style units have busted battery cover latches).

Having spent some time designing FMCE I know that most designs fail the "designed to be manufactured" test. The cost on automated PCB population changes considerably with not just number of component types but re-orientation of the tool heads and a whole load of other "unthought about" issues which also end up effecting product reliability, thus returns rate and can totaly wipe out any profit or the organisation...

Clive Robinson • December 8, 2013 9:02 PM

@ Figureitout,

With regards the Z80 CPU whilst it was very popular (due to it being an augmented 8080 that could run CP/M out of the box) it had issues...

Not realy well known was that internaly the ALU was 4bit and the odd addressing modes and non orthagonal registers were down to this in many respects.

If you want an 8bit CPU with bang for your clock rate have a look at the Z8 or 6809 especialy when you consider page zero RAM 8bit pointers it can knock a whole hunk of program size. Whatever you do avoide the 8051 or those earlier 8048 keyboad controler micros the programing pain they will cause you is the modern day equivalent to that of Medi-evil Religeous Furvor (hair shirts loaded with lice,ticks&fleas, with boils, running sours, rotting teeth stomach ulcers, malnutrition/scurvy and the "Kings Pox" or scroffula and piles and other issues, all befor you begin the self whiping, cold water plunges etc to bring on fevers and delirium to get you that little bit closer to your ideal ;-)

You might also want to have a look at Forth, when it comes to resources it tends to have quite a few advantages (depending on threading type). I know @Nick P does not like it because it's not a "strongly typed" language, but I disagree It's the programs that should be strongly typed not the language. The price you pay in strongly typed languages is way way to high and all you realy get is strong typing on simple data types. At the end of the day it's the programers responsability to code all data types in a strongly typed way and not rely on the faux crutch of language strong typing and casting.

One modern version of Forth is 4th which can be found at,

http://thebeez.home.xs4all.nl/4tH/

And if you fancy cutting your own Forth you could start by having a look at,

http://www.bradrodriguez.com/papers/

I've cut my own multi-tasking multi-user Forth for a Microchip PIC24 with four serial interfaces as a prototype platform for a number of hardware projects. And yes you can multi-task/user on a Z80 with Forth if you realy want to.

Clive Robinson • December 9, 2013 12:43 PM

@ Nick P,

What did you mean by that?

A few things are quite criticaly effected by the thread type.

Essentialy when you create a new dictionary word by the usual,

: name xxxx yyyy zzzz ;

You end up with a dictionary entry of,

[head][xxxx][yyyy][zzzz][end]

Where the head consists of the following,

[len][name][link][code]

And the xxxx/yyyy/zzzz are entries form the parameter entries and 'end' provides the code for the return function which leads into the next word in the program.

The head 'len' field gives the number of chars in the 'name' field, the 'link' field is to the next word in the directory and the 'code' field provides a jump or call address for the code which handles this directory word.

The paramters can be "constant" which loads a value onto the stack, "variable" which loads the variable address onto the stack "user" which identifies an offset into the user memory area or "code" which can either be a link to another word in the dictionary or a jump to a block of native code.

Your Virtual Machine can work with different types of fields in the head or parameter area depending on various trade offs.

For instance if the number of dictionary words is small then the DOCOLON head can be stripped back to nothing by using a lookup table instead, likewise the word parameter entries could be reduced to just a byte token. Whilst saving program space it does slow the VM interpreter down. At the other end of the scale the dictionary can be dispenced with by the VM running a compiled program where words are replaced with inline assembler macros, this gives the fastest execution speed but a very large compiled program without functions in this respect it's similar to "loop unrolling". Originaly Forth was optomised for miinimum memory foot print with the later standard Forths such as FIG Forth on 8 and 16 bit machines sat in the middle but the more recent ones for PC's with effectivly unlimited memory tend to go for the compiled option.

As for,

Now, as I write this, I wonder if it might be possible to design a Forth system that loads code at boot, validates it, and then allows no new code in the system. Might be doable.

Fairly easily, if you think about Forth on Harvard architecture CPU's much of the work has been done, and modifing the outer interpreter loop likewise fairly simple. The problem being for the programers not defining dictionary based data just user area data. Strictly speaking it would not be Forth but some other "Forth like" language of which quite a few exist.

Clive Robinson • December 9, 2013 4:15 PM

OFF Topic :

It would appear that the various US Gov federal agencies still uses floppies for data transfer with only one or two using CD ROMs. And if other sources are correct Win XP and even Win 95 are common. Apparently the reason being in part the cost of their internal IT market being way way to high (thus next to none sign up so costs don't come down...).

http://gawker.com/...

Anyone care to think about the security implications of this...

Clive Robinson • December 10, 2013 5:29 AM

@ Figureitout,

With regards real "books" on Forth they are getting a little like "hens teeth" to find these days.

That said if you have a hunt around you can find PDF's of the books often on the writters home pages.

However the link to 4th I gave above has a 500 page manual as a PDF. I'd have a look at it because although 4th is not a "True Forth" it is certainly a good threaded language to study being written in C makes it fairly easy to understand and link into your own code.

If you can track down "Frank Sargent's Pigmy Forth" it was small fast and when I originaly played with it easily understood.

The trick to understanding threaded languages like Forth is to take your "current programers head" off and put your logic/hardware head on ;-)

In essence what you are doing is building a virtual CPU as an emmulator ontop of an existing CPU. The result is often way greater than the sum of the parts ;-)

Oh and if you are thinking about "rolling your own" search out the "Jupiter Ace" documentation on the net it was a 1980's Z80 based system in many ways very similar to Sinclairs ZX80. At one time or another the Z80 assembler file, circuit diagram and PCB layout were up on the net and the user manual had a nice intro to Forth that young children found understanadable. Yup back in the 1980's there were 8year old Forth programers, my neighbours kid was one much to my annoyance, as she was better at it than I and won 1st prize at the local computer club for a game of "snakes" she wrote I didn't even place with my "Space Defender" game written in basic on the Apple ][ (which I still have).

Clive Robinson • December 10, 2013 7:54 PM

@ RobertT, et al,

That knowledge never dies so once discovered it exists forever as a potentia subversion method/ threat. Ignoring the facts does not eliminate the attack vector!

Some time ago I assumed that at some point we would have to secure systems built with technology we could not check therfor could not trust.

So whilst trying to build trusted technology is a laudable endevor I haven't thought for quite some time it's either cost effective or even practicle in any meaningfull definition of the word.

Which is why I started looking at ways to mitigate subverted technology and thus still be able to build secure systems from it.

The question is how, I've indicated some in the past perhaps it's time others think of ways to do so.

Clive Robinson • December 11, 2013 3:26 AM

OFF Topic :

More spying on citizens news from the UK this time it's on children and their hopes and dreams by interception of their corespondance...

Apparantly the Royal Mail has analysed this years "santa mail" and the top wish is for Lego, whilst the number two is dreams of "One Direction" related merchandice...

Clive Robinson • December 11, 2013 4:12 AM

@ Figureitout,

Yup life abounds with coincidences (including the number of people who share my name...).

One word of warning about Sir Clive Sinclair, he's concidered by some to be a "visionary" but not much positive has been heard about him since he developed a battery powered tricycle like vehical back in the mid 80's and called it the "Sinclair C5", supposadly the name was a shortend version of "Sinclair electric car version 5". Which implies there was a C1,C2 etc. However as I'm sure you are aware the name "C4" is more frequently associated with a product that produces a lot more bang for your buck and jokes were made in that vein at the time. It did not sell well and one poor bloke won one in a raffle one New Years Eve and was arreste early new years day for being "drunk in charge of a vehical" when he tried to get it home. That said the C5 has been modified in various ways you might approve of and one won the land speed record for electric vehicals, and another got fitted with a jet engine. And yes there were more recent press stories of a C6 in the works. (http://news.bbc.co.uk/1/hi/magazine/3125341.stm )

Again VOR is a coincidence if you think back to conversations on this blog between Wael, RobertT and myself abouut Near Field Communications and maintaining radio secrecy I mentioned Aero Navigation systems that used mixed modulation methods (of which VOR is one) to provide directional information.

Clive Robinson • December 11, 2013 5:59 AM

@ RobertT,

Unfortunately as we have seen in the past most programmers are terrible at understanding parallelism and inherently code for a single core. They just dont think in terms of tasks that can be done in parallel and dividing these tasks across an array of cores. even CPU's with very advanced interrupt structures often get used in RTOS's with simple round-robin task allocation.

I very much see programmers or as I prefer "artisan code cutters" as the major security problem, and why I said we need "strongly typed programs not languages". If they can not properly secure the data types they create them selves then what hope do we have...

The solution I thought of was not to alow the run of the mill code cutters to get at "sharp tools" they would try to run with. And instead give them pedestrian high level scripting which they should not trip with, where those very few capable of writing secure code would write the applets that the rest would script them together as required into aplications fairly rapidly. The applets would be written in a way where they would produce signitures that a hypervisor could monitor and check for abnormal behaviour.

The thing is "scripting" is about as "high level" in programing as you can get and do useful work, and usualy produces rapid development. Just about every study carried out shows that the number of bugs is related more to the number of lines of code not the functionality being built. Thus the higher the level the less lines of code to do any given job so (hopefully) the less bugs. Studies using Lisp suggest that currently it beats Java C++ and VisBasic and other .net languages hands down not just for speed of development, but on the less bugs and ease of maintanence side as well. Now I appreciate as there are so few Lisp programers it might reflect more on their abilities than Lisp it's self but...

Also few new code cutters appear to know that Rapid Application Development (RAD), Agile, Patterns and re-factoring all trace back to "Unix Scripting", which in turn picked up on methods (rapid incremental testing) used by NASA in it's Mecury Project, which in turn was based on work in the 50's by the New York Telephon Co. (Which also later spawned RAD).

So the idea has a reasonable pedigree behind it. The downside is it supposadly produces an inefficient and slow run time that then has to be optomised to be more efficient. However history shows that any attempt at optomisation generaly fails because of the lengthy time involved, and the fact that the power of hardware effectivly doubles in a relativly short time and end user needs change in a comprable short time, which means a release cycle might have a six month or less "usefull life" which means to be useful any optomisation needs to be no more than a couple of weeks.

As many sys admins will confirm they can write a reasonable script and test it in about 15% of the time it would take them to just type in the text of an equivalent functionality C program. Which is why I suspect the real sell to managment is "time to market" and "programmer productivity" both of which should improve considerably for competent practitioners.

However whilst this addresses the run of the mill single threaded design process multithreaded and parellel programing require different thought processes and also open the possability of increased security problems.

As far as I can see in many respects this is very much an open accademic research area currently. But if the applets represent minimal execution threads which run effectivly on a single CPU on a multi CPU chip, the problem moves more towards memory usage and communications, which is currently a beter understood area.

Clive Robinson • December 11, 2013 7:23 AM

OFF Topic :

It would appear that the FreeBSD developers have decided not to use the raw output of Intel and VIA's on chip TRNG's. And instead feed it through Yarrow before making it available.

http://arstechnica.com/security/2013/12/...

Personaly I think this is a sensible thing to do and have said so several times in the past.

The last time on this blog was in connection with Linus "throwing the toys out of the pram" over people suggesting similar about Linux.

I wonder what Linus's comments will be now if somebody raises it again ;-)

Clive Robinson • December 11, 2013 7:40 AM

OFF Topic :

Are you sitting comfortably ?

Probably not... it's been reasond for quite some time now that "sitting upright like the boss wants" is neither comfortable or healthy. Past medical advice was get up and move around frequently but that would for many cause. "Boss freakout" with accusations of not working but "sloping off".

Well recent research sugests sloping around 135 degrees (about the same as a reclined seat on aircraft) is probably best for your back.

http://news.bbc.co.uk/1/hi/health/6187080.stm

So now having solved that problem, we now need a solution to the stress caused by a "boss freakout"...

Clive Robinson • December 12, 2013 7:54 AM

@ Nick P,

5. Each node's interconnect chip has builtin MMU that restricts what shared memory the chip can read or write. The MMU is controlled by the master controller of the system. The compute node can't override it or even know what its rules say.

This needs a bit of amplification because of a number of issues.

Firstly, is the distance speed of propergation issue.

A signal is bound by two "light cones" one at the point of transmission one at the point of reception. The effect causes a "dead zone" the size of which is proportianate to the distance and propergation speed which limits the meaningfull spead of processing. One major issue @RobertT can answer better than I can is the reduction in propergation speed in chip traces. In the macro world transmission line speed ranges from around 0.7C to 0.1C depending on the dielectric effect and impedance geometry (coax tending to be faster than twisted pair)

The consiquence of this is the smaller a functional unit is the faster it can operate, thus the simplicity gained by functional decomposition not only helps security by reducing complexity it also alows an increase in operating speed. The downside of this is the "dead zones" which can open up new side channels (delay channels which are arguably the inverse of time channels not just mathmaticaly but functionaly as well). In our macro world we have seen "dead zone" exploitation by the likes of the NSA by simply being closer and thus responding faster than a more distant resource, and by the likes of stock market trading where trading systems are as closely coupled as possible.

One such resource that should be closely coupled to the CPU is memory we see this by the use not just of registers but also of multi-level caches. However caches are self limiting in that the more complex the cache algorithm the larger and slower the cache logic becomes. Thus it's faster to have local registers/stacks/memory when the number is small than it is to have equivalent size caches, hence we actually see a grading of dual port registers, single port registers, stacks/memory files, L1 cache, L2 cache... local SRAM, local DRAM... out to eventualy distant network storage. With coresponding memory size access thus bit/byte/word in registers, word/cell in stacks and memory files out to blocks of memory in increasing size the more distant the memory from the CPU. Likewise we see a greater increase in access algorithm cost with distance. Each of these has a "sweet spot" at which point the overall cost is minimised for a given memory type, which moves with the technology involved.

The same is true for memory access as well dedicated registers are less expensive than general purpose registers and often will be faster. This is because they are only connected to one bus at input or output thus have not just less loading but usually less signal trace distance. But more importantly they also reduce microcode logic as they have very much less RTL logic and don't give rise to bus locking issues.

This spreads out with distance and one problem is the choice between segregation, dedicated paging, segmentation, MMU and memory function tagging. This generaly provides an inverse relationship between how fine grained the control is and distance from the CPU the control logic is. For instance the difference between Harvard and von Newman architectures is an implicit function of the CPU architecture and thus is segregation inside the basic CPU logic, it has many speed benifits which is why these days "von Newman is cobbled onto Harvard" almost at the chip pins. Dedicated paging is an extention of this where you break the memory down not just into data and code but other types such as I/O and mapping for the likes of interupt vectors, it's a matter of architecture design as to if they have their own individual dedicated page memory maps or appear within a more general segmented memory map. Intel chose to do both with I/O having one memory map and vector mapping appearing at a fixed point within the main memory map which also was broken down by segmentation into code, data, heap, and stack areas. Dedicated paging is similar to segregation and forms part of the internal CPU logic and operats at that speed, segmentation however is like a "poor man's" MMU whilst it is often part of the CPU like the von Newman it tends to be cobbled on at the perifery and thus considerably slower than segmentation. A full MMU represents a considerable investment in logic and can involve more gates than the CPU, it is thus a bottle neck on the external bus of the CPU and is slow. However it's not as slow as tagging which in effect is a form of extension to a memory word, where each memory cell would consist of say a 32bit word and 4bit tag which are colocated at whatever distance they are from the CPU.

After an ongoing thought process I concluded that an optimal design for a chip with a significant number of cores would be that the CPU would be strongly segregated and aside from the general purpose dual port registers it would have four stacks/files/caches of 64bits each internal to the CPU and local memory of around 32K that would be segmented with access to general/shared memory and I/O streams via a simplified MMU. Both the segmentation registers and MMU would be under the control of the hypervisor, and any memory fault would halt the core for the hypervisor to investigate. I decided that all I/O should be abstracted via mediated "letter box" bufferes similar to "streams" but rather than being limited to "char I/O" it would alow for "block I/O" where the block could hold either arrays of data or data structures of simplified objects.

This brings up the issue of strong typing and casting of data types/objects and is a thorny subject. If it is to be done at the CPU level then the meta data of the object would be transfered via the stream control channel alowing the data to be strongly typed by a mechanism in the CPU logic [1] that is setup by the hypervisor. The issue of if typing and casting object data from one type/object to another type/object should be a policy enforced within the CPU logic or else where is one I'm still giving thought to. Whilst I want both the typing and casting to be runtime enforced by the CPU logic thus enabaling faults/exceptions to be trapped the CPU halted and the hypervisor to investigate, I'm quite aware of the significant effect it can/will have on the number of gates and the attendant issues in the CPU.

Mediating memory / I/O streams puts a lot of work onto the hypervisor, as I've previously indicated it needs to be a fully defined limited state machine not a Turing engine, however it needs only serial connections to the "task CPU" to set up segment registers, I/O metadata and examine the CPU when halted. However the task CPU hypervisor is effectivly a semi-autonomous head to a backend hypervisor system which controls the MMU and other asspects such as investigating faults and exceptions which means the backend of the hypervisor needs to be a CPU in it's own right. Thus whilst the head can be tightly integrated with the task CPU in effect forming part of it (think Jtag on steriods ;-) the backend needs to be part of a hierachy that also controls device level I/O.

An I/O CPU would be effectivly identical to a task CPU except for the addition of the connection to the I/O device switched matrix. Whilst the I/O CPU setup and matrix routing would be done by the hypervisor the I/O CPU would run like a task CPU in an unpriveledged manner and thus would embody the design ideas behind "user mode I/O". However as the I/O data is mediated by the hypervisor it can also be monitored as a "choke point" thus allowing additional segregation benifits as found in extended TEMPEST design rules.

I will for now leave out the issue of DMA, from my point of view it is a method long long past it's "best before date" modern chip technology should be fast enough that it is nolonger realy required. However if it is required it should realy be into "controled data" not "general purpose" memory to aid in preventing "data as code" issues.

[1] One thing I've not mentioned is "register tagging" as it is still very much a "thought in progress". Whilst general/shared memory tagging is a non starter for various reasons, a different set of rules applies to the general purpose CPU registers. As they are general purpose they need to be tagged, but in a more complex way than is normaly portraied. This is because the are --or should be-- the only place where data can be cast from one type/object to another and the place where strong type enforcment should be carried out.

Clive Robinson • December 12, 2013 8:47 AM

OFF Topic :

I occasionaly mention I read the UK satirical magazine "Private Eye" well the lates issue is 1355, and it's first item will probably be of interest to readers of this blog.

It involves a "hidden backhander" to the UK Coservative Party currently in power as part of the "coalition" and a Chinese Communications manufacturer Huawei which has been effectivly banned in the US Auz and several other countries but not in the UK.

I hope the "editor" will not object to me typing in the article (they don't put them up online at http://www.private-eye.co.uk ).

While David Cameron was in China having his headline grabbing love-in, the Eye uncovered evidence of an under-the-radar payment to his party from one of China's most controversial Companies.

The technology fire Huawei --banned in Australia and the US amid security concerns over it's perceived closeness to China's People's Liberation Army-- made an unrecorded payment of £8,600 to the Tories to attend a networking dinner at the party conferance in October.

The payment--which eentitled Huawei to rub sholders "with senior members of the frontbench teams"-- was listed with the Electroial Commision not under its own name but under that of its lobbying company, MHP Communications. The loobyests conceaded to the Eye that this was an "administrative error" and said they would ask the Commission to amend the record.

In Australia, Huawei is banned from working on the broadband network because of "advice from the national security agencies", and in the US last year the House Intelligence Committee said the company should be kept away from mergers with major US firms because it was a "security risk".

Huawei denies this and will have been reasured by Cameron's on-message performance in China --that Britain is open for business and up for sale-- as it is investing $2bn in the UK over five years.

Clive Robinson • December 14, 2013 9:20 AM

@ Vas Pup,

The article is light on technical details and distinctly worrying in one.

I'm assuming from having done similar (to electronic walets and pocket gambling machines back in the 1980's) that the intend to use the microwave EM carrier to get through ventilation slots and past cheap decoupling cap filters to carry a "fault injection signiture" into the on board computers to cause them to fault in some way. They will however run into problems if they try to patent the idea, firstly I hold 'prior art' as do one or two others (various researchers including Ross J. Anderson). Also it was discussed in depth in public forums when the car carrying Princes Dianna crashed in a tunnel in Paris that led to her early demise (though the usual UK tabloids did their usual shoddy journolist job on technical details). Secondly the man that claims (incorrectly) to have invented Differential Power Analysis will almost certainly try to patent troll with his own invalid patents as they don't appear to be earning him much money currently.

However in the NS artical there is a dangerous assumption put forward about pulling the computers into repeated "reset". The reason it's dangerous is the assumptions of 1, the brown out circuit(if actually installed&working) won't be effected by the EM signal and fault signiture (which I find dubious at best). 2, the computer circuit will "fail safe" when attacked by the EM signal and fault signiture (which I find to be a ludicrous assumption). Also I would not want to have any medical electronics implanted or worn within several hundred feet of such a devic, I've seen them go wrong in the past when subjected to a high field strength signal without modulation.

I can see somebody such as a bystander getting injured by the use of one of these units and suing the operator (LEA) and adjoining the manufacturer in the action, who when pressed for design documentation will refuse, or not provide evidence of sufficient testing and thus a big fat hunk of money being awarded to the injured party or their heirs/dependants. I suspect that it is this "fear of being sued" that is causing the stinger to be less and less deployed.

The real issue that lawmakers need to get to grips with is the conciquences of the laws of physics with respect to mass and momentm and what happens when the control system is impared/disrupted/imobalised in an unsafe manner, which is what all these "technical stopping solutions" do. Essentialy by removing the current controling persons ability you are also removing all the liability from them from that point on and putting it onto the shoulders of the person operating or ordering the operating of such equipment. Arguing "the greater good" might remove criminal liability from the LEA but in many juresdictions it won't remove the civil liability to those hurt.