Live data from Hacker News

No user accounts, by design

f-droid.org

21–30 of 147 posts

Re: No user accounts, by design

#21
post #19
post #17

I tried something like this once and it worked surprisingly well, even for a UGC site. Years back we were doing something that included users documenting TV shows. We had a big meeting where people put every feature they wanted on index cards. We laid the cards out a founder's dining room table. The host got their change jar and each person got a certain number of pennies to mark features they thought were vital for…

What about abuse/vandalism? If the whole web has edit privileges, what's to stop someone from scripting changing all of the titles to random strings every hour? Do you do a captcha on every edit or something? I think the main idea around user accounts is that they centralize a point of applying captchas as well as a tiny bit of data collection (some form of contact information) that can be used for antispam (e.g. ban…

I'm familiar with the theory. But accounts just aren't a big barrier to determined bad actors.

Note that the world's biggest content site, Wikipedia, allows anonymous edits and always has. And note also that some of big tech companies, despite having all the money in the world, still have problems with fake accounts. So at best, requiring user accounts is one possible anti-abuse step, but it's neither necessary nor sufficient to prevent abuse.

Re: No user accounts, by design

#22
post #18

App developer's perspective. I have a few apps on all major places, including F-Droid. The 'no user accounts' thing makes developing and distributing on F-Droid a freeing experience, as compared to the G/A 'jails'. There is no pressure to meet arbitrary undocumented restrictions, you are not subject to the whims of dehumanizing AI routines, there are no ratings and reviews (the feedback is direct). The build and depl…

I find the distributor-does-the-building-and-signing to be problematic from a security point of view. I would much prefer that each developer does a build, signs it, and a notarization of some kind is added by the distributor. It seems to me that if you can compromise the f-droid infrastructure you can compromise millions of handsets.

F-Droid already supports this. From GP's link:

> This means that F-Droid can verify that an app is 100% free software while still using the original developer’s APK signatures

Re: No user accounts, by design

#23
post #14
post #12

Earlier quoted context omitted.

The article gives specific examples like virtual meeting software that doesn't have users, just URLs. It's more than that.

The solution for that is easy: Don't share the new URL with someone that was a jerk in the past. (And don't make it easy to guess meeting URLs)

How do you share a URL without a user representation to share with? How do you prevent others from sharing URLs with bad actors? Or meeting passwords?

https://en.wikipedia.org/wiki/Zoombombing

Re: No user accounts, by design

#24
I've been thinking a lot about this for https://www.diffdiff.net. After convenience, privacy is the core of the value proposition - the text to diff doesn't get sent to the server.

On the other hand, though, if you want to publish/share a diff, then, you know, privacy is the core of the value proposition, so you probably don't want to share it with the whole world, much less let the whole world edit or delete it!

It's possible to design a scheme with hard-to-guess URLs, URL parameters with "secret edit tokens" and so on, but that feels hard to use and different from how other sites work.

I'm quite torn.

Re: No user accounts, by design

#26
post #24

I've been thinking a lot about this for https://www.diffdiff.net . After convenience, privacy is the core of the value proposition - the text to diff doesn't get sent to the server. On the other hand, though, if you want to publish/share a diff, then, you know, privacy is the core of the value proposition , so you probably don't want to share it with the whole world, much less let the whole world edit or delete it! I…

The way mega.nz works is the sharable url contains a decryption key in the hash. The server only sees encrypted data, the client requests that data then decrypts it. This design ensures they have no ability to see user content, while still enabling users to share links on the web.

Re: No user accounts, by design

#27
post #21
post #19

Earlier quoted context omitted.

What about abuse/vandalism? If the whole web has edit privileges, what's to stop someone from scripting changing all of the titles to random strings every hour? Do you do a captcha on every edit or something? I think the main idea around user accounts is that they centralize a point of applying captchas as well as a tiny bit of data collection (some form of contact information) that can be used for antispam (e.g. ban…

I'm familiar with the theory. But accounts just aren't a big barrier to determined bad actors. Note that the world's biggest content site, Wikipedia, allows anonymous edits and always has. And note also that some of big tech companies, despite having all the money in the world, still have problems with fake accounts. So at best, requiring user accounts is one possible anti-abuse step, but it's neither necessary nor s…

> Note that the world's biggest content site, Wikipedia, allows anonymous edits and always has.

Not really. You can't edit Wikipedia from a VPN (even with a user account!), and I think they ban most datacenters. The edits aren't really anonymous if they publicly associate with a piece of PII that, for most people, directly maps to their name and home address.

Re: No user accounts, by design

#28
post #26
post #24

I've been thinking a lot about this for https://www.diffdiff.net . After convenience, privacy is the core of the value proposition - the text to diff doesn't get sent to the server. On the other hand, though, if you want to publish/share a diff, then, you know, privacy is the core of the value proposition , so you probably don't want to share it with the whole world, much less let the whole world edit or delete it! I…

The way mega.nz works is the sharable url contains a decryption key in the hash. The server only sees encrypted data, the client requests that data then decrypts it. This design ensures they have no ability to see user content, while still enabling users to share links on the web.

They still have the ability to see user content, but it would require them to make a change to their codebase. If they did such a change silently...

Re: No user accounts, by design

#29
post #21
post #19

Earlier quoted context omitted.

What about abuse/vandalism? If the whole web has edit privileges, what's to stop someone from scripting changing all of the titles to random strings every hour? Do you do a captcha on every edit or something? I think the main idea around user accounts is that they centralize a point of applying captchas as well as a tiny bit of data collection (some form of contact information) that can be used for antispam (e.g. ban…

I'm familiar with the theory. But accounts just aren't a big barrier to determined bad actors. Note that the world's biggest content site, Wikipedia, allows anonymous edits and always has. And note also that some of big tech companies, despite having all the money in the world, still have problems with fake accounts. So at best, requiring user accounts is one possible anti-abuse step, but it's neither necessary nor s…

Accounts alone won't do it. Accounts and invites might? But then someone who doesn't know anyone on the site needs to figure out how to contact someone who's a member.

It's not good for growth, but some websites are fine with that.

Re: No user accounts, by design

#30
F-droid gets many things right (e.g. verifiable builds), but it's just not usable in practice.

Installing applications is a rare event, updating them is frequent, and needs to disrupt the user as little as possible. Android used to not allow alternative app stores to update apps without user interaction, but now supports this through UPDATE_PACKAGES_WITHOUT_USER_ACTION, which doesn't seem to be supported by F-droid. So it's manual clicking for each update.

F-droid also somehow gets the regular update flow wrong and often (always?) shows an error when you try to install the update from the notification. That has remained unfixed for years. So you have to manually open it, initiate the update, then click through the dialogs.

Additionally, the official repos update so slowly that they're useless for fast-moving stuff like NewPipe.

Together with Android bugs like https://issuetracker.google.com/issues/204233247 (resetting all "open with" URIs on update), this makes using packages installed through F-Droid a nightmare.

Post reply on HN