10 ms·

Chrome 97 is coming today with controversial Keyboard API feature

38 points by gardaani 5y ago

The_rationalist 5y ago
The keyboard api enable to fix vh unit on smartphones
- Tajnymag 5y ago
  How?
  - The_rationalist 5y ago
    I was not referring to this keyboard api but to another one that is coming very soon. It will allow to detect the event of a virtual keyboard being triggered, which allow the app to take into account the resize of its vh units. Maybe it also allow to make the virtual keyboard be above the viewport and therefore not affect it, I don't remember. Vh has other issues on mobile though.
krono 5y ago
With the conflict of interest being so obvious, the market share so massive, and the amount of controversial decisions increasing both in number and impact - isn't it about time for authorities to put some oversight and controls in the Chrome product management processes? Edit: And the same applies to Edge, they shouldn't be let off the hook.
- pjmlp 5y ago
  Meanwhile devs keep pushing Chrome disguised as Electron apps.
ksec 5y ago
It is obvious that "Web Page" with interactivity and "Web Apps" are two different things and have conflicting interest.
- remus 5y ago
  Personally I don't think it's that obvious. It seems more like a spectrum of functionality from static html pages to something like google maps, with most things sitting somewhere in the middle.
- danShumway 5y ago
  My obligatory crusade: most apps, including native apps, are just interactive documents and there would be strong benefits to everyone if they moved in that direction more explicitly. Some exceptions exist of course. But a surprisingly large number of apps on my computer are just XML trees (or could be represented that way) when you really dig into them. I want my keyboard settings to work the same way in documents and in the vast majority of the applications I run. I want to be able to query pure-text representations of state in applications, not just in documents. With some minor exceptions, I want standardized controls across most of my OS, including in web apps. In regards to privacy, I don't want applications to fingerprint me. I have capabilities that I'd like to turn on for some apps, but I don't want them all to be on by default for every app. The system shouldn't be "you're either static content, or you can do anything you want." All of my privacy/security concerns about documents also apply to apps; most applications I use don't need access to things like fullscreen, NFC, mouse control, etc. Some do, and I want them to work, but I shouldn't need to grant access to every application across the board for that. I think the division between apps and documents is largely fictional; it's a spectrum, not a hard line, and most "apps" are still fundamentally closer to documents than they like to admit, even in their flashy interactive forms with animations and user-state, and could benefit from the same kinds of standardization and sandboxing that documents enjoy. I don't think we should be separating out a category of websites (or native programs for that matter) where we say that anything goes just because they're "apps", I think that masks the problem that sandboxing is a UX/architecture issue everywhere across the entire spectrum.
iqanq 5y ago
>As such, the API change has been classified as "harmful" by Apple and Mozilla, and will not be implemented in Safari and Firefox, respectively. Then people here will say that google docs doesn't work well on firefox because google is sabotaging firefox.
- danShumway 5y ago
  I'm not sure as a user I would ever want Google Docs to ever handle shortcuts based on physical key locations instead of using OS conventions? I don't really use Google Docs, what does it do today with alternate layouts? My understanding was that (unless the user rebound them) DVORAK defaults for stuff like copy/paste were still ctrl-c, ctrl-v in most native apps.
  - deleted 5y ago
    [deleted]
- ohgodplsno 5y ago
  Google going their own way to be the only ones to implement a very specific API that every other member of the WHATWG has decried? Yeah that's Google sabotaging others as is usual. Why are you pretending it's not?
