Hacker News new | past | comments | ask | show | jobs | submit login

The problem with asking permission is dialog fatigue and similar.

As far as supporting local content: Historically a lot of terrible (read: Enterprise, H&R Block tax software, etc) apps are glorified webpages, coupled with a local server that provides things like FS access and malware installation. Those apps use a kludge of remote and localhost urls, and generally expect to work.

I suspect at this point though that browsers will just start going for the "no access to localhost" route as this practice is mercifully dying out (alas in favor of Electron apps shipping full, but out of date, browsers).

To me the bigger problem is: Zoom installed a server on a machine, without consent, with the ability to install software (without consent). Removing the browser's access to that service doesn't mean anything because an attacker can always just directly attack the server.

Even if the server locks connections to exclusively coming from localhost they've provided a service that can install and launch software, which can therefore be used as a sandbox escape - e.g a super constrained network service gets compromised - the idea is that service can't modify the filesystem or what have you, but now it can just connect to localhost and get a file written to disk.

People keep on complaining about apple "locking down the system", but its because of developers like Zoom that Apple needs to do this: and average user is not going to see this post, and Zoom has clearly decided that it is in their interests to leave a service running that can install software for them.

I hope that apple drops the XProtect hammer on the server binary, and the ban hammer on their signing cert.




Yes, but blocking browser access to localhost from non localhost pages would stop the attack by simply visiting a webpage.

It’s as much the fault of browsers for leaving the hole as Zoom for doing a shady job exploiting it.

Very disappointed at Mozilla for their meh response.


They have a web server on your machine. If the browsers did that, they would find some other way to handle this since they have a server running on your computer.

I don't think the browser vendors are to blame here.


> The problem with asking permission is dialog fatigue and similar.

That’s why I suggested config option and permission. There’s no dialog fatigue if you never see the dialog.

That being said, there really ought to be a little menu of permissions that can be granted to a website such that the website cannot make it blink, flash, or otherwise draw attention to it. Crud like “allow push notifications” could go there. Granting push notification permission to a site is fine, but I don’t think sites should be able to ask for push notification permission.


In my experience if you tell users "to use this awesome thing, you need to enable this option", a reasonable portion will do it.

It sounds like what you're saying is that there should be a dialog, but only if you've already enabled a setting, which raises the question of "if this feature is so bad you don't want it exposed, why would you have it available at all?".




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

Search: