You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I read that this fun gimmick could been a unintentional secret blunder due to its somewhat loud nature. Rather than to manually mind the protocols for discreet moments, we could just force automation upon the condition of discretion.
For lockscreen interaction, it's supposed to be a discreet moment. Same can be said for the use of privileged use of the terminal program. Since I am not keen enough to force the computer to detect such discreet moments, I have to settle for restricted use of the bucklespring program. One of those restricted uses would be the lockscreen. Now, why would I use the bucklespring with lockscreen? It surely will not guarantee safety. However, it can be quite the (annoyance) gimmick upon lockscreen input indication. I'm sure that there are other programs that could work with a lockscreen.
With restricted use of the bucklespring, comes the restricted use of its button sounds. Thankfully, the options allow us to edit the directory path for loading the proper audio files. We just need to restricted use to the Enter keyboard button. All other keyboard buttons are vulnerable to risk of input detection.
With the proper bucklespring command ready to go, we can focus our efforts on the custom lockscreen configuration. By combining the two commands to work together, we can let bucklespring to sound out (speakers required) for each sent input. As you can see, bucklespring in the context of (sufficient) security, is more of a hindrance to users than security. Still, a start is a start.
I was wondering if there is a chance to let the PC speaker play the buckspring sound (or uses PC beep[s]) upon bucklespring use. Who knows what else can be used with lockscreen, security-wise. If I can, I would probably execute a program to send notification to authorized recipients upon each sent input. Talk about security not being able to differentiate access success and failure.
The real reason I put up this post is because I feel that bucklespring could impose a unintentional security risk, especially when we are not mindful of discreet moments. That said, I hope my personal insights would at least be of some use.
The text was updated successfully, but these errors were encountered:
I read that this fun gimmick could been a unintentional secret blunder due to its somewhat loud nature. Rather than to manually mind the protocols for discreet moments, we could just force automation upon the condition of discretion.
For lockscreen interaction, it's supposed to be a discreet moment. Same can be said for the use of privileged use of the terminal program. Since I am not keen enough to force the computer to detect such discreet moments, I have to settle for restricted use of the bucklespring program. One of those restricted uses would be the lockscreen. Now, why would I use the bucklespring with lockscreen? It surely will not guarantee safety. However, it can be quite the (annoyance) gimmick upon lockscreen input indication. I'm sure that there are other programs that could work with a lockscreen.
With restricted use of the bucklespring, comes the restricted use of its button sounds. Thankfully, the options allow us to edit the directory path for loading the proper audio files. We just need to restricted use to the Enter keyboard button. All other keyboard buttons are vulnerable to risk of input detection.
With the proper bucklespring command ready to go, we can focus our efforts on the custom lockscreen configuration. By combining the two commands to work together, we can let bucklespring to sound out (speakers required) for each sent input. As you can see, bucklespring in the context of (sufficient) security, is more of a hindrance to users than security. Still, a start is a start.
I was wondering if there is a chance to let the PC speaker play the buckspring sound (or uses PC beep[s]) upon bucklespring use. Who knows what else can be used with lockscreen, security-wise. If I can, I would probably execute a program to send notification to authorized recipients upon each sent input. Talk about security not being able to differentiate access success and failure.
The real reason I put up this post is because I feel that bucklespring could impose a unintentional security risk, especially when we are not mindful of discreet moments. That said, I hope my personal insights would at least be of some use.
The text was updated successfully, but these errors were encountered: