wesbiggs
commented
1 year ago We had a discussion a while back about the realistic attack vectors for Bob.
In one case, he simply "reposts" Alice's content. While this may appear deceptive to a casual observer who hasn't seen Alice's original post, unless there is an untrustworthy intermediary (see next paragraph), Alice (or anyone else) can eventually prove that her announcement was published first, assuming the system provides a means of unambiguously ordering batches (in DSNP Over Frequency, this is the block counter; Bob's announcement would be in a later block than Alice's).
An untrustworthy intermediary—either an application provider or a system service provider (e.g. a node operator)—could theoretically front-run and insert Bob's announcement into the same block as Alice's. I'm not entirely clear if this is actually possible with the transaction pool on Frequency, but I'll guess it's theoretically possible, but sounds fairly hard to accomplish. This type of front-running would be harder to detect forensically. For a rogue application provider to do so, they would need to be the same application provider for both Bob and Alice; it follows that they're already in a position of trust that can be abused in any number of ways (posting fraudulent content, etc.), so while possible, a provider attack wouldn't significantly change the trust profile.
Along with "who said it first", the other feature of content ownership tagging is non-repudiation. That is, once I make a statement, I can't claim it was actually made by someone else. Tagging with a DSNP User Id does not provide this; we would need an option for a cryptographic signature within the content; this is discussed (and rejected) in the main issue text.
Given that DSNP activity content is not currently intended to be used for real-world commitments/transactions, it's hard to come up with a great deal of use cases where content-level non-repudiation is necessary. (Attestation is where this is more important, but that will have its own linked content that can expose signatures.) Non-repudiation would provide a stronger defense against rogue providers (if the signature key was not shared with those providers), but from a practical point of view does not accomplish much more than delegation revocation and key rotation already allows. And non-repudiation could be done in-band; Twitter users sometimes post a plaintext hash or signature within a tweet.
For all these reasons, I am comfortable closing this DIP, unless this discussion spurs anyone else to come up with a use case where this feature would provide real value.
wilwade
Abstract
By specifying how to use the "actor" key in Activity Content (Note and Profile) referenced from DSNP Announcements, we can achieve better trust in the authenticity of the provenance of the content.
Motivation
The current DSNP Activity Content specification does not mandate the use of "actor" to indicate the originator of a piece of content (in DSNP, a Note or Profile). Because of this, it would be possible for Bob to create an Announcement referencing the same Activity Content item that Alice has published, thus claiming it as his own. Alice may already have posted the Announcement, or Bob might be able to execute a form of man-in-the-middle attack where he front-runs the Announcement, claiming afterward that Alice was the plagiarist. While this scenario may be unlikely for the vast majority of user-generated content, preserving provenance is important when dealing with sensitive, controversial, or novel content.
Specification Pull Request
The specification will be updated to encourage the use of the DSNP User URI in Note and Profile Activity Content objects as the actor key. The key (and its usage) can remain optional; there may still be reasons why users want to reference content created using non-DSNP systems, or content that is meant to be Announced by multiple users.
For example,
"actor": "dsnp://1311768467294899700"The spec should mandate that applications treat as invalid (or at least warn when encountering) any content where the actor is a DSNP User URI but does not match the
senderIdindicated in the corresponding Announcement.PR: #255
Rationale
The "actor" key is already defined in the W3C Activity Content spec and it seems intended to have semantics that can be contextually defined.
An alternative approach would be to add a digital signature to the Activity Content. This has several disadvantages: (1) It requires a user (or their user agent/application) to have access to their signing key with every broadcast or reply; this then requires a tradeoff between security and usability. (2) It's unnecessary; there is already a signature or delegation signature chain leading to the Note/Profile. (3) There is no single common approach for adding signatures to JSON data; various approaches either end up encoding the entirety of the Note to form an envelope, which wastes space, or requiring a priori information about how to remove the signature in order to compute the original content hash. Other approaches require the signature to be embedded in HTTP headers, which (while still compatible with this approach) would place an additional technical burden on web hosts providing access, and may not be compatible with future content access protocols (e.g. IPFS) or HTTP gateways to the same.
In contrast, "actor" is a well-defined key, even if its semantics are intentionally undefined in the Activity Content 2.0 spec. The usage of a DSNP User URI in this field clearly indicates that the creator of the content is a DSNP User.
Backwards Compatibility
As long as the actor key is considered optional, there are no backward compatibility issues; however, it would be useful to specify what version of DSNP this field was introduced in, so that applications can behave accordingly with respect to user experience.
Reference Implementation and/or Tests
Any Note- or Profile-generating tests should be updated to include the actor key.
Security Considerations
This change doesn't solve the copy-paste issue; Bob can take the content of Alice's Note, for example, and make a new Note that he is free to create an Announcement for. Given the untrustworthiness of timestamps in off-chain content, it might still be possible for frontrunning to occur in copy-paste, if the two copies were in different batches submitting at different times.
This change does prevent "content freeloading", however; given that there is a non-zero cost for the storage of Alice's content, if Bob wants to post the same content, he should incur cost as well.
Dependencies
N/A
References
Activity Content: Actor
Copyright
Copyright and related rights waived via CC0.