[ b / kemono / coomer / memoryhole ]

/kemono/ - kemono.party

Kemono Development and Discussion
Name
Email
Subject
Comment
Verification
File
Password (For file deletion.)

File: 1640718130009.gif (263.8 KB, 500x500, FUCKA YOU.gif)

 No.14310

So looks like subscribestar is now banning kemono.party users based on some kind of connection ID under the premise that our credit card data is now "compromised" and all payment sources are then disabled as a result.

Not sure if it can be appealed or something but I'm guessing if the importer only uses one ip or a limited range of IPs it got pegged and now any connections from those get flagged and payments disabled.

 No.14325

only time before patreon starts doing this too

 No.14350

>>14310
This is odd.

>>14325
Kemono is important to them.

 No.14379

ya if it gets disabled it shows as a "This card is declined. Error code 0692. Please, contact support"
it means they disabled all billing functions of your subscribestar account.

 No.14382

>>14350
ok they are doing some either advanced shit or heavy handed shit.
cleared cookies, connected via VPN in another state, generated new virtual credit card number and i still get the card decline error.
i think they may have banned the card issuer or are tracking via some other means, though i don't know what that could been since it was a new subscribestar account with an entirely different email, name and card number.

 No.14406

>>14382
Spoof a different User Agent maybe?

 No.14433

There is nothing much I can say about this issue. We are working with a literal black box.
Where and how the detection happened is hard to say. There are a dozen of speculations, but again, black box.
For now things are on halt and will be reworked. We can only guess how it will end.

>>14382
>connected via VPN in another state
Skip this step in favor of open wifi endpoint or something residential. Only so much that can be done.
My guess it is network related, but maybe they do more. Probably do more.

 No.14444

>>14350
Leaking and pirating sites will always be targeted, because they go against their business model. Gumroad and Subscribestar already ban people who leak in kemono, it's a matter of time until Patreon does too.

Basically be ready to have your payment methods banned off those platforms. Artists are reporting leaker's Paypal accounts and getting those closed, so don't have money on your wallet and only use your credit card if you don't want to lose your money. I don't think it's worth it tbh

 No.14464

So that really is happening after all. Goddamn it, this complicates things a lot if you can't even jump onto a different card or VPN to dodge the ban.

 No.14483

Just create seperate account with a different email and use prepaids, s'what I've been using for fanbox, fantia AND subscribestar.
Patreon's the only one who doesn't accept them, and even then, if you find an account without CUF enabled you can just add the prepaid, grab their shit, and cancel without paying a dime, cause their system won't bother checking the card until the first of the month.

 No.14484

>>14444
Bullshit.

