ptpb.pw permanent shutdown

[buhman]

TL;DR: coin miners are assholes, ruining this great service for everyone

Due to continued write and egress abuse, ptpb.pw is now ~permanently shut down. The current pb implementation has always been a toy at best, and is unsuited for mitigating very real modern internet threats. Unchecked, current usage would have resulted in $3000+/mo GCP bills for network egress--grossly innapropriate for what has always been a charity project.

See the following github issues for more information:

• ptpb.pw 500 Internal Server Error on uploading png #245
• ptpb.pw is out of disk space #240

In the future, ptpb.pw may be restored, but with an entirely new (possibly backwards incompatible) API/implementation. This is months away, optimistically.

[Earnestly]

That's a pity, but thank you very much for hosting this service while it lasted.

[Cloudef]

Pity indeed, ptpb was a great paste service.

[mpan-pl]

Thanks for providing us with the service for so long!

[diamondburned]

RIP. Forgot how to use this so I went to the site. Very unfortunate to hear this.

[Forty-Bot]

RIP best paste service

[Thunderbottom]

I feel bad for this being shut down. Is there any way possible for ptpb to be a temporary storage, and use a similar formula to that of what 0x0.st uses to generate its "File Retention Period"? If I may quote so:

FILE RETENTION PERIOD
---------------------

retention = min_age + (-max_age + min_age) * pow((file_size / max_size - 1), 3)

   days
    365 |  \
        |   \
        |    \
        |     \
        |      \
        |       \
        |        ..
        |          \
  197.5 | ----------..-------------------------------------------
        |             ..
        |               \
        |                ..
        |                  ...
        |                     ..
        |                       ...
        |                          ....
        |                              ......
     30 |                                    ....................
          0                        256                        512
                                                              MiB

Something similar of this sort, if not the same formula could be used; which helps against people abusing this service. If there is anything I can do for it, please let me know. I'd be more than happy to help in any way possible.

[buhman]

Happy to discuss creative solutions.

Most cloud providers don't charge terribly much for storage or IO, so this was a mere annoyance (which is why ptpb.pw didn't shut down in december or even earlier).

I think 0x0's formula is interesting.

I've also considered some kind of "fingerprint"-based bucketing and rate-limiting. The same fingerprint buckets could be weighted in to a garbage collector.

I'm also not against tuning a logistic regression model against every imaginable feature to compute a overall "abuse" factor, which could be consumed by both the rate limiter and the garbage collector.

There are also possible privacy issues with this that I'm not sure how to handle (or even if people care about this). I think ideally the pastebin should have no knowledge of paste content via some at-rest encryption scheme, despite this possibly being one of the strongest model features: "does this look like a magnet link, mining pool file, etc.."

If there is anything I can do for it

A distributed service might be inherently more resilient to abuse. I think there is a void here, in that existing distributed services focus more on being fully distributed, greatly sacrificing usability.

A split-view DNS based service might have a centralized coordinator that handles advertisement, membership, health/sanity validation, space partitioning. There are also some harder questions related to how resilient individual pastes should be to single-node failures, how do pastes get read/write partitioned without proxying, etc.. I think this might be a fun experiment at the very least.

The dream would be people interested in contributing resources could leisurely deploy/undeploy any number of object servers, and the process for doing this should be as easy as "copy+run this signed binary".

[buhman]

I thought I'd also point out I considered redeploying pb on a provider that doesn't charge for network egress, but I think the end result of ignoring the underlying problems will be poor performance and high latency, due to abusers saturating ptpb's (now more limited) networking. I think the shutdown is more appropriate than continuing to run a degraded service.

[CounterPillow]

coiners truly are the scum of the earth.

[Cloudef]

I guess pastebin over IPFS would work for distributing.

[Thunderbottom]

I've also considered some kind of "fingerprint"-based bucketing and rate-limiting. The same fingerprint buckets could be weighted in to a garbage collector.

Yes, rate limiting is definitely a viable solution. But it would not take much for people who want to abuse the service to do so.

think ideally the pastebin should have no knowledge of paste content via some at-rest encryption scheme, despite this possibly being one of the strongest model features: "does this look like a magnet link, mining pool file, etc.."

There could be something done like "retention period" based on the type and size of the file. For example: if the service does not delete files that are <10MB in size for over a year's time, there'll be people abusing it as a "free photo backup service". So to limit that, as an example, photos can be retained for only x number of days, after which they get deleted. If someone really needs a "free service" for them to host photos for infinite number of days, I guess it would only make sense for them to self-host it.

Talking of encryption, that would be a good thing to do.

A distributed service might be inherently more resilient to abuse. I think there is a void here, in that existing distributed services focus more on being fully distributed, greatly sacrificing usability.

I think more than the usability, the question that arises is about security. Even though decentralization does seem like a really cool thing, there's a lot of things in terms of encryption that you need to figure out. Something like a mega.nz approach with a file-hash and a key would be really cool but imho, it would really be over the top and take over the simplicity that we have right now in pb.

I thought I'd also point out I considered redeploying pb on a provider that doesn't charge for network egress, but I think the end result of ignoring the underlying problems will be poor performance and high latency

I'd like to point out that pb was legit the fastest pb (duh.) that I've used. 0x0.st is way slower, but it does a lot of things in terms of file checking, and that it also does not use GCP like pb did. What it means is that for a "free" service, that's being hosted by someone for the community, is a reason enough for me to use it. I wouldn't be looking towards how long it takes for the file to upload, or even that the service is slow. If I was to expect a free service to be the best ever service possible, well, that would be me just being a really stupid asshole for asking everything for free. As quoted before, people that expect a free service to do a lot are free to host it themselves (or pay for it).

I respect your decision to shutdown pb, but I would love to see it back up. Sorry for quoting a lot of your messages, but that's just my 10c about where the service could be in the future.

[CounterPillow]

0x0.st is way slower, but it does a lot of things in terms of file checking, and that it also does not use GCP like pb did.

As far as I can tell, the biggest reason for 0x0's slowness is Hetzner's routes outside of Europe. Within Europe, they've got decent routes and 0x0 is fast, but outside you're going to have some very congested paths over bargain-bin transit providers. So not really an issue with the software, but with the host.