From 58eff0f840b3f98f11be1593f8e28988d648c42f Mon Sep 17 00:00:00 2001 From: No Date: Tue, 10 May 2022 18:46:21 -0400 Subject: [PATCH 1/7] Create obfuscated-events.md --- proposals/obfuscated-events.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 proposals/obfuscated-events.md diff --git a/proposals/obfuscated-events.md b/proposals/obfuscated-events.md new file mode 100644 index 000000000..8b1378917 --- /dev/null +++ b/proposals/obfuscated-events.md @@ -0,0 +1 @@ + From a1cc3981d096865b70b841add4fe4ce161225186 Mon Sep 17 00:00:00 2001 From: No Date: Tue, 10 May 2022 18:48:09 -0400 Subject: [PATCH 2/7] Add template --- proposals/{obfuscated-events.md => 3813-obfuscated-events.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{obfuscated-events.md => 3813-obfuscated-events.md} (100%) diff --git a/proposals/obfuscated-events.md b/proposals/3813-obfuscated-events.md similarity index 100% rename from proposals/obfuscated-events.md rename to proposals/3813-obfuscated-events.md From 9ae081d13ccb578b55b38e23fda894f36624aca4 Mon Sep 17 00:00:00 2001 From: No Date: Tue, 10 May 2022 18:48:24 -0400 Subject: [PATCH 3/7] Update 3813-obfuscated-events.md --- proposals/3813-obfuscated-events.md | 110 ++++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) diff --git a/proposals/3813-obfuscated-events.md b/proposals/3813-obfuscated-events.md index 8b1378917..55e096943 100644 --- a/proposals/3813-obfuscated-events.md +++ b/proposals/3813-obfuscated-events.md @@ -1 +1,111 @@ +# MSC0000: Template for new MSCs + +*Note: Text written in italics represents notes about the section or proposal process. This document +serves as an example of what a proposal could look like (in this case, a proposal to have a template) +and should be used where possible.* + +*In this first section, be sure to cover your problem and a broad overview of the solution. Covering +related details, such as the expected impact, can also be a good idea. The example in this document +says that we're missing a template and that things are confusing and goes on to say the solution is +a template. There's no major expected impact in this proposal, so it doesn't list one. If your proposal +was more invasive (such as proposing a change to how servers discover each other) then that would be +a good thing to list here.* + +*If you're having troubles coming up with a description, a good question to ask is "how +does this proposal improve Matrix?" - the answer could reveal a small impact, and that is okay.* + +There can never be enough templates in the world, and MSCs shouldn't be any different. The level +of detail expected of proposals can be unclear - this is what this example proposal (which doubles +as a template itself) aims to resolve. + + +## Proposal + +*Here is where you'll reinforce your position from the introduction in more detail, as well as cover +the technical points of your proposal. Including rationale for your proposed solution and detailing +why parts are important helps reviewers understand the problem at hand. Not including enough detail +can result in people guessing, leading to confusing arguments in the comments section. The example +here covers why templates are important again, giving a stronger argument as to why we should have +a template. Afterwards, it goes on to cover the specifics of what the template could look like.* + +Having a default template that everyone can use is important. Without a template, proposals would be +all over the place and the minimum amount of detail may be left out. Introducing a template to the +proposal process helps ensure that some amount of consistency is present across multiple proposals, +even if each author decides to abandon the template. + +The default template should be a markdown document because the MSC process requires authors to write +a proposal in markdown. Using other formats wouldn't make much sense because that would prevent authors +from copy/pasting the template. + +The template should have the following sections: + +* **Introduction** - This should cover the primary problem and broad description of the solution. +* **Proposal** - The gory details of the proposal. +* **Potential issues** - This is where problems with the proposal would be listed, such as changes + that are not backwards compatible. +* **Alternatives** - This section lists alternative solutions to the same + problem which have been considered and dismsissed. +* **Security considerations** - Discussion of what steps were taken to avoid security issues in the + future and any potential risks in the proposal. + +Furthermore, the template should not be required to be followed. However it is strongly recommended to +maintain some sense of consistency between proposals. + + +## Potential issues + +*Not all proposals are perfect. Sometimes there's a known disadvantage to implementing the proposal, +and they should be documented here. There should be some explanation for why the disadvantage is +acceptable, however - just like in this example.* + +Someone is going to have to spend the time to figure out what the template should actually have in it. +It could be a document with just a few headers or a supplementary document to the process explanation, +however more detail should be included. A template that actually proposes something should be considered +because it not only gives an opportunity to show what a basic proposal looks like, it also means that +explanations for each section can be described. Spending the time to work out the content of the template +is beneficial and not considered a significant problem because it will lead to a document that everyone +can follow. + + +## Alternatives + +*This is where alternative solutions could be listed. There's almost always another way to do things +and this section gives you the opportunity to highlight why those ways are not as desirable. The +argument made in this example is that all of the text provided by the template could be integrated +into the proposals introduction, although with some risk of losing clarity.* + +Instead of adding a template to the repository, the assistance it provides could be integrated into +the proposal process itself. There is an argument to be had that the proposal process should be as +descriptive as possible, although having even more detail in the proposals introduction could lead to +some confusion or lack of understanding. Not to mention if the document is too large then potential +authors could be scared off as the process suddenly looks a lot more complicated than it is. For those +reasons, this proposal does not consider integrating the template in the proposals introduction a good +idea. + + +## Security considerations + +*Some proposals may have some security aspect to them that was addressed in the proposed solution. This +section is a great place to outline some of the security-sensitive components of your proposal, such as +why a particular approach was (or wasn't) taken. The example here is a bit of a stretch and unlikely to +actually be worthwhile of including in a proposal, but it is generally a good idea to list these kinds +of concerns where possible.* + +By having a template available, people would know what the desired detail for a proposal is. This is not +considered a risk because it is important that people understand the proposal process from start to end. + +## Unstable prefix + +*If a proposal is implemented before it is included in the spec, then implementers must ensure that the +implementation is compatible with the final version that lands in the spec. This generally means that +experimental implementations should use `/unstable` endpoints, and use vendor prefixes where necessary. +For more information, see [MSC2324](https://github.com/matrix-org/matrix-doc/pull/2324). This section +should be used to document things such as what endpoints and names are being used while the feature is +in development, the name of the unstable feature flag to use to detect support for the feature, or what +migration steps are needed to switch to newer versions of the proposal.* + +## Dependencies + +This MSC builds on MSCxxxx, MSCyyyy and MSCzzzz (which at the time of writing have not yet been accepted +into the spec). From 13cd6cc19fcf75b6e548400d05e872b97b919d05 Mon Sep 17 00:00:00 2001 From: No Date: Tue, 10 May 2022 19:24:01 -0400 Subject: [PATCH 4/7] Update 3813-obfuscated-events.md --- proposals/3813-obfuscated-events.md | 95 ++++++++++++++++++++++++++--- 1 file changed, 85 insertions(+), 10 deletions(-) diff --git a/proposals/3813-obfuscated-events.md b/proposals/3813-obfuscated-events.md index 55e096943..2d19da663 100644 --- a/proposals/3813-obfuscated-events.md +++ b/proposals/3813-obfuscated-events.md @@ -1,6 +1,6 @@ -# MSC0000: Template for new MSCs +# MSC3813: Obfuscated events -*Note: Text written in italics represents notes about the section or proposal process. This document + +Currently, event content can be end-to-end encrypted, but the metadata cannot. This means that if +someone inspects the Matrix homeservers, they can see in what rooms one is most active, and at what +time they are most active. + +We propose that clients send "dummy" events from time to time, at random intervals and times, in +random rooms to obfuscate the user's online times and relationships. It is mainly intended to +imitate the structure of two-sided conversations. ## Proposal -*Here is where you'll reinforce your position from the introduction in more detail, as well as cover + +### Introduction + +### Events + +We add the following types of events: + +#### `m.obfuscate.request` + +Initiates a request to send obfuscated events to the other party. + +Content attributes: + +| Name | Type | Comments | +|------|------|----------| +| version | string | Must be `v0`. | +| min_interval | number | Minimum interval, in seconds, between two keepalive events. | +| max_interval | number | Maximum interval, in seconds, between two keepalive events. | +| retries | number | The number of retries that can be sent in keepalive events if the other party does not respond in a timely manner. | +| payload | string | Can be arbitrary content. | + +The attributes `min_interval`, `max_interval` and `retries` indicates the parameters this party will stick to, not the parameters it expects the other party to stick to. + +#### `m.obfuscate.accept` + +Indicates that this party is willing to exchange obfuscated events with the other party. + +| Name | Type | Comments | +|------|------|----------| +| version | string | Must be `v0`. | +| min_interval | number | Minimum interval, in seconds, between two keepalive events. | +| max_interval | number | Maximum interval, in seconds, between two keepalive events. | +| retries | number | The number of retries that can be sent in keepalive events if the other party does not respond in a timely manner. | +| payload | string | Can be arbitrary content. | + +The attributes `min_interval`, `max_interval` and `retries` indicates the parameters this party will stick to, not the parameters it expects the other party to stick to. + +#### `m.obfuscate.reject` + +Indicates that this party is not willing to exchange obfuscated events with the other party, or wants to stop doing so. + +| Name | Type | Comments | +|------|------|----------| +| version | string | Must be `v0`. | +| duration | number | Tells the other party how long, in seconds, they should not send a request again. -1 means they should never send requests again. 0 means they can send again immediately. | +| payload | string | Can be arbitrary content. | + +#### `m.obfuscate.keepalive` + +The keepalive message that imitates the structure of a conversation. + +| Name | Type | Comments | +|------|------|----------| +| version | string | Must be `v0`. | +| payload | string | Can be arbitrary content. | + +### Client behaviour + +Clients MUST negotiate to exchange obfuscated events before sending the keepalive messages. + +### Server behaviour ## Potential issues @@ -85,7 +152,7 @@ idea. ## Security considerations -*Some proposals may have some security aspect to them that was addressed in the proposed solution. This + + +The events MUST be sent in end-to-end encrypted rooms. + + +The payload SHOULD be randomly generated, and with random lengths. It SHOULD ideally be similar in length to other non-obfuscated +events in the room. ## Unstable prefix -*If a proposal is implemented before it is included in the spec, then implementers must ensure that the + + +Please use `moe.kazv.mxc.msc.obfuscated-events` as the unstable prefix. ## Dependencies -This MSC builds on MSCxxxx, MSCyyyy and MSCzzzz (which at the time of writing have not yet been accepted -into the spec). +No hard dependencies. From 629e4b1052b75b59d7ecda99e6562eda010959ed Mon Sep 17 00:00:00 2001 From: uranuspucksaxophone <84784521+uranuspucksaxophone@users.noreply.github.com> Date: Sun, 15 May 2022 16:47:46 +0200 Subject: [PATCH 5/7] Update 3813-obfuscated-events.md --- proposals/3813-obfuscated-events.md | 90 ----------------------------- 1 file changed, 90 deletions(-) diff --git a/proposals/3813-obfuscated-events.md b/proposals/3813-obfuscated-events.md index 2d19da663..c594e35ed 100644 --- a/proposals/3813-obfuscated-events.md +++ b/proposals/3813-obfuscated-events.md @@ -1,23 +1,5 @@ # MSC3813: Obfuscated events - - Currently, event content can be end-to-end encrypted, but the metadata cannot. This means that if someone inspects the Matrix homeservers, they can see in what rooms one is most active, and at what time they are most active. @@ -28,35 +10,6 @@ imitate the structure of two-sided conversations. ## Proposal - ### Introduction ### Events @@ -121,47 +74,12 @@ Clients MUST negotiate to exchange obfuscated events before sending the keepaliv ## Potential issues -*Not all proposals are perfect. Sometimes there's a known disadvantage to implementing the proposal, -and they should be documented here. There should be some explanation for why the disadvantage is -acceptable, however - just like in this example.* - -Someone is going to have to spend the time to figure out what the template should actually have in it. -It could be a document with just a few headers or a supplementary document to the process explanation, -however more detail should be included. A template that actually proposes something should be considered -because it not only gives an opportunity to show what a basic proposal looks like, it also means that -explanations for each section can be described. Spending the time to work out the content of the template -is beneficial and not considered a significant problem because it will lead to a document that everyone -can follow. - ## Alternatives -*This is where alternative solutions could be listed. There's almost always another way to do things -and this section gives you the opportunity to highlight why those ways are not as desirable. The -argument made in this example is that all of the text provided by the template could be integrated -into the proposals introduction, although with some risk of losing clarity.* - -Instead of adding a template to the repository, the assistance it provides could be integrated into -the proposal process itself. There is an argument to be had that the proposal process should be as -descriptive as possible, although having even more detail in the proposals introduction could lead to -some confusion or lack of understanding. Not to mention if the document is too large then potential -authors could be scared off as the process suddenly looks a lot more complicated than it is. For those -reasons, this proposal does not consider integrating the template in the proposals introduction a good -idea. - ## Security considerations - - The events MUST be sent in end-to-end encrypted rooms. @@ -170,14 +88,6 @@ events in the room. ## Unstable prefix - - Please use `moe.kazv.mxc.msc.obfuscated-events` as the unstable prefix. ## Dependencies From f7d55580596564af3a02161fc9f28c71de7a73ec Mon Sep 17 00:00:00 2001 From: uranuspucksaxophone <84784521+uranuspucksaxophone@users.noreply.github.com> Date: Sun, 15 May 2022 16:57:26 +0200 Subject: [PATCH 6/7] Update 3813-obfuscated-events.md --- proposals/3813-obfuscated-events.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/proposals/3813-obfuscated-events.md b/proposals/3813-obfuscated-events.md index c594e35ed..7d28a8d24 100644 --- a/proposals/3813-obfuscated-events.md +++ b/proposals/3813-obfuscated-events.md @@ -9,9 +9,9 @@ random rooms to obfuscate the user's online times and relationships. It is mainl imitate the structure of two-sided conversations. ## Proposal - +TBD ### Introduction - +TBD ### Events We add the following types of events: @@ -70,14 +70,11 @@ The keepalive message that imitates the structure of a conversation. Clients MUST negotiate to exchange obfuscated events before sending the keepalive messages. ### Server behaviour - - +TBD ## Potential issues - - +TBD ## Alternatives - - +TBD ## Security considerations The events MUST be sent in end-to-end encrypted rooms. @@ -93,4 +90,3 @@ Please use `moe.kazv.mxc.msc.obfuscated-events` as the unstable prefix. ## Dependencies No hard dependencies. - From 0559a9546c0e2f229825658b75fa9320998c59fc Mon Sep 17 00:00:00 2001 From: uranuspucksaxophone <84784521+uranuspucksaxophone@users.noreply.github.com> Date: Thu, 21 Jul 2022 19:57:25 +0200 Subject: [PATCH 7/7] Refactor and remove non-used sections. --- proposals/3813-obfuscated-events.md | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/proposals/3813-obfuscated-events.md b/proposals/3813-obfuscated-events.md index 7d28a8d24..f0e633e28 100644 --- a/proposals/3813-obfuscated-events.md +++ b/proposals/3813-obfuscated-events.md @@ -1,5 +1,6 @@ # MSC3813: Obfuscated events +## Introduction Currently, event content can be end-to-end encrypted, but the metadata cannot. This means that if someone inspects the Matrix homeservers, they can see in what rooms one is most active, and at what time they are most active. @@ -7,11 +8,6 @@ time they are most active. We propose that clients send "dummy" events from time to time, at random intervals and times, in random rooms to obfuscate the user's online times and relationships. It is mainly intended to imitate the structure of two-sided conversations. - -## Proposal -TBD -### Introduction -TBD ### Events We add the following types of events: @@ -69,12 +65,8 @@ The keepalive message that imitates the structure of a conversation. Clients MUST negotiate to exchange obfuscated events before sending the keepalive messages. -### Server behaviour -TBD ## Potential issues TBD -## Alternatives -TBD ## Security considerations The events MUST be sent in end-to-end encrypted rooms.