Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wacom drawing tablets track the name of every application you open (2020)

robertheaton.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Wacom drawing tablets track the name of every application you open (2020)

#51

Post by NekkoDroid »

jcelerier wrote: post #42
concerndc1tizen wrote: post #31

Earlier quoted context omitted.

Yeah, but any application with that privilege can log all keystrokes and upload it to a third party. Obviously this privilege needs to be far more fine grained and have limitations, i.e. registering a hook on particular key combinations, rather than listening on all key events.

How do you implement an app that displays all the keys you type on screen then no matter which Wayland compositor? (For when you're making video tutorials of an app)

In short: you wouldn't.

What you are suggesting is overstepping 2 security boundries for unpriviledged apps/processes: 1. Reading global key presses 2. Drawing in an always-on-top window with transparent content

Both these things would require that process to get special user/compositor opt-in permissions and integration. Your best bet would be using compositor plugins/native integration, or maybe you could hook into some toolkits (this is usually what FPS overlays do, hook into the graphics APIs).

That is at least my current knowledge and there might be already some wayland extensions/XDG-portal that allows it, but not to my knowledge.

Re: Wacom drawing tablets track the name of every application you open (2020)

#52

Post by [deleted] »

terminalbraid wrote: post #2

Please note this heinous and inexcusable overreach is over five years old and was addressed shortly after being caught: https://web.archive.org/web/20200307082846/https://community... Wacom now has an opt-in for data collection. What should be the real continuing inexcusable outrage is that Windows, even today, grants all applications full access to read the titles of all windows with no way to disable it . If you ru…

[deleted]

Re: Wacom drawing tablets track the name of every application you open (2020)

#53

Post by nilslindemann »

Gigachad wrote: post #36
jfim wrote: post #11

Earlier quoted context omitted.

> What should be the real continuing inexcusable outrage is that Windows, even today, grants all applications full access to read the titles of all windows with no way to disable it. That's there because it's been in there forever in the win32 API, and changing that would break applications. For example, a long time ago, I wrote a small application that would iterate through a list of executables, launch each one seq…

There’s nothing wrong with a breaking change for good reasons. Locking down the API to protect user privacy and security is one of those good reasons.

FUCK YOU! DO NOT TAKE AWAY MY AUTOHOTKEY.

Re: Wacom drawing tablets track the name of every application you open (2020)

#54

Post by MyPasswordSucks »

yjftsjthsd-h wrote: post #43
MyPasswordSucks wrote: post #39

Earlier quoted context omitted.

> Why useless? "This program is asking for extended permissions. It's asking: File permissions: Read, write, and modify" Now, is this because it allows me to select a custom avatar from the files on my device and save it after cropping it in the app? Or is it because it's going to check all my files and upload the really juicy ones to Scary Hacker Doods and change my name in all my documents to "Ima Dichwied"? I dunn…

I think I agree with your general point, but I have to point out that the correct solution - implemented by Flatpak, Android, and I believe macOS and iOS - is that selecting an avatar should use a file picker that only hands the app access to what it needs, and a request for full filesystem access is a red flag.

Yes, but now I have to contort my file organization around the preferences of the machine, which is completely backwards to how the user:device relationship should be. My files belong where I feel they belong, optimized for the idiosyncratic and individualized workflow that works for me.

And of course, it kinda also doesn't change much, since (assuming I've learned to give in and submit to Moloch's $HOME) now all my documents are in the siloed "these documents can be accessed by apps" area, still just as ripe for upload to Scary Hacker Dudes or CTRL-H shenanigans. Giving the app access only to its own personal directory would make the hypothetical avatar feature impossible (well, possible only through exiting out, opening gallery, finding a suitable image, manually copying that image over to the app's personal directory... and all that on mobile... yeugh), as well as a whole lot of other features we (should) take for granted.

So in the end, we still have the initial pointlessness, we've just sprinkled in a fair amount of annoyance on top.

Re: Wacom drawing tablets track the name of every application you open (2020)

#55

Post by yjftsjthsd-h »

MyPasswordSucks wrote: post #54
yjftsjthsd-h wrote: post #43

Earlier quoted context omitted.

I think I agree with your general point, but I have to point out that the correct solution - implemented by Flatpak, Android, and I believe macOS and iOS - is that selecting an avatar should use a file picker that only hands the app access to what it needs, and a request for full filesystem access is a red flag.

Yes, but now I have to contort my file organization around the preferences of the machine, which is completely backwards to how the user:device relationship should be. My files belong where I feel they belong, optimized for the idiosyncratic and individualized workflow that works for me . And of course, it kinda also doesn't change much, since (assuming I've learned to give in and submit to Moloch's $HOME) now all my…

Er, no? To select an avatar, the app triggers a file picker, you navigate anywhere in the filesystem and pick a file, and the system hands the app just that file with no access to anything else.

In the case where you want an app to have persistent access to a directory, it's true that the easiest way is to use the normal filesystem layout and then take the default mappings, but at least with flatpak you can tell it to map in arbitrary different directories and then use them just fine (ex. I've used this to give Steam storage on external disks).

These features are effective when used, and while they can have inconveniences, those rough edges can be rounded off by customizing the protections (while still protecting most of the system).

Re: Wacom drawing tablets track the name of every application you open (2020)

#56

Post by jcelerier »

NekkoDroid wrote: post #51
jcelerier wrote: post #42

Earlier quoted context omitted.

How do you implement an app that displays all the keys you type on screen then no matter which Wayland compositor? (For when you're making video tutorials of an app)

In short: you wouldn't. What you are suggesting is overstepping 2 security boundries for unpriviledged apps/processes: 1. Reading global key presses 2. Drawing in an always-on-top window with transparent content Both these things would require that process to get special user/compositor opt-in permissions and integration. Your best bet would be using compositor plugins/native integration, or maybe you could hook into…

I mean the reality of things is I'll just add myself to the input and video groups and let the process do what it wants for my computer to be useful

Re: Wacom drawing tablets track the name of every application you open (2020)

#57

Post by MyPasswordSucks »

yjftsjthsd-h wrote: post #55
MyPasswordSucks wrote: post #54

Earlier quoted context omitted.

Yes, but now I have to contort my file organization around the preferences of the machine, which is completely backwards to how the user:device relationship should be. My files belong where I feel they belong, optimized for the idiosyncratic and individualized workflow that works for me . And of course, it kinda also doesn't change much, since (assuming I've learned to give in and submit to Moloch's $HOME) now all my…

Er, no? To select an avatar, the app triggers a file picker, you navigate anywhere in the filesystem and pick a file, and the system hands the app just that file with no access to anything else. In the case where you want an app to have persistent access to a directory, it's true that the easiest way is to use the normal filesystem layout and then take the default mappings, but at least with flatpak you can tell it t…

Oh, yeah, duh. Sorry about that. The file picker route is generally fine*, though I still think the edge cases where I want a program to be able to modify another program's files in-place are numerous enough that I don't think it should become a "soft-standard" on desktop environments.

*As long as it isn't GTK browser on Windows, which absolutely should be a U.N. matter.

Post reply on HN