Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Helper agents are dark patterns.

Unless installing an always running service on my device is directly related to the intended functionality of your software, setting one up is unwelcome and deceptive. Especially when it is done to work around existing security controls.



Absolutely. If the user indicates they don't want your software running anymore, it should stop.

In Zoom's case, if the user exits the app, the web server keeps running. When the user uninstalled the app, the web server still keeps running.

The user twice said "I don't want Zoom's software running on my computer and both times Zoom ignored the user's request.

This behavior is both unethical AND malicious.

Edit: wrote up more thoughts on this: https://salibra.com/p/viral-growth-doesnt-mean-writing-virus...


I don't want the web server running when Zoom is running either.

Video conferencing has nothing to do with a web server or any server listening to ports.

When I install a video conferencing client its only function should be me initiating a connection.


Then why don’t you switch to webex?


I have never been in the position to choose other than voicing my opinion, all video conferencing sucks for some reason or another, and it has never been anywhere near the most important thing.


I disagree with declaring all helper agents as dark patterns.

From a regular user point of view, it would be acceptable to have a helper agent as long as it follows:

- platform provided background process methodology (example: launchd could launch your process when you hit the socket),

- and it is made clearly apparent that such a thing is installed on your system (say, via system preferences panel, via status bar icon menu, and via in-app preferences panel),

- and it does cleanly uninstall as part of a simple standard regular uninstall.

And from a technical/security point of view, it would be acceptable if it:

- has minimal necessary privileges and proper separation of concerns.

- and does only what it needs to provide a user-expected functionality and doesn't do random egregious things.

- has secure ways to allow only expected/authorized caller to talk to it.

- does not violate any platform guidelines or tries to circumvent protections.


> From a regular user point of view, it would be acceptable

It would be not, stop pretending acquiring consent from a statistical model counts as acquiring consent from the actual user.

Thing you wrote may make it acceptable for you, but certainly ain't sufficient for me.


> It would be not, stop pretending acquiring consent from a statistical model counts as acquiring consent from the actual user.

I don't know what you are referring to here. Care to elaborate?

> Thing you wrote may make it acceptable for you, but certainly ain't sufficient for me.

This isn't about individual taste. Nothing I wrote above was about my personal taste. My point was about differentiating between the OS provided valid architectural mechanisms vs surreptitious dark patterns applied on top of it by an application developer.


I don't know what you are referring to here. Care to elaborate?

You make assumptions about individual user's consent from whatever bulk experiences you might have measured. Either that, or you didn't even measure anything and therefore you're just making things up about what's "acceptable."

> This isn't about individual taste.

Who said anything about taste, it's about individual boundaries.

> My point was about differentiating between the OS provided valid architectural mechanisms vs surreptitious dark patterns applied on top of it by an application developer.

First, that's a word salad. Second, after untangling it, I'm pretty sure you mean "if there's a mechanism in the OS that enables this then it's okay" in which case that's even more absurd than the usual "if it's legal then it's okay." Look, even if you take Zoom's "let's leave a tray icon there when you thought you quit the app without putting a honking huge notice you just did that like a decent app usually does" is more about having a way to disawov ("see, we did leave a notification, lol") than actually ethical design. That's the _essence_ of a dark pattern.

Seriously, though, you're being creepy and advocating pushing people's boundaries here.


But for what?

My caveat is that a helper service is acceptable when it is doing something necessary for the basic function of the software.

Virus scanners, file sync, and things which are obviously servers fit the bill. Not much else I can think of does.


Libreoffice has an agent that preloads java bins to make the startup time comparable to MS Office. There are valid uses for startup agents, please get over yourself


I don't want that.

I don't want installing an office suite to permanently take away a percentage of my computer's resources.


That’s the meat of it, Zoom wanted an app feature macOS said was a no-no so they coded up an insecure workaround. On iOS that would get your app pulled at the least.


I want an operating system with a permissions model which specifically forbids this kind of thing.

My Linux desktops are also always full of processes which I have to dig to figure the purpose, unless I build my own distribution it's hard to make anything work which feels satisfactorily under control.


So how does your OS differenate between Apache and a local helper?


Non-OS provided applications are installed as packages and given package-level permissions which are easily audited and revokable (without forcing uninstall).

Apache has permission to start at boot, run in the background, and listen to 0.0.0.0:80,443. Photoshop has permission to write to files in $HOME, and connect to network services while the application is running optionally with explicit permissions for each access. Adobe's update service can be disabled with a click.


Well windows pops open a huge GD window that allows you to decide firewall rules if it notices a change


Helper agents are an integral part of said security controls, e.g. for XPC, privilege separation, etc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: