#4914 - Radical Privacy (holding issue)
-
By Chris Graham
- Added
- 4 views
| Identifier | #4914 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | Radical Privacy (holding issue) |
| Status | Open |
| Tags |
Roadmap: Over the horizon (custom) Roadmap: v11 partial implementation (custom) Type: Legal compliance / Privacy (custom) Type: Standards compliance (custom) |
| Handling member | Deleted |
| Addon | core |
| Description | Goals:
i) Allow a Composr site to be hosted in a somewhat insecure way. Minimal damage if an SQL dump is leaked, as we are passing it around across multiple people hosting the site. ii) Be the opposite of the modern "Big Tech" companies, where all kinds of private/personal data is stored; a Composr site could be the "off the grid" alternative. Composr stands for independence, privacy, security, flexibility. Features/changes around goal i specifically (i.e. forces no private data to be stored even for trusting users)... 1) New "Announce open hosting" option. If set, the default privacy policy explains that anything stored on the database that may be widely shared, and that the site is hosted on many machines that could potentially be hacked or altered - hence don't store or say anything private. 2) New "Private Topics Enabled" option, 3 settings: - Enabled - Enabled with warning that the contents can be seen by others (on private topics, and when creating them) - Disabled If Disabled then notifications can no longer go to private topics. 3) Option to force email addresses to be from a certain domain. Find and document some email anonymization service that we can recommend using with that. The UI must be clear that (and why) email addresses must go through that domain. 4) If e-mail addresses are viewable by guest users in the privileges (which may be done if private topics are disabled and we want to signal a lack of privacy) AND if email addresses are not forced from a certain domain, then have a clause in the privacy policy, an extra agreement checkbox on the join form, and a message in the e-mail description field to use some kind of throwaway e-mail address for privacy reasons. 5) Make sure instant messaging can be disabled. Features/changes around goal i and ii... 1) New "Log IP addresses" option. If disabled then anything in the software about/using IP addresses is disabled and they are not logged in any tables. Guest voting on the forum would need to be prohibited, also. Various clauses in the privacy policy builder would no longer apply (see b). 2) New option to make "invisible" the default log in type. 3) New option to disable "last login time" being visible on on profiles. Or maybe make it per member, and have an option to set what the default is. Needs discussion. 4) Make sure the client_time cookie is not gathered is timezone detection is disabled, and it's not referenced in the privacy policy generator. Changes to privacy policy builder... Generally review the default privacy policy and make sure it doesn't mention anything we can't do when privacy is radically ramped up. Review anything it does still say, could we do more changes so we don't need to say that either? The PRIVACY_*_metadata strings definitely need to change. Additions to admin_privacy... a) Tool in privacy tools to assign random temporary passwords to any member with an insecure password (i.e. any that don't have Composr's most modern hashing+salting). b) Tool in privacy tools to erase any logged IP address (see 2). c) Tool in privacy tools to erase any private topics for any particular member ID, or all members. Marketing... I) The compo.sr website needs to be updated to advertise all this well. I like the new slogan as Composr being "the antidote to big tech". II) The compo.sr website should deploy some of this stuff. III) What PR (podcasts, articles, etc) could this stuff lead to for the project? Documentation... Document all these options/features in a new privacy tutorial, including also: - Disabling timezone detection - Disabling analytics (set stats_store_time to 0) - Disabling any third party trackers or analytics (Google Analytics, Facebook buttons, CSS fonts, etc) - Locking down CSP - Other existing privacy options we already have? Document that session security won't be as good, as IP address checks cannot run. Document that if IP logging is disabled it's highly recommended to force logins for doing any actions on the website. Document that Apache (etc) may do it's own logging and need configuring differently. Testing... Generally check no HTTP calls are going to anything other than the main website domain if all the documented privacy options are locked down and nothing special has been added. Document how to do this check as a webmaster. |
| Steps to reproduce | |
| Related to | #2140 - User tracking system (to replace cookies) |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
#4931
#4962
Other stuff will be moved out too over time, until eventually this issue no longer exists.