Fix inaccurate claims across site, README and SECURITY.md - #12
Merged
Conversation
The FAQ asserted that sandboxed apps cannot read HID devices and therefore this cannot exist on the App Store. OctoKeys ships per-keyboard input source switching on the Mac App Store today, so the claim is wrong. On a launch thread that gets corrected in public within minutes, and a factual error in your own FAQ is expensive for an app asking for keyboard access. The answer now states what is actually true: InputPilot is not sandboxed and uses IOKit HID directly; the sandbox constrains but does not forbid this; distributing outside the store means no review cycle, free, and auditable. The comparison answer now names OctoKeys alongside autokbisw and Input Source Pro, and says plainly what differs — explicit per-device assignment rather than last-used memory, open source, free. Naming the closest competitor yourself reads as confidence; being corrected reads as sloppiness.
There was a problem hiding this comment.
Pull request overview
This PR updates the public FAQ (both visible HTML and the JSON-LD FAQPage schema) to correct an inaccurate App Store claim and to explicitly name relevant prior art/competitors, improving factual accuracy and credibility around Input Monitoring permission requests.
Changes:
- Rewrote the “Why is it not on the App Store?” answer to reflect the actual relationship between sandboxing, HID access, and input-source switching, and explicitly mentions OctoKeys as proof of feasibility.
- Expanded the “How is this different…” answer to include OctoKeys and clarify InputPilot’s differentiator (explicit per-device assignment vs. “last used” behavior), plus “open source” and “free.”
- Kept JSON-LD FAQ entries aligned with the visible FAQ content (same questions/answers mirrored in both places).
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Two overstatements found by auditing the copy against the code: The site, README and SECURITY.md all said no key code exists anywhere in the app, 'not in memory'. HIDKeyboardMonitor.handleInputValue does read the HID usage — it has to, to decide whether the key was a modifier — and holds it in a local until the callback returns. The claim as written was false. It now says what actually happens: the usage code is read only to compute that boolean, then discarded, never stored, logged or transmitted, and no character or text is derived from it. This is the single most important claim in the project, on an app that asks for the same permission a keylogger asks for. The precise version survives scrutiny; the loose version was close enough to be tempting and wrong enough to be caught, which would have cost more than the claim ever bought. Also: 'about 4,000 lines' was measured — the app is 3,249 lines excluding tests, so the figure is now 3,200 and points at the 15-line callback that readers actually want to check.
LucaGerlich
changed the title
websiteURL was intentionally blank while no site existed; the row is hidden when empty. inputpilot.lucagerlich.dev is live, so show it.
Owner
Author
|
Two additions since the description above:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three claims were wrong or overstated. All are public, and two sit exactly where a skeptical reader lands.
1. The App Store claim was false
The FAQ said sandboxed apps cannot read HID devices, so this cannot exist on the App Store. OctoKeys ships per-keyboard input source switching on the Mac App Store today, using Input Monitoring. The premise is simply wrong.
Now it says what is true: InputPilot is not sandboxed and reads USB vendor and product IDs through IOHIDManager, which is what lets it tell two keyboards of the same model apart; the sandbox constrains rather than forbids this; direct distribution means no review cycle, free, and auditable.
2. The privacy claim was overstated — the important one
The site, README and SECURITY.md all said "No key code … exists anywhere in the app — not in memory".
That is not what the code does.
HIDKeyboardMonitor.handleInputValuereads the HID usage and holds it in a local to computeisModifierUsage(usage):It now states precisely that: the usage code is read only to decide whether the key was a modifier, then discarded — never stored, logged or transmitted, and no character or text derived from it.
This is the single most important claim the project makes, on an app requesting the same permission a keylogger requests. The precise version survives someone reading the source; the loose version was close enough to be tempting and wrong enough to be caught.
3. "About 4,000 lines" was unmeasured
Actual app source is 3,249 lines excluding tests. Now says 3,200, and points readers at the 15-line callback they actually want to check.
Also
The comparison FAQ now names autokbisw, OctoKeys and Input Source Pro, with the real difference: explicit per-device assignment rather than remembering the last source used.
Verified: JSON-LD still parses, 7 schema FAQ entries matching 7 visible ones.