Archive for October 23, 2017

Monday, October 23, 2017

How Well Do Filesystems Handle Errors?

Dan Luu (tweet, Hacker News):

We’re going to reproduce some results from papers on filesystem robustness that were written up roughly a decade ago: Prabhakaran et al. SOSP 05 paper, which injected errors below the filesystem and Gunawi et al. FAST 08, which looked at how often filessytems failed to check return codes of functions that can return errors.

[…]

No tested filesystem other than btrfs handled silent failures correctly. The other filesystems tested neither duplicate nor checksum data, making it impossible for them to detect silent failures. zfs would probably also handle silent failures correctly but wasn’t tested. apfs, despite post-dating btrfs and zfs, made the explicit decision to not checksum data and silently fail on silent block device errors.

[…]

Relatedly, it appears that apfs doesn’t checksum data because “[apfs] engineers contend that Apple devices basically don’t return bogus data”. Publicly available studies on SSD reliability have not found that there’s a model that doesn’t sometimes return bad data. It’s a common conception that SSDs are less likely to return bad data than rotational disks[…]

Plus, APFS can be used on non-Apple SSDs as well as on hard drives, so there’s really no reason to believe that checksums wouldn’t detect errors.

Previously: Apple File System (APFS).

Backing Up Cloned APFS Files

Dave Nanian:

QThere are cases where we can’t make an exact copy of your APFS volume. And Time Machine can’t either. Nothing can.

[…]

The reason is there’s no (public) way to find out that two files are actually sharing the same data (they might even only be sharing some of the same data, as I explain above). So, when copied, the “clone” relationship is broken, as is the ten-pounds-of-shit-in-a-five-pound-bag magic. You now have a full ten pounds. It doesn’t fit…so you end up covered in shit.

[…]

Time Machine does seem to be able to determine if two files are clones (which I assume it’s doing with private APIs, because I can’t find any documented APIs to determine if two files are clones). When it backs up cloned files, it uses hard links to represent them (since HFS+ doesn’t support clones, and Time Machine can only back up to HFS+ volumes), and when it restores, it checks to see if those files are clones (which it tracks in a special database), and restores them as clones to APFS…unless they’re restored to an HFS+ volume, where all bets are off.

But even in the best case, restoring to APFS, when files get ‘separated’ when they’re changed, again, only the part of the file that was changed is separate. The other blocks are still shared. So even though they’ve jumped through hoops to maintain the clone relationship, there are lots of cases where Time Machine’s own copies will increase in size too, and it happens more and more as the files diverge further.

[…]

What does this mean for you? It means you can get in cases where data that fits on a source drive won’t fit on a destination, even when the drives are exactly the same size.

Previously: SuperDuper and APFS.

Update (2017-10-29): See also: Howard Oakley.

Stealing Sensitive Browser Data With the W3C Ambient Light Sensor API

Lukasz Olejnik (via Ricky Mondello):

To better compete with native apps, websites might soon be able to access ambient light readings. There is currently an ongoing discussion within a W3C Device and Sensors Working Group whether to allow websites access the light sensor without requiring the user’s permission. Most recent versions of both Chrome and Firefox have implementations of the API.

[…]

Since a website can apply different styles to visited and unvisited links, but cannot detect how the links are displayed to the user, we use the sensor to identify its true color[…]

[…]

Potentially more troubling is the fact that attackers can extract pixel-perfect representations of cross-origin images and frames: essentially, discover how a given site or image looks for the attacked user (in our demo we focus on images because they are easier to exfiltrate). In extreme cases, for example on sites which use account recovery QR codes for emergency access to an account, this could allow the attacker to hijack the victim’s account.

Update (2017-10-25): John Gruber:

I don’t want web browsers to compete with native apps. I want web browsers to be document viewers that I can trust with anything.

The Camera Button

Savannah Reising:

We set out to find an alternative to the Astropad ring. The obvious first option was to make a new gesture, but we realized pretty quickly that there was limited room for this. Every edge of the iPad is already occupied with an existing gesture: swipe up for your dock, left to search, and down for notifications. We really needed something novel to work with.

Our Astro HQ cofounder Giovanni Donelli said that the idea to turn the camera into a button came like lightning, “I had been staring at a white bezel iPad for so long, and I kept wishing there was another home button we could use. My eyes kept falling on the camera, and I really wanted to touch it!”

[…]

The Camera Button works by detecting the amount of light coming in through the camera. Covering up the camera with your finger blocks all light, triggering a response from the iPad. The tricky part was getting it to work in all lighting conditions, across all iPad cameras.

Why Work Without a Nib?

Jeff Johnson:

You can’t merge changes to nib files on different version control branches.

[…]

Unlike source code, nibs have no place for comments written by the developer.

[…]

A couple years ago I was working on an app that was itself around 10 years old. I wanted to fix a bug, and that required a change in a nib file, but when I made the change, that somehow caused another problem even worse than the one I was trying to fix. It was a total mystery. Ultimately, we just had to declare that nib file off-limits, untouchable, in order to avoid the problem caused by modifying the file. This is a terrible position to be in as a developer.

No matter how outdated the source file, no matter how many deprecations and build errors, you can always at least read the old source code and try to refactor it to work again. The same is not true of nibs. Old nibs can become completely unrecoverable, and you just have to trash them and start over from scratch. You may not even be able to use them as a model for the new UI. Remember Interface Builder 3 Plugins? Any nib with an IBPlugin dependency is now garbage.

Previously: Working Without a Nib, Decoding Old Nibs: a Sad Tale of Vendor Lock-in and Abandonment.

Update (2017-10-24): Arek Holko:

XIBs/storyboards are kinda technical debt. Quick and easy to create, hard to maintain.

Update (2017-10-25): Mark Damon Hughes:

These NIB files “work”, in that they deserialize into objects, but there’s no way to edit them. Where possible, I now do most UI work in code; this isn’t great fun, I end up with a ton of builder functions to avoid repetitive code blocks, but it’ll still compile and work in 10 years.

Update (2017-10-27): James Shore:

You say, “no coding necessary!” I hear, “we built a crappy DSL accessed via point-and-click with no version control or testing API.”

Copyright © 2000–2024 Michael Tsai.