Some clean up and adding Signals #16
Conversation
sysrqb
commented
Nov 1, 2021
sysrqb
commented
- Tried improved readability
- Deleted Reputation Requirements section (hopefully only temporarily) - but I felt it was a distraction right now, we can re-add it later
- Added a new section on replacement signals, and associated commentary.
- Added a new reference to Private Access Tokens
|
|
||
| - $ publisher norms: Standard expections of publishers including identity transparency and conflicts of interest. | ||
| - $ protocol improvements: Increasing security of existing protocols. |
There was a problem hiding this comment.
Thinking about business email compromise, as an example we use later, are there better and more recent improvements than OpenPGP and S/MIME for authenticating the sender of a message? MLS comes to mind but seems like a stretch without suggesting entirely deprecating email.
There was a problem hiding this comment.
We can delay this one until later. #21
|
|
||
| In the following the requirements of reputation signals are listed. Note that by "client(s)" it is intended an end user device (e.g., a PC or a mobile phone), while by "server(s)" it is intended a device offering an Internet service, which belong to an organisation/company but is not a personal device. | ||
| - $ ADDRESS_ESCROW: Provides sufficient information for retroactively obtaining a client's IP address. | ||
| - $ PEER_INTEGRITY: Provides a secure, remote attestation of hardware and/or software state. |
There was a problem hiding this comment.
Do we have a use case for this? Including this as a replacement signal is a little confusing without it helping solve an anti-abuse use case.
There was a problem hiding this comment.
device integrity signals can make it harder for bots to go undetected
There was a problem hiding this comment.
That's a good point, thanks.
|
I'll rebase commits before merging. |
