Re: [w3c/permissions] A new permission for canvas data (#165)

Is this going to be a thing be for TOR or mainstream browsers? I dont think a permission is required for this thing because no personal information is leaked. Maybe this only fits TOR, and we already block TOR nodes due to spam and abuse. Even ClouldFlare and Google's ReCapcha dislikes TOR and block them most of the time. 

Having excessive permission for even rendering and getting rendered data to be displayed in some other form is going to cause a permission fatigue. There is no critical personal permission involved in this case.  

TOR probably has different priorities than regular browser and they come at a huge cost. Sadly we've invested too much time in developing a PWA to move away from native our native app on phones, without realizing that we are at the mercy of browser vendors. 

We already stopped testing on Firefox because of this, because we're not going to deal with edge cases that get introduced after 3 years into development of our product when all of a sudden Mozilla decides it, and much of our spam comes from Firefox and TOR users. After they introduced it we started shadow banning Firefox users who present us with a white canvas, because spammers hide in legitimate users. If Firefox starts doing this by default, I'm afraid they'll get a sub par treatment like TOR users. We're not going to fingerprint Firefox users, but we're not going to allow allow them on the platform if this happens because Facebook already has a very negative reputation after Cambridge Analytica fiasco and there is a stigma about privacy even though there is not much of a risk here. 

I'd like to know Google's stance on this before we decide to launch our desktop product pwa. We already had a redesign, but there are further improvements that are being made for better visual performance. If this is also on their roadmap than we'll publish on the Windows Store instead of the web and be done with it. We use fingerprinting for bot detection and avoid multiple signups for vote manipulation. or shadow-banning spammers. And to be honest the fingerprint is only accurate until the next minor release of a browser. Of course there is not enough information to create a unique id but it is good enough to hold information for next 48 hours and disallow signups from same users while not informing them. If this happens, then we can expect that permissions could be introduced for things that don't require permission now, and we would move to a native app on Windows entirely. The web unfortunately is already prone to abuse, and since our website is in Alexa Top 10, we can no longer allow this. In-fact there are already many attempts for vote manipulation, and its is difficult to keep a watch on suspicious users. 

And this only works because most legitimate users dont know about this. Spammers and very few privacy users fake their fingerprint, legitimate users do not. and as a result spammers and vote manipulators get shadow banned. 

It would be helpful if browsers could provide us with a standard device id to avoid fraud and manipulation, because the other way is to force them to download a native app which we don't want to but have to for reasons of the safety of the community as a whole. Since fingerprint on mobile are not unique enough, we have to partner with several apps that are already likely to be on the users device to perform the risk analysis in order to decide shadow banning. 

We would like to once again remind that if it is decided for mainstream browser, drawbacks and benefits need to be taken into account. Many banking apps use the same thing for detecting fraud, and Akamai and other folks likely do the same thing for spam detection. 

Also fingerprint it not deterministic but probabilistic that it allows for risk analysis. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/issues/165#issuecomment-394332419