Jump to content
Keileon

Adjust how hatcheries can use API

Recommended Posts

I'd be OK with that as long as it was like evina's where we can choose to use it, or not.

Share this post


Link to post

Having thought about more, and after some arguments made in the remove sickness thread, I'm only for this in the (rather limited) form of allowing login to provide hatcheries access to hidden scrolls.

Edited by osmarks

Share this post


Link to post

I certainly don't want to login anywhere, I'd rather get viewbombed(not that viewbombers would be harmed in the first place), thank you.

Share this post


Link to post

Technically, you're not logging in anywhere, you're logging into DC.

Once a given fansite has verified that you are the owner of a scroll, it can set a cookie and could possibly know forever that the owner of your device/browser is the owner of your scroll - that's how Evina's works.

 

It's not only viewbombing that happens, but also view deprivation. Some people seem to have fun taking people's scrolls out of fansites - which they couldn't do anymore if I could simply NOT ALLOW my scroll to be modified AT ALL on any fansite I use by people who aren't me.

Edited by Ruby Eyes

Share this post


Link to post

Exactly. I have been view-de-bombed more often than bombed !

Share this post


Link to post

This whole issue could be solved using what already exists. We already do have that acceptaid flag that effectively not NOTHING right now, only displays some text that might as well say "will comb your flowerpot" in Quenya because it doesn't really do ANYTHING.

 

But fansites could actually be made to react on it - the API returns it, after all.

People who set it to "yes" could simply go on without logging in.

