Just defining the threat model of hardware addressing, as it stands.
I don't agree with them sending more than the first half either.
Just defining the threat model of hardware addressing, as it stands.
I don't agree with them sending more than the first half either.
Not that the local DHCP servers falling over has anything to do with it...
A MAC address isn't really unique. Each has six octets, of which three refer to the manufacturer. The other three octets have at most 16,777,216 possible values. That seems like a lot but it really isn't; a MAC is supposed to be unique on a LAN, not globally. Rollovers during manufacturing happen, and collisions are rare but happen once in a while.
What do you mean, custom firmware? Are you trying to boot a different distro of Linux?
When you have the USB drive plugged in, how are you booting up? What's the process you're using?
The first three octets of a MAC specify the manufacturer of a NIC chipset. That could come in handy for driver debugging.
Manufacturers and firmware versions of storage devices? You can make the argument; perhaps it would have helped figure out the SSD firmware bugs years ago.
But stuff like whether or not you have video capture card or your current system temperature stats? Nah.. that's getting into "identifiable information as toxic waste" territory.
Outfits that haven't installed patches since February are getting popped in May by a vuln that was published in January.
For non-profits (like 501(c)(3)'s) that's not unusual. Non-profits are more like specialized tools for the board of directors than like companies.
Source: First ten years of my career were at non-profits.
Oh, for fuck's sake... no. It isn't. And I find myself pondering whether or not the article's authors are themselves sapient.
Publishing everything on a blockchain means that everybody who's running a node has access to a copy. If confidentiality of communications is an issue, this may as well be a data breach with a few more steps. Also, how does giving everybody running a part of or monitoring the blockchain equate with "control over personal data?"
Centralized control: Only one entity can see it. Blockchain: Lots of third parties run a node, so every node can see it.
Each channel has a separate ledger: That makes surveillance of a particular communications channel much easier. Thanks. Also, each user has to have a keypair; great for pseudnonymity, lousy for repudiability.
Messages cannot be altered but they can be audited to prove their metadata. Did they learn nothing from the Obama administration? At this point in the paper I can't shake the feeling that this is a deliberate effort to invert all of the properties of privacy.
Smart contract: Yay, more deliberately memory unsafe programming. I guess they never played with Core Wars as kids, either.
An attacker would be unable to breach the network: An attacker would just have to stand up a node. If channels are side ledgers on a blockchain, and the network assumes that nodes can come and go (which they all do, as far back as bitcoind), any node can join, say "Hey, I'd like to join this channel," and get at the very least a pointer to the side ledger for that channel.
Long-term storage of communications is dangerous, mm'kay?
I'm going on professional year 24 of clients requiring that IPv6 be deactivated on every device in their network. Whee.
There are two models I've used for this over the years, the Linksys EA8300 and the WRT 1900AC. Here's how I did it both times (though I only got around to writing up my notes the second time.