Introducing UpRock! DePin for AI - Share your idle internet and earn $UPT

Personal Privacy

Our app does not integrate with the end users’ browsers at all. This means we neither know nor could know what sites they visit, where they browse or anything else about their personal data. We are not collecting our end users’ data. Their devices are only being used as “workers” in our distributed network, the decisions about which sites to load and from which devices are driven by the data projects, meaning that an end user won’t inadvertently steer or influence this process in any way, and thus cannot leak data to it, even accidentally.

TouchGrass (GetGrass?)

Assuming that you mean Grass (getgrass), there’s actually a lot we think this project is doing right, and it seems like a hardworking and earnest team. That is to say, in the absence of them having done something shady (which we’re not aware of), we don’t want to throw shade.

We do think UpRock is superior to Grass, however. The main reasons for this are the nature of how work is distributed, the fact that UpRock works natively on mobile and the fact that UpRock is native app. In UpRock work providers never communicate directly with work producers, meaning that there is little to nothing that can leak about the user.

UpRock is also a native citizen on mobile. By far and away the most valuable and numerous users are mobile device users, and UpRock can address all of these. As a browser extension, Grass will always be blocked or severely limited on mobile devices.

UpRock cannot access the users’ browsers because it doesn’t run in the browser. Even if the Grass team never makes a dubious decision with their designs, the fact that it’s a browser extension means that a supply chain attack against the app will have the capability of injecting malware into the users’ browsers where their personal passwords, browsing data, etc live. In comparison, the UpRock app is designed to run with minimal permissions as a standalone app. Therefore even in a worst case scenario we aren’t in a position to be inside the users’ browsers. We are also not dependent on the user having Chrome running, and can run as a super lightweight background process.

Building native apps is more work than browser extensions, but the performance, security and reliability are worth “doing things right”.

Security Measure

We do not reveal our end users’ devices directly to data ingestion tasks, rather the devices run jobs which produce a result. Some of these jobs are interactive, but the end users’ devices are not hosting open ports and the data collection tasks do not communicate directly with the end user’s devices, but rather submit jobs to the coordinator nodes. These nodes then process these jobs with parameters specifying which sorts of devices (speed requirement, geo location, network type, etc) can fulfill these jobs, before returning the job result to the data task.

In terms of bandwidth usage, we have controls (and are developing more) to allow users to limit when tasks run, how much bandwidth they may use, etc. We expect that most users will want more bandwidth consumed on their devices, because this obviously provides them with bigger rewards, but if a user has some hard cap, or simply doesn’t want it running at certain times, they can control this as they like (and we will have more fine grained controls in the future, such as only accept tasks that pay more than some value, for certain types, etc).

CAPTCHAs

We cannot totally guarantee that no process will ever hit a captcha (although with a DePin network this is much rarer). However, CAPTCHAs present another opportunity to reward our members. If tasks are blocked on CAPTCHAs we can allow our users to earn extra rewards for solving these CAPTCHAs. In fact, this is merely another way that users can increase their earnings. In fact, the user who solves the CAPTCHA doesn’t even need to be the same user whos device encountered the CAPTCHA, rather we can forward the CAPTCHA to a user who’s expressed an interest in earning for solving CAPTCHAs, and then forward the completed result back to the device that actually is doing the crawling (it’s a bit complicated, since we have to forward the solution not the result, but this encompasses the main ideas).

19 Likes