leecommamichael 5y ago
The kind of spyware they’re imagining has been possible since the beginning of personal computers. Given the critics understand this, do they believe the required knowledge to write a native app is too obscure at this point to be considered harmful? I say this because the measurable difference between a desktop keylogger and this is having to run the downloaded program manually. Heck I bet a lot of keyboard manufacturer’s “drivers” do this today.
- hyperman1 5y ago
  The thread model is different. On PCs, there was no fast/commercialized enough internet to worry much about spyware. What good is fingerprinting if you can't send the result to a server. What good is tracking every individual if nobody will pay you to send ads? Notice in the same way how good old IE6 with ActiveX was horribly insecure, but it didn't matter as much until the Internet itself became an ad-infested environment. Desktop software could theoretically do a lot of harm in the past, but there was no point apart from childish damage. Viruses were more a kind of graffiti. Ransomware did not exist, there was no way to pay the ransom. I don't like how e.g. Wayland pulls up high walls between software. Applications work best when they can easily share data, including robotic automatization, keylogging and screen recording. But it seems that innocent time is simply gone. Even major software companies shamelessly piss in the well by deploying trackers and malware together with their software. So I hate to say it but the wayland devs are probably doing it right.
- danShumway 5y ago
  > do they believe the required knowledge to write a native app is too obscure at this point to be considered harmful? No, but user expectations about safety between native apps and web apps are different. I will say that, personally, I think that native apps place far too little emphasis on security/fingerprinting, and I think that we're kind of ignoring a serious problem with the lack of default sandboxing for native apps. I don't know that it makes sense for every native app on my computer to have this kind of capability. I think most of the native apps on my computer shouldn't be able to access the Internet at all if I'm being honest. But that's just my personal opinion, other people have different approaches/philosophies about software -- and disregarding my own preferences, I think it makes a lot of sense to worry more about fingerprinting in an environment like the web where people are running a lot more untrusted code than they normally would. The web has kind of been a boon for native security, it's really good that users have a quick way to run code that doesn't involve download software and giving it access to their filesystem. It significantly lowers the number of opportunities for attacks. But that only works if the alternative to native apps is both: A) useful enough that users can commonly use it as an alternative to downloading software and running it on their filesystem B) sandboxed enough that it's not just equivalent security-wise to downloading software and running it on a native filesystem. Figuring out how to strike a balance between those two concerns is why thinking about security/fingerprinting on the web is hard.
