Hacker Newsnew | past | comments | ask | show | jobs | submit | merlish's commentslogin

For a user to correctly answer a permissions dialog, they need to learn programming and read all the source code of the application. To say nothing of the negative effects of permission dialog fatigue.

In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer.

Asking the user a question they realistically can't answer correctly is not a solution. It's giving up on the problem.


I think browsers should distinguish more aggressively between "web application", "web site", and "user hostile web site".

Many APIs should be gated behind being a web application. This itself could be a permission dialog already, with a big warning that this enables tracking and "no reputable web site will ask for it unless it is clear why this permission is needed - in doubt, choose no".

Collect opt-in telemetry. Web sites that claim to be a web application but keep getting denied can then be reclassified as hostile web sites, at which point they not only lose the ability to annoy users with web app permission prompts, but also other privileges that web sites don't need.


Clearly if we knew how to perfectly identify user hostile websites we'd not need permissions dialogs at all.

Distinguishing between site and app, e.g. via an installation process, is equivalent to a permissions dialog, except that you're now advocating for one giant permission dialog instead of fine-grained ones, which seems like a step backwards.


Yes, if we knew how to do it perfectly, we wouldn't need them. But we can identify some known-good and known-bad cases with high confidence. My proposal mainly addresses the "fatigue" aspect: it allows apps to use some of the more powerful features without letting every web site use them, and it prevents random web sites from declaring themselves an app and spamming users with the permission request just so they can abuse the users more.

The new permission dialog wouldn't grant all of the finer-grained permissions - it would be a prerequisite to requesting them in the first place.


SafeBrowsing filters out the known bad ones.

Curating known good would equate to some sort of app store. There are probably initiatives to make one for web apps, but it kind of makes me sad to think of applying that to the web, which is supposed to be a free and open commons (although I suppose Google already de facto controls enough of it to be considered a bit of a gatekeeper).

Making the user the arbiter of "known good", ie reliance on permissions dialogs, is not perfect but it's what we have. Yet I fail to see how your proposal of "just add ANOTHER dialog" improves the situation.


SafeBrowsing filters whatever Google wants filtered. It has only a marginal overlap with "bad sites".


Do you have something specific in mind with your opening paragraph?

Because defining what is a web site and what's an app, strikes me as particularly impractical idea. You correctly point out that yes, there are a number of powerful APIs that should be behind permissions. But there are a number of permissions already, so we need to start bundling them and also figure out how to present all this to the regular user.

Frankly, I wouldn't know where to begin with all this.


News sites are a particular category that I expect to spam people with permission prompts, as they did when notifications became a thing. Without the deterrent of possibly landing in the naughty box, they'd all do it. With it, I still expect some of them to try until they land in the box.


> In practice, no-one who answers a web permissions dialog truly knows if they have made the correct answer.

Counterpoint: if webpage with latest news (for example) immediately asks me to allow notification, access to webcamera and location I definitely know what is correct answer to these dialogs.


"Do you want to allow example.com to send you notifications" is way more understandable to a layperson than "do you want to allow access to WebGPU" or "do you want to allow access to your graphics card". Especially because they would still have access to canvas and WebGL.

Permission prompts are a HUGE user education issue and also a fatigue issue. Rendering is widely used on websites so if users get the prompt constantly they're going to tune it out.


You can always word things in a way that the user understands.

> Especially because they would still have access to canvas and WebGL.

Those should also be behind a (or the same) permission prompt.


They don't need to learn programming. Just write that this technology can be used for displaying 3D graphics and fingerprinting and let user decide whether they take the risk.


They're going to be confused if you say "display 3D graphics", because canvas and WebGL will still work. The website will just be laggier and burn their battery faster. That's not going to make sense to them.

"Fingerprinting" is a better approach to the messaging, but is also going to be confusing since if you take that approach, almost all modern permissions are fingerprinting permissions, so now you have the problem of "okay, this website requires fingerprinting class A but not fingerprinting class B" and we expect an ordinary user to understand that somehow?


Most of them will say, "I need to see this site, who cares about fingerprints." Some will notice that they're on their screen anyway, a few will know what it's all about.

