dffd1fd959
|
||
|---|---|---|
| .. | ||
| Readme.md | ||
Readme.md
Product features
Here we prototype potential product features within our "l2beat for privacy" platform. All they are based on market survey available here
Validity track
"yes/no" applicability like if "docs" exist or not. Benefit: easy to source manually & empower scoring model with the links. Downside: the existence of Git repo or docs doesn't guarantee the state of privacy within a certain solution.
Approach: "validity track" serves as an MVP of privacy analytics, and challenges a culture of open-source delivery.
Validity examples (yes, no):
- Github repo
- Docs
- Public team
- Third-party audit
This could be broken down into 100% (4 yes, each - 25%; where 2 no & 2 yes = 50%)
101 educational materials.
| Benefit | Downside | Approach | Selected 101s |
|---|---|---|---|
| significantly upgrades DYOR & flags main misconceptions about privacy execution plus 1 guide could serve all audiences | too many content pieces to write or assemble to encompass the whole privacy services & nuances spectrum (needed to be broken down into delivery phases) | select essential educational materials for the first audiences (example: crypto, but not privacy native instead of "non-crypto" first served) | privacy tech vocabulary |
| make 101 modular (block system) + composable (to be reused in other guides) | privacy data leakages 101 | ||
| transaction traceability 101 (the basics on Etherscan example) | |||
| web3 comms 101 (with a focus on misleading comms that create an obscure understanding of the tech/product) |
The scoring model could consist of passive & active parts. When passive means what could be automated or req no subjective gaze, active - for personal consideration (research).
Checklists (example: trusted sources list).
| Benefit | Downside | Approach | Checklist MVP |
|---|---|---|---|
| serves as a self-check navigation within the complex audit stream (and a predecessor of an actionable database) | there will be always something missing from the list | pick a direction (like "trusted sources") | Storage: What user information is stored? (username, IP address, last connection, wallets associate, etc) -> the less the better |
| write down it as an actionable plan | Infra: Number of nodes/servers/ -> the larger the footprint the best privacy | ||
| help a person spend less time on data aggregation (the easiest to follow checklist - the better) | Signup: no email or tel number for signup -> the less data the better | ||
| Traction: number of people using it -> the more the better (with examples) | |||
| Public comms: simplified socials analysis (for a negative sentiment) | |||
| Product-readiness: test-net, mainnet; date of the release. |
This is a mix of objective metrics & subjective takeaways (like an old product release can be a negative sentiment for privacy & vice versa). Case studies will help to empower these assumptions. If we will collect good case studies lib -> it will help people to have market benchmarks for every step of scoring system.
Academy (content from case studies to third-party services to check net data, leakages).
| Benefit | Downside | Approach |
|---|---|---|
| this will be the backbone of our platform in the future that will bridge the gap between lack of privacy-centric education, lack of third-party services to check-up solutions & poor transparency on behalf of privacy-devs. | usually takes too long time to deliver & many different contributors (should be simplified via tracks like Web3 Privacy 101). | Stick with privacy 101 (basics). |
| Brake down the most crucial knowledge into simplified blocks. | ||
| Create a simplified & actionable "lecture framework" for guest lectors. | ||
| Invite lectors within a micro-learning format. | ||
| Cover basic 10 lectures via "Web3 privacy 101 introduction". | ||
| Deploy via videos + texts > test them out. |
Long 2do list (filtered out product features)
| Validity | Education track 101 | Checklists | Additional content | Automation (beta) |
|---|---|---|---|---|
| * documentation: exists/missing | forkability x privacy 101 | trusted sources checklist (&/or a list) | case studies when solutions actively embed privacy education within the workflow | "DERP"-alike tool for the future privacy script-based "check-up" product releases |
| 3rd party list (yes/no) from security audit agencies to independent security engineers (+their reputation 101 in later versions) | security audits 101 (basics) | web3 open-source checklist (soft screening like whitepaper (yes/no), docs (yes/no) etc) | List of external third-party resources in a Wiki (for those, who like to make extra effort -> influence micro-services creation) | web3-native IP-checker for a beta version |
| website checklist (1-2-3-4-5..., yes/no validity) | web3 privacy 101 (focus on a misleading comms like blockchain security equals privacy) | different self-check recommendations by security audits, white hackers as a supplement (how would you test product privacy) | case-studies (privacy matching): protocol = transparent, but use-cases = private (like Ethereum) | web3-native privacy features checker to be R&D (what could be automated & coded for QA-automation) |
| code audit (yes/no). Case studies (how those audits could look alike with active links) | web3 comms 101 (with a focus on misleading comms that create an obscure understanding of the tech/product) | GitHub basic score (flag system could be a part of the second product release) | future: privacy features comparison within solutions (creating a comprehensive privacy market metrics set) | |
| privacy tech vocabulary | a checklist of when you need a "tech" person help to attest privacy features & when not (with a focus on a second scenario) | case studies when solutions actively embed privacy education within the workflow | ||
| privacy data leakages 101 | "net usage stats" services guide for the end user (but with a focus on empowering product managers to incorporate third-party tools to self-check their products & publicly report on their privacy features) | |||
| transaction traceability 101 (the basics on Etherscan example) | "privacy stack" enhancement prototyping (1 solution + 1 solution = privacy "2x" (like Session messenger + dVPN) | |||
| web3 comms 101 (with a focus on misleading comms that create an obscure understanding of the tech/product) | examples of how products enhance privacy creatively (like a game mentioned by Obscuro) -> potential market benchmarks | |||
| open source 101 (short version) | part of the wiki: web3 privacy products biases (in relation to privacy features x user experience) | |||
| social recovery 101 | ||||
| missing 3rd party audit potential risks 101 | ||||
| simplified media analysis 101 | ||||
| privacy in ZK 101 | ||||
| "attacks" (threats) 101 | ||||
| transaction traceability 101 (the basics on Etherscan example) | ||||
| web3 docs 101 (basic description in relation to privacy) | ||||
| pubkey, network key, viewing key etc 101 | ||||
| "Anti-features" 101 | ||||
| did 101 (with a focus on the linkage between different data types) |
DYOR section
- useful links (like dVPN studies in a DYOR section)
Future releases
- in the future: collab with a security audit company to create a new docs audit service description when a third party will attest privacy features of the initial idea x tooling description