[HN Gopher] Looks like you are typing while in full screen
___________________________________________________________________
Looks like you are typing while in full screen
Author : jereees
Score : 90 points
Date : 2021-04-24 16:39 UTC (6 hours ago)
(HTM) web link (imgur.com)
(TXT) w3m dump (imgur.com)
| jereees wrote:
| 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.
| ogre_codes wrote:
| 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.
| jereees wrote:
| 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.
| ogre_codes wrote:
| Yes, but it could have been that I was tapping to specific
| portions of the time line. I can't honestly recall if I was
| tapping or sliding or both.
| ksaj wrote:
| 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.
| spicybright wrote:
| For myself, macos is really good about monitor layouts and
| keeping everything the same when plugging/unplugging monitors.
|
| What version are you running, I'm running catalina.
| oakwhiz wrote:
| 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.
| spijdar wrote:
| 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.
| spicybright wrote:
| In my experience, generally yes. It's a good escape hatch to
| unstuck a system.
| gulbanana wrote:
| This feature has existed for several years.
| jereees wrote:
| 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?
| beirut_bootleg wrote:
| 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.
| jereees wrote:
| 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.
| akersten wrote:
| 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...
| klyrs wrote:
| On my phone, I use an obscure keyboard with a custom theme --
| good luck faking that. Doesn't help your average user, though.
| jereees wrote:
| 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.
| jtth wrote:
| URL bar at the top, UI chrome is different in full screen vs
| windowed. (Full screen media playback on iOS has OS-level
| controls at the top.)
| realusername wrote:
| > almost as if the real motivation is to drive you to the app
| store...
|
| Every "security" feature on Safari points into harming web apps
| so you are on the right tracks...
| __s wrote:
| 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
| toxik wrote:
| 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.
| majewsky wrote:
| 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.
| gruez wrote:
| > 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.
| jereees wrote:
| Is this a feature built in into the OS? I have only heard
| of some third party code to allow that...
| akersten wrote:
| > , so url bar tells you you're on a website
|
| 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
| saurik wrote:
| This is iOS, though, where the URL bar is always at least
| minimally present.
| t0mas88 wrote:
| On safari, but not on for example Edge for iOS or Chrome
| for iOS.
| ogre_codes wrote:
| Is this security feature present on Edge or Chrome on
| iOS?
| jereees wrote:
| Huh. I'm surprised apple didn't make it a requirement
| before approving those apps into their store given how
| strong their stance on privacy is.
| rsa25519 wrote:
| > 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
| spicybright wrote:
| That's a spooky one, although I've never heard of that
| happening in practice before.
|
| But then again how, how someone know if that happened!
| chmod775 wrote:
| This makes no sense any way I look at it.
|
| "youtube.com" could show you a fake keyboard anyways and why
| can't it trick you with a real keyboard.
| ben_w wrote:
| Two situations, how do you distinguish them?:
|
| 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.
| dcow wrote:
| How about a site that says it will help you log into your
| bank and secure your bank credentials?
| ben_w wrote:
| 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.
| dcow wrote:
| What about Plaid? Should users avoid that?
| gruez wrote:
| 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.
| guipsp wrote:
| ...Yes? The point is that you should be aware of who
| you're giving your information to.
| dcow wrote:
| 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.
| ben_w wrote:
| > 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.
| dcow wrote:
| Exactly, it could just show a real keyboard, tell you it's got
| a new discount partnership with Pornhub premium and catch you
| trying to log in.
| tedunangst wrote:
| And it will say youtube.com at the top of the screen, which my
| real bank app does not.
| dcow wrote:
| Isn't this an accessibility concern for someone who isn't able to
| interact with a touch screen?
| tedunangst wrote:
| If you're unable to interact with a touch screen, you're
| unlikely to trigger the popup for typing on the touch screen.
| jereees wrote:
| You're forgetting about dictation and head-based input
| controls.
| tedunangst wrote:
| Your dictation input is unlikely to trigger the typing on
| touchscreen pop up.
| spicybright wrote:
| And you can always hit system buttons anyways with
| accessibility tools.
___________________________________________________________________
(page generated 2021-04-24 23:02 UTC)