Maybe "it can be used to display 3D graphics and to track you", but I expect that most people will shrug and go on.


You could maybe display the request in the canvas instead of a popup. If the user can't see it, they'll never say yes.


You'd be better off believing neither, but taking the participants' stories as what they believe happened.

Then drawing your own conclusions.

(Sorry, not picking on you in particular; I'm just quite annoyed to see this thread treating the incident as a spam problem to be solved technically. There were also people who really did not like Wil Wheaton, and then suddenly found him in their online home.)


Sure, and these are good points, but they solve a problem far less interesting than the real problem.

Of the (let's guess) 60 people telling Wil to go do one, up to about half[1] might be the shitposting crew taking advantage to troll a not well-liked celebrity, but the rest were people and their friends who were genuinely incensed at his appearance in their graph.

For the latter, you might argue they should block him, but if he's on the same instance then effectively he's come in and sat down in their home. If he's on a remote instance, then there still exists the desire for retributive justice for past wrongs (yes, including perceived).

In this specific case, there was no-one (except the moderator!) sticking up for Wil. The groups that dislike him are small, but genuinely plural. (e.g. 4chan doesn't like him, a number of trans* artists don't like him, some Star Trek geeks...)

Given that he came to the fediverse to escape harassment and trolling on _mainstream_ platforms, I don't think there is a great solution.

So here's two options, instead:

One: Don't join the platform as "Wil Wheaton". If you want to join a community as another face in the crowd, then use an internet handle. Then you can interact as equals.

Pseudonymity is one of the great gifts of the internet.

If you come as a celebrity to link your blog posts and try and talk to fans, then I don't think the fediverse makes any sense. It's too small and people are territorial of the instances they adopt.

Secondly - a more social solution - find some way to calm the people involved. This may involve temporarily suspending instance links, or saying that (as moderator) you need time to discuss this and are working towards an acceptable solution, etc. Don't know what you do next.

Finally - and the point of my rant: Dismiss those you don't understand / greatly simplify social problems at your peril. (Sure is great reading a bunch of trans artists arguing in earnest turned into "abusers" - nice!)

As humans, we make great changes and build general solutions based on one-off undesirable acts, and if you don't even make an effort to completely understand the problem then you WILL build the wrong solution.

[1] Possibly more than 50%? There were people involved who kept saying they had just joined Mastodon and didn't know how to use it, which is weird.


Yes - but never mind the requests, what's up with that "GDPR bar"? Where's the 'No, I do not want you to do this' button?


Ah, never mind! It's a simple 56-step opt out process:

https://www.voxmedia.com/pages/cookie-policy#your-cookie-cho...


How do you implement co-operative multitasking in WebAssembly?

Do you have to analyze the source program & know where every possible call to a yield is, and store all resulting suffixes of a function as new functions?


I managed to log in, but the system is pretty barebones.

Trying to change or apply for a new banking product just takes you to a help page saying the ability to do this is 'Coming soon'. (Some other features are scheduled to be available by the 'End of April', for comparison.)

Also, in the 'pending transactions' popdown, e.g. £38.60 is displayed as '38.6'...


That implies the balances are being represented as floats and turned directly into strings ... how does something that basic happen at all? Is Sabadell's Spanish web UI like that too? No wonder they're screwed


> That implies the balances are being represented as floats ... how does something that basic happen at all?

Javascript only has floats. For the unwary this is a common source of bugs in frontends to financial systems.

Hopefully the backend is using some kind of decimal type.


They're planning both. Reference counting/bump pointer allocation in-frame for temp stuff & no GC & manual memory management for the upcoming high-performance restricted C# subset data-oriented jobs code, and for full-fat real C# code they're slowly working to clean up their (C++ coded) runtime so that a non-conservative garbage collector can work.

Re. Boehm, that was the garbage collector Mono shipped until they wrote SGen some years back.

I'm quite excited by the work they're doing on performance. It looks great.


The gist contains a 2018 update section at the bottom...


Ok thanks, we'll take that out.


The article has additions up to 2018 as additional sections.


To add (baseless) speculation to the mix, I think it's more NIH than GPLv3 concerns...


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

Search: