A post on Promotion Driven Development yesterday touched on something I really dislike; Rigid Career Levelling. "Level Worthy" is a phrase I feel a lot of managers misuse as a means of pressuring engineers to take on projects. alsutton.blog/post/what-is-lev

@dazinism @larma You still get the launcher databases in Android 12 because launcher isn’t a third party app.

A few folk pinged me overnight my time (UK) to say "adb backup" addresses only one exfil vector. That's true, but it's a vector I have the most context on. If I wanted to make all exfil harder my temptation would be to require a factory reset when enabling developer mode.

This would follow the model of unlocking the bootloader; If you enable something which reduces the security of the device you have to wipe the users data, but would be a *huge* behaviour change.

@sheogorath The biggest hurdle would probably be getting Google to accept the submission.

Something pointed out to me on T*itter; Apps targeting Android 12, which aren’t declared as debuggable in their manifest, will not have their app data included in an ‘adb backup’ backup.


@sheogorath Doing all of the things you mention would leave user visible traces on the device. There is no easily accessible sign adb backup has been executed.

@sheogorath I don’t think that the unauthorised user should be able to choose what destination is trusted, and, on almost all production devices sold, they wouldn’t be able to without adb backup being available.

@larma The target device for adb backup can be something the user is unaware of.
Can you tell me why you believe adb backup files and the files stored on Googles servers are the same? Where has this information been publicly stated?

@sheogorath With the addition of “to a trusted place”, yes, but the trusted place guarantee is missing in this context.

@pvagner I’m not familiar with other offerings because I haven’t looked into them.

@sheogorath If a backup solution allows for the quick and easy exfiltration of a users data then yes, it shares the same problem.

@larma Google cloud backup restoration needs a target device to restore to, and you can’t quickly perform an operation which dumps all the data to a PC or other unprotected area without modifying the OS or kernel of the device.

I've submitted a patch to the to take the next step in what was probably, externally, my least popular contribution to while I was at Google. Here's the reason I think it's time to go beyond deprecating `adb backup` and remove it entirely. alsutton.blog/post/adb-backup-

Selling things like Single Sign On for big identity providers (e.g. Google) as an additional extra comes across, to me, as pretty sleazy given the maintenance overhead should be lower than maintaining your own authentication solution. atlassian.com/software/access

Al Sutton boosted

Looks like I might be spending some of tomorrow cleaning up some code to push to a public repo so that folk can start building Automotive OS 11 for the @samsung and test apps in their cars…

@MarcatoMarc Running it on a device would require the same binary support package as a phone targeted build, so you’d need to create a car target for your device with the same BSP the lineage build used.


The original server operated by the Mastodon gGmbH non-profit