https://twitter.com/backblaze/status/1373751015594356739
Not sure if they intended to send file names and sizes to FB, but in any case this doesn't look good. I'm currently looking for alternatives.
My guess the bulk of that price difference is due to economies of scale.
Technically you do have to pre-allocate, but it works like pay-on-demand because:
<paste>
We can increase the size of your filesystem at any time, with no downtime involved - so there is no need to overbuy in anticipation of future usage.
Further, you are granted a +10% grace at all times, so you always have some room to grow.
Finally, the system automatically emails you as you get close to your limit, so there is never an unexpected filling of space.
</paste>
Given it's all personal data that I can stand to be without for days if needed, I could probably use Glacier (or even Glacier Deep Archive) and pay less than a third of the cost (or less than a twelfth!), but the absolute dollar amount isn't high enough for me to go through the trouble of changing up my backup scripts.
Sure, if you're running a business and are constantly generating lots of new data that needs to be backed up, that gets more expensive, but I also would expect a business with that much data could easily afford to spend several orders of magnitude more than I do on backups.
So far I'm happy with it, pricing is $5/month per 250gb + 1To egress. And, most importantly, none of the AWS complexity overhead. I have enough of that at work.
OVH has two interesting products here:
OVH cloud archive works with rsync, costs roughly half as much for storage as blackblaze, roughly the same for egress, but charges for ingress (at the same rate as egress).
OVH object store is s3 compatible (like blackblaze), charges roughly the same for bandwidth, 2x for storage.
https://www.ovhcloud.com/en/public-cloud/prices/#439
Digitalocean has a blob store with the same pricing on bandwidth, 4x the pricing on storage, a minimum spend of $5/month on storage, but the first tb ($10) of bandwidth free.
I would be surprised if OVH had another fire in the future.
seems this the cheapest of all
However I do think there is value in Tarsnap if security is really that important. Colin is really switched on, and I trust both the service, and if anything happened, he would deal with it quickly and professionally. If I had the kind of profile that meant I needed to protect myself against determined attackers, then tarsnap would be a no-brainer for me.
> the original version, which can survive the loss of 2 datacenters, not the "reduced redundancy" version which can only survive the loss of a single datacenter
These days, there's not just reduced redundancy, but also infrequent access, which seems better for backups…
First, we only offer SSH / TCP22 so the transit is encrypted.
Second, we have installed, and maintain on the server side tools like 'borg' and 'rclone'. So while you might just 'rsync' or 'sftp' your data to us (in which cases it would not be encrypted on our end) you can also use sophisticated, encrypted backup tools like (borg, duplicity, git-annex, rclone, restic, etc.)
If you choose a tool like that, rsync.net does not hold the encryption keys. The data appears to be random from our viewpoint.
– Cross-sell/Up-sell campaigns. Build an audience based on usage patterns, and create a create a campaign for a complimentary service or higher tier (say, for example, someone clicks the button for a gated feature they don't have access to).
– Suppression lists. If you don't want your campaigns to target existing users, you can build an audience from pixel data on your authenticated pages and suppress against that.
– Lookalike audiences. After you create an audience in Facebook, you can create a "lookalike audience" from that. So even if you aren't actively doing either of the above, you'd derive value from tracking your "best" customers and using it as a seed list for a lookalike audience.
You're also not limited to using the FB Pixel for any of the above. In addition to a browser-side pixel, FB allows you to upload hashed customer information and use those for conversion tracking and audience building. Which used to be completely transparent to end users, but now you're able to see a list of companies that have uploaded your info to FB in this manner (I can't recall where it's buried in the user settings, off the top of my head).
All of that said, it's entirely likely that Backblaze wasn't intentionally sending any of this data to FB to begin with. An insidious aspect of FB's Pixel is that it automatically attaches listeners to a bunch of stuff on the page such as buttons and sends back interactions and associated metadata[1]. The flag to disable this isn't mentioned in the implementation instructions that are generated upfront, and it's actually a fairly uncommon trait for ad pixels. So a typical implementation tends to leave it on out of ignorance rather than make a deliberate determination on whether to use or disable that functionality.
[1] https://developers.facebook.com/docs/facebook-pixel/advanced...
Um. Holy crap. Is this common knowledge? I don't get shocked easily these days but... wow
In the analytics space, you traditionally had to: – Initialize a tracking object on page load – Explicitly call methods on that tracking object when you wanted to actually send a hit
This is how it works for Adobe Analytics and Google Analytics historically. Many of the newer analytics providers instantiate auto-listeners, which gave them an edge on the out-of-the-box analytics features. And Google Analytics 4 (the newest release), also does this.
So it's not unheard of for site analytics. And a quick glance at a particular provider's website can usually make it obvious if this is occurring, based on the advertised features.
Ad pixels tend to be different though. You create a conversion event within the ad platform, and you're given a snippet of code to fire when that specific event occurs, which both instantiates the tracking object and calls the tracking method with the conversion event's configuration details.
Facebook's pixel works far more like a modern analytics library than an ad pixel. It vacuums up the hit data from the site and the marketer is able to sort it out after the fact in Facebook's interface and use what they want from it. Marketers working within Facebook can see this is happening because they set up the conversions and audiences against the hit data, but that's "just the way things work" in Facebook so they think nothing of it. Marketers coming from other channels will notice how different it is, but won't realize what's actually happening nor the implications behind it. Devs would realize pretty quickly what's happening after a few minutes exposure to the FB Pixel interface and it'd trigger a red flag for them, but that's marketing's territory and all devs see are the snippets provided for implementation. So the only time most people become aware of it is if marketing has someone technical working directly within FB's interface or if the person tasked with implementation has a reason to dig into Facebook's dev documentation rather than just plop the snippet on the page like they were told.
[1] https://www.facebook.com/business/help/164749007013531?id=40...
Having said that, this sounds like "Hey guess what? We are gonna snoop on you, and profile the hell out of you and leak all of your sensitive data all over the place (filenames can be) all because you are a paying customer"
That's about the worst way to disrespect a paying customer. Is there a way to easily identify companies that does this, I can avoid them?
> "easily identify companies that does this"
No. And this can happen for a lot of reasons as explained so even harder to check for.
> What happens if you resolve http://facebook.com to 127.0.0.1 via hosts-file? (Or put it into your Pi-Hole DNS Ad-Blocker, or the like.) Does the Backblaze UI still work?
> Answer: Seems to work well. You need to add the main domain and sub domains (www. in this case), btw.
But why they need to submit that to Facebook for paying users I don't understand. The only thing I can think of is excluding active users from advertising... But is that worth the privacy intrusion?
This doesn’t look like the right data to be sending FB for that, though.
Good job, backblaze. So many years of work building goodwill with transparency in hard disk reports ruined completely with one stroke.
There really isn't any competitor to B2 on price, or convenience (e.g. them sending you a NAS device for recovery).
Also, huge warning for Wasabi newbies so you are not surprised. This might wreck your wallet.
Your egress is capped at your total amount stored. You cannot store 5TB and have 6TB of downloads against that account. The front page is covered in 'No Charges For Egress' 'no additional charges for egress or API requests'.. etc. This is not written anywhere on the main marketing pages, only behind a small link.
Another important point is file deletion. You are required to pay for multiple billing cycles (months) of files. Be very cautious about this. Using it as a temporary bucket will incur significant costs, if you upload a file, YOU WILL PAY FOR 90 DAYS OF THAT FILE. It is almost certainly not cost effective to store files in Wasabi any less than long term. Deleting a file that you just uploaded will incur a deletion fee equivalent to 3 months of storing that file.
The same goes for AWS IA and Glacier classes and Google's Nearline and Coldline. Unless you're storing files for a long time, always factor in the minimum retention period before estimating costs. It'll prevent any nasty billing surprises -- speaking from experience unfortunately.
As a provider of a paid service, it seems like they're in a better position to take the high road than a lot of tech companies are, but they have to decide that's who they are, and be clear they mean it.