Hardware killswitch alternative
#1
I've seen several threads that has mentioned that the kill switches are a bit hard to reach and awkward to use in a smooth way. At the same time I understand that it is an added complexity in the manufacturing process to make them external.

My suggestion.

As a user I can in principle not verify that the kill switches work but have to trust the hardware manufacturer. So I wonder if it would be possible to instead have a LED solution that can show if the HW is disabled, these LED's can be assembled in a way that software can not turn them on/off without also impact the power mgmt to these components.

The good things with this is that it can make it possible to use software switches instead which can be very easy and convenient.

The drawback is of course that there would be need for extra hardware drivers specifically for this device, but maybe it can be worked into some sort of standard.

There are many details to figure out here. For example it is important that the software can not control when the LEDs are turned on at all, so either they are constantly lit or there is one external test button that can be used to check the state to ensure that the software can not turn on/off only before showing the LED state.

Just wanted to share the idea.
#2
Malware with a Pinephone module could briefly turn on the GPS to sample location, briefly turn on the wireless to do a squirt transmission of the most important harvested data and download queued instructions, monitor the system state and wait for a good opportunity when there hadn't been any user input for a while and you likely weren't looking at your phone. It would need to have an audible beep or buzz, and lock the LEDs on for long enough to be noticed.

The switches need to be external and robust enough to enable and encourage regular use. It's more work, but it's the only right way to do it.
#3
(04-22-2020, 01:33 PM)deckaddict Wrote: I've seen several threads that has mentioned that the kill switches are a bit hard to reach and awkward to use in a smooth way. At the same time I understand that it is an added complexity in the manufacturing process to make them external.

My suggestion.

As a user I can in principle not verify that the kill switches work but have to trust the hardware manufacturer. So I wonder if it would be possible to instead have a LED solution that can show if the HW is disabled, these LED's can be assembled in a way that software can not turn them on/off without also impact the power mgmt to these components.

The good things with this is that it can make it possible to use software switches instead which can be very easy and convenient.

The drawback is of course that there would be need for extra hardware drivers specifically for this device, but maybe it can be worked into some sort of standard.

There are many details to figure out here. For example it is important that the software can not control when the LEDs are turned on at all, so either they are constantly lit or there is one external test button that can be used to check the state to ensure that the software can not turn on/off only before showing the LED state.

Just wanted to share the idea.
If you don't trust the manufacturer to wire up the hardware switches as they say they do then why would you trust them to wire up the LEDs as you want them?

In practice you can verify that the hardware modules no longer respond to the kernel you supply when the hardware switches are off. Depending on skill level you may be able to inspect the board and test voltages on pins to see that it is wired as promised.
#4
(04-22-2020, 05:04 PM)wibble Wrote:
(04-22-2020, 01:33 PM)deckaddict Wrote: I've seen several threads that has mentioned that the kill switches are a bit hard to reach and awkward to use in a smooth way. At the same time I understand that it is an added complexity in the manufacturing process to make them external.

My suggestion.

As a user I can in principle not verify that the kill switches work but have to trust the hardware manufacturer. So I wonder if it would be possible to instead have a LED solution that can show if the HW is disabled, these LED's can be assembled in a way that software can not turn them on/off without also impact the power mgmt to these components.

The good things with this is that it can make it possible to use software switches instead which can be very easy and convenient.

The drawback is of course that there would be need for extra hardware drivers specifically for this device, but maybe it can be worked into some sort of standard.

There are many details to figure out here. For example it is important that the software can not control when the LEDs are turned on at all, so either they are constantly lit or there is one external test button that can be used to check the state to ensure that the software can not turn on/off only before showing the LED state.

Just wanted to share the idea.
If you don't trust the manufacturer to wire up the hardware switches as they say they do then why would you trust them to wire up the LEDs as you want them?

In practice you can verify that the hardware modules no longer respond to the kernel you supply when the hardware switches are off. Depending on skill level you may be able to inspect the board and test voltages on pins to see that it is wired as promised.

If you don't trust the HW manufacturer you can't use anything. And sure you can use different technology to check it but I was more thinking about an on-the-go solution that you could trust.
#5
(04-22-2020, 02:39 PM)Dendrocalamus64 Wrote: Malware with a Pinephone module could briefly turn on the GPS to sample location, briefly turn on the wireless to do a squirt transmission of the most important harvested data and download queued instructions, monitor the system state and wait for a good opportunity when there hadn't been any user input for a while and you likely weren't looking at your phone.  It would need to have an audible beep or buzz, and lock the LEDs on for long enough to be noticed.

The switches need to be external and robust enough to enable and encourage regular use.  It's more work, but it's the only right way to do it.

True, what if the LED got lit every time they were enabled by software and then a latch held it lit until you reset it with a hardware buttom.

Makes me think that maybe it should just be two RGB led's that can be lit in different patterns for what is on/off and then the hw control can be a specific button combo like double tap on power. Sure then you risk toggling through an unwanted state for a second.


Possibly Related Threads…
Thread Author Replies Views Last Post
  Battery Life- hardware abstraction layer-GPU VS optomizing app for GPU-openGL biketool 1 248 09-20-2024, 04:04 AM
Last Post: Kevin Kofler
  Microphone on Hardware Model 1.2 is Unusably Noisy In Some Circomstances ASmartSuitedSimpleton 4 4,815 03-23-2024, 10:55 AM
Last Post: Ferriah
Question Alternative Designs or Materials for the Back Cover? BMayes 2 1,055 12-18-2023, 11:19 AM
Last Post: BMayes
  Is the hardware still being developed and refined? orbital 10 6,695 09-01-2022, 08:05 PM
Last Post: orbital
  How to check hardware revision? jojuma 1 2,046 07-16-2022, 12:28 AM
Last Post: bokomaru
  Modem Hardware bad? Not ready for 5g?? linux76 8 6,074 05-31-2022, 06:41 PM
Last Post: SwordfishII
  Any experiences with hardware mod to improve eMMC speeds? kqlnut 9 7,453 04-19-2022, 02:36 PM
Last Post: kk22
  Hardware switch for mic is not working properly submariner 10 9,367 01-25-2022, 07:01 AM
Last Post: wibble
  Case hardware request/idea HobanWashburn 5 5,394 09-15-2021, 04:02 AM
Last Post: biketool
  Battery replacement alternative sax1960 7 7,378 08-29-2021, 07:03 AM
Last Post: bcnaz

Forum Jump:


Users browsing this thread: 1 Guest(s)