danShumway 5y ago
I'm sure there is a use-case for this, but normally when I look at controversial Chrome features it's immediately obvious why I'd want them (risks aside), or at least why someone would want them -- but with this feature I'm having a hard time imagining what I'd ever build that would want to use it. Going off of physical locations of keys is pretty bad UX practice for shortcuts as far as I know; we pretty much always want keys to be remappable either in software or at the OS level. Games spring to mind (WASD), but games definitely want remappable keys, and it's not clear to me that this (to use a Chrome term that I kind of like) is encouraging developers to fall into a "pit of success" in regards to gaming and user controls. This has popped up occasionally for me where gamepads are concerned -- it's nice to be able to provide a sensible default when someone plugs in a controller. But in that situation I care more about just having a default layout then I care about knowing the specific key that was pressed. In that scenario what I actually want is a gamepad "type" string that I can just map to a list of defaults I've pre-configured for that specific gamepad type. In fact, the more I think about it, getting a key code is almost the opposite of what I want in that situation since different gamepads have different norms about what locations should do what and are shaped differently, there isn't a universal map. It's explicitly the wrong decision for me to say that the top button on the right hand side of a gamepad will always do one thing, because that's going to breaking norms on different controllers. And it seems like keyboards are kind of the same? I sort of see the value of a keyboard being able to signal a common layout that has different default shortcuts, but I'm having a really hard time thinking beyond that why I would want to as a dev override normal shortcuts. Okay, sure, it would be nice to query that a keyboard is in AZERTY layout and suggest different shortcuts. Beyond that? Enough people have asked for it that it must have a use, but even from a gamedev perspective this seems like a strange API to me. The privacy angle is one thing, but I also just have an instinct that this is probably not a behavior that users want from applications. They probably want Internet applications to respect their shortcuts instead of overriding them. And they probably want games to avoid forcing controls based on physical locations of buttons. ---- From the Github spec: > E.g., If a game supports the standard WASD keys (to move up/left/down/right), then the instructions for the game need to be able to tell the user which keys to press. On a US-English keyboard, they are 'W', 'A', 'S', 'D', but for French (AZERTY) layout the user would be told to use 'Z', 'Q', 'S', 'D'. [...] > Some applications make use of keyboard shortcuts that are based on the position of the key rather than the symbol that is generated. [...] > E.g., a drawing app may have a number of drawing modes arranged from left to right on the screen and may wish to have keyboard shortcuts that correspond to the screen position. I don't know, maybe I'm being unimaginative. But I've dealt with at least the first problem here, and I don't think that keymaps are necessarily the best way to solve it. Also, if we're talking about games we should be coming up with a solution that maps to controllers as well, so I don't really get why we're going down this specific route. And the second two use-cases seem like user accessibility bugs, not features. I guess enough devs want it that Chrome is implementing it, but I feel like there's something I'm missing. As a user, I want a user-controlled (or at least OS-controlled) layer between myself and app shortcuts/keycodes; it's super useful and I customize that layer all the time, even for simple things like rebinding caps-lock. And as a dev I'd rather not have to try and intuit what setup a user has based on physical locations. Heck, maybe someone toggles into a different layout to game and they use IJKL to move around when they're playing web games. Maybe their W key is broken and it's bad for me to try and force them to use that specific physical button. I don't want to have to think about any of that as a dev, just have the OS signal to me what keys they want me to think they pressed. And if they can signal to me a common string for the overall layout that allows me to give them a sensible default, then great, I'm happy to do something like that. But this feature doesn't seem to make any of that easier, it just gives me a granular map for individual keys and then makes it my problem to interpret. :shrug: I don't know, maybe there's some nonsense with native behavior that we're trying to match or something. I customize my keyboard layout a lot, but I've never jumped to DVORAK/AZERTY, maybe there's a lot of weirdness with shortcuts there that native apps expect to just paper over, where they bypass the layout? But I'm not really seeing that online?
poetril 5y ago
Does anyone know if Edge/Brave will be implementing this?

38 points by gardaani 5y ago

The_rationalist 5y ago

The keyboard api enable to fix vh unit on smartphones

Tajnymag 5y ago
How?
- The_rationalist 5y ago
  I was not referring to this keyboard api but to another one that is coming very soon. It will allow to detect the event of a virtual keyboard being triggered, which allow the app to take into account the resize of its vh units. Maybe it also allow to make the virtual keyboard be above the viewport and therefore not affect it, I don't remember. Vh has other issues on mobile though.

krono 5y ago

With the conflict of interest being so obvious, the market share so massive, and the amount of controversial decisions increasing both in number and impact - isn't it about time for authorities to put some oversight and controls in the Chrome product management processes? Edit: And the same applies to Edge, they shouldn't be let off the hook.

pjmlp 5y ago
Meanwhile devs keep pushing Chrome disguised as Electron apps.

ksec 5y ago

It is obvious that "Web Page" with interactivity and "Web Apps" are two different things and have conflicting interest.

remus 5y ago
Personally I don't think it's that obvious. It seems more like a spectrum of functionality from static html pages to something like google maps, with most things sitting somewhere in the middle.
danShumway 5y ago
My obligatory crusade: most apps, including native apps, are just interactive documents and there would be strong benefits to everyone if they moved in that direction more explicitly. Some exceptions exist of course. But a surprisingly large number of apps on my computer are just XML trees (or could be represented that way) when you really dig into them. I want my keyboard settings to work the same way in documents and in the vast majority of the applications I run. I want to be able to query pure-text representations of state in applications, not just in documents. With some minor exceptions, I want standardized controls across most of my OS, including in web apps. In regards to privacy, I don't want applications to fingerprint me. I have capabilities that I'd like to turn on for some apps, but I don't want them all to be on by default for every app. The system shouldn't be "you're either static content, or you can do anything you want." All of my privacy/security concerns about documents also apply to apps; most applications I use don't need access to things like fullscreen, NFC, mouse control, etc. Some do, and I want them to work, but I shouldn't need to grant access to every application across the board for that. I think the division between apps and documents is largely fictional; it's a spectrum, not a hard line, and most "apps" are still fundamentally closer to documents than they like to admit, even in their flashy interactive forms with animations and user-state, and could benefit from the same kinds of standardization and sandboxing that documents enjoy. I don't think we should be separating out a category of websites (or native programs for that matter) where we say that anything goes just because they're "apps", I think that masks the problem that sandboxing is a UX/architecture issue everywhere across the entire spectrum.

