Considering that digital electric meters have been compromised, and that the one I studied had dual-band radios including WiFi spectrum, it may be best to assume that there may be unexpected data pathways that could use a MAC address.
Note that the WiFi of many routers broadcasts the wired MAC addresses on the LAN as well as the wireless clients.
You're right about false-negatives with sniffers. If you read the source on pages you visit, you'll see https analytics data mining, so don't assume that every outgoing https connection is okay. (and some browsers don't use your normal DNS / hosts settings, so sites you think are blocked may not be)
Privacy from OS creators is likely outside of the scope of your project, but I thought I'd pass along recently observing that filtering using the hosts file on older Intel OS X which works for other browsers does not seem to be effective for Safari. I'd long ago read of MS using their own DNS for IE, perhaps Apple is doing something similar? It could be done for performance reasons, but it certainly has privacy implications.
I hope you consider things like blocking loading of webpage icons, and something to deal with data being appended to redirects or even CSS calls when cookies are disabled. I'd read about detecting caching of slightly different colored versions of icons and beacons. Sneaky offsite https accesses (analytics etc) are commonly bundled in a pages JS and NoScript doesn't alert to that. Also, some browsers seem to make accesses to a number of sites on startup, before even going to open a page.
Widening the view from "advertisers" to data-mining contractors that even do drive-bys, it might also be worthwhile to study what could block local data broadcasts by code designed to modulate r.f. noise leaking from our machines. Tune across the A.M. broadcast band on a nearby battery operated radio. I've noted that sometimes there's much more pulsed/bursty noise that doesn't seem to be tied to any obviously more demanding content.
Some of the insideous Ad-Choices content seems to go beyond Flash for hiding data. From the plugin being called when there wasn't any visible content needing it, I think even Quicktime is being used to cache data.
It would really help if scripts from one tab could not be accessed by another, and were killed on closing the parent tab. I guess the litterboxing would best be done by a trusted browser? Bring on the worming tablets!
> filtering using the hosts file on older Intel OS X which works for other browsers does not seem to be effective for Safari
Could you clarify this point? I may well simply be misunderstanding, but a quick check of a hosts-blocked site using Safari, in El Capitan, does indeed not resolve (or rather, resolves to localhost, as specified).
>This bandwagoning dismisses more collective works and industries than any technology in the past just for the sake of promoting bleeding edge, evergreen tech.
Flash needs to go for the sake of our security, not to climb up to a bleeding edge. The security risks are way beyond unacceptable.
Perhaps you could argue that some similar functions in HTML5 have just as serious of threats but additionally lack an off switch??
As for accessing legacy content, treat Flash like Ebola and keep an old machine around for that? It would help if the old machine has no writable flash or drives (or at least includes a non-writable restore image if there's a drive).
If our machines have writable flash for the network adapter, video card, hard drive, bios, and a few other things, how secure can they be? Even our flash isn't safe from Flash.
Systems with UEFI are more likely to also support virtual machines at the CPU level which makes it much easier to transparently slip in a layer under everything else.
You're right about false-negatives with sniffers. If you read the source on pages you visit, you'll see https analytics data mining, so don't assume that every outgoing https connection is okay. (and some browsers don't use your normal DNS / hosts settings, so sites you think are blocked may not be)