Civcraft / JukeAlert

Do not open issues here; open them on the maintained fork @ DevotedMC
https://github.com/DevotedMC/JukeAlert
BSD 3-Clause "New" or "Revised" License
5 stars 15 forks source link

Add unique quriable hashes to snich log pages #31

Closed Goldmattress closed 8 years ago

Goldmattress commented 9 years ago

Given a command JA requesting a page + "proof"( /jainfo [n] proof should return a hash to the player that allows anyone to then /ja proof [hash] to view the censored version of the page.

rourke750 commented 9 years ago

@ttk2 Thoughts?

jjj5311 commented 9 years ago

Sounds pretty cool

On Saturday, June 20, 2015, rourke750 notifications@github.com wrote:

@ttk2 https://github.com/ttk2 Thoughts?

— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-113712799.

ttk2 commented 9 years ago

One one side its cool. On another I don't like totally doing things for the player like this. It would be much harder to implement but I think the right way to do this would involve a printing press.

But then you just screenshot the printed doc and never make more than one I guess.

So that won't work. Either way this brings us I to addressing the metagame more. It's a direction roruke wants to go as well.

On Sat, Jun 20, 2015, 7:01 AM jjj5311 notifications@github.com wrote:

Sounds pretty cool

On Saturday, June 20, 2015, rourke750 notifications@github.com wrote:

@ttk2 https://github.com/ttk2 Thoughts?

— Reply to this email directly or view it on GitHub <https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-113712799 .

— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-113751114.

ProgrammerDan commented 9 years ago

Actually, ttk, that wouldn't be too hard. What if the snitch itself gave you a special security-type note, that couldn't be replicated in the printing press?

Hit the snitch with a book & quill, it takes the book and gives back hard-proof for the last page accessed by /jainfo as a set of special papers.

Advantages:

The return would be a few papers, not a book -- books are too easy to directly duplicate.

ttk2 commented 9 years ago

that sounds like a good compromise between being possible to totally metagame everything and breaking the metagame and with it lots of interesting ideas, thoughts matta?

erocs commented 9 years ago

"Hit the snitch with a book & quill" except for most snitches being buried. Maybe digging to it is part of the cost.

Part of this is likely to give others a way to verify snitch log screenshots posted to the sub / forum. Spawning a book doesn't do that, but does provide a slow in-game path for people to use. The book would need lore to mark it as official. Can books be edited by players after initially written?

On Sat, Jun 20, 2015 at 9:33 AM, ttk2 notifications@github.com wrote:

that sounds like a good compromise between being possible to totally metagame everything and breaking the metagame and with it lots of interesting ideas, thoughts matta?

— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-113788549.

ttk2 commented 9 years ago

not after they are signed.

ProgrammerDan commented 9 years ago

@erocs That's why I didn't suggest the output to be a book, but paper with special lore. You are reading right, digging to the snitch is the "cost" of getting proof. That was also intentional :)

Alternatively it could be a signed book, I'd just have to carefully test against printing press to be sure duplicates can't be made, and forgeries aren't possible.

erocs commented 9 years ago

Nah, paper would be better then. Is there any other cost to generating these beyond the book'n'quill? What factory / MC recipes is paper used in and could this be abused to generate nearly free paper? The cost of a book includes three paper so I would guess not, but I don't know what recipes are in FactoryMod. There could be a create 1000 book'n'quills for the cost of 10 or some such.

On Sat, Jun 20, 2015 at 10:08 AM, Daniel Boston notifications@github.com wrote:

@erocs https://github.com/erocs That's why I didn't suggest the output to be a book, but paper with special lore. You are reading right, digging to the snitch is the "cost" of getting proof. That was also intentional :)

Alternatively it could be a signed book, I'd just have to carefully test against printing press to be sure duplicates can't be made, and forgeries aren't possible.

— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-113790178.

ProgrammerDan commented 9 years ago

I know for sure that lored paper doesn't work in Printing Press right now; paper is also used as an input to create bookshelves in the Carpentry factory. Haven't tested to make sure lored paper is rejected there.

I'm not aware of other uses of paper in the factory system.

TealNerd commented 9 years ago

Not sure if anyone has thought about this more but I think having it command-based would be better. Forcing it to use a book feels more annoying than anything and just means an insignificant cost of some paper and leather. I think it would be best to have a flag for jainfo to generate a unique key for the page (/jainfo -s maybe?) which returns the page and a unique page id. Then anyone can use /javerify and it returns the page with or without censored coordinates based on how the original log was viewed. Thoughts?

ProgrammerDan commented 9 years ago

Considering this contribution basically brings the discussion full circle, can you address why a meta-game function is superior to an in-game action? E.g. why should "secure verification" of a snitch be free?

TealNerd commented 9 years ago