iqanq 5y ago

>As such, the API change has been classified as "harmful" by Apple and Mozilla, and will not be implemented in Safari and Firefox, respectively. Then people here will say that google docs doesn't work well on firefox because google is sabotaging firefox.

danShumway 5y ago
I'm not sure as a user I would ever want Google Docs to ever handle shortcuts based on physical key locations instead of using OS conventions? I don't really use Google Docs, what does it do today with alternate layouts? My understanding was that (unless the user rebound them) DVORAK defaults for stuff like copy/paste were still ctrl-c, ctrl-v in most native apps.
- deleted 5y ago
  [deleted]
ohgodplsno 5y ago
Google going their own way to be the only ones to implement a very specific API that every other member of the WHATWG has decried? Yeah that's Google sabotaging others as is usual. Why are you pretending it's not?

leecommamichael 5y ago

The kind of spyware they’re imagining has been possible since the beginning of personal computers. Given the critics understand this, do they believe the required knowledge to write a native app is too obscure at this point to be considered harmful? I say this because the measurable difference between a desktop keylogger and this is having to run the downloaded program manually. Heck I bet a lot of keyboard manufacturer’s “drivers” do this today.

hyperman1 5y ago
The thread model is different. On PCs, there was no fast/commercialized enough internet to worry much about spyware. What good is fingerprinting if you can't send the result to a server. What good is tracking every individual if nobody will pay you to send ads? Notice in the same way how good old IE6 with ActiveX was horribly insecure, but it didn't matter as much until the Internet itself became an ad-infested environment. Desktop software could theoretically do a lot of harm in the past, but there was no point apart from childish damage. Viruses were more a kind of graffiti. Ransomware did not exist, there was no way to pay the ransom. I don't like how e.g. Wayland pulls up high walls between software. Applications work best when they can easily share data, including robotic automatization, keylogging and screen recording. But it seems that innocent time is simply gone. Even major software companies shamelessly piss in the well by deploying trackers and malware together with their software. So I hate to say it but the wayland devs are probably doing it right.
danShumway 5y ago
> do they believe the required knowledge to write a native app is too obscure at this point to be considered harmful? No, but user expectations about safety between native apps and web apps are different. I will say that, personally, I think that native apps place far too little emphasis on security/fingerprinting, and I think that we're kind of ignoring a serious problem with the lack of default sandboxing for native apps. I don't know that it makes sense for every native app on my computer to have this kind of capability. I think most of the native apps on my computer shouldn't be able to access the Internet at all if I'm being honest. But that's just my personal opinion, other people have different approaches/philosophies about software -- and disregarding my own preferences, I think it makes a lot of sense to worry more about fingerprinting in an environment like the web where people are running a lot more untrusted code than they normally would. The web has kind of been a boon for native security, it's really good that users have a quick way to run code that doesn't involve download software and giving it access to their filesystem. It significantly lowers the number of opportunities for attacks. But that only works if the alternative to native apps is both: A) useful enough that users can commonly use it as an alternative to downloading software and running it on their filesystem B) sandboxed enough that it's not just equivalent security-wise to downloading software and running it on a native filesystem. Figuring out how to strike a balance between those two concerns is why thinking about security/fingerprinting on the web is hard.

danShumway 5y ago

