What stood out the most to me in this particular pop up was the wording. It seemed unusually natural speech. Do you known of any other places on iOS that have a similar feeling?
What prevents a non-fullscreen site from just faking a keyboard with `position: fixed; bottom: 0;`? Really weird stance they're taking here. Kind of excludes an entire class of web applications (full screen games) from being usable on iPad, almost as if the real motivation is to drive you to the app store...
What prevents them is that it'd be within the confines of a website, so url bar tells you you're on a website & not the appstore asking for permission
This gets into sandboxes needing to have "sacred pixels" as a border to prevent the sandbox tricking the user into thinking they exited from the browser
This issues goes way back: imagine if after executing a program on CLI instead of closing it gave you a fake shell, where you eventually went about your day until you had to type your password into sudo..
Of course, your point about the app store is good motivation to address this, whereas consoles don't go about offering much protection there
Is this even the case anymore? On Android, all my URL bars peel up into the top of the screen as I browse, and I'm pretty sure a website can capture the vertical swipe/arrange an inner-scrolling element to make it very difficult to quickly get the URL bar visible again.
I think that would be enough to trick most users. This seems like an unnecessary limitation
> This issues goes way back: imagine if after executing a program on CLI instead of closing it gave you a fake shell, where you eventually went about your day until you had to type your password into sudo..
As a fun fact, even worse might be a program maliciously aliasing sudo in ~/.profile
They'd have to know to look for it, but running `alias sudo` would show if it had an alias assigned to it. It would honestly be more effective to change $PATH to include the malicious version of sudo.
Which is a good reminder that password entry is terrible security wise. With macOS, you can sudo authenticate with your Apple Watch, which is really nice.
If you're concerned that a script's root password prompt may be a forgery, you can run "sudo -v" before executing the script.
For background, there is a convenience feature in sudo: It only requires your password prompt if you have not had a successful sudo invocation in the same terminal in the last X minutes (5 minutes, I think? not sure on the exact value). "sudo -v" is a special invocation which does not actually execute any command, but it renews your 5-minute lease. ("sudo true" is effectively equivalent, though not idiomatic.)
So if you're executing a short script that needs sudo, run "sudo -v" before running the actual script. Then you know that if a root password prompt pops up again, it's not really sudo who's asking.
> If you're concerned that a script's root password prompt may be a forgery, you can run "sudo -v" before executing the script.
The bigger problem is that even without sudo or your root password, malicious scripts can do a lot of damage. ie. they can add a fake sudo to your .profile, so you next time you try to do "sudo -v" your password still gets stolen.
Fair enough. An attacker wouldn’t need to fake your keyboard though, it’s probably just enough to trick you into thinking you are entering sensitive information into a legit website while in reality it’s made to look that way but still using normal text inputs.
1. The username/password form of your bank, as shown in your browser.
2. A pixel-perfect fake of your bank as it would look if you were to go there directly in your browser, including the browser UI, except you’re actually looking at a full-screen image displayed on a random scammer website, and you already were in the fake when you typed the bank domain name into the fake address bar on the fake UI.
Because your hypothetical is something a user can learn to avoid, whereas my hypothetical is one where literally no user could distinguish real from fake without assistance from the OS or the browser.
Plaid is a valid service that helps glue bank APIs together. Why should it be avoided?
I am not arguing your point strictly. But the problem in general can only really be solved with education. Users should always know who they’re giving credentials to. A technical measure like not allowing keyboard input in a full screen browser is a leaky stop gap. The full screen app could just as well show its own pixel perfect full screen keyboard and trick users to tap it.
If you care about security, yes. It operates identically to a phishing service, complete with a logos/imagery to suggest you're sending your credentials to your bank rather than a third party. What's worse is that as far as the user's concerned, they're inputting their credentials into the consumer site[1], as you can see in the demo: https://plaid.com/demo. This is as opposed to something like google oauth where you enter your credentials on accounts.google.com only.
[1] ie. you're on site A, which wants access to your account details on bank X. when you're entering your details, the address bar shows site A's domain, not plaid.com or bank X.
I guess I would say it the other way around: phishing services operate identically to legit services. If we outlaw everything that someone has attempted to phish we’ll eventually have nothing.
If a user trusts plaid to handle their credentials, so be it.
On the Mac, you can switch desktops even while YouTube is full screen. In that case, YT just shows up as an additional desktop in the switcher. I wonder if this YT "feature" would react against doing that.
It doesn't if you have dual monitors and are typing on the other, which I do rather often.
I'm not particularly inclined to reconfigure to see if that's still the case when switching desktops on a single-monitor setup, since OSX mangles the desktop layouts if you unplug a monitor and reboot.
Such a pointless popup. We enter personal information into websites every day. Want to prevent this from happening? Make it the home page for every browser.
I agree it feels rather dated. Can’t hurt to have it I guess, also I couldn’t manage to trigger it a second time after choosing to stay in full screen. Could be that now Safari remembers my choice for youtube.com.
I’ve seen this pop up a few times, usually when scrubbing video. I thought it previously gave you the option to continue so maybe it’s changed a bit.
I think it’s not a bad idea in terms of security, and likely its a response to an actual attack vector. But maybe there should be a way to disable it for specific sites or just have a warning bar.
Interesting. I didn’t know you could trigger it by scrubbing, did you use your finger? This pop up showed up while I was randomly tapping the screen with the Apple Pencil.
Mentioned in another comment but this message showed up while watching a Youtube video in Safari on iPadOS 14.5. It was triggered by tapping the screen a few times with an Apple Pencil 2nd generation, I didn’t manage to make it show up a second time after choosing to stay in full-screen.
Modern computing is in need of the "Secure Attention Key" concept. A dedicated user input which deliberately has no other function than to escape any kind of virtualization or input capture, and ensure that subsequent communications goes directly to a trusted part of the operating system.
Doesn't Ctrl+Alt+Delete still serve this function pretty well on Windows? I'm not sure how impossible it is to block/bypass, but it seems to almost always work despite input capturing.
Perhaps the (non-fullscreen) user interface shouldn't be the only recognizable visual cue which the user depends on before proceeding to trust their computer.
Maybe, instead, there ought to not be 'sacred pixels' on the screen, but a secret image to be displayed to the user (which only they recognize and can perhaps even change over time), and only the user, alongside every prompt for user input.
Admittedly, this could engender a false sense of trust if the secret image is ever compromised. I think there is an architecture around this, though.
The daemon providing the secret image service could simply stop screen sharing applications from reading those pixels. Why not expose the screen as a virtual filesystem, where every pixel has mutable unix permissions? Then, in any secure system, the screen sharing services would merely need to be served its pixels by the secret image server. The secret image server then just has to preserve the condition that programs aren't served secret pixels if they aren't run by a user in the 'secret pixel' entry in /etc/group. Then it would just be a matter of (secret) pixel files remaining unreadable for untrusted programs.
This could require some deep hooks into the display system, though, considering that a lot of graphical programs are going to be running on the video driver (well, technically, all of them). I suppose another reason to care about open source and graphics.
I wonder as well if Rio from Plan 9 can accomplish this with a minimal amount of code, since Rio already serves windows through a file server!
This has been tried in the past, I remember when Yahoo had a system to put a secret image on their login page with the exact same sort of goal (avoid phishing). Regular people don't use/understand such a system (enough to make it worthwhile).
52 comments
[ 2.8 ms ] story [ 15.4 ms ] threadThis gets into sandboxes needing to have "sacred pixels" as a border to prevent the sandbox tricking the user into thinking they exited from the browser
This issues goes way back: imagine if after executing a program on CLI instead of closing it gave you a fake shell, where you eventually went about your day until you had to type your password into sudo..
Of course, your point about the app store is good motivation to address this, whereas consoles don't go about offering much protection there
Is this even the case anymore? On Android, all my URL bars peel up into the top of the screen as I browse, and I'm pretty sure a website can capture the vertical swipe/arrange an inner-scrolling element to make it very difficult to quickly get the URL bar visible again.
I think that would be enough to trick most users. This seems like an unnecessary limitation
As a fun fact, even worse might be a program maliciously aliasing sudo in ~/.profile
But then again how, how someone know if that happened!
For background, there is a convenience feature in sudo: It only requires your password prompt if you have not had a successful sudo invocation in the same terminal in the last X minutes (5 minutes, I think? not sure on the exact value). "sudo -v" is a special invocation which does not actually execute any command, but it renews your 5-minute lease. ("sudo true" is effectively equivalent, though not idiomatic.)
So if you're executing a short script that needs sudo, run "sudo -v" before running the actual script. Then you know that if a root password prompt pops up again, it's not really sudo who's asking.
The bigger problem is that even without sudo or your root password, malicious scripts can do a lot of damage. ie. they can add a fake sudo to your .profile, so you next time you try to do "sudo -v" your password still gets stolen.
Every "security" feature on Safari points into harming web apps so you are on the right tracks...
"youtube.com" could show you a fake keyboard anyways and why can't it trick you with a real keyboard.
1. The username/password form of your bank, as shown in your browser.
2. A pixel-perfect fake of your bank as it would look if you were to go there directly in your browser, including the browser UI, except you’re actually looking at a full-screen image displayed on a random scammer website, and you already were in the fake when you typed the bank domain name into the fake address bar on the fake UI.
I am not arguing your point strictly. But the problem in general can only really be solved with education. Users should always know who they’re giving credentials to. A technical measure like not allowing keyboard input in a full screen browser is a leaky stop gap. The full screen app could just as well show its own pixel perfect full screen keyboard and trick users to tap it.
You should’ve led with that, it’s a much better question than your others on this thread.
[1] ie. you're on site A, which wants access to your account details on bank X. when you're entering your details, the address bar shows site A's domain, not plaid.com or bank X.
If a user trusts plaid to handle their credentials, so be it.
It doesn't if you have dual monitors and are typing on the other, which I do rather often.
I'm not particularly inclined to reconfigure to see if that's still the case when switching desktops on a single-monitor setup, since OSX mangles the desktop layouts if you unplug a monitor and reboot.
What version are you running, I'm running catalina.
I think it’s not a bad idea in terms of security, and likely its a response to an actual attack vector. But maybe there should be a way to disable it for specific sites or just have a warning bar.
Maybe, instead, there ought to not be 'sacred pixels' on the screen, but a secret image to be displayed to the user (which only they recognize and can perhaps even change over time), and only the user, alongside every prompt for user input.
Admittedly, this could engender a false sense of trust if the secret image is ever compromised. I think there is an architecture around this, though.
The daemon providing the secret image service could simply stop screen sharing applications from reading those pixels. Why not expose the screen as a virtual filesystem, where every pixel has mutable unix permissions? Then, in any secure system, the screen sharing services would merely need to be served its pixels by the secret image server. The secret image server then just has to preserve the condition that programs aren't served secret pixels if they aren't run by a user in the 'secret pixel' entry in /etc/group. Then it would just be a matter of (secret) pixel files remaining unreadable for untrusted programs.
This could require some deep hooks into the display system, though, considering that a lot of graphical programs are going to be running on the video driver (well, technically, all of them). I suppose another reason to care about open source and graphics.
I wonder as well if Rio from Plan 9 can accomplish this with a minimal amount of code, since Rio already serves windows through a file server!