For the person who has to approve it
PixelDeck for IT and security
Somebody wants one of these on a machine you are responsible for. This page is the answers, including the ones that are not flattering, and how to check them yourself rather than take our word for any of it.
| Enumerates as | A USB HID keyboard and a USB CDC serial port. Both are in-box Windows classes |
|---|---|
| Driver | None. No kernel driver, no filter driver, no vendor stack |
| Network, device | None. No radio and no network hardware exists on it |
| Network, companion | One outbound HTTPS request, only if a calendar is configured. Otherwise none — see below |
| Admin rights | Not required to install or to run |
| Windows Service | None. A tray program inside the user's own session |
| Account | None. No sign-in, no licence check, no cloud |
| Telemetry | None. No analytics, no crash reporting, no update ping |
| Mass storage | None. The memory card is not exposed to the host as a drive |
| Works with nothing installed | Yes, for chords and macros. That is the point of it |
The part you should actually think about
It is a keyboard, and it types. That is the whole design, and it is also the honest risk statement: a device that can send keystrokes can send any keystrokes. This is the same consideration as any macro pad, programmable keyboard or barcode scanner already on your estate, and it is not made safer by our software, because our software is not in that path.
If your policy is to block HID devices by hardware ID, block this one the same way. It will enumerate with the controller's own VID/PID; ask us and we will tell you exactly what they are for the units you are looking at.
What a tile can be configured to do
Two of these run on the device with nothing installed. The rest are the companion, running as the logged-in user, and are the reason this section exists.
| Key chord | On the device. A real keystroke |
|---|---|
| Macro | On the device, replayed from the card as real keystrokes |
| Launch | Companion. Starts a program the user has named |
| Shell | Companion. Runs a command line the user has typed, with the user's own privileges |
| HTTP | Companion. A request to a URL the user has typed, made with the in-box curl.exe |
| Typed text | Companion. Synthetic input, so it is subject to the usual boundaries |
| Media keys | Companion. Play, mute, volume |
None of these can do anything the signed-in user could not already do from a shell. There is no elevation path and nothing here asks for one. The configuration is a plain file you can read — if you want to know what a particular deck will do, open it.
Network, precisely
The deck has no network hardware, so there is nothing to say about it beyond that. The companion is a normal desktop program and the answer is nearly as short.
With no calendar configured, the companion makes no outbound connections at all. No update check, no analytics, no licence call, no crash upload.
With a calendar configured — the user has to create a file called
deck-calendar.txt containing a published calendar address — the companion fetches
that one URL over HTTPS roughly every five minutes, using the curl.exe that ships
with Windows. That is what makes a tile count down to the next meeting and open the call. It
is the only scheduled outbound request in the program.
Treat deck-calendar.txt as a credential. A published calendar address grants
read access to that whole calendar to anyone holding it. If that is not acceptable in your
environment, do not create the file and the feature does not exist.
Where it puts things
| Installed | Per-user, under Program Files or the user's own folder depending on the choice at install time. No admin prompt |
|---|---|
| Portable | A folder you unzip. Everything it writes stays inside it |
| Settings and profiles | Under %APPDATA%, or beside the executable in portable mode |
| On the deck | A memory card holding the tile art and the configuration. Not reachable from the host except over the cable's serial protocol |
The installer is not code-signed yet. You will meet a SmartScreen warning, and you should treat an unsigned binary with exactly the suspicion your policy says to. Checksums are published beside every download so you can verify what you got is what we built. Signing is on the list and not done; we would rather you heard it here than found it at the UAC prompt.
How to check any of this
- The network claim. Run it with no
deck-calendar.txtpresent and watch it with Wireshark, Fiddler or your egress logs. It should be silent. If it is not, that is a bug and we want to hear about it. - The service claim.
services.msc, and the Scheduled Task library. There is one process, in the user's session, and closing it closes everything. - The admin claim. Install it as a standard user. It does not prompt.
- The works-without-it claim. Close the companion — or never install it — and press a tile. The chord still arrives.
- What a deck is configured to do. Read the configuration file. It is not a database and it is not encrypted; it is meant to be inspected.
The deployment nobody else offers
If your answer to "may I install this" is no, the deck still works. Profiles, pages, icon art and macros are written to its card once — on any machine, including one of ours before it ships — and from then on it is a keyboard with twelve labelled keys. Nothing to install, nothing to allowlist, nothing running.
What you give up in that mode is the half the companion does: live telemetry on the status bar, profiles that follow the foreground application, media keys, and the launch, shell, HTTP and typed-text actions. Chords, macros, pages and profile switching are all still there.