Aunali ревизій цього gist 1 month ago. До ревизії
1 file changed, 52 insertions
rv.md(файл створено)
| @@ -0,0 +1,52 @@ | |||
| 1 | + | This is a technically sophisticated proposal, but I have significant concerns about both its effectiveness and its implications for the project. Let me break down my thoughts: | |
| 2 | + | ||
| 3 | + | ## Technical Effectiveness Issues | |
| 4 | + | ||
| 5 | + | **The fundamental contradiction:** You've identified the core problem yourself - if patches can be compiled from source, all of this elaborate security is bypassed. And you're right that gating source code behind captcha is defeated by "first user solves it once and shares." This means you're building an extremely complex system that determined actors will circumvent on day one. | |
| 6 | + | ||
| 7 | + | **The arms race problem:** Each layer of protection you add: | |
| 8 | + | - Increases maintenance burden significantly | |
| 9 | + | - Creates more points of failure | |
| 10 | + | - Will be studied and bypassed by motivated actors | |
| 11 | + | - Hurts legitimate users more than bad actors | |
| 12 | + | ||
| 13 | + | Hardware attestation in particular is notoriously unreliable - it fails on: | |
| 14 | + | - Rooted devices (including privacy/security-conscious users) | |
| 15 | + | - Custom ROMs (your likely user base) | |
| 16 | + | - Older devices | |
| 17 | + | - Some legitimate configurations | |
| 18 | + | ||
| 19 | + | ## User Experience Impact | |
| 20 | + | ||
| 21 | + | You're proposing to add friction for *every legitimate user* to stop automated systems, but: | |
| 22 | + | - Power users (your core audience) often run rooted devices | |
| 23 | + | - Captchas are annoying and accessibility-hostile | |
| 24 | + | - Network/API dependencies create new failure modes | |
| 25 | + | - You're making the tool harder to use for people who should be using it | |
| 26 | + | ||
| 27 | + | ## Philosophical Concerns | |
| 28 | + | ||
| 29 | + | If ReVanced is open source, this approach seems fundamentally at odds with that ethos: | |
| 30 | + | - You're trying to implement DRM on open source software | |
| 31 | + | - Gating source code access contradicts open source principles | |
| 32 | + | - You're treating your users as adversaries to be controlled rather than collaborators | |
| 33 | + | ||
| 34 | + | ## Alternative Approaches to Consider | |
| 35 | + | ||
| 36 | + | Instead of complex technical barriers, consider: | |
| 37 | + | ||
| 38 | + | 1. **Legal/Policy measures** - If prebuilds violate terms, pursue that angle | |
| 39 | + | 2. **Make official builds more attractive** - Better UX, faster updates, verified safety | |
| 40 | + | 3. **Accept it's unpreventable** - Focus energy on what you can control | |
| 41 | + | 4. **Community education** - Help users understand why official sources are better | |
| 42 | + | ||
| 43 | + | ## The Real Question | |
| 44 | + | ||
| 45 | + | **What problem are you actually trying to solve?** | |
| 46 | + | - If it's automated redistribution harming users → focus on making official channels better | |
| 47 | + | - If it's unauthorized monetization → that's a legal/policy issue | |
| 48 | + | - If it's just annoyance at automation → is the cost worth it? | |
| 49 | + | ||
| 50 | + | The amount of engineering effort described here would be better spent improving the core product, especially when you've already acknowledged it can be bypassed. This feels like security theater that will frustrate legitimate users while barely slowing down determined bad actors. | |
| 51 | + | ||
| 52 | + | What's the actual harm you're trying to prevent? That might lead to more practical solutions. | |
Новіше
Пізніше