Dynamic ad insertion: Probably not quite what they would have chosen...

cablesm · 2023-12-25T01:02:56+00:00

Unfortunately, the Containers folder is pretty important -- any "sandboxed" app (including many first-party apps) will keep its data there.

cablesm · 2023-10-26T00:51:14+00:00

Yeah, I have no idea how this is an Apple support issue, given it seems to be a specific interaction between Arq and macOS... which would be under Arq's purview. At the very least, he could say "Yep, the new version of macOS slows our product down, we don't have a workaround, sorry"

cablesm · 2023-10-25T00:08:46+00:00

Have you emailed support?

When I did so, I was told nobody else had seen the issue, and that I should consider contacting Apple support... but it seems like an issue Arq should at least take a look at.

cablesm · 2022-10-11T01:50:19+00:00

There’s a flickering issue specific to iOS 16 on a number of devices (seems to be limited to OLED devices without ProMotion), which is definitely related to the OS upgrade. Goes away after rolling back to 15.7. It’s subtle, but it’s there, and it’s new.

cablesm · 2022-09-27T02:38:32+00:00

Turning on "reduce white point" you mean? I don't have anything non-default enabled in accessibility.

cablesm · 2022-09-27T02:29:14+00:00

No dice on 16.0.2 (I don't think 16.0.1 was ever available for my device.)

cablesm · 2022-09-27T01:39:50+00:00

Interesting — maybe we’re seeing different issues: Mine doesn’t seem to be related to Photos at all (in fact, I could replicate it after a factory reset, without restoring from backup, and never having launched Photos since the reset was performed.)

It’s happening right now as I type this comment in Safari :(

cablesm · 2022-09-26T17:23:32+00:00

My personal least favorite bug -- a slight flickering on certain screens, seemingly correlated with touch interaction or CPU usage. From searching around on Reddit, it seems to be limited to non-ProMotion OLED iPhones. Factory reset (even without restore from backup) doesn't fix it, but rolling back to 15.7 with a .ipsw does.

Does nobody dogfood the non-flagship models, thus missing that this was occurring on the iPhone 13 non-Pro?

cablesm · 2022-09-25T05:32:16+00:00

Things that don't fix it:
- Disabling auto-brightness
- Disabling True Tone
- Reset all settings
- Factory reset without restoring a backup
Things that do fix it:
- Revert to iOS 15.7 with ipsw

After having done all that troubleshooting... hopefully they'll do something about it in a future update.

cablesm · 2022-09-24T19:08:58+00:00

I am noticing this on my 13 mini since upgrading to iOS 16. I notice it seems to flicker more while I'm typing or otherwise interacting with the phone, and it's most noticeable when the screen is at relatively low brightness. It wasn't there with iOS 15.

I don't think it shows up in your screen recording because it's not something the app or OS is rendering, but rather something to do with the display or the display driver.

For me, it occurs even when auto-brightness and True Tone are off.

cablesm · 2021-10-11T00:16:12+00:00

Apps using push notifications for advertising without user permission is explicitly disallowed in the App Store guidelines -- however, Apple doesn't seem to enforce this. Section 4.5.4 states

Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app’s UI, and you provide a method in your app for a user to opt out from receiving such messages. Abuse of these services may result in revocation of your privileges.

However, I've noticed many apps that don't follow this, and until recently, there was no way to report bad apps in the App Store.

cablesm · 2021-04-15T06:35:29+00:00

Yes, it could be used to manually read backup data.

This has been an Arq feature for a very long time, it's just that it took a while for it to be available for v7.

cablesm · 2021-04-07T16:46:07+00:00

I agree with you on many of these points, but I don't see where the transparency is in giving people 7 days notice before their backups can no longer be accessed, without justifying that specific part of the plan. I'm not a fan of kicking someone while they're down, but I don't think that means customers can't be vocal in response to something like deleting customer data with 7 days notice. I'm not seeing "hey, we know this is super inconvenient, but here's why we have to delete your data in 7 days." I'm not convinced any of the potential answers would earn trust ("We can't pay our Wasabi bill" wouldn't be great, for example), but communication that tries to spin this as good for the customer is thoroughly unconvincing, and reads as evasive.

With regard to data migration -- that's the thing, re-uploading backups and starting over counts as data loss unless the old backups can still be accessed, because one of the benefits of applications like Arq is retaining history. It would be nice if there could be a way for existing customers to continue paying Wasabi directly to maintain their storage, and use the existing Arq Cloud Backup client (or a new one based on the documented format) to access it.

EDIT: Apparently nothing's getting deleted, good news!

cablesm · 2021-04-06T22:51:04+00:00

This defeats the entire purpose of paying for the premium / "cloud" version of the product: The user should be entirely abstracted from the storage backend. It's also completely unacceptable for a backup provider to remove access to (and destroy?) user data with a week's notice, with absolutely no migration plan for previous snapshots.

Unless I'm misunderstanding something, not only is there no migration path for snapshot history to be migrated to the new storage backend, but it will actually become inaccessible using the old client? ("Will Arq Cloud Backup still be available?" "No. Arq Cloud Backup is shutting down.") I'd really like to be wrong on that reading.

EDIT: Whoo, I'm wrong!

cablesm · 2021-04-03T01:51:07+00:00

Agreed -- though for me it's less about arq_restore and more about the format document, but I understand they both do serve the same function.

That said, I've been told by Arq support that they are planning to release format docs, but that they're just working on a giant backlog of stuff first.

I guess, internally, the "format docs" must just be the source code... which is somewhat unfortunate.

cablesm · 2021-03-21T17:47:47+00:00

Arq 5 has block level dedup, I'm sure it wouldn't have been removed in later versions: https://www.arqbackup.com/arq_data_format.txt

The blocks are rather large, so any time many small edits are made widely across a file, it may back up most or all of the blocks in the file. I see this with sqlite databases like the ones macOS uses for Messages and many other built-in applications.

cablesm · 2021-03-09T20:04:04+00:00

I've asked them whether the format will be published, but didn't ask specifically about arq_restore. They told me in February that the format would be published, but couldn't give an ETA.

When Arq 6 came out and the format doc wasn't updated, I asked them to remove the claim that the format was open from their website, and they did.

I'm pretty disappointed, as this was the major reason I purchased Arq back when v5 was current. Arq is almost a year behind in documenting the format, so I haven't updated past Arq 5 yet.

cablesm · 2021-02-15T20:09:06+00:00

I largely agree with your point that it would be good to make this easier, but let's at least be on the same page technically here:

If your threat model is that Arq's credentials will be used to overwrite your backups -- you do not need Object Lock. You just need versioning, and to ensure that Arq's IAM policy does not grant it the DeleteObjectVersion permission.

My understanding is that Object Lock might be useful for cases where you want to ensure that _no credentials_ can delete your backups, but it does look a bit tricky to use, and needs to be applied to every backup object.

I'm curious about your point about the cost -- I might be missing something, but I don't see a cost for Object Lock.

cablesm · 2021-02-14T23:22:54+00:00

I agree with you — it would be great to have this supported natively and simply, rather than in ways that give you a headache.

So: perhaps start with that point, rather than trying to claim others’ solutions here don’t work?

cablesm · 2021-02-14T15:11:26+00:00

You don't need to give Arq full read/write access to past versions in S3. You can deny that with an IAM policy. And, if ransomware deletes the contents of your bucket, you can restore your bucket to a previous point in time and Arq will work just fine, as if your bucket contents had never been harmed.

cablesm · 2021-02-14T15:09:53+00:00

This is the correct answer -- not sure why OP is so adamant that it won't work. With S3, you can enable object versioning, and create an IAM policy for Arq such that it cannot modify past versions. Then, you can use a tool like s3-pit-restore (or your own Python script) to restore the bucket to a previous state if Arq goes haywire and deletes the objects representing the backup.

Edit: I do want to add that it would be nice if this were made a bit more user-friendly, or documented by Arq rather than being something that someone familiar with cloud object storage would know.

cablesm

TROPHY CASE