rv.md - Opengist

rv.md · 2.8 KiB · Markdown Raw

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: ## Technical Effectiveness Issues **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. **The arms race problem:** Each layer of protection you add: - Increases maintenance burden significantly - Creates more points of failure - Will be studied and bypassed by motivated actors - Hurts legitimate users more than bad actors Hardware attestation in particular is notoriously unreliable - it fails on: - Rooted devices (including privacy/security-conscious users) - Custom ROMs (your likely user base) - Older devices - Some legitimate configurations ## User Experience Impact You're proposing to add friction for *every legitimate user* to stop automated systems, but: - Power users (your core audience) often run rooted devices - Captchas are annoying and accessibility-hostile - Network/API dependencies create new failure modes - You're making the tool harder to use for people who should be using it ## Philosophical Concerns If ReVanced is open source, this approach seems fundamentally at odds with that ethos: - You're trying to implement DRM on open source software - Gating source code access contradicts open source principles - You're treating your users as adversaries to be controlled rather than collaborators ## Alternative Approaches to Consider Instead of complex technical barriers, consider: 1. **Legal/Policy measures** - If prebuilds violate terms, pursue that angle 2. **Make official builds more attractive** - Better UX, faster updates, verified safety 3. **Accept it's unpreventable** - Focus energy on what you can control 4. **Community education** - Help users understand why official sources are better ## The Real Question **What problem are you actually trying to solve?** - If it's automated redistribution harming users → focus on making official channels better - If it's unauthorized monetization → that's a legal/policy issue - If it's just annoyance at automation → is the cost worth it? 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. What's the actual harm you're trying to prevent? That might lead to more practical solutions.

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:

Technical Effectiveness Issues

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.

The arms race problem: Each layer of protection you add:

Increases maintenance burden significantly
Creates more points of failure
Will be studied and bypassed by motivated actors
Hurts legitimate users more than bad actors

Hardware attestation in particular is notoriously unreliable - it fails on:

Rooted devices (including privacy/security-conscious users)
Custom ROMs (your likely user base)
Older devices
Some legitimate configurations

User Experience Impact

You're proposing to add friction for every legitimate user to stop automated systems, but:

Power users (your core audience) often run rooted devices
Captchas are annoying and accessibility-hostile
Network/API dependencies create new failure modes
You're making the tool harder to use for people who should be using it

Philosophical Concerns

If ReVanced is open source, this approach seems fundamentally at odds with that ethos:

You're trying to implement DRM on open source software
Gating source code access contradicts open source principles
You're treating your users as adversaries to be controlled rather than collaborators

Alternative Approaches to Consider

Instead of complex technical barriers, consider:

Legal/Policy measures - If prebuilds violate terms, pursue that angle
Make official builds more attractive - Better UX, faster updates, verified safety
Accept it's unpreventable - Focus energy on what you can control
Community education - Help users understand why official sources are better

The Real Question

What problem are you actually trying to solve?

If it's automated redistribution harming users → focus on making official channels better
If it's unauthorized monetization → that's a legal/policy issue
If it's just annoyance at automation → is the cost worth it?

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.

What's the actual harm you're trying to prevent? That might lead to more practical solutions.