People who set it to "no" would be required to be verified via login. DC would return a "fansite session key" that said fansite would store in a cookie and deliver every time that scroll is being accessed with that browser on that device. That key could expire every 2 weeks (I think that's a standard session length?) for safety measures so you'd verfiy yourself every 2 weeks.

Share this post


Link to post

I don't know that I'd want to go that far. There are the times I want to zap things and use a fansite I usually don't use for half an hour. I don't particularly want hurdles at those times. I'd rather have it like evina's.

Share this post


Link to post
1 minute ago, Fuzzbucket said:

I don't know that I'd want to go that far. There are the times I want to zap things and use a fansite I usually don't use for half an hour. I don't particularly want hurdles at those times. I'd rather have it like evina's.

But what I described would basically work like Evina's. :blink: Log in once, work all your stuff for weeks.

The only difference would be that you'd set the login requirement (yes or no) in your scroll and not on every single fansite.

Share this post


Link to post

But you are missing my point - sometimes I want to use a different fan site for half an hour or so, or even VERY FAST INDEED - and to THAT one I don't want to have to log in.

Share this post


Link to post
9 hours ago, Ruby Eyes said:

This whole issue could be solved using what already exists. We already do have that acceptaid flag that effectively not NOTHING right now, only displays some text that might as well say "will comb your flowerpot" in Quenya because it doesn't really do ANYTHING.

 

But fansites could actually be made to react on it - the API returns it, after all.

People who set it to "yes" could simply go on without logging in.

People who set it to "no" would be required to be verified via login. DC would return a "fansite session key" that said fansite would store in a cookie and deliver every time that scroll is being accessed with that browser on that device. That key could expire every 2 weeks (I think that's a standard session length?) for safety measures so you'd verfiy yourself every 2 weeks.

 

This sounds great in theory, but I'm not sure I'd like to constantly have to log in every 2 weeks to every single hatchery I use (3-4 normally, more if I'm not getting enough views). And presumably log in every single time I use a new device (I use library computers a lot...). 

 

In general I really don't think that requiring log-in is the grand solution that people seem to want it to be, or that it will really do anything at all to stop viewbombing (contrary to an earlier post I made...). People can viewbomb just fine in other ways, ways that don't even require a hatchery at all. In order for *anything* having to do with hatcheries to actually affect viewbombing in a big way, TJ would have to make it so that the *only* way people could get stats would be through hatcheries. I don't even know if that's possible to code, but I certainly wouldn't want it. 

 

I would love if every single hatchery had an option like DragHatch, where you *can* secure your scroll so no one can mess with it but you. I would love that. I don't think *requiring* that is the best solution to viewbombing/sickness, though. 

Share this post


Link to post

Pretty sure it would be possible to limit view/click/UVs to hatcheries by checking that refer(r)er headers come from them. That would stop them coming from other websites, at least, though it could be spoofed by anyone deliberately trying to viewbomb.

 

@Ruby Eyes I just checked and I think the API does not return accepting-aid status. And I don't think your proposal would be better than just having people able to secure their scroll per-fansite, not that that would help much.

Share this post


Link to post
22 minutes ago, osmarks said:

Pretty sure it would be possible to limit view/click/UVs to hatcheries by checking that refer(r)er headers come from them.

Yeah, that should be possible. I actually suggested a referred-based whitelist approach for hatcheries (and other websites) ages ago:

It's not my preferred solution any more, since it doesn't help against early adding (minor-ish problem compared to the others, to be fair), and it doesn't help against DDoSing hatcheries (which hadn't ever happened yet back when I made that description - way back then, view bombing was always very individually targeted) or scrolls. (That said, it would definitely cut off views from other high-traffic sites that one didn't even know existed, as you said, so there's still some charm in it.)

 

I'd prefer reworking sickness so it can't kill people's eggs/hatchlings unless the views keep flooding in for more than 24 hours (wording carefully chosen since it's distinct from "unless the egg/hatchling is sick for more than 24 hours", which can happen with less than 24 hours viewbombing).

 

Mind, I don't think I have much of a right to comment on this API restriction suggestion itself - I strongly feel it won't help, but given it would make work for me (as the admin of Daily Dragon Fix), you should discount my opinion on it.

Share this post


Link to post
On 12/14/2018 at 10:44 AM, Ruby Eyes said:

It's not only viewbombing that happens, but also view deprivation. Some people seem to have fun taking people's scrolls out of fansites - which they couldn't do anymore if I could simply NOT ALLOW my scroll to be modified AT ALL on any fansite I use by people who aren't me.

So what? Put your stuff into the hatcheries of your choice and then hide your scroll - and let the trolls figure out how to get there then. If you still want to show off your whole scroll, create a group "whole scroll" with all your dragons in it and hand out the group link. Simple as that.

Share this post


Link to post
28 minutes ago, olympe said:

So what? Put your stuff into the hatcheries of your choice and then hide your scroll - and let the trolls figure out how to get there then. If you still want to show off your whole scroll, create a group "whole scroll" with all your dragons in it and hand out the group link. Simple as that.

 

This. This is what I do, more or less. I don't really care if people see my whole scroll, but I DO want to advertise my awesome Cheese army (yeah, yeah, not so great YET) so I put a link to the group in my sig to make it public, but keep my actual scroll hidden. No viewbombing ever happens. Even to the Cheese hatchies/eggs in perfectly public view. I don't have my scroll name listed anywhere. Kinda ashamed of it, really...

Share this post


Link to post
1 hour ago, osmarks said:

I just checked and I think the API does not return accepting-aid status. And I don't think your proposal would be better than just having people able to secure their scroll per-fansite, not that that would help much.

Huh, I'm pretty sure that it used to. At least I recall the api.txt mentioning it (years ago - it says "(Updated April 2018)" though). I guess it has been removed in the meantime.

 

58 minutes ago, olympe said:

So what? Put your stuff into the hatcheries of your choice and then hide your scroll - and let the trolls figure out how to get there then. If you still want to show off your whole scroll, create a group "whole scroll" with all your dragons in it and hand out the group link. Simple as that.

You cannot imagine how SICK I am of having to hide and unhide all the time when some random idiots are going around messing with people's scrolls again. I frigging LOATHE it. So anything getting around that would be GREAT. If YOU don't need it, be happy. That doesn't mean that OTHERS wouldn't like something around that issue.

Edited by Ruby Eyes

Share this post


Link to post

@Ruby Eyes: Believe it or not, I don't like it, either. But it's still a possible work-around. How often does this happen, anyway? The times I got a personal attack on my growing things are so few and far between that I can count them off on one hand. Everything else has always been fansite-related. And it's not like a view-starvation attack was deathly in a matter of minutes or hours at the latest, so it's not that much of a problem in the first place.

 

Personally, I'd rather do the whole hide scroll / unhide scroll thing when either kind of attack is ongoing than having to log in whenever I want to add stuff to a hatchery.

Share this post


Link to post
On 12/14/2018 at 10:44 AM, Ruby Eyes said:

Once a given fansite has verified that you are the owner of a scroll, it can set a cookie and could possibly know forever that the owner of your device/browser is the owner of your scroll - that's how Evina's works.

 

It's not only viewbombing that happens, but also view deprivation. Some people seem to have fun taking people's scrolls out of fansites - which they couldn't do anymore if I could simply NOT ALLOW my scroll to be modified AT ALL on any fansite I use by people who aren't me.

NO THANKS. My browser clears cookies and history for a reason you know, I have enough pain in the backside with other unnecessary verifications since RODO, I just won't stand any more of those... had to switch browsers because of Patreon (which kept on demanding me to verify my login attempt from my main browser with extra steps like clicking something from my e-mail, I don't want to use my Patreon cookie-remembering browser for anything else, especially for a game full of loopholes and malicious attackers who could afford a DDOS attack...). I don't know how saved passwords and cookies make me an easier target (for hackers, data leak etc.) and if they actually do or my advisor was paranoid(but sorry, I have more reasons to believe them than a bunch of srangers from a browser mini game like DC), but I better be safe than sorry, cookies are to be auto-cleared everyday. Don't deprive me of the game, plz... As long as I can opt out from all the extra would-be-safety-measures-against-trolls (plz, just fix the game: remove death from Sickness and add an on-site hatchery which ofc noone would be able to remove your things from no matter what) I don't care, but if I'm to be forced such nonsense, I protest...

