It doesn't log passwords using EnableSecureEventInput.
There are probably other use cases, but Apple seems to have implemented things rather well here.
Yes I once spent a whole day debugging an issue related to this because I was unaware of it. I was getting a game Steam ready and I was working on the Steam overlay that is triggered by the tab key.
QA reported that on the login screen, you sometimes had to press tab twice to get the overlay to open. Just on that one screen.
I had a piece of code that was looking for the tab keydown event to open the overlay, but in some cases the event was not being triggered. Turned out that the browser password field used EnableSecureEventInput and so the if the cursor focus was in the password input box, the tab button press would not be detected by my code. Pressing it twice worked because:
-first tab press moved cursor focus out of the password box
-second tab press was in the username input field which was not a secure input field, so my code received the tab keydown event.
The weird part about this is since the tab keydown moves the cursor focus out of the secure text box what you receive is a tab keyup event with no keydown before it.
Yes, you could detect the condition by tracking key-up events without matching keydown events, so I wrote a little logic that would keep track of tab keyup-keydown states and with that I could detect it.
The cause for both of these is that my mobile HN experience is horrible for me (a lazy person).
I spent a few seconds looking for a word to replace "She/He", when none came to mind I fell back to a regular expression[1]. As iaml pointed out[2] (along with others) https://en.wikipedia.org/wiki/Singular_they is the proper solution to this issue, and I will try to remember that in the future.
In my second attempt at comedy today, Trying to perform the error-prone art of interpreting genders based on usernames, the best I came up with for you is
/^\0_$/
Feedback welcome, this is my first attempt at matching null in a regular expression.
I'll explain the joke, so that no-one feels left out: I interpret name "Void" as gender "null", then carry the underscore over, using artistic license, to make the regex more interesting.
It would be nice if macOS had the same permissions models as iOS, and then some. A permission before apps can access the camera, or access what keys are held down when the app isn't in the foreground - that would block this case.
Yes, it would be very nice if operating systems had a sane (let alone user-friendly!) way to properly, thoroughly sandbox userland applications.
It's a large reason why "web applications" became a thing -- it gives you sandboxed remote programs (and easy-access to boot!) Even if the web-browsing sandbox is flawed, it's been a convenient band-aid over a fundamental OS feature that, sadly, still doesn't properly exist.
macOS has sandboxed apps, with the same underlying model as iOS (not sure if it asks for camera permissions and such, but apps declare a list of “entitlements” and are granted only those). It’s required for App Store apps, but other than that it’s opt-in. Outside of the App Store, basically it’s just something like DEP or ASLR: a mitigation that isn’t really visible to users unless they look for it.
That's not the problem. The problem is that the whitelist of permissions is limited, fixed, i have no control over it and i can't easily work around it.
I can't create a great way to batch install/update/migrate my phone because everything requires manual approval.
I can't use my own browser or sms app on ios cause it's not allowed by the permissions system.
I can't install a new driver on my phone.
Remember the bs update apple did that broke the home button, forcing people to buy a new phone ? I can't prevent that either.
I'm actually for permissions and sandboxes for most apps. But i want a manual override when i need one.
Not on ios though. See, the problem is not the permissions, but the fact you are at their mercy. And because by definition innovations assume you have nit thought of it before, this will limit innovation.
Is there (or was there every) any OS app store that allowed an app to go trawling through another apps's memory? Or if you don't want to be that radical, one that at least allows overlays.
Plenty of apps on Android are allowed to draw over other apps (e.g. Facebook messenger, Lux Auto Brightness). There are also apps that use the accessibility APIs to determine what the user is seeing (e.g. LastPass with AppFill enabled).
I think both of these features require explicit manual permissions (i.e. having to go to the system settings and whitelist the app) to be enabled. Also Android permission dialogs refuse to pop up if there is an untrusted screen overlay (which meant that my experience with Lux when with other apps' permission dialogs involved either manually disabling the virtual screen brightness adjustment or having it automatically disabled temporarily, which resulted in unpleasant surprises while using the phone at night).
I'm not sure I buy that requiring user opt-in to camera access is why the Mac app ecosystem is is much larger than that of iOS. Can you elaborate on what apps/innovations would become impossible because of a mandatory opt-in? I cannot think of any...
Everything that is either very low level or is used for deep introspection of other parts of the system.
I'm not against sandboxing, but if there should be a way to say i know what i'm installing, go with it. Otherwise you will say good bie to new ways of debugging, alternative drivers, unusual way of routing network packets, innovative UI interactions that are not part of the standards widgets, or anything you haven't think of yet.
The computing experience you have today is the result of all the stuff we fiddle with for the last 30 years because it was allowed to. It would be foolish thz big players invented most of it.
The problem with an opt-in system is that you have to sandbox the whole app (otherwise, evading the opt-in would be trivial) and therefore lock out any advanced access not explicitly listed as an opt-in permission.
If you want an example, there's F.lux, which doesn't work (without rooting) on Android and iOS.
No you can't. You just have a very limited way to use it. Even with the same screen size, give me a laptop os and i'll be more productive, with a factor of 10. It's not a figure of style. Phone os are terribly limited.
So, without rooting or plugging your phone into a real computer you can:
Run a database ? (good luck running postgres with the OS killing processes all the time)
Run docker ?
Taking screen captures anywhere ? (this one actually got me yesterday while trying to screen capture netflix on my one plus 3)
Run f.lux ?
Run one virtual machine with windows on it ?
Capture 3G traffic with wireshark ?
Install a driver to read a USB key in another partition format not allowed by the OS ?
Bypass DRM ?
Resize partitions to get a dual boot ?
Run Wine ? (and they tried hard. Since fosdem 2014 at least)
Install patches as soon as a vulnerability is discovered, and not waiting on your phone seller to wake up ?
And if you just consider iOS, it's way, way worse. At least on android you have access to part of the filesystem.
The thing is, in computing, nothing works exactly right. And with my laptop, I have always a way to work around problems. With phones, I'm just stuck with it. Multitasking sucks. Automation is terrible. You may install a GNU env, but it has access to so little you can't script your way out of anything.
Depends on workflow and apps. iPad OS has made steady progress. If Apple allowed advanced users to manually override permissions, they would gain data to help the OS to evolve much faster. See landscape architects’ experience with human foot paths.
> but Apple seems to have implemented things rather well here.
Reading up on it further [0] it seems you could write an anti-keylogger. Just have an app that calls EnableSecureEventInput and never disables it and no other processes would be able to capture key input:
"The system will no longer pass keyboard intercept processes keyboard events if your process has enabled secure input even when your process is moved to the background. It now becomes your process' responsibility to call DisableSecureEventInput when secure entry input is not required, such as when your process detects that it is moving to the background."
So are there any keyloggers for MacOS in the wild that still manage to capture keystrokes with EnableSecureEventInput, or can I consider this as "secure"? Also, is there a way to tell when/for which processes EnableSecureEventInput is active?
Chromebooks are disappointing because they can have great hardware but you need to jump though hoops to install any real software, and even that's sketchy depending on the model.
Please articulate your concerns with this. Is it because it's copyrighted? I think most open source software is under copyright; but the license (MIT in this case) grants end-users certain rights that can be revoked if that license is broken.
Hey. Sorry, it appears that I am totally wrong. I just assumed that those statements were totally conflicting, but ten seconds on Google tells me that’s not so.
Yeah usually open source software grants some permissions but retains copyright ownership. This somewhat disallows abuse of Open Source projects, and is probably part of what makes something like the GPL enforceable in court. IANAL
No, you're reserving all rights that a copyright indicates and then granting specific exceptions (i.e. "I won't enforce my copyright against you if you follow these rules") without giving up those rights