I don't know I feel like if there is a cost associated there should be more of a cost. Maybe log books created in a factory that you then do /jainfo -log to save it to a log if there's one in your inventory.

ProgrammerDan commented 9 years ago

Howabout the mechanics aspect of it -- overly complex systems involving multiple parts plus an ingame command sounds prohibitive versus smacking the snitch with a book & quill and get back a few Lored Paper items (my proposal).

Goldmattress commented 9 years ago

We want to make a secure system or else there is little use in it, we want people to use snitches to prove that someone did something, the malleability of evidence and the fact that people can't be 100% sure that a snitch log is real undermines this original goal.

I think smacking the snitch makes no sense, it´s supposed to be something anyone, anywhere can access at anytime so long as they have the hash give to them by the owner, the point is to allow the community to verify that the person has not fabricated the logs on a different server. Having the snitch produce a hash along with the page does not seem like such a complex thing from the players perspective and querying it is even simpler.

erocs commented 9 years ago

That was not an original goal. This is new functionality to evolve the purpose of the plugin. On Sep 4, 2015 6:08 AM, "Goldmattress" notifications@github.com wrote:

We want to make a secure system or else there is little use in it, we want people to use snitches to prove that someone did something, the malleability of evidence and the fact that people can't be 100% sure that a snitch log is real undermines this original goal.

I think smacking the snitch makes no sense, it´s supposed to be something anyone, anywhere can access at anytime so long as they have the hash give to them by the owner, the point is to allow the community to verify that the person has not fabricated the logs on a different server. Having the snitch produce a hash along with the page does not seem like such a complex thing from the players perspective and querying it is even simpler.

— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-137731022.

ttk2 commented 9 years ago

@Goldmattress I agree with @erocs that this is a significant expansion of jukealert as far as in game purpose and its already very powerful.

Allowing universal proof of snitch logs is a very big deal, lying is part of human society and we can't just close that off because its annoying, that's part of the point, allowing some sort of local verification (essentially allowing someone else to check that snitch) as @ProgrammerDan proposed is the only way I can see this not becoming impossibly overpowered.

Goldmattress commented 9 years ago

Overpowered? What? The snitches are literally worthless if you can't prove anything with them, a compromised security system has no purpose or credibility.

If we want the game to revolve purely around how much players intrinsically trust each other then I question the use of juke alert at all, surely removing it puts and even larger emphasis on trust and player relations and communications?

erocs commented 9 years ago

You devalue the player's ingenuity. Third party verification has become a topic recently. I think we can agree that the plugin doesn't lend itself well to such a procedure, but the solution for CivCraft isn't to provide perfect security. CivCraft provides players with tools, not solutions.

On Fri, Sep 4, 2015 at 7:51 AM, Goldmattress notifications@github.com wrote:

Overpowered? What? The snitches are literally worthless if you can't prove anything with them, a compromised security system has no purpose or credibility.

If we want the game to revolve purely around how much players intrinsically trust each other then I question the use of juke alert at all, surely removing it puts and even larger emphasis on trust and player relations and communications?

— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-137757595.

TealNerd commented 9 years ago

I think the issue is there's literally no way to verify snitch logs currently. You can't add everyone to your snitches or they become useless, you definitely can't add most people because then everyone would know where your snitches are. Even recording a video of you typing in /jainfo and the information appearing can be easily faked with a very simple forge mod. unless the plugin itself provides a verification method, third party verification isn't possible. Also, JukeAlert is a parallel to a real life security system. With a real security system there's a tape you can share, with snitches there's no physical object or code you can share with others as proof.

erocs commented 9 years ago

I think the issue is there's literally no way to verify snitch logs currently. You can't add everyone to your snitches or they become useless

I think we agree that there's room for improvement.

Also, JukeAlert is a parallel to a real life security system. With a real security system there's a tape you can share

How do you know that tape wasn't faked? Is there a real life command /japroof we can run on the tape to know it's authentic?

TealNerd commented 9 years ago

No but tapes are a lot harder to fake than a snitch log

ttk2 commented 9 years ago

@TealNerd @Goldmattress then would yall be satisfied with an insecure hash that could be faked with a few days of computing power? That's too much metagame for me, but it would be kinda cool until some guy with a GPU farm started selling faked snitch images.

@Goldmattress the point of JukeAlert is to let you know what happened, not to serve as proof for everyone else, its a tool, not a solution to the problem of inter-player trust, in the same way prisonpearl will not make sure your pearling is just and Citadel will let you steal stuff.

Goldmattress commented 9 years ago

No one is going to do that ttk2, no one.

I think we need juke alert to be 100% secure, player trust in incredibly hard to build online, espscially between people that don't talk on mumble, the default is hostility and if we want to see community building we need to have a way for people to prove something happened.

