View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 4914 | Composr | core | public | 2022-09-01 02:21 | 2024-03-30 16:14 |
| Reporter | Chris Graham | Assigned To | Guest | ||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Summary | 4914: Radical Privacy (holding issue) | ||||
| 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. | ||||
| Tags | Roadmap: Over the horizon, Roadmap: v11 partial implementation, Type: Legal compliance / Privacy, Type: Standards compliance | ||||
| Attach Tags | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
| related to | 2140 | Not Assigned | Guest | Composr | User tracking system (to replace cookies) |
| related to | 4931 | Resolved | PDStig | Composr | Allow disabling anonymous transactions |
| related to | 4962 | Resolved | PDStig | Composr | Points for people loyal to privacy and Open Source |
| related to | 3792 | Not Assigned | Guest | Composr website (compo.sr) | Host on geo-distributed ARM cluster |
| related to | 5065 | Not Assigned | Guest | Composr | Google fonts violating GDPR / General privacy around IP and referrer transfer to third parties / Need superset of cookie consent |
| related to | 3540 | Not Assigned | Guest | Composr | De-Googleificiation (idea staging issue) |
|
|
Some of this has been moved out for early implementation into v11, as it relates to points which we are currently overhauling... 4931 4962 Other stuff will be moved out too over time, until eventually this issue no longer exists. |
|
|
Also look at the DNT and GCP headers (https://globalprivacycontrol.org/), and see if we can implement support for them. Document our use in tut_markup if we do. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-09-01 02:21 | Chris Graham | New Issue | |
| 2022-09-01 02:21 | Chris Graham | Tag Attached: Roadmap: v12 | |
| 2022-09-01 02:21 | Chris Graham | Tag Attached: Type: Legal compliance | |
| 2022-09-01 02:23 | Chris Graham | Tag Renamed | Type: Legal compliance => Type: Legal compliance / Privacy |
| 2022-09-01 02:23 | Chris Graham | Relationship added | related to 3792 |
| 2022-09-01 02:24 | Chris Graham | Relationship added | related to 2140 |
| 2022-09-01 17:56 | Chris Graham | Description Updated | |
| 2022-09-01 18:10 | Chris Graham | Description Updated | |
| 2022-09-02 20:33 | Chris Graham | Description Updated | |
| 2022-09-02 20:51 | Chris Graham | Description Updated | |
| 2022-10-03 17:30 | Chris Graham | Description Updated | |
| 2022-10-04 17:18 | Chris Graham | Description Updated | |
| 2022-10-04 17:18 | Chris Graham | Tag Attached: Roadmap: v11 partial implementation | |
| 2022-10-04 17:19 | Chris Graham | Note Added: 0007537 | |
| 2022-10-05 23:54 | Chris Graham | Note Added: 0007542 | |
| 2022-10-05 23:54 | Chris Graham | Tag Attached: Type: Standards compliance | |
| 2022-11-22 18:11 | Chris Graham | Relationship added | related to 5065 |
| 2022-11-22 18:53 | Chris Graham | Relationship added | related to 3540 |
| 2022-11-27 00:55 | Chris Graham | Description Updated | |
| 2024-03-26 00:58 | PDStig | Tag Renamed | Roadmap: v12 => Roadmap: Over the horizon |
| 2024-03-30 16:14 | PDStig | Relationship added | related to 4931 |
| 2024-03-30 16:14 | PDStig | Relationship added | related to 4962 |
