Call for Collaboration to Apply to NGI "Privacy & Trust Enchancing Technologies" Grant

[tlaurion]

Grant Information here: https://nlnet.nl/PET/
Form here: https://nlnet.nl/propose/

Framapad for grant proposal collaboration: https://mensuel.framapad.org/p/AQqOdrEBWr

Anyone wants to jump in?

[tlaurion]

Some ideas that needs to be picked up and integrated, don't know how to include them in paper yet:
EDIT: Multiple additions. QubesOS will also apply to this for UX improvements.

Please comment all pertinent ideas!

Heads specific work

• Properly support Intel based, most binary free initialized platforms in coreboot (Ivy Bridge and Sandy Bridge). This implies integrated Measured boot improvements that landed in Coreboot 4.9+, which sits atop of VBOOT and change Head's internal logic to take advantage differently of TPM PCRs to have proper and mainstreamed BIOS integrity measured. Technically, it means:
  • integrate/ test :
    • Add VBOOT support
    • Enable VBOOT support
  • check if fmap is correct
  • set CMOS flags correctly
• [Support TXT in Coreboot/Heads, so that QubesOS Anti-Evil Maid can be used with coreboot Open Source Firmware](Explore QubesOS AEM usb boot #502)
• Integrate write protection, preventing firmware modification from the Operating System through io386 lock down module Introduce io386 to heads and use it to finalize chipset at runtime #326
• Upgrade disk encryption (cryptsetup LUKS) support in Heads:
  • QubesOS dom0 fedora-29/debian-9 based to be able to support LibremKey-enabled LUKS container unlocking so that Heads can take advantage of this in a generic way.
  • Integrate Kali LUKS key slots wipe permitting the user to deny themselves and others system and data access, basically locking themselves out of the system until a full disk backup is restored.
• Reduce Heads Whiptail graphical footprint to fit a broader range of devices having 4Mb SPI flash, including x200 (Tails perfect Laptop. More generally in 4MB flash, while available in 8MB SPI if vPro) and G505s and probably a lot of others.
• Implement forward sealing of firmware upgrades

Hardware mods to streamline/for which open source blueprints needs optimizations

• Fablab test/build/improve NSA-B-GONE camera and mic hardware datalink cutoff through thinklight keyboard shortcut, so it can be easily laser cutted/ordered online from oshpark or elsewhere. Insight is that those could be laser cut and the connector be made out of mica (capacitor) pastic.
• Fablab test/build last blobfree x86 reasonably secure server/workstation (KGPE-D16/KCMA-D8) open sourced iKVM ASMBV4 remote administration chip, so that QubesOS/private hosting solutions/FPF SecureDrop Workstation/Servers have trustable root of trust in Heads. Current unmaintained OpenBMC port exists for that module, where some work would need to be done for that server to boot u-root

QubesOS related work

Create and deploy additional Salt recipes at QubesOS installation/new defaults that

• Grow QubesOS user base by developing third party assistance services base.
  • Develop Whonix (sys-whonix) on-demand hidden onion GUI, opening dom0 remote support through SSH and socat. Whonix ticket here.
• Properly handle qube's LVM freed space at all levels, reducing catastrophic user experience of running out of of disk space.
• Deploy qubes-update-cache and make update-vm dependent on it, so that packages are downloaded once per TemplateVM types (fedora, debian, whonix-gw, whonix-ws) even if many clones were created and specialized out of them. Keeping one's system up to date then requires only minimal bandwidth.
• Deploy good privacy default for NetworkManager, forcing randomized mac usage when not told otherwise.

Sent from my Galaxy S3 using FastHub-Libre

[tlaurion]

@merge @marmarek @osresearch @kakaroto @mfc :
Any other improvements you would love to see happening into Heads Heads/QubesOS, integration of better privacy/confidentiality enforcing measures that would benefit all privacy conscious?

[merge]

what comes to mind, but that's more of a question: how far are we with "forbid software-flashing everywhere except in one root-of-trust place inside the flash"?, for the coreboot side, it started with this discussion: https://coreboot.coreboot.narkive.com/ovqZj0CI/spi-controller-and-lock-bits and I don't know how far that is. In Heads we should use that and maybe, when we read a grub config off disk, think about warning/forbidding kernel parameters like "iomem=relaxed"... thanks.

[tlaurion]

what comes to mind, but that's more of a question: how far are we with "forbid software-flashing everywhere except in one root-of-trust place inside the flash"?, for the coreboot side, it started with this discussion: https://coreboot.coreboot.narkive.com/ovqZj0CI/spi-controller-and-lock-bits and I don't know how far that is.

@merge : #326? Never tested it though.

In Heads we should use that and maybe, when we read a grub config off disk, think about warning/forbidding kernel parameters like "iomem=relaxed"... thanks.

@merge : It could be as easy as putting that here:
export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

[marmarek]

@merge : It could be as easy as putting that here:
export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

This isn't viable solution - there are way too many potentially harmful kernel options. If anything, there should be a whitelist of allowed options.

[merge]

thanks for the links and updates. sorry for the confusion. actually it's quite unrelated and not a good idea to mess with user's kernel commandline so much. All we need for a proper root of trust is (persistent until reboot-)write-protection of the flash as soon as possible unless the user chooses "upgrade" or something. Once we have that, it should really be irrelevant what iomem or others say.

We really need to verify whether that works for the X230's flash chips, and implement a user-friendly solution.

[tlaurion]

@merge : It could be as easy as putting that here:
export CONFIG_BOOT_KERNEL_REMOVE="iomem=relaxed"

This isn't viable solution - there are way too many potentially harmful kernel options. If anything, there should be a whitelist of allowed options.

@marmarek: agreed. But:

• Potentially harmful added kernel options arrives into grub configuration per logged in user upgrades or manual Head's recovery shell manipulations.
• /boot changes are detected here. Since /boot hashes are generated at each boot and validated against user's signed kexec.sig, no file under /boot can be changed without the user approving/knowing what changed.

Following this, a whitelist seems overkill, io386 actually prohibits iomem=relaxed from being successfully used to reprogram the SPI flash from within OSes other then Heads which locks it. Following this, if io386 is in, removing iomem=relaxed from KERNEL_REMOVE is useless.

[mfc]

hey folks, just chipping in that the Qubes proposal I will draft will be focused on Qubes usability (integrating existing efforts that still haven't been reviewed/incorporated into the release) and internationalization/localization/accessibility support. so it will be a bit "conservative" in approach but filling in some very necessary gaps Qubes has.

I don't expect any overlap with these topics so the Heads/Qubes proposal can be as ambitious as desired! :)

[snmcmillan]

I think that one idea for heads-specific work is to port to more devices. Ideally, support more ThinkPads and as many Chromebooks as feasibly possible.

On the ThinkPad side of things, since xx20 and xx30 are incredibly similar, it should be rather simple to port kernel configs to T420 (I currently have a PR for that), T430 (someone else seems to be on that), T420s/T430s, T520 and T530. I presume the T410, T510 and X201(s/t) should also be trivial as well (they may even work with the same config to the X230 config that the X220 and the T420 are using currently).

For Chromebooks, the most ideal and easiest way to do this is to collaborate with Mr. Chromebox, which maintains custom coreboot builds for many, many Chromebooks. If we can get the patches used for heads to be merged into mainline coreboot, that effort would be very easy, all that's needed is for someone to update Mr. Chromebox's repo (either via a fork or getting the new base to the main repo) and having a mostly universal kernel config for them to use when building the kernel.

Having several different hardware options for users to choose from would not only open heads up to more users, but it could also lead it to being more streamlined than it currently is.

Another thought I just had was to get Heads (and even possibly Qubes) running on ARM devices (namely ARM Chromebooks). ARM-based Chromebooks may remove the threat of IME/PSP, unless they also have a hardware level backdoor that I'm presently unaware of.

On the Qubes side of things (independent of Heads), one thing is to get the GUI out of dom0. I've heard chatter about this from various places, but this would be huge.

Another thing worthy of being implemented is proper touch screen and stylus proxy support. I do know that this would be very difficult considering USB input device security is already a problem in itself.

I apologize for this text wall and if it's difficult to read.

[tlaurion]

I think that one idea for heads-specific work is to port to more devices. Ideally, support more ThinkPads and as many Chromebooks as feasibly possible.

@SebastianMcMillan : Agreed, with some personal limitations, see below.

On the ThinkPad side of things, since xx20 and xx30 are incredibly similar, it should be rather simple to port kernel configs to T420 (I currently have a PR for that), T430 (someone else seems to be on that), T420s/T430s, T520 and T530. I presume the T410, T510 and X201(s/t) should also be trivial as well (they may even work with the same config to the X230 config that the X220 and the T420 are using currently).

For Chromebooks, the most ideal and easiest way to do this is to collaborate with Mr. Chromebox, which maintains custom coreboot builds for many, many Chromebooks. If we can get the patches used for heads to be merged into mainline coreboot, that effort would be very easy, all that's needed is for someone to update Mr. Chromebox's repo (either via a fork or getting the new base to the main repo) and having a mostly universal kernel config for them to use when building the kernel.

Having several different hardware options for users to choose from would not only open heads up to more users, but it could also lead it to being more streamlined than it currently is.

Agreed, while again, the most free platforms (binary free of Intel FSP/no AMD PSP, me_cleaner neuterable Intel ME platorms containing only ROMP and BUP modules) should be priorized in that list. This is why I push so much the x230 right now and think that Ivy bridge first, and then sandy bridge second, based laptops should be supported more.

This doesn't mean that other platforms should not be added in parallel. My point here is that my own priority is to push most trustable hardware available today (binary blobfree 4.9 coreboot (graphic init, native ram init, etc) with Measured boot support, TXT support(optional), TPMv2 support) well supported/tested before integrating other platforms.

I invite others to collaborate on that and will gladly add those platforms in the points to be covered for the grant but won't do that work myself nor will be able to test those platforms, while inviting the community to do it and be paid for those contributions.

Another thought I just had was to get Heads (and even possibly Qubes) running on ARM devices (namely ARM Chromebooks).

Follow GSoC progress for ARM64 here. I'm personally more interested into PPC64 port, for the same reasons evoked above with even more user ownership possibilities (PowerPC notebook, Power9 completely open designs like the Talos II/BlackBird and others).

ARM-based Chromebooks may remove the threat of IME/PSP, unless they also have a hardware level backdoor that I'm presently unaware of.

TrustZone is IME equivalent.
This is an interesting file to follow, but not all ARM architectures include virtualization extension, and from what I saw, the ones that does, for laptops, don't have enough memory to be minimally interesting for QubesOS(8Gb+). But that might change in the future.

On the Qubes side of things (independent of Heads), one thing is to get the GUI out of dom0. I've heard chatter about this from various places, but this would be huge.

It's planned for QubesOS 4.1.
EDIT see here: https://groups.google.com/d/msg/qubes-devel/CA7gHGQk5WE/JEfADyFaBAAJ

Another thing worthy of being implemented is proper touch screen and stylus proxy support. I do know that this would be very difficult considering USB input device security is already a problem in itself.

I've roughly tested this myself and it works:
Scripts
Tablet support in QubesOS

I apologize for this text wall and if it's difficult to read.

No problem. :)

Edit: priorities

Sent from my Galaxy S3 using FastHub-Libre

[snmcmillan]

TrustZone

How did I forget this? That name makes me shudder every time I hear it. Thankfully, it's not a part of ARM in itself, and that not all current ARM devices have it (yet).

I do agree that testing is very important for a project like this, and that also putting more work more free platforms than others is a better choice (seeing how user trust is the entire point of this project). I wouldn't mind maintaining the T420 and X220.

Another thing I recall reading back in the later half of 2017 was that Libreboot was in the works for the X220 and that it would be released in 2018. Seeing how that never happened, I may try to find where I saw that and track down what caused that to never happen. If someone is able to somehow find a way to get rid of the blobs on the X220, that'll likely be relevant to other Sandy Bridge devices at the very least.

[tlaurion]

@SebastianMcMillan

Libreboot on x220 was conditional to the tiny possibility to have it RYF certified if IME could be completely wiped, which, thanks to Trammel and me_cleaner afterward, showed different level of disablement and not be completely possible from a deeper understanding of the dependency torward ME in firing up the main cpu. Creating debates and confusion on ME being deactivated/neutered/deleted.

RYF guidelines and conditions would have had to be modified to tolerate neutered IME (90Kb BUP and ROMP required modules to fire up main CPU on Ivy, even less on Sandy), which they didn't and still don't and probably won't do, since that cpu is still there and alive, running unknown code. I would consequently greatly doubt RYF certification criteria to change for that reason.

I think that debate for the x220 to be supported by libreboot happened on Reddit under Leah's name. The x220 product page can be found with web.archive.org for minifree.org.

Following me_cleaner work to not being able to completely delete IME like it was possible on gm45 (x200), Leah dropped the project. That's what I remember of it but my memories may not include all the details.

Edit: added archive.org link to the minifree x220

[snmcmillan]

That's the picture I seem to be getting as well. I apologize for getting a little off-topic with that thought.

[tlaurion]

@flammit, @marmarek, @mfc, @osresearch

Anything else to add? I'll begin working on the proposal in the beginning of the week.

Would gladly take reviews/corrections on the framapad link in first post while I go.

Sent from my Galaxy S3 using FastHub-Libre

[tlaurion]

Thanks to all that collaborated! The grant application was delivered in time!

[tlaurion]

Retained! Gonna be considered and evaluated against all other projects in the next 3 weeks before final approval/refusal:

It is my pleasure to inform you that your project "Integrating measurable security into daily lives" (2019-04-XXX) has been selected to enter the second round of the 2019-04 call, which means that your project likely fits the eligibility criteria. Given that the amount of remaining candidates still exceeds the available budget, there will be another strict selection round.

This means that your project now has to compete with the other proposals selected with regards to urgency, relevance and value for money. Unfortunately we will not be able to fund all projects proposed, as much as we would like that. For the next three weeks we will be thoroughly evaluating the remaining proposals for the second round, during which we may ask you to supply additional details. After that we will inform you on the outcome of this second (and final) selection round.

[tlaurion]

Passed! Last stage!
@mfc @marmarek @BlackMaria @merge @osresearch @SebastianMcMillan @kylerankin @zaolin @adrelanos

[...] you applied to the NGI0 PET open call from NLnet. Currently a selection of the projects is with the independent review committee to validate their eligibility, and we are happy to inform you that this includes your project "Integrating measurable security into daily lives" (2019-04-XXX).

Should your project pass that final hurdle, the selection will be made public and we will contact you to negotiate a Memorandum of Understanding. The final amount of the grant will be determined at that point.

We will then also need to share some information about the project both with the general audience and with the European Commission. In the interest of time, we ask you to prepare a one paragraph management summary of the project. For examples we refer you to https://NLnet.nl/thema/NGIZeroDiscovery.html and https://NLnet.nl/thema/NGIZeroPET.html

[tlaurion]

The "Finish porting Replicant to a newer Android version" fits similar general background behind this grant application.

The idea is to facilitate firmware/boot integrity attestation on more hardware platforms (Heads support for smaller SPI, broader support through coreboot VBoot measured boot subconfig: coreboot/Heads), ease accessibility and support of such hardware (OEM reownership (Heads) permitting QubesOS preinstallation, TXT support for AEM(Coreboot/Heads), additional hardening/anonymizing defaults through Salt (QubesOS/Whonix), Additional Hardware security(NSA-B-GONE x220/x230 prototype evolution) and new user support/integration (through hidden onion remote AdminVM administration (QubesOS/Whonix).

Anyone has the talent to write such executive summary? @BlackMaria?

[BlackMaria]

@tlaurion sure, I will try to write something for the one paragraph management summary of the project but I dont understand your point about the similarities with the android text?

IIUC our text only needs to be one paragraph and the examples are provided.

I will aim for tomorrow evening to write this. [ edit: I pinged you in slack, I posted a text ]

[tlaurion]

@BlackMaria : I was referring to the tone mainly of the executive summary, since it's about supporting more hardware and setting bases to ease further platform integration (most of the budget would go on that).

[BlackMaria]

This is my suggested text for such a proposal

The "Accessible Security" project's initiative was sparked by the need for usable security made available to the average citizen. Several projects are contributing a part of this bigger puzzle, QubesOS, coreboot, Heads, me_cleaner, Whonix and others, yet the average person does not have the sophistication to integrate these software projects. With some effort we can add some missing parts, help the effected projects usability, and facilitate access to cutting-edge developments, currently only usable by developers and more sophisticated users. Bringing these projects together will reduce the amount of expertise and effort required to benefit from these projects.

[tlaurion]

Project name changed to "Accessible Security" following Michiel request to ease internal communication exchanges about the project. Again, thanks to @BlackMaria to have this kind of brain which simplifies language! My brain is not good at that but yours is, definitely :)

[tlaurion]

@SebastianMcMillan said:

Another thing I recall reading back in the later half of 2017 was that Libreboot was in the works for the X220 and that it would be released in 2018. Seeing how that never happened, I may try to find where I saw that and track down what caused that to never happen. If someone is able to somehow find a way to get rid of the blobs on the X220, that'll likely be relevant to other Sandy Bridge devices at the very least.

@MagicFab @kylerankin @mfc @marmarek @SebastianMcMillan
Update in regard of RYF certification guidelines.

Personal confusion on certifyable hardware criteria "product software"
and Intel ME: https://www.fsf.org/resources/hw/endorsement/criteria

"However, there is an exception for secondary embedded processors. The
exception applies to software delivered inside auxiliary and low-level
processors and FPGAs, within which software installation is not
intended after the user obtains the product. This can include, for instance,
microcode inside a processor, firmware built into an I/O device, or
the gate pattern of an FPGA. The software in such secondary processors
does not count as product software."

Would the Lenovo ThinkPad X230 be RYF certifyable
<https://github.com/osresearch/heads-wiki/blob/master/Clean-the-ME-
firmware.md>?
Coreboot on this platform is FSP free with native ram init. Heads
makes its root of trust (firmware) tamper evident through measured boot,
while the /boot sha256sum digest is autogenerated at every boot while that
digest is verified with user's GPG public key injected inside to
detect any change. Intel ME with only the ROMP and BUP modules (previous link
PoC) is considered "neutered" and the most trustworthy available
platform for reasonably secure computing (QubesOS moto), having the
possibility to meet their certification baseline and FSF RYF.

If the X230 is certifiable with Heads linux coreboot payload, then i'm
interested in starting the process for RYF certification. The X230 i'm
making, being under QubesOS certification
#551 as the PrivacyBeast
X230, will land public market in the next weeks and permit, for the first
time, shipping of preinstalled Linux inside LUKS container, without
the OEM having the possibility to hand to authorities encryption key or
associated passphrase, the user reowning secrets, first thing, after
having validated firmware and boot integrity prior to launch the
re-ownership Wizard, leading to the re-encryption of its container and
change of its passphrase through generated EFF diceware dictionary
randomly chosen words.

Please clarify first quoted paragraph about RYF certification
requirements to let me know if the neutered, Heads' Open Source
Firmware powered X230 would fit your guidelines.

Thanks for checking in on this. We've been discussing this issue, but as of yet haven't come to a firm conclusion on neutralized Intel ME. We'll certainly raise the priority of that discussion, but I can't guarantee a time frame on when we'll reach a conclusion.

If you would like to go ahead and file an application for RYF certification, we can take a look for other potential issues. I've attached the application form and you can return it to [email protected].

Thank you for working to make hardware that users can trust, and I hope to have an answer to your question soon.

--
Sincerely,

Donald R. Robertson, III, J.D.
Licensing & Compliance Manager
Free Software Foundation
51 Franklin Street, Fifth Floor
Boston, MA 02110, USA
Phone +1-617-542-5942
Fax +1-617-542-2652 ex. 56

[snmcmillan]

The only issue with that is ME is updatable.

…

On Fri, Jun 14, 2019, 10:29 tlaurion ***@***.***> wrote: @SebastianMcMillan <https://github.com/SebastianMcMillan> Update in regard of RYF certification guidelines <https://www.fsf.org/resources/hw/endorsement/criteria>. Contacted FSF, waiting for clarifications, since, from what I undertand, Intel ME is considered an exception: "However, there is an exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software." — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#540>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFNTUNGEEATHMDA46V6CBKTP2O2O5ANCNFSM4G76LDGQ> .

[tlaurion]

@SebastianMcMillan

The only issue with that is ME is updatable.

As is the EC in laptops, the microcode updates for processor (now required....), TPM firmware, hard drive firmware, etc.

The GM45 (x200) was certified in a time microcode updates were a probable prejudice to security, while right now, not having them applied is the prejudice to security. The EC in GM45 was upgradeable, while still certifiable. As is the firmware of the hard drive.

The question being what are they considering acceptable. The open source SSD/HD firmware is still not readily accessible. But closed source is tolerated on that level. The X200 was certified even with those closed source components.

Everything is upgradeable with physical access.

The point being, I think, that once SPI is locked down (#326) or measured (not done actually, but measurements could be extended with something like #493 (complete rom read measurements, SPI address range measurements or modules measurements) or VBOOT/measured boot in coreboot 4.9+ to include ME integrity checks), what would be RYF certifiable.

I wrote back an e-mail dissecting differences in vocabulary currently used to describe Intel ME states.
Removed(GM45 RYF certified)/Neutered (ROMP BUP + AltMeDisable bit) /Neutralized or Deactivated (AltMeDisable bit/ HAP bit while modules still being in SPI [kernel syslib and rbe]).

Waiting for a feedback in their currently made/to be made differentiation.

[tlaurion]

@zaolin @marmarek @BlackMaria @mfc @osresearch @kylerankin @adrelanos @merge

Project receives grant :)

[mfc]

Qubes just received confirmation as well :)

[tlaurion]

@zaolin @marmarek @BlackMaria @mfc @osresearch @kylerankin @adrelanos @merge
NGI0-intakedocument.pdf

As stated in this document, it is expected to have smaller deliverables, so that the funds are transmitted directly to you from NLNet, every two weeks upon completion of tasks. You are responsible to create your own timeline. The results must be public and reproducible.

Questions?

[tlaurion]

Heads/Coreboot specific work

@zaolin

• Properly support Intel based, most binary free initialized platforms in coreboot (Ivy Bridge and Sandy Bridge). This implies integrated Measured boot improvements that landed in Coreboot 4.9+, which sits atop of VBOOT and to change Head's internal logic to take advantage differently of TPM PCRs to have proper and mainstreamed BIOS integrity measured. Technically, it means:
  • integrate/ test :
    • Add VBOOT support
    • Enable VBOOT support
  • check if fmap is correct
  • set CMOS flags correctly
• [Support TXT in Coreboot/Heads, so that QubesOS Anti-Evil Maid can be used with coreboot Open Source Firmware](Explore QubesOS AEM usb boot #502). @marmarek said this was not considered a necessity. A discussion should be engaged between you two before going forward.

[mfc]

FYI just had call with NLNet regarding our own grant and to be clear, a timeline is not very important, just the deliverables. you can ask for funds for a completed deliverable (or sub-task) right after you complete it, or months later if that is useful for you.

Thierry I am assuming since you are the point of contact on this grant you will make clear who is working on which deliverables, get their consent and confirmation on it and the associated costs, and if there are any deliverables missing owners that you will flag that and we can find folks to work on them.

edit: you are doing these things, great :D

[tlaurion]

QubesOS/Whonix related work

@marmarek @adrelanos

Create and deploy additional Salt recipes at QubesOS installation/new defaults that

• Grow QubesOS user base by developing third party assistance services base.
  • Develop Whonix (sys-whonix) on-demand hidden onion GUI, opening dom0 remote support through SSH and socat. Whonix ticket here. @adrelanos: @marmarek provided approximate billing time that got filed for the project. The ideal would be to have a GUI that can manage access to dom0 from sys-whonix, on-demand, when support is necessary. The GUI would permit to copy-paste hidden onion service address and authentication. It could be VNC or other mean.
    EDIT: VNC being too slow, a trick could be to share a setuped terminal through tmux to reach an ideal where the user is seeing what is happening to his system while remote support is ongoing.
    EDIT: Planning here
• Properly handle qube's LVM freed space at all levels, reducing catastrophic user experience of running out of of disk space.
• Deploy qubes-update-cache and make update-vm dependent on it, so that packages are downloaded once per TemplateVM types (fedora, debian, whonix-gw, whonix-ws) even if many clones were created and specialized out of them. Keeping one's system up to date then requires only minimal bandwidth. EDIT: since all update sources are now HTTPS, this feature is now questionable.
• Deploy good privacy default for NetworkManager, forcing randomized mac usage when not told otherwise.