And look even if we have the hash there are still loads of things that can go wrong, most of the time charges are made on incomplete circumstantial evidence and there has often been drama surrounding those incidences and they won't go away with hashes, snitches still only catch a glimpse of what happens and the it's the players job to interpret that data. Interpreting the data is damn meaningless if no one trusts it.

ttk2 commented 9 years ago

We have intentionally avoided making any of our plugins 'perfect' up to this point because the players needed to bridge the gaps, use them not be used by them, to take the step over into a perfectly trustable tool is a big deal.

ProgrammerDan commented 9 years ago

Players definitely need to find their own route to trust. And there needs to be room for that trust to be broken. These are important mechanisms; it breeds uncertainty, which breeds conflict, which breeds growth and resolution.

Even my idea of tapping it with a book&quill is probably going too far, as those would be the "perfect" record you want, just less shareable and damned inconvenient to get. The positive is they add a significant opportunity cost to achieving "perfect" proof. Either have hard to reach snitches that are "safer" from raiders but hard to access for proof purposes, or make snitches easy to reach/get to with easily accessible proof, but at the "cost" of easy detection and removal by the very people you seek to catch in the act.

Edit for Tealnerd: If we implement the idea of Snitches "writing to" a book, you get that physical object -- the tape -- that you could in fact "submit" or share as evidence, and it would be "harder" to forge correctly if we code it right.

Investigation and proof should come at a cost; trust should be player determined and while they should be able to trust that our plugins are accurate, there is no onus on us to provide means for perfect trust between players (especially since as discussed, we're simply raising the bar for forgeries, not preventing them).

I know for some of these plugins we want to move to an API approach. Although I'm still not fully convinced that's a good idea, if we ever do move to that sort of an approach for snitches this issue becomes effectively null and void; then the "trust issue" simply becomes -- do you trust the aggregater that pulled data from your snitches? Etc.

erocs commented 9 years ago

I think we could make a new form of block that improves the ability for 3rd parties to provide verification without making JA all powerful. It would be owned by the 3rd party via reinforcement but tied back to the 1st party's snitch group with some command run by the 1st party. Querying the block to receive verification would take the account name to check, possibly some code to identify the snitch and time frame, and some resource so it isn't a free ride. It would display any relevant jukebox snitch records. It would be vulnerable to being broken, it takes up space in the world, it can only query that single group snitch history, and it requires /jainfo to gather the token knowledge to make the query (keeping the cost of walking physically to the snitch). The 1st party could revoke this special block's link at any time with another command. Attribution rooms would come into existence run by "trusted" players.

On Tue, Sep 8, 2015 at 7:27 AM, Daniel Boston notifications@github.com wrote:

Players definitely need to find their own route to trust. And there needs to be room for that trust to be broken. These are important mechanisms; it breeds uncertainty, which breeds conflict, which breeds growth and resolution.

Even my idea of tapping it with a book&quill is probably going too far, as those would be the "perfect" record you want, just less shareable and damned inconvenient to get. The positive is they add a significant opportunity cost to achieving "perfect" proof. Either have hard to reach snitches that are "safer" from raiders but hard to access for proof purposes, or make snitches easy to reach/get to with easily accessible proof, but at the "cost" of easy detection and removal by the very people you seek to catch in the act.

Investigation and proof should come at a cost; trust should be player determined and while they should be able to trust that our plugins are accurate, there is no onus on us to provide means for perfect trust between players (especially since as discussed, we're simply raising the bar for forgeries, not preventing them).

I know for some of these plugins we want to move to an API approach. Although I'm still not fully convinced that's a good idea, if we ever do move to that sort of an approach for snitches this issue becomes effectively null and void; then the "trust issue" simply becomes -- do you trust the aggregater that pulled data from your snitches? Etc.

— Reply to this email directly or view it on GitHub https://github.com/Civcraft/JukeAlert/issues/31#issuecomment-138581262.

suirad commented 8 years ago

On-topic - Was anything ironed out for this?

Semi-on-topic - An idea i had a while about about meta stuff: Pretty much snitches pages would be exportable. There could be a microservice that is connected to the rabbitmq that listens for a specific message from jukealert. What it would do after that is connect to a civcraft-run pastebin api(or similar/simpler). Using that, players could export the specific page(s) of a snitch log to paste bin page. After that paste is generated, the link is sent back to the player ingame. Of course have some sort of rate limiting to prevent abuse, as well as having the pastes expire after .

ProgrammerDan commented 8 years ago

We should add this to the topic list for one of our meetings, and simply go with what the group decision is at the end of the discussion. Lots of strongly held opinions here. Either that or just let @ttk2 make a firm decision and run with it :P

ttk2 commented 8 years ago

Firm decision, too powerful unless significant other changes are made.