Also, I don't know what this Evina is and I bet I don't want to, sounds like something I definitely don't want to use - ever.

 

View deprivation is as easy as having your thing clicked in the remove corner of the sprite (meant for manual removal of adults), you know? e.g. in Silvi:  1794519791_soeasytoremoveyourderg.png.3b3eb9993fdf7f69ce55bf59c8eb1cc1.png

Sorry to admit that, but it did happen to me that I accidentally misclicked a hatchie there(will always feel sorry to the accidental victims of my clumsyness)... rarely but it did happen a few times already... This is how you will stil have your thigns removed, even if you used the thing you're asking for..

 

 

Edited by VixenDra

Share this post


Link to post
Just now, VixenDra said:

View deprivation is as easy as having your thing clicked in the remove corner of the sprite (meant for manual removal of adults), you know? e.g. in Silvi:  1794519791_soeasytoremoveyourderg.png.3b3eb9993fdf7f69ce55bf59c8eb1cc1.png

Sorry to admit that, but it did happen to me that I accidentally misclicked a hatchie there(will always feel sorry to the accidental victims of my clumsyness)... rarely but it did happen a few times already... This is how you will stil have your thigns removed, even if you used the thing you're asking for..

As far as I know, most hatcheries implement removal as another API request. As in, you're just speeding up the "remove by checking status" call. In those cases, you can't accidentally remove a dragon that isn't ready for removal - you just tell the site "check if this dragon can be removed", and if it can't, nothing will actually happen. :)

Share this post


Link to post

@VixenDra: I just checked, if you click on something that's not meant to be deleted from Silvi's, it doesn't get deleted. (If you don't believe me, click on an egg/hatchi to get the code, then on the removal arrow for the same thing and re-enter the code. You'll get told that the egg/hatchling was already on the site.

Share this post


Link to post

@VixenDra If you want to go around doing weird things like constantly clearing cookies (as opposed to, say, using private browsing mode for some stuff, for example, which is designed to not save data like cookies), it is not the responsibility of everything to support it. I'm also pretty sure there's a Firefox extension ("Firefox Multi-Account Containers") which allows you to have groups of tabs with different sets of cookies.

EDIT: "evina's" is Evina's DragHatch hatchery, and signing in is optional on it.

Edited by osmarks

Share this post


Link to post

Yeah sorry but... pretty much every login-based website uses cookies. If you want to clear them every single day that's up to you, but that's honestly kind of your own problem. Don't deprive others of security measures just because your advisor was being paranoid.

 

You can still delete that cookie anyway, so I don't see what the issue is.

Share this post


Link to post

The issue probably is having to delete the cookie, having to log in before every use. It takes away quite some liberty by making people jump through hoops that aren't exactly necessary. And the benefit - if there is one at all - is temporary at best.

 

Quote

Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.

(Benjamin Franklin)

 

Share this post


Link to post

I don't think that quote, nor the term "liberty", are particularly accurate here. Nobody's forcing anyone to delete cookies; that's a choice. And it's not giving anything up except maybe three seconds of time every time you want to go to that fansite. It is a minor inconvenience at worst.

 

Ultimately it boils down to someone's choices making everyone else's safety harder to attain.

Edited by Keileon

Share this post


Link to post

But having to log in time and again instead of just putting your stuff in there is less than... liberating. Personally, I add stuff to hatcheries more often than I go to bed - whenever I've caught something in the AP, for example. And when I unlock again and catch some more low-time eggs. The effort is pretty much the same as hiding/unhiding your scroll, just less often. Plus, you get more protection from actually hiding your scroll than from an API feature for fansites that can easily be circumvented with click-exchange sites and who knows what else. (I really don't know. I don't want to know. But I'm sure there are more ways I don't know about.)

Share this post


Link to post

I'm pretty sure just asking hatcheries to add login as an option - or allowing it to provide access to hidden scrolls - would at least ensure that if you want to you could keep your scroll protected, though not actually fix viewbombing.

 

I would also like to note that pulling in in vaguely relevant quotes does not automatically make you correct.

Edited by osmarks

Share this post


Link to post


  • Recently Browsing   0 members

    • No registered users viewing this page.