I'm sure there is a use-case for this, but normally when I look at controversial Chrome features it's immediately obvious why I'd want them (risks aside), or at least why someone would want them -- but with this feature I'm having a hard time imagining what I'd ever build that would want to use it. Going off of physical locations of keys is pretty bad UX practice for shortcuts as far as I know; we pretty much always want keys to be remappable either in software or at the OS level. Games spring to mind (WASD), but games definitely want remappable keys, and it's not clear to me that this (to use a Chrome term that I kind of like) is encouraging developers to fall into a "pit of success" in regards to gaming and user controls. This has popped up occasionally for me where gamepads are concerned -- it's nice to be able to provide a sensible default when someone plugs in a controller. But in that situation I care more about just having a default layout then I care about knowing the specific key that was pressed. In that scenario what I actually want is a gamepad "type" string that I can just map to a list of defaults I've pre-configured for that specific gamepad type. In fact, the more I think about it, getting a key code is almost the opposite of what I want in that situation since different gamepads have different norms about what locations should do what and are shaped differently, there isn't a universal map. It's explicitly the wrong decision for me to say that the top button on the right hand side of a gamepad will always do one thing, because that's going to breaking norms on different controllers. And it seems like keyboards are kind of the same? I sort of see the value of a keyboard being able to signal a common layout that has different default shortcuts, but I'm having a really hard time thinking beyond that why I would want to as a dev override normal shortcuts. Okay, sure, it would be nice to query that a keyboard is in AZERTY layout and suggest different shortcuts. Beyond that? Enough people have asked for it that it must have a use, but even from a gamedev perspective this seems like a strange API to me. The privacy angle is one thing, but I also just have an instinct that this is probably not a behavior that users want from applications. They probably want Internet applications to respect their shortcuts instead of overriding them. And they probably want games to avoid forcing controls based on physical locations of buttons. ---- From the Github spec: > E.g., If a game supports the standard WASD keys (to move up/left/down/right), then the instructions for the game need to be able to tell the user which keys to press. On a US-English keyboard, they are 'W', 'A', 'S', 'D', but for French (AZERTY) layout the user would be told to use 'Z', 'Q', 'S', 'D'. [...] > Some applications make use of keyboard shortcuts that are based on the position of the key rather than the symbol that is generated. [...] > E.g., a drawing app may have a number of drawing modes arranged from left to right on the screen and may wish to have keyboard shortcuts that correspond to the screen position. I don't know, maybe I'm being unimaginative. But I've dealt with at least the first problem here, and I don't think that keymaps are necessarily the best way to solve it. Also, if we're talking about games we should be coming up with a solution that maps to controllers as well, so I don't really get why we're going down this specific route. And the second two use-cases seem like user accessibility bugs, not features. I guess enough devs want it that Chrome is implementing it, but I feel like there's something I'm missing. As a user, I want a user-controlled (or at least OS-controlled) layer between myself and app shortcuts/keycodes; it's super useful and I customize that layer all the time, even for simple things like rebinding caps-lock. And as a dev I'd rather not have to try and intuit what setup a user has based on physical locations. Heck, maybe someone toggles into a different layout to game and they use IJKL to move around when they're playing web games. Maybe their W key is broken and it's bad for me to try and force them to use that specific physical button. I don't want to have to think about any of that as a dev, just have the OS signal to me what keys they want me to think they pressed. And if they can signal to me a common string for the overall layout that allows me to give them a sensible default, then great, I'm happy to do something like that. But this feature doesn't seem to make any of that easier, it just gives me a granular map for individual keys and then makes it my problem to interpret. :shrug: I don't know, maybe there's some nonsense with native behavior that we're trying to match or something. I customize my keyboard layout a lot, but I've never jumped to DVORAK/AZERTY, maybe there's a lot of weirdness with shortcuts there that native apps expect to just paper over, where they bypass the layout? But I'm not really seeing that online?

poetril 5y ago

Does anyone know if Edge/Brave will be implementing this?