# Making web3-privacy assessment research: public feedback By [Web3Privacy Now](https://paragraph.com/@web3privacy-now) · 2023-09-27 --- We are prototyping an educational website to help the general public understand whether a web3-service is private. We interviewed 100 privacy players & gathered an MVP vision — we are running a series of 1-on-1 feedback loop sessions to make the scoring model community validated. Here it is important to apply MVP mindset to ship the scoring model ASAP & then move towards a more efficient & inclusive scoring model. So it will evolve over time from serving non-technical & the most vulnerable people to technical professionals. _Example of the reflection sessions_ **MVP criteria**: — non-technical, privacy newbie person — simplest manual check-up — less time on privacy assessment _MVP description_: [here](https://github.com/web3privacy/web3privacy/blob/main/Web3privacynowplatform/scoringmodel/Web3Privacy%20Now%20scoring%20platform_test%20framework.pdf) _Initial idea_: [here](https://github.com/web3privacy/web3privacy/tree/main/Web3privacynowplatform) _Privacy players' survey_: [here](https://github.com/web3privacy/web3privacy/tree/main/Web3privacynowplatform/scoringmodel) Feedback loop sessions are structured within the “proposal” - “reflection” way. This helps to keep progress in a unified form & save future features in 1 place. Participants: Ethereum Foundation, Nym, Monero community, Waku privacy actors. Validity track -------------- ![Fast scoring check-up](https://storage.googleapis.com/papyrus_images/e1115bdbfb03091b494caebf0ebf179c8d60185d55b759180f7fae0f2bfa7ab3.png) Fast scoring check-up These simple actions help non-techie &/or non-web3 people to do a quick test if the project is alive, open-source & open for a third-party audit. **Journey** * check GitHub: exist, not * check docs: available, not * make a team screening: public, missing **Github repo** --------------- ![](https://storage.googleapis.com/papyrus_images/00e3cd818efdcc36ee9eb37bf999f37b12e072e2733766fbbbc9c5abf7f7f02d.png) **proposal** * Is it in stable release, 1.0 and not an alpha or untested code? * Latest release is less than 6 months old? * Are there many PRs and Issues pending? * Are there external contributors outside of the team members? * What licenses are in use (free and/or open license)? ![Prototyping original take x proposals](https://storage.googleapis.com/papyrus_images/33e908c1eaccb713255372ef1bb339bddf35cd4dbd05d52b9c9291fd9cfaba18.png) Prototyping original take x proposals **reflection** The majority of additional check-ups require basic knowledge of potential threat scenarios. Even if they are obvious like “dead GitHub repo that no one was updating for 1 year”. 101 should be short & practical (examples, suggestions). 1. Releases: product versions 101. 2. Commits: contribution x timing x commits 101. 3. Contributions: PR, issues 101. 4. Licenses: 101 description & assessment tips. ### Docs ![](https://storage.googleapis.com/papyrus_images/53a0a6264c1aa8279753f3faad4f29c9b290e8f4003dace271b48cd805b37554.png) **proposal** User docs or technical docs? **reflection** “Read the docs” is a typical technie reflection on how to check the privacy features of the dApp or a protocol. But “read” doesn’t mean “understand”. Here “docs validity” 101 could be broken down into “must haves” from existing docs to type of the docs (fake, poor, deep, sufficient). ### Public team ![](https://storage.googleapis.com/papyrus_images/3b10d2d79d5c610730b3ca35050ad63b9b46e8f54157bbf54d47be4de1ef67f5.png) **proposal** * Does that mean knowing the real people behind the project? * Isn't that against privacy? * Check if there are known contributors (reputation 101) We should be fine knowing the digital identity, but then, we still don't know much. ![](https://storage.googleapis.com/papyrus_images/f848830443ff8307c7f3d981a0e1d38bef112802859525d177a0a8fc4727c511.png) **reflection** Reputation is one of the biggest challenges for the whole web3 space, not just the privacy market. Moreover, anonymous engineering could be a mass phenomenon in the future. So educating about deliberately missing team & active GitHub contributors differences should be well articulated. Especially, when there's room for anon, sudo-anon presence: research, essays, text-based interviews & so on. Here “public”/anon/digital avatar team presence should lead to additional exploration behind both public figures & avatars. We actively check public vs anon team tendencies in our database: [link](https://github.com/web3privacy/web3privacy/tree/main) ### Third-party audit ![](https://storage.googleapis.com/papyrus_images/b767d9621daf33a87453cf9f60d8804bb5c5cb171c5d9514838423fa328c1a93.png) **proposal** * is the latest less completed in the last 6 months? * more than one audit? * are the auditing firms known? ![](https://storage.googleapis.com/papyrus_images/8394be217c4a238051176d7cfaf8493d3698513a539dfcc462494fe7de0d7fc7.png) **reflection** Matching quantitative & qualitative assessment - key to the project's success. The quantitative assessment (was there any security audit?) is easy to perform (main website, Duckduckgo, X, GitHub searches), while quantitative adds big complexities: * there’s no culture of privacy-features-focused audits within security firms * security companies could perform smart contract audits ignoring privacy leakages or data aggregation (anti-privacy features) Web3privacy now team prototypes privacy-features focused security audit with one of the market leaders. The result of the research will be a service description impacting the nature of security research in the market & and their quality. _This will significantly increase the number of security audits within the privacy market_ & and help to protect people in general. ### Scoring mechanism **proposal** General scoring mechanism: _add more complexity, but allow the scoring to be more granular than four 25% yes/no options in assessment_. 1. The main four count for 25% each but they can be broken down into subelements. 2. Giving more data - better-scoring distribution overall. _Why are there no score values for the other tracks as well?_ Quantifying all the variables would be interesting and more elements improve granularity in data samples after testing platforms/services etc **reflection** At the moment we don’t have a developed scoring mechanism system validated with the market players. Our goal is not to oppose a single vision of how it should be done, but to propose multiple ways how assessment scoring could look alike, reflect with privacy actors & and ship a well-balanced framework. _That’s why_ * “%” is a filter rather than an accurate measurement. * “yes / no” approach simplifies assessment for non-technical people Optimal model in the future will have “weights” related to threat actors’ impact or vulnerability (critical, minor etc). Especially, within the “consent” & “data aggregation” fields - measuring ethical approach to privacy (including usage of marketing slang that obscures understanding of the product). ### Support **proposal** Some form of support available? (telegram, discord, forum) **reflection** Support could be an indication of a lively project &/or active community. Although, it could be easily faked via obscure avatars & bots. Not sure how we could highlight it via assessment - could be a short checklist of the visiting community, check its liveliness & so on. ### **Checklists** ![](https://storage.googleapis.com/papyrus_images/c1eda65b68840bbe0ee2eddb142afb0db9c50c7aa01809b569e36399809fabeb.png) We want to build a simplified culture of the privacy-auditing process that many people could replicate by following simple instructions. **Journey (product-readiness example)**: * read a short definition of open-source product delivery cycles (test-net, mainnet for protocols, versions for dApps etc). * find the latest public announcement (website, socials, duckduckgo, blog) * check year & updates (not just readiness, but support, commits & upgrades etc). * have a simple “red flag” matrix within DYOR (no test-net - red flag, no mainnet - 50/50 etc) Each checklist will have a description of the direction & examples of anti-privacy features &/or non-ethical product delivery (claiming dedication to privacy, but tracking people & aggregating personal data like wallets). **proposal** * have they been hacked or had other known technical issues? (review media sources online) * funding (VC, donations)? * third-party trackers **reflection** Scoring model should allow people in the future to do fast-checking procedures within the attention economy & constant micro-content bombardment in socials & messaging apps. But everyone with more time should have an option of extra work that will improve privacy assessment (cosmetic check-up & deep dive). **_Additional proposals_** * Check up anonymity set - set 101 benchmarks * Transaction obfuscation 101 (on-chain analytics methods) * Single point of Failure 101 * Check up privacy leveling: network, application level privacy **Summary** ----------- Many privacy experts understand the complexity behind privacy-claims assessment & huge gap between technical & non-technical audience. Especially when we talk about the latest research in ZKP, FHE, account abstraction (AA) etc. Meaning that they don’t patronise non-technical &/or non-web3/crypto people, but try to help them build simple & ease tools for privacy assessment. To be continued… we aim for 30 min 1-on-1s. ![](https://storage.googleapis.com/papyrus_images/1357b897c2203e75b0bae805e883f020ca4b4d48d3793079358b9e0d267f4ce8.png) --- *Originally published on [Web3Privacy Now](https://paragraph.com/@web3privacy-now/making-web3-privacy-assessment-research-public-feedback)*