"You say that you don't store any information to ensure privacy but this is essentially asking users to trust you. Why not build trust into the technology from the outset?"
I am also working on a project where users can optionally self-store their data (at the cost of making what I hope are useful algorithms dumber). I'm sort of banking on the hope that 90% of users won't care, and the ten percent that do care will appreciate that option and become enthusiasts.
I'm curious what Richard's answer to the trust question is, but also what you (@abetusk) mean by "build trust into the technology by the outset"? Even when open sourcing everything, there is the question of, "are you actually using that branch on the servers?" I don't know how to answer that.
> I'm curious what ... you ... mean by "build trust into the technology by the outset"?
I'm not sure I could come up with a checklist that would take all the considerations in mind, so it's an ill defined question in some sense. For folks who market their product as "secure" and "privacy conscious", I would hope they would have thought about these questions and come up with a solution. At the very least, I would hope they would be able to list out their assumptions and limitations of whatever solution they came up with.
To try and actually answer the question, though, I would think something along the lines of queries that are Tor enabled or have an option to allow for Tor connections (without the need for Javascript). Maybe something that uses distributed data/queries for decentralization and resiliency against snooping or attacks on a central location?
It looks like You.com uses a chrome extension, so they should have more control over what form the queries take. Connection to the Tor network is presumably not out of the question.
I agree that knowing what code is running where is a hard problem in general but besides being able to audit code that's open source, the other leg of that is to be able to stand up your own instance. There could be a way to provide incentives for people to return "good" results by random verification and/or user (transparent/frictionless/micro) payments.
There are fancier systems like homomorphic encryption but I'm not sure those are really ready for everyday use yet.
The amount of data is massive and any search service is going to be competing with a corporation that has 20+ years of domain knowledge and a compute infrastructure that is many orders of magnitude larger than anything that's really available, so I'm not sure there are any easy answers, which is why I'm asking.
Maybe You.com is focusing on a more AI centric search service, which is how they're trying to compete or differentiate themselves? If so, then making that data available (under a libre/free license) along with the code would go a long way towards building good will and cold lead to a path for a "trustless" community built search engine.
I am also working on a project where users can optionally self-store their data (at the cost of making what I hope are useful algorithms dumber). I'm sort of banking on the hope that 90% of users won't care, and the ten percent that do care will appreciate that option and become enthusiasts.
I'm curious what Richard's answer to the trust question is, but also what you (@abetusk) mean by "build trust into the technology by the outset"? Even when open sourcing everything, there is the question of, "are you actually using that branch on the servers?" I don't know how to answer that.