macOS keyboard layouts: "The developer can access anything you type..."???

Jump to latest Follow Reply
effgee

effgee

Ars Praefectus
4,373
Subscriptor
  • #1
    Quick background: I frequently correspond in English as well as in German, and as such I need to be able to quickly access characters on my US keyboard that are usually available only on German keyboards: ä, ö, ü, Ä, Ö, Ü, ß, etc. For this purpose I always install a custom keyboard layout (*) that lets me access these characters with less fuss than Apple's standard US layout.


    This has been my MO for ages – install macOS/boot new machine/whatever, do my customization thing (system utils, system prefs, etc.), install apps, copy over documents – and Bob's yer uncle, back to work I get.

    Today however, while doing my usual customization thing, I got stuck at a stern and (to me) new, and rather weird warning "System Settings.app" flashed at me. Following the install of my custom keyboard layout, in the attempt to select this layout as my default, "System Settings.app" tells me:

    macOS' System Settings.app said:
    Installed Input Source - The developer can access anything you type with this input source. This could include sensitive information such as your credit card number or home address.
    Click to expand...

    warning.jpg


    Somewhat alarmed by this dire warning, I head on over to "/Library/Keyboard Layouts/" to take a closer look at the contents of the *.bundle file I'd just installed. Therein lie the following files...

    bundle-cnt.jpg


    The bundle contains no executables or scripts of any kind (.app/.sh/*.py/whatever), there are no weird permissions to any of the files, no invisible files – only four XML files of various flavors (plist/strings/keylayout), none of which as much as mention any domains, IP addresses, whatever they might want to contact, and a single *.icns icon/image file.

    Now I sit here, scratching my head over how this particular a keyboard layout file, or rather bundle, could possibly either collect any information I am typing, let alone contact a remote server to transmit such surreptitiously collected data?

    What am I missing? Am I just an utter clot who needs to hand in his macOS license, am I losing my mind, or did Tim Cook (**) go off the deep end?

    I am genuinely at a bit of a loss here... any ideas from the hive mind?


    (* – custom keyboard layouts/input sources having been around for ages in macOS, created for example with simple utilities like Ukulele, etc.)
    (** – using him as a metaphorical stand-in for Apple Inc.)
     
    effgee

    effgee

    Ars Praefectus
    4,373
    Subscriptor
  • #5
    iljitsch said:
    You're not using a tool like Karabiner, are you?
    Click to expand...

    Nope. It's basically a fresh install, and this file @ "Macintosh HD/Library/Keyboard Layouts/US-with-German-Umlauts.bundle" was only the fourth or fifth piece of (non-Apple) software on the boot drive. Only stuff that got on there before it was LittleSnitch, Cookie and AdGuard Pro, all of which were fresh downloads from the respective developer's website.

    grahamb said:
    My guess is that warning is telling you that third-party layouts have the ability to capture whatever you type, not necessarily that the specific one you're looking at is definitely doing so.
    Click to expand...

    That was my hope, that the presence of the bundle file triggered some generic drivel that might've slipped past Apple's usually 'stellar' QA. Completely threw me for a loop since I'd never seen anything like it on macOS. Did feel a bit like Google's Gemini insisting authentic Italian pizza must always contain a good dab of Elmer's, and to not forget to eat my daily pebble.

    Entegy said:
    Wouldn't that just be generic text for third-party keyboards carried over from iOS?
    Click to expand...

    On one side that'd be grand since it'd most likely mean some kind of false positive in my case, and quite disheartening on the other since it'd once again speak volumes about Apple's... whatever they consider 'QA' these days.
     
    H

    Honeybog

    Ars Tribunus Militum
    2,415
  • #6
    I know this doesn’t address your topic specifically, but have you considered just switching to the U.S. International keyboard? It’s significantly faster for adding accents and diacritics than the standard keyboard’s press and hold shortcut. With umlauts, you would just press option+u to add the umlaut, then type the letter you want it to appear on. Option+control+u will add the umlaut to the last letter you typed.
     
    • Like
    Reactions: analogika, grahamb, SportivoA and 1 other person
    effgee

    effgee

    Ars Praefectus
    4,373
    Subscriptor
  • #7
    ^ It's actually a very good tip for folks who want to dip a toe into the wonderfully weird world of diacritics with their accents, Umlaute, and Scandinavian murder characters (ø!!!). However, not quite sure what you mean with 'US int'l keyboard', I only know that term from Windows, and the 'standard' US layout in (the US-version of) macOS behaves as you describe – "⌥ + u" = umlaut dots, plus respective character for result, e.g. ä.

    The slight advantage my custom layout offers is that I only need to hit "⌥ + a for ä", "⇧ + ⌥ + a for Ä", etc., meaning it saves me a fraction of a second for not having to hit "⌥ + u" first and then the character I need. By itself the time difference between the two is of course ludicrous, but taking into consideration the fact that Umlaute make up about 2% of an average German text, and over an entire year, my tendons are grateful for every keystroke and second saved.

    Oh, for folks interested in this, on recent macOS versions (not sure since when), users can simply hold down the respective key, e.g. "o" until a lil' menu pops up, displaying a choice of special characters, where they can then either click in the special character of choice or hit the respective number displayed underneath each of them (1-9 in the example below).

    special.jpg
     
    • Like
    Reactions: IncrHulk, analogika and dal20402
    gabemaroz

    gabemaroz

    Ars Tribunus Militum
    1,689
  • #8
    grahamb said:
    My guess is that warning is telling you that third-party layouts have the ability to capture whatever you type, not necessarily that the specific one you're looking at is definitely doing so.
    Click to expand...
    Exactly this. It's could not does. Apple has increased the amount of security information in newer OS versions to show granular information on exactly what applications can access.

    I find Apple's keyboard switching to be excellent in comparison with others, but if you are using a third-party then you need to make sure you trust the developer.

    I mean that kind of 'scary' language is present in just about any system extension.

    Screenshot 2025-01-23 at 9.16.00 AM.png

    Do I think Dark Reader is capturing all my passwords and credit card numbers? No, but it is entirely possible given that it is 'reading and altering' webpages.

    Users are given the ability to make informed decisions, but it can also come off as alarmist. It's a difficult line to walk.
     
    • Like
    Reactions: analogika and grahamb
    stevenkan

    stevenkan

    Ars Legatus Legionis
    16,060
  • #9
    effgee said:
    The developer can access anything you type with this input source. This could include sensitive information such as your credit card number or home address.
    Click to expand...
    Yeah, I would read that as a more generic, "Any developer of a custom input source has the potential to intercept your keystrokes," and not "This particular input source is logging your passwords."
     
    • Like
    Reactions: analogika and grahamb
    H

    Honeybog

    Ars Tribunus Militum
    2,415
  • #10
    effgee said:
    I only know that term from Windows, and the 'standard' US layout in (the US-version of) macOS behaves as you describe – "⌥ + u" = umlaut dots, plus respective character for result, e.g. ä.
    Click to expand...

    D’oh, yes, you’re right. I should have said “ABC - Extended,” which gives you a huge range of diacritics, including some rarer ones like super and sub-script dots. I didn’t know the umlaut shortcut worked on the normal layout.

    1737599554524.png

    https://support.apple.com/lv-lv/guide/mac-help/mh27474/mac

    At any rate, point taken about saving the extra keystroke.
     
    • Like
    Reactions: effgee
    effgee

    effgee

    Ars Praefectus
    4,373
    Subscriptor
  • #11
    Thanks guys, definitely appreciate the input!

    What I don’t get though – and let me just re-emphasize that I’m solely talking about macOS here – why in the name of all that is holy would Apple even permit any kind of executable to be run from “Macintosh HD/Library/Keyboard Layouts”, and/or allow a file located therein to call up another (non-Apple) executable/script/whatever?

    This may be my ignorance showing, but what possible legitimate reason could a file that is exclusively meant to (re-)map keyboard inputs have executing any kind of code?

    Everything I’ve ever heard about alternative input sources on macOS can be achieved with the structure of XML files show in my initial post, so to me this seems like such a bizarre instance to issue such a stern warning for something that (IMO) shouldn’t be possible in the first place.

    E.g., Apple doesn’t warn me not to delete dozens upon dozens of fonts designed exclusively for scripts I’ll never use – they simply lock ‘em away on a system partition no regular user will ever be able to access. Compared to the “hey, there may be malware in that keyboard layout file you just dropped in the Library folder” approach, the two just seem like absurd, diametrically opposed ways of implementing system security. Almost like they were developed by two entirely different teams that have never talked to each other, but are nonetheless working on the same OS.
     
    • Like
    Reactions: The Limey and benwiggy
    gabemaroz

    gabemaroz

    Ars Tribunus Militum
    1,689
  • #12
    effgee said:
    What I don’t get though – and let me just re-emphasize that I’m solely talking about macOS here – why in the name of all that is holy would Apple even permit any kind of executable to be run from “Macintosh HD/Library/Keyboard Layouts”, and/or allow a file located therein to call up another (non-Apple) executable/script/whatever?

    This may be my ignorance showing, but what possible legitimate reason could a file that is exclusively meant to (re-)map keyboard inputs have executing any kind of code?
    Click to expand...
    This has to do with the nature of bundles on MacOS. For all intents and purposes they are considered executables in terms of system security and therefore may require explicit privileges depending on what level of access they require.

    A bundle is a directory with a standardized hierarchical structure that typically contains executable code and the resources used by that code. Bundles fulfill many different roles: apps, app extensions, frameworks, and plug-ins are all bundles. Bundles can also contain other bundles; for example, an app may contain an app extension.
    Click to expand...
    There is no restriction (that I know of, someone correct me if I'm wrong) on where executable files can be placed in POSIX (e.g. Unix, Linux, MacOS, ...) compliant systems so long as those files have -x in their access control lists.

    Apple's security model regarding bundles is intentional and appropriate because they are an extraordinarily common attack vector.
     
    • Like
    Reactions: analogika, ham bulu and effgee
    I

    iljitsch

    Ars Tribunus Angusticlavius
    8,999
    Subscriptor++
  • #17
    Ok, I found the github page for this project. Granted, my github game is weak, but this project is truly a disaster for a user who just want to solve a problem. On one Mac I was able to find a curl command to download and install the bundle mentioned above. But onder Ventura, no security warnings.

    On another machine, there were insufficient bread crumbs to do the same, but I did manage to find the .dmg file that is supposed to contain the bundle... but doesn't. It just has the XML .keylayout file, which is all you really need although an icon is nice. Apparently I really do need to reboot my computer to activate it, but I just started a first Time Machine backup so I'll have a separate post on that.

    I'm thinking it's the bundle thing, though.

    In the meantime, I've spent way too much COVID time experimenting with keyboard layouts. I came up with a system where you use the regular QWERTY keys but then use the keys that are ` - = [ ] \ ; ' , . / on the US layout whichever way you want. But if you need to get those characters mentioned before, just use their US key along with alt. (There's more to the whole system but let's not get into that now.)

    One result of that work was this web app that amongst other things, lets you select a number of existing keyboard layouts and then edit them as JSON (the edit/import link) and generate a Mac .keylayout file, or, with some more effort, generate a Windows keyboard layout file.

    This way, you should be able to get a custom keyboard layout that works for you with relatively minimal trouble.

    Or just use Apple's ABC or ABC Extended. You get umlauts with alt-u and then the letter that goes under the umlaud, and ß with alt-s. No capital ß though, but I gather life is possible without it. ABC Extended can do very many more accents so it should be the default choice for anyone who doesn't want to go out of their way doing complex stuff, doesn't want to mess up a US layout but still be able to type many accents.
     
    Last edited:
    gabemaroz

    gabemaroz

    Ars Tribunus Militum
    1,689
  • #20
    Because if I am creating a keyboard layout, I could remap a single keypress to something like:

    ⌘ <space> terminal <enter> sudo rm -rf / <enter>

    or just about anything else that might peripherally execute terminal commands or other similar code – as a hypothetical example.

    Unless the user is going through the .keylayout line by line and double checking everything, they may never even know until after it has executed. And how many people just enter their password automatically when there is a prompt?

    There is a third-party .bundle file which sits between the user and the computer, intercepting each keystroke, manipulating it, and passing it to the operating system. If I added in 'and logging every input', the danger here is patently obvious. It is not less dangerous without that addendum, however.

    Hence the warning. And rightly so.
     
    Last edited:
    • Like
    Reactions: analogika and grahamb
    I

    iljitsch

    Ars Tribunus Angusticlavius
    8,999
    Subscriptor++
  • #21
    I think you can send multi-character responses to a single key, but remember, those are just characters, not key combos, so no ⌘ <space>.

    So sure, be careful about maliciously crafted keyboard layouts as unexpected things may happen, but not that "the developer" can see all your key presses. That's the stuff you get when you abolish fact checking.
     
    effgee

    effgee

    Ars Praefectus
    4,373
    Subscriptor
  • #24
    iljitsch said:
    Ok, I found the github page for this project. Granted, my github game is weak, but this project is truly a disaster for a user who just want to solve a problem. On one Mac I was able to find a curl command to download and install the bundle mentioned above. But onder Ventura, no security warnings. ...
    Click to expand...
    ^ That one up there is close but not the layout file/bundle I am using. The one you found uses caps-lock, whereas the ones I've been using for probably going on a decade or so use "(⇧ +) ⌥ + vowel (or s)" for (Ä)ä, (Ö)ö, (Ü)ü and (ẞ*)ß. That's all I need to make my German correspondents happy.

    I didn't want to link to the repo with the file I'm using until I was reasonably certain that my own conclusion about it being benign turned out to be correct. The whole thing was created with the lil' Ukelele utility I'd linked to at the bottom of my initial post, as it creates a "org.sil.ukelele.keyboardlayout." string under the "CFBundleIdentifier" key in the bundle's Info.plist.

    And at least in the case of the file I'm using, you don't need to resort to the command line to download or install the bundle. A simple download from the repo page, unzip the archive, drag and drop the bundle file into "Macintosh HD/Library/Keyboard Layouts". I only had to log out and back in for the new input source to show up in System Settings.


    (* – There is indeed such a thing as a capital 'ß'. World, meet 'ẞ', the latest craze in German spelling, introduced (AFAIK) in 2017, so a very recent addition.)

    eszett.jpg
     
    Last edited:
    effgee

    effgee

    Ars Praefectus
    4,373
    Subscriptor
  • #25
    gabemaroz said:
    Because if I am creating a keyboard layout, I could remap a single keypress to something like:... Hence the warning. And rightly so.
    Click to expand...

    Well, aside from the fact that even as an admin you can't just run a command as su without first authenticating, I totally get the reasoning behind the policy, and now that I know what's going on I also don't have a major issue with Apple's approach here. ... however, and there just had to be a "but", there are two points that make the whole thing a little less palatable for me than it needs be:
    1. As seems Apple's new normal these days, there is zero further explanation as to why this particular warning was issued – something as simple as a (?) button next to the warning with a link to a respective help file would be perfectly sufficient. But since there's zilch beyond the "DANGEROUS!!1!" warning, the likelihood that users are left confused and frustrated is much higher than it ought to be.
    2. macOS in general, with Gatekeeper, Notarization and XProtect in particular have no problem checking executables for a developer signature before running them for the first time, and/or flat-out preventing certain code from running at all. And so it ought to be trivial to simply prevent any executable from being launched from certain locales such as "/Library/Keyboard Layouts", for example. Among others, no keyboard layout, font, or preference file has any business being/containing an executable file, or calling such a file, for that matter.

    On my part at least, this is not so much a discussion over whether or not Apple chose the right approach to system security here, but more a point of "offer users more info if they want it" and "be consistent system-wide in what you allow/prevent". In terms of information hierarchy, Apple is leaving users hanging in a dead end here instead of guiding them to more information and/or a desired outcome. It's like filling out a web form, hitting submit, and then getting a stern warning with nothing else happening thereafter - on a detail scale, that is nothing short of bad information design.
     
    Last edited:
    G

    gregatron5

    Ars Legatus Legionis
    11,776
    Subscriptor++
  • #26
    I would bet the dire warning is for software defined keyboards, which, given Macs generally have hardware keyboards, are probably relatively unlikely to be used. That said, I could see how if AS-based macs can run iOS/ipadOS software, one might install something like the Bitmoji keyboard. Assuming that's possible, that is definitely more than a static mapping and could read and phone home what you type. Probably has to in order to work in some respects.
     
    • Like
    Reactions: The Limey and effgee
    I

    iljitsch

    Ars Tribunus Angusticlavius
    8,999
    Subscriptor++
  • #27
    effgee said:
    There is indeed such a thing as a capital 'ß'. World, meet 'ẞ', the latest craze in German spelling, introduced (AFAIK) in 2017, so a very recent addition.)
    Click to expand...
    With the font used by this forum the capital ß (LATIN CAPITAL LETTER SHARP S) shows as SS. In other fonts it's basically a fatter version of the original beta-like ß: ẞ.

    (For those who don't read/write German: it's generally fine to use ss rather than the ß symbol, like Friedrichstraße ↔︎ Friedrichstrasse.)
     
    effgee

    effgee

    Ars Praefectus
    4,373
    Subscriptor
  • #29
    iljitsch said:
    With the font used by this forum the capital ß (LATIN CAPITAL LETTER SHARP S) shows as SS. ...
    Click to expand...

    Are you sure you haven't at some point set a custom font for this forum? Because on my end, under macOS 15.2 (Firefox 134.0.2 and Safari 18.2), as well as the latest versions of iOS and iPadOS, the capital form of 'ß' does show up as its own, 'single' character 'ẞ'.

    Not that it matters much for regular folks like us, either way. AFAIK, the only reason the capital 'ß' was introduced in 2017 is for officiall documents like German passports or ID cards where names are spelled in all caps, and names like 'Meissner' are distinctly different from ones like 'Meißner'.

    capeszett.jpg
     
    effgee

    effgee

    Ars Praefectus
    4,373
    Subscriptor
  • #30
    gregatron5 said:
    I would bet the dire warning is for software defined keyboards, which, given Macs generally have hardware keyboards, are probably relatively unlikely to be used. That said, I could see how if AS-based macs can run iOS/iPadOS software, one might install something like the Bitmoji keyboard. Assuming that's possible, that is definitely more than a static mapping and could read and phone home what you type. Probably has to in order to work in some respects.
    Click to expand...

    I always thought it was a very odd choice on Apple's part to make something as integrally security-relevant as the on-screen keyboard accessible to 3rd-party binaries, while at the same arguing that allowing 3rd-party browser engines in iOS would threaten users' security... it's back to the whole consistency* malarkey.

    Apple: "Entering sensitive data into a web form using non-Apple browsers like Firefox is dangerous. Sorry Dave, we can't allow that."
    Apple: "Entering sensitive data into a web form using a 3rd-party keyboard app created by some shady dev is perfectly fine after we collect the 30% from the sale and have shown our users a warning they'll click tap away anyway."


    (* – or, IMO more likely, that the entire 'We're only doing this to make sure our users are safe, pinky-swear!' was merely a semi-pathetic fig leaf for: 'We DEFINITELY want the commission $$$ we can make off of developers of 3rd-party keyboard crap, but we're not interested in supporting/fielding calls related to free nonsense like Firefox that doesn't earn us a dime anyway.')
     
    • Like
    Reactions: gabemaroz
    A

    andrewme

    Senator
    7,080
    Subscriptor
  • #31
    gabemaroz said:
    This has to do with the nature of bundles on MacOS. For all intents and purposes they are considered executables in terms of system security and therefore may require explicit privileges depending on what level of access they require.


    There is no restriction (that I know of, someone correct me if I'm wrong) on where executable files can be placed in POSIX (e.g. Unix, Linux, MacOS, ...) compliant systems so long as those files have -x in their access control lists.

    Apple's security model regarding bundles is intentional and appropriate because they are an extraordinarily common attack vector.
    Click to expand...

    You're talking about application bundles specifically. Not all bundles are application bundles. If a macOS "Input Source" bundle were defined to be, say, a plist containing keyboard key mappings, documentation (possibly in multiple files for multiple languages), and an icon image, the framework that loaded it would look for those files and nothing else. Nothing would happen if you stuck a dylib or an executable or a kext or any other random file into the Input Source bundle - the input source handler would ignore the irrelevant files. It wouldn't try to load them into memory and run them. If you shove a command-line executable into a kext bundle, it won't get run when the kext gets loaded into the kernel, for example.

    This warning suggests (if it's not just an accidental copy from iOS) that Input Source implementations actually do intentionally support running code to handle key events (which could then send your keystrokes back to the developer). That does seem like overkill when a simple data plist (of what input maps to what output) would suffice, but maybe it's for more advanced Input Sources like handwriting recognition. Still it seems like they could have two classes of Input Source - one mapping-only, one with code - and only throw the scary warning on ones that actually contain code. Perhaps they decided it wasn't worth the trouble to make a distinction.
     
    I

    iljitsch

    Ars Tribunus Angusticlavius
    8,999
    Subscriptor++
  • #33
    effgee said:
    Are you sure you haven't at some point set a custom font for this forum? Because on my end, under macOS 15.2 (Firefox 134.0.2 and Safari 18.2), as well as the latest versions of iOS and iPadOS, the capital form of 'ß' does show up as its own, 'single' character 'ẞ'.
    Click to expand...
    Nothing is ever simple...

    It looks like the forum uses this system to show text in the system font. On this computer running MacOS 10.14 and Safari 14, this selects Helvetica Neue. Here capital ß shows as SS.

    But on my other laptop running MacOS 12 with Safari 17, capital ß shows as the fat ß. However... the font is also Helvetica Neue!

    Turns out on the older machine, Helvetica Neue is version 13.something from 2018, on the newer machine 17.something from 2021. So apparently some time between 2018 and 2021 Linotype got the memo about the new capital ß.
     
    • Like
    Reactions: VirtualWolf and effgee
    J

    jeanlain

    Ars Tribunus Angusticlavius
    6,841
  • #34
    andrewme said:
    This warning suggests (if it's not just an accidental copy from iOS) that Input Source implementations actually do intentionally support running code to handle key events (which could then send your keystrokes back to the developer). That does seem like overkill when a simple data plist (of what input maps to what output) would suffice, but maybe it's for more advanced Input Sources like handwriting recognition. Still it seems like they could have two classes of Input Source - one mapping-only, one with code - and only throw the scary warning on ones that actually contain code. Perhaps they decided it wasn't worth the trouble to make a distinction.
    Click to expand...
    That's what I was trying to say. The warning suggests that macOS can execute whatever code is in keyboard layout bundles.
     
    You must log in or register to reply here.
    Jump to latest Follow Reply
    Jump to latest Follow Reply