Creators should NOT be able to view your Paypal account at all (I have seen the creator's patron management page), they are probably just reporting your patreon email to Paypal and if your Paypal happens to use the same email then you MIGHT get banned

but I find it hard to believe Paypal gives a flying fuck about random "creators" reporting random users for leaking porn (at which point they will get banned themselves cause Paypal no likey porno), there's no proof at all that a specific user used kemono. You can easily get innocent patrons banned if you pledge and then wait til someone else pledged to import. Even with proof, Paypal wouldn't give a shit.

 No.14487

maybe dev can find some way to relay scrapping

 No.14504

>>14444
According to people in the Telegram group, this ban is by IP and per day? Unless there's new info, I've imported from Gumroad before and my account seems safe.

 No.14506

>>14406
the vpn client does this, it has a browser extension as well as the standalone client

>>14433
no it was a residential IP, one of the reasons i pay for it, let me use netflix and the rest while on the vpn because it doesn't recognize it as a datacenter owned ip
>>14504
no this has been over several days, its not by IP or time based; i hopped ips from new york, mass, CT, and ohio, clearing cookies and identifiers stored locally each time. they all show the same error.

 No.14534

>>14487
Proxy scraping is one of the solutions. But we won't be investing time into the whole thing anytime soon.

>>14506
>no it was a residential IP
Welp, it leaves only the payment provider that allows to flag you.
Not much I can say to the whole fiasco. Shit happens, the only question is when.

 No.14617

>>14484
hey anon, this isn't a question about should not, cannot or anything. Anyone can see anything you provide with or without being aware of it before you even have a chance to wonder what went wrong.

Stop relying on magic undefeatable encryption that either doesn't exist or is laughed at when the communication is intercepted before any encryption takes place and start wondering what leads to weird shit instead

this is very visible
this is about as anonymous as Justin Bieber
and this is samefagging

 No.14620

>>14310
Surprisingly someone has already suggesting this idea to patreon dev. Right now, its either patreon going to care or nah.

 No.14621

>>14310
Is this really happening? has anyone having the same problem as OP? I been thinking to import dome of the Substar artist to kemono, if this really a problem, then it is not worth it to lose my access to an artist just because the import to kemono

 No.14633

I am no computer scientist
but how is subscribestar importer actually work ?
if it use only one IP range and then connect to same website while changing "account" multiple times it will easily detectable and look suspicious as fuck

 No.14657

>>14620
If they really cared, they would've nipped it in the bud in yiff.party's prime

 No.14663

>>14433
or you could get some cheap residential proxies (fun fact sci-hub uses stolen accounts to leech paywall article sites based on what i heard)

or better yet why not just make some kind of scrapper and download the substar content manually from within the same device and upload the finished zips to kemono shared files even though its slow as hell
getting caught should be next to impossible since you are not signing in on another device unless they put some kind of hidden watermark in the images
inb4 comment dissapears for no reason

 No.14678

>>14617
what the fuck are you trying to say?

 No.14734

why not use gallery-dl to rip from subscribestar, and then upload the local files?

 No.15004

>>14734
manual upload is still down

 No.15008

>>14534

did some digging and i think i stumbled on to how they are doing it; made a new SS account using my own browser after clearing cookies and using a foreign (to me) state ip (yes residential, its what i had been using but in a different state) and new email and everything. still got the error; now cleared ss cookies AND kemono cookies and then new IP, email and virtual card number.
this time it worked, let me sub and no error.
i don't know how they are doing it without throwing a cross-domain violation in the browser console but it seems they are looking for the existence of a kemono.party cookie in combination with a banned card and maybe this "card_spam" cookie their authorize.net instance sets.
so it identifies you by a server side ban, and seems to automatically expand that ban based on cookies.
maybe they are getting around it by simply seeing if a cookie from the kemono.party domain exists without actually trying to read the cookie values? dunno.

all i know is that i'm not adding my key ever again, if you get some kind of API to point an archiver tool at that would route to manual uploads i'd be up for that but not going through this BS again with a direct connection.

 No.15009

>>15008
> maybe they are getting around it by simply seeing if a cookie from the kemono.party domain exists without actually trying to read the cookie values? dunno.
Browsers don't allow to peek at the cookies of a different site.

 No.15268

>>15009
that is normally true but i see that the kemono cookies use the lax samesite setting so it could, at least in theory, do a CSRF exploit against the favorites page or something on kemono maybe in combination with some kind of MITM via the SS site and if it can in fact get a valid response and not a redirect to the login page (as is normal if you wern't logged in) then they wouldn't need to actually read the cookie but would know by proxy if the user has used the site or not.
i had manually gone in and set (and locked) the cookies to the strict mode instead of lax just to be safe.

 No.15407

Is this gonna spark an exodus by paywalling assholes to Substar?

 No.15954

>>15008
Cookie theory seems to check out. I made an account on a separate browser just to be safe and used a different card, the payments went through.

 No.16106

>>15008
>>15954
If that's the case then, should the SubStar importer come with a warning to be in, like, incognito mode before trying to avoid being banned?

 No.16171

>>16106
That won't help since the import doesn't use your browser. Whatever the way they use to detect, they can do it on their backend without touching your browser.

 No.16595

>>16171
That can't be legal. Can it?

 No.16598

>>16595
Correct. If it is what I think it is, it could be very illegal.

 No.16603

>>16595
Depends. It looks like the system is cookie-based and you literally get greeted with cookie consent banner. If they don't go beyond analyzing a request, then there is nothing illegal.

 No.16621

Anyone get banned here despite never importing their S* account?

 No.16622

>>16621
^ genuine question, had to reword my post five times to avoid triggering the auto-delete.

 No.16627

Even if it's illegal, there's pretty much jackshit you can do about it from that angle. You'll just end up doxxing yourself and if you want to make them stop, you'll pay hundreds of thousands on a lawsuit which they'll either ignore or obey while changing to another almost identical system.

It's a size thing. Creators aren't big enough to do anything to you, and the platforms don't really care. You're not big enough to do anything to the platforms, and neither the creators nor the platforms really care. It's like pottery.

 No.16650

Is it possible they're detecting the presence of cookies on a domain by importing from kemono (iframe or something) and measuring how long it takes to get a cross origin error, indicating the presence of cache/cookie session data? Sort of like a web version of spectre

 No.16676

>>16650
It doesn't matter what way they detect, the underlying problem is the workflow on the repo is being a COMPLETE FUCKING TRASHFIRE. It takes at least 3 weeks on average to get even the most basic bitch changes on the site. Let alone debug anything more complex. That's enough time for subscribestar to react to anything.

 No.16704

The solution ought not be difficult, admin just needs to subscribe to a popular VPN and sync content using their IPs. Intersection between kemono imports and genuine users on those IPs would be high.

 No.16720

>>16704
Without going into detail about how internal Kemono infrastructure works, I can tell you for certain this will not help.

 No.16811

>>16720
Hey admin, out of curiosity when did these issues with S* start getting reported/the very last import from there? Maybe the answer lies in working backwards to see why the system doesn't work now?



[Return][Go to top] [Catalog] [Post a Reply]
Delete Post [ ]
[ b / kemono / coomer / memoryhole ]