Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Amending reservations against DEP 0006 #49

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Amending reservations against DEP 0006 #49

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions proposals/0006-session-data-extension.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,14 +42,15 @@ The client may respond to the message by emitting an event, so that it may be ha

After publishing this DEP, the "Beaker Browser" will implement a Web API for exposing the `'session-data'` protocol to applications. It will restrict access so that the application code of a `dat://` site will only be able to set the session data for connections related to its own content.


# Drawbacks
[drawbacks]: #drawbacks

- This DEP may present privacy concerns, as it may be used to track users in a similar fashion to HTTP Cookies.
- The payload of the `'session-data'` message is not authenticated in any way. If a public key is sent, proof of ownership of the private key is not provided. The lack of trust must be considered by applications which leverage the data.
- If the recipient of the `'session-data'` message is not authenticated (as is currently the case in all Dat replication connections) the client will not know who is receiving the payload and may broadcast sensitive information.

- By implementing this DEP, servers **can** return different data depending on the session-data as such we must expect that they will. This is hidden behavior that can not be explained without debugging the server within the session state: Users need to be educated about this fact.
- Different data per session can be implemented at the discretion of the server. It may be related to the session data or to unrelated data (time, amount of other users, etc.). The client may never share any data received within a session. To be consistent: every new session needs to be treated as independent from former data received.
- In order to allow users to enter session data, clients need to implement an UI for this as well: if the session data is only machine readable: UI's may be difficult to implement.

# Rationale and alternatives
[alternatives]: #alternatives
Expand All @@ -62,6 +63,7 @@ An alternative approach would be to establish an ephemeral messaging channel, pe
# Changelog
[changelog]: #changelog

- 2018-11-15: Drawback information amended
- 2018-06-06: Merged as draft
- 2018-05-31: First complete draft submitted for review