Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rating for websites that are not on ToS;DR, extension's tos db, and related website URLs. #118

Open
tasn opened this issue Feb 5, 2018 · 0 comments
Assignees
Labels
needs response issue that needs a response from the product team

Comments

@tasn
Copy link

tasn commented Feb 5, 2018

My name is Tom and I develop https://www.etesync.com .
I recently got a complaint by a user saying that the main EteSync website is showing as B in this extension, even though it does no user tracking, and is very privacy friendly (and oriented). The reason for that was the lack of a ToS;DR entry. I think this is a bit extreme to mark a site as non-privacy friendly based on a database that includes less than 0.0000001% of the websites in existence.
I think this should be softened to show A, and maybe ones with great ToS show A+.
EteSync is a service, so obviously it should be on ToS;DR. But what about my personal blog? I don't have any trackers there, and I'll never be on ToS;DR, will I always be penalised?
EteSync has since been added (about a week ago, see etesync/etesync-web#7), though this change is still doesn't show in the extension, which was updated after. Are you taking the old ToS;DR db or using the new one?
Another issue I came across (I'm not sure how this will behave, but sounds like it would be a problem) is related URLs. If my service's main website is www.etesync.com, what will happen with client.etesync.com, and other subdomains? Is there a hard-coded list? Because I didn't see one in ToS;DR. Could be a concern if a company is offering different services under different terms.

In essence, I'd like to ask you to soften the impact of a lack of ToS;DR until all of the issues above are solved. At the moment, as a user, I just can't trust the rating (unless it's a big negative one), and as a developer, I'm feeling the impact of these issues.

I understand and applaud what you are trying to do, but I think that without the above, it's causing more harm than good, and probably will reduce user's trust in the long term.

@alohaas alohaas added the needs response issue that needs a response from the product team label Mar 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs response issue that needs a response from the product team
Projects
None yet
Development

No branches or pull requests

3 participants