Add optional password confirmation to add scroll to click sites

[Fuzzbucket]

3 hours ago, _Charky said:

I intend to have scroll protection activated as standard, with an option to disable it per-user once you log in for the first time. Other sites could quite easily do the same, as long as it's left up to them; if it's not, some will probably shut down rather than having to re-write their entire scroll management process.

 

I don't see why it's necessary to have it as stand\rd - why not make like evina's and offer it.as an option - you get a warning "this scroll is not secure- log in ?" and you choose or don't.

[_Charky]

15 hours ago, Fuzzbucket said:

 

I don't see why it's necessary to have it as stand\rd - why not make like evina's and offer it.as an option - you get a warning "this scroll is not secure- log in ?" and you choose or don't.

It isn't "necessary", but it seems like a reasonable precaution- people would have to log in once to "claim" the account, but then your preference would be stored in the database and you won't have to log in again. Mostly it's just so people who don't even know the site exists don't have to worry about having their eggs added to it without their knowledge. I was planning to store some other user preferences per-scroll in the database too, so it'll be a one-time step for everyone. I'll probably not use the scroll protection myself. I think that's straying from the topic a little though, I'll make a forum thread of my own closer to the time.

[Fuzzbucket]

Sure - but why not invite them to claim the account when they show up, rather than assuming they will want to. Make like evina's, is all I'm suggesting. When I go there, I am logged in and it knows. People can see that's an option the second they arrive. (I'm one of those who feel very strongly that nothing in life should be opt-in by default ! As with cookies - do you or don't you accept... and like those companies that try to suck you in to accepting stuff. I know that's not your plan - but opt-in by default is not something I welcome, even on sites where I plan to opt in willingly.)

[KageSora]

On 1/4/2023 at 8:53 AM, MissK. said:

 

But this is a loophole, I severely doubt it would pass as an intended feature. Trading is for trading, not for protecting your eggs with no intention to trade, especially if it's only applied to public teleports as has been suggested. Regardless, this is not the thead for this discussion so I shouldn't get us even more off topic.

 

On 1/4/2023 at 8:59 AM, Fuzzbucket said:

 

This - and it needs mentioning in this thread so that the loophole doesn't get set up by accident. You can fog indivdual things you don't plan to trade, to prevent views,.

 

I mean, how exactly, do you plan to tell that somebody has done that, though?  I've had multiple times where I set up a trade, kept an egg in there nearly a week, let it hatch, set up a trade, kept in in there nearly a week, then ended up maturing it myself because I simply didn't get any offers that I felt were worthwhile.  I fully intended to trade it if I got an offer I liked--I just never did.  I guarantee that's happened to other people as well.  How would that be easily separated from somebody who simply used a trade as a protected stasis thing?  Especially if they're not on the forums and thus can't be posting in the trade threads to "prove" they want to trade it.

 

But, that's a concern you can definitely bring up in the pause views on trades thread--personally I'd just fog 'em instead of using a loophole, but again I don't think you can necessarily tell who's abusing a loophole and who isn't unless they're doing it for every single dragon they have.

 

On 1/4/2023 at 9:36 AM, _Charky said:

With the theoretical forced scroll verification:

 

