Rationale:

 - Right now:

   - These pages' Markdown will be rendered when browsing our
     repository in the GitLab web interface

   - The .md extension is more common nowadays: GitHub, GitLab, and various
     other major players have settled on it. Let's get used to it.

 - If we decide to migrate our blueprints to GitLab (#18079),
   this will be a necessary first step.

macchanger.md

+[[!tag archived]]
+
+[[!toc levels=2]]
+
+# Future work
+
+## Using NetwokManager for AvoidConnectionProbs?
+
+Instead of our current hack, we'd ideally want to hook into
+NetworkManager's error handling, which certainly would be more robust,
+and hopefully would provide more information about the error, but this
+currently seems unsupported.
+
+An experiment has showed that when connecting to a password-protected
+(WPA-PSK) wireless network with MAC address white-listing, spoofed
+(and hence blocked) MAC addresses resulted in an endless cycle of NM
+asking for passphrase. When cancelled, NM displays a "Disconnected"
+notification, and during this time no NM dispatcher events were
+emitted.
+
+Some bugs of interest that may bring some hope:
+
+* [[!gnomebug 387832]] resolved
+* [[!debbug 518368]] fixed upstream
+* <https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/336736> wontfix
+
+## Vendor bit randomisation with macchiato
+
+These are the current relevant OUI counts from macchiato's git:
+
+5       oui/bluetooth_laptop.sh
+2       oui/bluetooth_misc.sh
+12      oui/bluetooth_mobile.sh
+1       oui/bluetooth_pmp.sh
+2       oui/wired_console.sh
+3       oui/wired_desktop_dedicated.sh
+11      oui/wired_desktop_onboard.sh
+8       oui/wired_infrastructure.sh
+17      oui/wired_laptop.sh
+6       oui/wired_misc.sh
+4       oui/wired_printer.sh
+2       oui/wireless_camera.sh
+1       oui/wireless_console.sh
+4       oui/wireless_desktop_dedicated.sh
+2       oui/wireless_desktop_onboard.sh
+4       oui/wireless_handheld.sh
+6       oui/wireless_infrastructure.sh
+1       oui/wireless_laptop_dedicated.sh
+21      oui/wireless_laptop.sh
+17      oui/wireless_mobile.sh
+7       oui/wireless_pmp.sh
+4       oui/wireless_printer.sh
+8       oui/wireless_usb.sh
+
+In particular there's ~20 each in wireless_laptop and wired_laptop,
+which is what we should care about most (desktops rarely need MAC
+spoofing). However, after investigating the sources for some OUI:s
+(via git history), some OUI:s are (according to the submitter) only
+common in certain geographical areas. This makes the lists too small
+and unreliable at the moment.
+
+There are others attempts at collecting MAC addresses for various
+kinds of hardware:
+
+* [Boruch-Baum's mac_changer_choice](https://github.com/Boruch-Baum/mac_changer_choice)
+* Subgraph's ouiner
+  ([Bitbucket](https://bitbucket.org/mckinney_subgraph/ouiner),
+  [GitHub](https://github.com/mckinney-subgraph/ouiner))
+  whose data is used by
+  Macouflage ([Bitbucket](https://bitbucket.org/mckinney_subgraph/macouflage),
+  [GitHub](https://github.com/subgraph/macouflage))
+
+# Questions, remaining issues, and other random stuff
+
+## MAC spoof failure warning and failsafe
+
+If MAC spoofing fails for some interface we'd like to prevent it from
+exposing the real MAC address, and warn the user about this via a
+notification.
+
+In the current implementation there's no failsafe that verifies that
+the selected MAC spoofing setting has been enforced before
+connecting. This would be easy if there was something like pre-up NM
+dispatcher hooks but just like in the section about "Connection
+failure detection", there's none yet.
+
+An alternative would be to do this in
+[[!tails_gitweb config/chroot_local-includes/usr/local/lib/tails-spoof-mac]], which
+is run by the udev hook. In the end of the script we could try to
+verify that the spoofing indeed happened for the NIC in question, and
+if it didn't we could go into full-out panic mode:
+
+1. Down the interface
+2. Try to unload the module used by the NIC. While one easily can find
+   the module used by a `$NIC` via `readlink
+   "/sys/class/net/${NIC}/device/driver/module"`, we'd also have to
+   resolve reverse dependencies. For instance, for current Intel
+   wireless chipsets, the `iwlwifi` module is loaded, but with current
+   Linux kernels another module called `iwldvm` is loaded, and it uses
+   `iwlwifi`, so a `morprobe -r iwlwifi` will fail. Sadly `modprobe`
+   doesn't have a `--recursive-remove` or `--show-reverse-depends` so
+   we'd have to e.g. parse "Used by" field of `lsmod` or similar, and
+   we'd have to do it recursively to be rigorous.
+3. Perhaps prevent NetworkManager from starting if the previous step
+   failed?
+4. Show a scary error message to the user
+
+It would obviously require to drop `set -e`, because errors are indeed
+what could cause this to happen.
+
+## Detecting MAC-spoof related connection errors for wired NICs
+
+While Wi-Fi connection are covered, this gets trickier for wired
+connections. The problem is that there's no strong concept of being
+"associated" to a wired network (at least a "standard" one, perhaps
+there is with 802.1x security...). It'll probably be hard to identify
+blocking without confusing it with other types of wired connection
+failures (i.e. false positives). How does wired MAC address blocking
+usually work? On which level? DHCP? Lower layer?
+
+# Old stuff from blueprint
+
+## Improving macchanger
+
+Some of our goals would be easier to achieve by patching macchanger
+itself. Since it's been unmaintained upstream for a while, we've been
+discussing and working with someone who has taken its maintenance over
+and has already started patching it to better suit our needs:
+
+* [Redmine project](https://labs.riseup.net/code/projects/show/macchanger)
+* Git repository: `git://labs.riseup.net/backupninja.git`
+* Debian packages: the maintainer of the macchanger package in
+  Debian has already integrated some of these patches (uploaded to
+  sid: 1.5.0-8) and is likely to go on this way. Tails has been
+  using this improved version for a while.
+
+## Inspiration sources
+
+### Haven
+
+Haven does not automatically start network-manager at boot time.
+It provides shortcuts in the application menu to run macchanger-gtk
+and start the network if desired.
+
+### Liberte Linux
+
+Liberte Linux randomises wireless MAC addresses at boot time and
+allows changing wired interfaces' MAC addresses after boot, see their
+`src/usr/local/sbin/mac-randomize` that uses `ifconfig IFACE hw ether`
+rather than macchanger.
+
+## Documentation
+
+Investigate and possibly document the kind of information that could
+still be seen on the LAN about the system. Such as the manufacturer (ex:
+Sony), model number, BIOS and version, etc.?