1. User inputs scroll name
2. asks DC if the user has scroll protection turned on (a call it didn't have to make when using its own check)
   1. (if protection is on) DC responds to hatchery saying verification is required
   2. (if protection is on) hatchery redirects to DC for login
   3. (if protection is on) DC Redirects to hatchery after successful login
3. DC Redirects to hatchery saying "you can request information now"
4. Hatchery has a think about whether it needs to provide evidence of authorisation to see eggs or not
5. hatchery asks DC for information about user
6. DC provides the information
7. hatchery offers it up for scroll management

Do you see how it's getting more complicated / further from the existing code (and thus, harder to code, slower to process/load, and more likely to kill hatcheries) as we add more verification steps?

 

This, specifically, is more what I meant--I figured this kind of thing was what OP wants for every single fansite.

 

The point about not even needing the API has been brought up by Fuzzbucket a few times, as well--It's a solid reason, IMO, why this suggestion isn't really a viable solution to the issues of viewbombing and trade spoiling.

Edited January 6, 2023 by KageSora

[Fuzzbucket]

3 hours ago, KageSora said:

I mean, how exactly, do you plan to tell that somebody has done that, though?  I've had multiple times where I set up a trade, kept an egg in there nearly a week, let it hatch, set up a trade, kept in in there nearly a week, then ended up maturing it myself because I simply didn't get any offers that I felt were worthwhile.  I fully intended to trade it if I got an offer I liked--I just never did.  I guarantee that's happened to other people as well.  How would that be easily separated from somebody who simply used a trade as a protected stasis thing?  Especially if they're not on the forums and thus can't be posting in the trade threads to "prove" they want to trade it.

 

Exactly. (And for the record I just deliberately bombed something of my own to force a hatch. It's EASY. No fan site required.)

 

3 hours ago, KageSora said:

This, specifically, is more what I meant--I figured this kind of thing was what OP wants for every single fansite.

 

Yes - and a pain.for those of us who don't want to use it, It should absolutely not be on by default, either. Go to fan site "Do you gnat to protect your scroll ?" If no - carry on as you do now - and the cookie for that HOLDS UP, so that it doesn't happen every time..

[HeatherMarie]

9 hours ago, KageSora said:

The point about not even needing the API has been brought up by Fuzzbucket a few times, as well--It's a solid reason, IMO, why this suggestion isn't really a viable solution to the issues of viewbombing and trade spoiling.

 

This is basically why I'm wary of any suggestion like this. It won't actually *solve* anything, certainly won't stop viewbombing, but it could give users a *false* sense of security. Just the fact that it's being suggested in the first place shows that at least some users assume this will safeguard against viewbombing... But it won't. The only thing a suggestion like this *actually* does is stop other people from adding your dragons to fansites, but there are plenty of ways to viewbomb without using the hatcheries at all (and without needing API access, as has been pointed out). 

 

Do we need safeguards against viewbombing? Heck yeah. Is this suggestion actually going to help with that? I doubt it.

[MissK.]

16 minutes ago, HeatherMarie said:

Do we need safeguards against viewbombing? Heck yeah. Is this suggestion actually going to help with that? I doubt it.

 

While I absolutely think that a blanket solution to all types of viewbombing would be awesome, I disagree that this suggestion wouldn't have an effect at all. I post a lot in the trading hub, and have been targeted multiple times, but the vast majority has been people adding my scroll to all hatcheries or specifically ERing low time things. Because that's extremely easy to do right now, without needing special knowledge or completely separate forums/sites. And when eggs get enough UVs through fansites, it's then also possible to viewbomb through an AR. Yes, sometimes I've been viewbombed in other ways, but not having to worry about people adding my stuff to hatcheries would cut down on a lot of trouble already. 

[ACDragonMaster]

I'm not even going to bother quoting specific people because I saw the exact same misunderstanding come up repeatedly, but to clarify:

 

This would be, as suggested, an entirely opt-in feature.  This means that if you don't opt in to using it? Nothing will change for how you use the site or click sites.  This is a very important element and why I included it not only in the first post but right smack in the title of the thread.  Nobody is going to be inconvenienced by it other than maybe click sites having to update how their site interacts with the API when a protected egg/scroll is added, and the viewbombers themselves.  Nobody who doesn't want to use it will be impacted, all that's being proposed is adding an option that would flag a scroll (and the dragons on it) as "verification required" to ALL fansites.  If you don't turn the option on?  It does absolutely nothing.  You continue playing and using the site the same way you always have.

 

Are there other ways to viewbomb, up to and including simply sitting on someone's scroll and hitting the refresh button?  Yes, there are.  Are those methods as easy as it is currently to just toss a scroll (or single egg) into a half-dozen or more different fansites at once? Definitely not.

 

Other than the work it creates for TJ and the question of whether the coding is feasible (which TJ alone can answer) I haven't seen anything on here that really shows a downside, certainly none that would outweigh the benefits that many people have pointed out and affirmed.

 

[KageSora]

30 minutes ago, ACDragonMaster said:

I'm not even going to bother quoting specific people because I saw the exact same misunderstanding come up repeatedly, but to clarify:

 

Yes, you do seem to continually miss the point that if somebody is being targeted and needs protective measures they cease to be truly optional when the choice is "enable this or continue to suffer".

 

If somebody's playstyle would be notably inconvenienced by this measure, they are then forced to choose between "get a new playstyle, take on notable annoyance and frustration, or continue to just put up with other players causing them notable inconvenience and frustration".

[ACDragonMaster]

4 hours ago, KageSora said:

 

Yes, you do seem to continually miss the point that if somebody is being targeted and needs protective measures they cease to be truly optional when the choice is "enable this or continue to suffer".

 

If somebody's playstyle would be notably inconvenienced by this measure, they are then forced to choose between "get a new playstyle, take on notable annoyance and frustration, or continue to just put up with other players causing them notable inconvenience and frustration".

 

So you're basically saying we can't have an optional new protection just because people would have to do an extra step to use it?  When right now we have zero protection and everyone suffers?

 

I'm really not seeing your logic here.  It sounds like you're saying "because some people would choose not to use it due to the inconvenience everyone should continue to have to suffer because it's unfair that others who opt in get extra protection" more or less.  That it's not okay to add a security option for people who wish to use it because not everyone would want to do so.... but that just means the people who choose not to are in the same place as if it never existed.  It changes absolutely nothing.  It doesn't exist now, so a user's playstyle now and methods used to avoid getting viewbombed wouldn't change or be affected at all.  Not unless you count "knowing there's an option and choosing not to use it" to be different in itself, but fundamentally absolutely nothing has to change in anyone's playstyle if they don't want to click the button to opt in.

 

This sounds more like "if I can't have it no one should have it" to me, which is not a terribly productive stance to take.  For that matter, if enough people choose to opt in it may provide a degree of herd immunity for those who don't, as trolls may simply get frustrated enough to be less inclined to try random users' scrolls.  Though that's purely speculation, of course.  What isn't speculation, however, is that there would be absolutely zero changes whatsoever to anyone's playstyle if they don't want it to be.  This would be no different than the already existing option to require password verification to use BSAs and other actions, which players already have to choose whether to opt in and accept the 'hassle' for an added layer of security, or not bother.

[Fuzzbucket]

9 hours ago, ACDragonMaster said:

"verification required" to ALL fansites.  If you don't turn the option on?  It does absolutely nothing. 

 

It should NOT come up with "verification required"; which suggests it is REQUIRED (note that word...)  It should come up with "do you want to log in to protect your scroll". Like evina's already does. Though if it becomes part of the API I'm not sure how easy it would be to avoid using it.

[_Charky]

9 hours ago, ACDragonMaster said:

Other than the work it creates for TJ and the question of whether the coding is feasible (which TJ alone can answer) I haven't seen anything on here that really shows a downside, certainly none that would outweigh the benefits that many people have pointed out and affirmed.

 

You don't need TJ to answer that at all. He definitely could code it, I just doubt he's going to, and THAT only he can say.

 

I'm guessing that you're counting "half of the hatcheries close because their owners don't want to re-write the entire thing" as downside which outweighs the benefits? Interesting perspective.

[Fuzzbucket]

2 hours ago, _Charky said:

 

I'm guessing that you're counting "half of the hatcheries close because their owners don't want to re-write the entire thing" as downside which outweighs the benefits? Interesting perspective.

 

That would be a downside. But we can protect our scrolls by hiding them and using evina's right now anyway. I don't support this - but if it were to happen, it has to be a "do you want to log in," NOT something you have to opt OUT of.

 

[11th]

Maybe I'm misunderstanding, but this sounds like something that we can already do: Hide our scrolls.

 

There are only two "big" hatcheries that allow growing things to be added via code. One of those two only accepts ER codes specifically. The other isn't particularly threatening unless the creature is below 4d 1h. Other hatcheries are not able to add creatures from hidden scrolls, even if the user's scroll name is visible. (ex. On the hub, or on view pages.) Auto-refreshing tools such as FART don't add UVs, only OVs, which greatly limits the amount of damage that can be done with them.

 

If someone insists on targeting things from hidden scrolls despite all of that, then they are less likely to be stopped by the inability to use hatcheries to do the dirty work. That is the same problem that this suggestion would have. If the problem still is that you don't want your (entire) scroll hidden to protect things better, then there is already a suggestion thread up for the option to hide things by stage.

[MissK.]

1 hour ago, 11th said:

Maybe I'm misunderstanding, but this sounds like something that we can already do: Hide our scrolls.

 

There are only two "big" hatcheries that allow growing things to be added via code. One of those two only accepts ER codes specifically. The other isn't particularly threatening unless the creature is below 4d 1h. Other hatcheries are not able to add creatures from hidden scrolls, even if the user's scroll name is visible. (ex. On the hub, or on view pages.) Auto-refreshing tools such as FART don't add UVs, only OVs, which greatly limits the amount of damage that can be done with them.

 

If someone insists on targeting things from hidden scrolls despite all of that, then they are less likely to be stopped by the inability to use hatcheries to do the dirty work. That is the same problem that this suggestion would have. If the problem still is that you don't want your (entire) scroll hidden to protect things better, then there is already a suggestion thread up for the option to hide things by stage.

 

But when I hide my scroll, I can't add my eggs to hatcheries either. I do want to hatch some of them, just not have the whole thing added, and especially not freshly caught eggs or the things I want to put up for trade. This suggestion allows the use of all hatcheries by the person who owns the scroll, while preventing anyone else from messing with it (if the option is enabled). 

 

7 hours ago, Fuzzbucket said:

 

It should NOT come up with "verification required"; which suggests it is REQUIRED (note that word...)  It should come up with "do you want to log in to protect your scroll". Like evina's already does. Though if it becomes part of the API I'm not sure how easy it would be to avoid using it.

 

It would come up with verification required, for the users that have protection enabled on DC. Anyone who doesn't have it enabled would not get a prompt at all, as has been explained. If it comes up with "do you want protection?" then that defeats the purpose of having an on-site setting for it.

[11th]

44 minutes ago, MissK. said:

But when I hide my scroll, I can't add my eggs to hatcheries either. I do want to hatch some of them, just not have the whole thing added, and especially not freshly caught eggs or the things I want to put up for trade. This suggestion allows the use of all hatcheries by the person who owns the scroll, while preventing anyone else from messing with it (if the option is enabled). 

Then this suggestion should be directed at hatchery owners instead of DC, since we know that it is already possible for them to use login confirmation. Asking for DC to change the API first would just force everyone into DragHatch until other hatcheries adapt, which seems a bad idea.

[Fuzzbucket]

2 hours ago, MissK. said:

But when I hide my scroll, I can't add my eggs to hatcheries either. I do want to hatch some of them, just not have the whole thing added, and especially not freshly caught eggs or the things I want to put up for trade. This suggestion allows the use of all hatcheries by the person who owns the scroll, while preventing anyone else from messing with it (if the option is enabled). 

 

You can to evina's, actually. That's why I love it !

 

1 hour ago, 11th said:

Then this suggestion should be directed at hatchery owners instead of DC, since we know that it is already possible for them to use login confirmation. Asking for DC to change the API first would just force everyone into DragHatch until other hatcheries adapt, which seems a bad idea.

 

Exactly this. As it is NOT POSSIBLE for @TJ09 to prevent bombing completely, given that there are ways to do it without using fan sites, encouraging other sites to do as evina;'s does is surely the best way forward.

[KageSora]

19 hours ago, ACDragonMaster said:

I'm really not seeing your logic here.  It sounds like you're saying "because some people would choose not to use it due to the inconvenience everyone should continue to have to suffer because it's unfair that others who opt in get extra protection" more or less.  That it's not okay to add a security option for people who wish to use it because not everyone would want to do so.... but that just means the people who choose not to are in the same place as if it never existed.  It changes absolutely nothing.  It doesn't exist now, so a user's playstyle now and methods used to avoid getting viewbombed wouldn't change or be affected at all.  Not unless you count "knowing there's an option and choosing not to use it" to be different in itself, but fundamentally absolutely nothing has to change in anyone's playstyle if they don't want to click the button to opt in.

 

What I'm saying is that this would make the game take a stance of "change how you play or just suffer the consequences, because your playstyle isn't worthy of being protected from harm even if you face the exact same problems as people with other playstyles."

 

This is not the forum for "purely support for suggestions, no offering counter-suggestions", this is a forum where things get debated.  I explicitly stated that I do not like the way this suggestion purports to solve the problem because it would create undue frustration to get the protection that I require--and it introduces other potential issues.  Such as "well, now only one hatchsite works until the others update--if they even feel like re-coding how they manage instead of just shutting down entirely".

 

I expressed that I prefer a different solution, and your response was "well why do you assume we can't have both" and I want to know why you assume we would get both.  It's safer to err on the side of assuming less rather than more and being pleasantly surprised rather than making your entire argument for why people shouldn't support only one option hinge on "we can have more than one solution" and only one element of it get implemented and leaving a bunch of other players screwed over.

 

Honestly, at this point?  I thing the better solution is just to have the option to mark individual dragons as "do not permit views", and be able to toggle that at will.  Like "fog" except allow them to remain visible, and usable on things in trade.  Allows for people to selectively protect what they want to protect as needed, doesn't require using a loophole like the trade view pause would require, and is useful for people of any playstyle without undue extra hassle to use.

 

19 hours ago, ACDragonMaster said:

For that matter, if enough people choose to opt in it may provide a degree of herd immunity for those who don't, as trolls may simply get frustrated enough to be less inclined to try random users' scrolls.

 

I mean, maybe but also...  Plenty of viewbombing isn't done at random.  You've mentioned multiple times that since you made this topic you've been viewbombed--that might be coincidence, sure.  Or it might be some of a user who's taken exception to you for some reason and is doing this deliberately because they think it's funny to target people who're already frustrated by this behavior (or some other reason I can't fathom).  People have had rare eggs immediately get viewbombed right after being caught and the most logical assumption is "another person got mad that they failed to catch it so they're trying to kill it in revenge".  I would assume the same logic happens with trades--somebody gets angry that their offer got rejected so they try to either kill it or they try to force a hatch/mature to ruin the trade as payback.  People have found themselves repeatedly targeted no matter what steps they take, which IMO indicates somebody with a personal reason (possibly a grudge?  Or just dislike?) to target them over and over.

 

It might help with random trolling, but if somebody is pissed off at you specifically and trying to ruin your stuff that's not gonna stop them from trying to find a way to mess with your stuff.  And, as has been repeatedly pointed out, there's plenty of ways to do that.

 

15 hours ago, _Charky said:

I'm guessing that you're counting "half of the hatcheries close because their owners don't want to re-write the entire thing" as downside which outweighs the benefits? Interesting perspective.

 

This would be another of my concerns.

 

Though, question on that--if a fansite did not want to re-write their coding to deal with the verification, would the entire site be unusable to everybody?  Or would it still be usable by people who had the verification requirement disabled?  I mean either way it poses a problem--just differs on if the problem is heaped on everybody or only those who enable the protection.

 

7 hours ago, 11th said:

Then this suggestion should be directed at hatchery owners instead of DC, since we know that it is already possible for them to use login confirmation. Asking for DC to change the API first would just force everyone into DragHatch until other hatcheries adapt, which seems a bad idea.

 

While I agree, I see the reason why it was pointed at DC instead--if you leave it up to the fansites they can easily refuse and then you don't get a unified fansite experience.  If you force the matter via DC, then all fansites that want to remain in operation are forced to give you the unified protective experience.  Of course, they may not be willing to remain in operation if it means re-writing their code.

[Fuzzbucket]

4 hours ago, KageSora said:

Honestly, at this point?  I thing the better solution is just to have the option to mark individual dragons as "do not permit views", and be able to toggle that at will.  Like "fog" except allow them to remain visible, and usable on things in trade.  Allows for people to selectively protect what they want to protect as needed, doesn't require using a loophole like the trade view pause would require, and is useful for people of any playstyle without undue extra hassle to use.

 

This is brilliant - BUT - we do have fog; I think it shoul be available only for dragons in a trade / teleport link.

 

4 hours ago, KageSora said:

I mean, maybe but also...  Plenty of viewbombing isn't done at random.  You've mentioned multiple times that since you made this topic you've been viewbombed--that might be coincidence, sure.  Or it might be some of a user who's taken exception to you for some reason and is doing this deliberately because they think it's funny to target people who're already frustrated by this behavior (or some other reason I can't fathom).  People have had rare eggs immediately get viewbombed right after being caught and the most logical assumption is "another person got mad that they failed to catch it so they're trying to kill it in revenge".  I would assume the same logic happens with trades--somebody gets angry that their offer got rejected so they try to either kill it or they try to force a hatch/mature to ruin the trade as payback.  People have found themselves repeatedly targeted no matter what steps they take, which IMO indicates somebody with a personal reason (possibly a grudge?  Or just dislike?) to target them over and over.

 

It might help with random trolling, but if somebody is pissed off at you specifically and trying to ruin your stuff that's not gonna stop them from trying to find a way to mess with your stuff.  And, as has been repeatedly pointed out, there's plenty of ways to do that.

 

Yes indeed. It's awful and petty - but I'd lay odds that's the reason for the OP being bombed recently.

 

4 hours ago, KageSora said:

Though, question on that--if a fansite did not want to re-write their coding to deal with the verification, would the entire site be unusable to everybody?  Or would it still be usable by people who had the verification requirement disabled?  I mean either way it poses a problem--just differs on if the problem is heaped on everybody or only those who enable the protection.

Good point that hadn't occurred to me.

 

4 hours ago, KageSora said:

 

 

While I agree, I see the reason why it was pointed at DC instead--if you leave it up to the fansites they can easily refuse and then you don't get a unified fansite experience.  If you force the matter via DC, then all fansites that want to remain in operation are forced to give you the unified protective experience.  Of course, they may not be willing to remain in operation if it means re-writing their code.

 

This. Unless TJ would offer them the code they need ?

 

4 hours ago, KageSora said:

I explicitly stated that I do not like the way this suggestion purports to solve the problem because it would create undue frustration to get the protection that I require--and it introduces other potential issues.  Such as "well, now only one hatchsite works until the others update--if they even feel like re-coding how they manage instead of just shutting down entirely".

 

I had missed that they have to update the protection with every scroll update. Evina's doesn't - why would this need to happen ? I would ASK (not force) every site owner if they could please set up whatever it is evina's has set up and make that opt in. THAT works for EVERYONE, I think - even including the OP, except for not forcing it on fan sites.

[_Charky]

7 hours ago, KageSora said:

This would be another of my concerns.

 

Though, question on that--if a fansite did not want to re-write their coding to deal with the verification, would the entire site be unusable to everybody?  Or would it still be usable by people who had the verification requirement disabled?  I mean either way it poses a problem--just differs on if the problem is heaped on everybody or only those who enable the protection.

That depends on how the API is changed and the fansite is written. At the very least, entering a protected scroll would cause the site to error out because it had no means of dealing with the information it was sent, and that could even be a gateway to a data breach if we got really unlucky. At worst, the entire site would be unusable, because the mechanism for fetching scroll data had changed in a way the hatchery code couldn't deal with.

[KageSora]

3 hours ago, Fuzzbucket said:

I had missed that they have to update the protection with every scroll update. Evina's doesn't - why would this need to happen ? I would ASK (not force) every site owner if they could please set up whatever it is evina's has set up and make that opt in. THAT works for EVERYONE, I think - even including the OP, except for not forcing it on fan sites.

 

The problem comes in when you have things set up to discard cookies on close, and then you have to log back in again.  I dislike the idea of having to give every single fansite permanent cookies instead of them being able to have them automatically cleared when I switch back to my scroll or close the tab/window the fansite was open in.  I can't believe I'd be the only user who has that sort of thing set up, either.  No cookies saved, no persistent login.

 

But this wouldn't be the place to ask other sites to implement something.  That would be each of their own threads.

 

And they could, of course, refuse to do so.  Much easier to ask that DC force it rather than asking every single currently running and all future fansites to make use of that.