Did MacOS Stop Allowing Changes to Wifi MAC Addresses? 118
ugen (Slashdot reader #93,902) writes: Something I discovered today, while trying to change a MAC address on a new MacBook Air (as I did for years on other MacBooks): ifconfig en0 ether "new mac" no longer works. It appears that this is a change made sometime last year, applicable to all Apple newer MacBooks.
Implications of permanently fixed MAC addresses on privacy and security are hard to underestimate. Given that Windows now supports complete Wifi MAC address randomization — I am sad to admit that Microsoft looks like a champion of privacy here. What are your thoughts? Solutions anyone knows of (I'll take a reasonable technical hack).
Here are a few mentions of this elsewhere:
Mac Rumors forums
The GitHub repo for SpoofMAC
A discussion on Stack Overflow
I've seen other theories about what's going on, though the bigger question is still what's the solution? Leave your own thoughts and suggestions in the comments.
And did MacOS stop allowing changes to wifi MAC addresses?
Implications of permanently fixed MAC addresses on privacy and security are hard to underestimate. Given that Windows now supports complete Wifi MAC address randomization — I am sad to admit that Microsoft looks like a champion of privacy here. What are your thoughts? Solutions anyone knows of (I'll take a reasonable technical hack).
Here are a few mentions of this elsewhere:
Mac Rumors forums
The GitHub repo for SpoofMAC
A discussion on Stack Overflow
I've seen other theories about what's going on, though the bigger question is still what's the solution? Leave your own thoughts and suggestions in the comments.
And did MacOS stop allowing changes to wifi MAC addresses?
Probably have to turn SIP off (Score:4, Funny)
but then chrome will eat your computer, lol.
USB wifi (Score:2, Funny)
Oops you said it was a Mac.
Re: (Score:2, Insightful)
Go back to 1995 when people gave a fuck about platform wars.
Re: (Score:1)
Are you implying that platform wars don't exist today? Normally I ask what rock you've been living under, but actually I have a more relevant question: How did you get internet access under that rock under which you so clearly still live!
Re: (Score:2)
Not much of a war when you only have two ports and you need to use one of them for charging.
Hm (Score:4, Informative)
Good change (Score:5, Insightful)
Re:Good change (Score:4, Interesting)
This.
MAC addresses are supposed to be hard-coded : first 3 octets are manufacturer ID, last 3 octets are device ID. Programmable MAC addresses have always been a hack - mostly useful to spoof another machine and bypass MAC-based security or get a fixed IP from a DHCP server that's meant to be doled out to another machine.
Impossible-to-modify MAC addresse are the norm, not the other way round.
Re: (Score:3)
That's the theory, but I seem to remember there used to be mac conflicts back in the day with some card manufacturers. If you were in this situation with two cards with the same address, and couldn't change them, what would you do?
Re: (Score:2)
Address collisions are a reality, because the address space is just too small in today's world (kind of like people thought the IPv4 address space was inexhaustible back in the good ole days).
But the reality is, they're very rare, even in large networks: the likelihood of one switch seeing two identical network interfaces with the same MAC is vanishingly small.
Re:Good change (Score:5, Informative)
IPv4 was limited to 4 bytes because (1) RAM was insanely expensive back then (graphics cards couldn't even display a monochrome bitmap graphic at full screen resolution because that would exceed the amount of RAM in the system - they used font bitmaps pre-stored in ROM to display text), (2), that was the length of a long integer back in the day (32 bits) and (3) "the Internet" was supposed to be a DoD network meant to survive a nuclear first strike. It wasn't meant to be inexhaustible, it was considered overkill for its intended purpose - it was highly unlikely the DoD and its contractors were ever going to exceed 4 billion computers. They never expected it to become The global standard for networking. And when they realized it was going to become that, they made IPv6, except nobody adopted it.
Re: (Score:2)
Every port on a modern switch can potentially need one or multiple MAC address. There's a load of virtual machines and virtual networking going on.
Choosing a MAC address that will never collide with something else is near impossible.
Re: (Score:2)
RAM was insanely expensive back then (graphics cards couldn't even display a monochrome bitmap graphic at full screen resolution because that would exceed the amount of RAM in the system - they used font bitmaps pre-stored in ROM to display text),
Perhaps it's time to replace that old VIC-20 with a shiny new VAX-11/780!
Re: Good change (Score:1)
Re: (Score:2)
Until we start making nanomachines with WiFi, there is no reason for a MAC address collision.
Incompetence. Accident. Miscommunication with contractors. There are probably loads more reasons why you could have a MAC collision. Are any of them good reasons? You could argue about that all day and it would still be irrelevant. The fact is that MAC collisions have occurred in the real world with zero MAC changes.
It's also a fact that MACs are used for tracking, so this whole MAC collision argument is a red herring. That alone is a good reason to be able to change them.
There were always means of changing
Re: (Score:2)
I believe this was usually due to counterfeit cards or dodgy manufacturers using other another company's MAC address range.
Re: (Score:2)
Re: (Score:2)
I'm not a networking guy, I only know enough to get myself into trouble, but I have some cheap Chinese IP cameras and one day a few of them just disappeared from the network, whilst another was responding to the wrong IP address. This was because a bug in the firmware caused them to revert to the same MAC address as each other and now an ARP who-has was giving multiple responses and the DHCP server was issuing the IPs it had in its database. These are linux machines and a real ISC DHCP server, no cheap knoc
Re: (Score:2)
It's absolutely NOT fine. If you change the MAC address on your device to match another device, your device will receive traffic destined for the other device. This isn't quite a Man-In-The-Middle attack, but I could see it being part of a progression to perform a MITM or to redirect people to a malicious web site.
Re: (Score:1)
"The problem you call "mac conflict" does not exist. It is perfectly fine that 2 machines share the same mac address on the same network."
On the same SUBNET? No. It does not work. Different Subnets on the same network? Yes, it does work.
Re:Good change (Score:5, Informative)
Fully half of the MAC address space is reserved for "locally administered addresses". Meaning non-hard-coded addresses set by local administrators.
It has always been that way, at least from day one of IEEE 802, and I think in the original Xerox Ethernet as well.
Now get off my lawn.
Re:Good change (Score:5, Informative)
Well, *technicall* 25% of the macs, not half.
To be concrete about things, the second to last bit of the first byte singifies whether the mac should be vendor based or local.
Additionally, the last bit of the first byte of zero means unicast, and 1 means it is a multicast mac. So macs with first byte ending in 0b10 would be legitimate locally managed mac addresses to put on nics, but 0b11, 0b01, and 0b00 would not.
Re: (Score:3)
Re: (Score:2)
This.
MAC addresses are supposed to be hard-coded : first 3 octets are manufacturer ID, last 3 octets are device ID. Programmable MAC addresses have always been a hack - mostly useful to spoof another machine and bypass MAC-based security or get a fixed IP from a DHCP server that's meant to be doled out to another machine.
Impossible-to-modify MAC addresse are the norm, not the other way round.
You probably never had to use DECnet,
Re: Good change (Score:1)
Re: (Score:1)
The DECNETprotocol used to run over Ethernet. And they did it by setting the MAC address to match your machine's MAC address. I'd forgotten about that.
You sound really silly lecturing people who actually used the stuff, you know.
Re: Good change (Score:2)
Re: (Score:2)
If you want to get in a pissing contest over it, I debugged implementations of that protocol. Among half a dozen other protocols.
I never said it only ran over Ethernet. Regardless of what it ran over, it also ran over Ethernet. In fact, about 99.95 percent of the DECNET nodes that ever existed were attached over Ethernet, or over some other link layer that used essentially the same MAC format. It used the essentially identical MAC hack on all the other media you actually mention, which share the same MAC ad
Re: (Score:1)
Now lets look at how we can easily tell that you had no idea about any o
Re: (Score:2)
Re: (Score:2)
Now lets look at how we can easily tell that you had no idea about any of what you just wrote prior to your current research. DEC systems didn't have a MAC address, NICs do. It makes absolutely no sense to claim that one sets a NIC address to the "machines MAC address" and such a statement represents an admission that you have no idea what a MAC Address [wikipedia.org] even is.
This is being pedantic - it's obvious what the parent poster intended when he made his statement, and I have no doubt he knows what
Re: (Score:2)
Ah, good morning. Yes, I guess I could be totally ignorant, or there's the more obvious possibility that I could have accidentally typed "setting the MAC address to match your machine's MAC address" when I meant "setting the MAC address to match your machine's DECNET address". That could have happened too. I mean, if you saw a sentence that was nonsensical on its face, you could have quoted it and said something about it.
They changed the MAC address to match the assigned network layer address because there
Re: (Score:1)
Consider it done,as I just did exactly that. You wrote an extremely short post consisting of a ridiculous statement followed by a suggestion I was the one that looked silly. Now to be fair, I could have said "The proprietary CDMA based protocol that DECnet used and also called Ethernet predates what we currently refer to when we say Ethernet, and tells us nothing of value about how Ethernet
Re: (Score:2)
I thought I had admitted that I said something nonsensical. I don't know about "ridiculous"; I don't think it made enough sense to be ridiculous. "Set the MAC address to the MAC address"?
As for the rest, I don't know what you mean by "addressing scheme". The address format is 48 bits, first bit being unicast/multicast, second bit being local/global, and in the case of global addresses, the next 22 bits being the OID and the remaining 24 being the device ID. Do you think it's a coincidence that 802.11, 802.3
Re: (Score:2)
... I imagine DECNET probably had some way to run over serial, with HDLC or something like that; I never got involved in that and don't recall. Such serial protocols may have, and indeed probably did, predate Ethernet...
DECnet used the DDCMP protocol, not HDLC, to run over serial links. It was developed in the mid-1970s and needed to work using existing serial interfaces, hence could not use the bit-stuffing of IBM's DLC. I was the junior member of the committee--my job was to take the current draft protocol, implement it, and bring the results back to the next meeting. It was becuse of my work that we added a checksum after the header of the data message. If a transmission error changed a high-order bit of the count f
Re: (Score:1)
The DECNet protocol on my old AS/400-powered network system ran over fucking Ethernet and TwinAX.
You must have been a poorly-trained manager (as most managers tend to be, they're usually only in management so they don't fuck things up. As the saying goes, promote the incompetent to management, keep the competent people on the actual floor doing real work.)
Re: (Score:1)
The systems I managed also ran over something called Ethernet that was actually a proprietary DEC protocol and was not, nor could it be, the Ethernet (802.3) about what we were discussing. Of course we were talking about DEC and you just pulled an IBM system out of your ass. ROTFLMAO.
Re: (Score:2)
As obvious I used to wrangle DECnet setups and unfortunately miss those good old days when you need a drill to tap a new terminal or a DECnet bridge to Ethernet cable. I personally do not like MAC a
Re: (Score:2, Insightful)
Oh, and by the way "MAC based security" is a hack mostly used by incompetent morons, because it is not and can never be reliable. The rest of the world isn't obligated to support your halfassed kludgery.
Re:Good change (Score:4, Insightful)
Oh, and by the way "MAC based security" is a hack mostly used by incompetent morons, because it is not and can never be reliable. The rest of the world isn't obligated to support your halfassed kludgery.
Its one tool in the toolbox and hence useful. Many useful things are not 100% reliable, DNS for instance, it can be hijacked. Its only a problem when a person thinks its a complete security solution rather than one piece of a larger solution.
Re: (Score:2)
Its one tool in the toolbox and hence useful.
No, it isn't. It's worse than worthless because it gives you a false sense of security.
DNS for instance, it can be hijacked.
And therefore it is untrustworthy, and that's why DNS-over-HTTPS is now a thing. (And DNSSEC, and dnscrypt...) Nobody should be using ordinary DNS for anything any more.
Re: (Score:2)
Its one tool in the toolbox and hence useful.
No, it isn't. It's worse than worthless because it gives you a false sense of security.
And yet quite pickable locks keep a whole lot of unwanted people out every damn day.
Re: (Score:2)
And yet quite pickable locks keep a whole lot of unwanted people out every damn day.
This isn't a lock. And a lock doesn't keep anyone out by itself. Defense in depth does that. The lock is just there to slow people down, or to make them make noise getting in, to aid in detection. It was never intended to keep people out. A good lock plus bars and the like can keep people out, but MAC filtering never will.
Re: (Score:2)
And yet quite pickable locks keep a whole lot of unwanted people out every damn day.
This isn't a lock. And a lock doesn't keep anyone out by itself. Defense in depth does that. The lock is just there to slow people down, or to make them make noise getting in, to aid in detection. It was never intended to keep people out. A good lock plus bars and the like can keep people out, but MAC filtering never will.
MAC filtering keeps the low skilled out.
Regarding defense in depth, I wrote above that MAC filtering is just one tool in the toolbox, one piece of a larger solution. As a simple lock is one piece of a larger solution.
Re: (Score:2)
Mostly by convention, and because these people would most likely also not enter your home if you didn't lock the door at all.
Re: (Score:2)
Mostly by convention, and because these people would most likely also not enter your home if you didn't lock the door at all.
Untrue. Unlocked doors, open windows, etc, increase the problem. In particular for cars which have even easier to defeat locks than homes.
Re:Good change (Score:5, Insightful)
The only hack here is you.
Devil's Advocate (Score:2)
It's like you forgot the purpose of the OS is to abstract the consumer's money from their wallet. There is nothing wrong with ordering the OS to display a different MAC address if the customer submits a valid micropayment. The PEBKAC layer may be hardcoded, but the OS doesn't have to respect it, and can output any number we choose. It's not your place to judge or moralize how we command our OS to abstract your money.
Re: (Score:3)
They are a _useful_ hack, one that is available to most other operating systems. That "bypassing DHCP reservation based MAC security" has been useful for a host to resume the identity of the host it replaces. Disabling it without notification is disturbing.
Re: (Score:1)
MAC addresses are supposed to be hard-coded : first 3 octets are manufacturer ID, last 3 octets are device ID. Programmable MAC addresses have always been a hack - mostly useful to spoof another machine and bypass MAC-based security or get a fixed IP from a DHCP server that's meant to be doled out to another machine.
The problem with that theory is there is such a thing as a locally administered MAC address akin to rfc1918 but for MAC addresses and is a perfectly legitimate use case for alterable MAC addresses.
Re: (Score:2)
Re: (Score:2)
because it's a unique value only connected to the physical network device.
Who are you to say really? Sometimes the network admin may decide to assign their own MAC addresses -- for example, make the MAC follow the user particularly for highly secure environments.
The standard even provides a mechanism for this. its called the Locally Administered MAC Address bit [noah.org] -- The second bit of the first byte of a MAC address determines the type of OUI. If the bit is 0 then it is an OUI globally assigned by the IE
Re: (Score:2)
DECnet [wikipedia.org] used to use programmable MAC addresses to avoid the need for an address resolution protocol when using Ethernet as the physical layer.
Re: (Score:1)
The MAC address 1.) should have never been editable to begin with because it's a unique value only connected to the physical network device. 2.) Allowing the OS to change this value is a mistake and it should have been fixed decades ago.
Reasons?
Re:Good change (Score:5, Insightful)
Reasons?
a) If you are the Chinese government then it's important to know which citizens had which IP address since otherwise they could spread unseemly propaganda like claiming that there was a "massacre" in some Tienanmen Square when everybody knows that it was just some silly students committing suicide by jumping under tanks. Instead of allowing that you can help these misguided people by sending them to a nice friendly "reeducation" camp where they can enjoy watersports and new techology. Luckily with fixed MAC addresses and access to the logs of WiFi routers this success is guaranteed.
b) If you are an data broker helping advertisers spy on people then you can use contracts with WiFi providers to match MAC addresses to IP addresses. This can be even more useful if you can then match them with people using specific VPNs and do traffic analysis on them. Specifically, some people clear their cookies and stuff from time to time to achieve privacy. If you know their cookie and MAC address before a clearing and their cookie and MAC address after a clearing then you can see that the MAC address is the same and use it to know that the cookie belongs to the same person. This is especially valuable because they are clearly a person who doesn't want to be monitored, so its likely other data brokers won't be able to match them as one person so advertising agencies will pay you extra.
c) if you are a dead person who set up a router with MAC address filtering then it might happen that someone wants to update their hardware and use a new MacBook to replace their old broken one. However, when you set up the MAC address filtering that laptop didn't exist so it's hardly fair if they allow it to access the network now. If people could change their MAC address they would just do it and forget about the issue as they happily use the network you set up. If
d) if you are an advertiser and you can check that their connections come from a unique MAC address then you can be sure that it's a real person with a real computer and target them with malware and other standard advertising things without losing money on fakers who pretend to be
As you can see, there are lots of valuable reasons to stop people from changing their MAC addresses.
Re: (Score:2)
Re:Good change (Score:4)
e) If you are an eveildoer and can read the unchangeable MAC address and match it against a list of manufacturers, you can select a script or attack specific to that hardware instead of trying hundreds or thousands and wasting time or even getting caught in the process.
Re: (Score:2)
Found the guy who apparently has never configured VMs or containers.
Suggestion: go read the data sheets for the Intel 82599 or Intel XL710 chips and then come back to us and pronounce what the OS should and shouldn't do.
Re: (Score:3)
Wrote a boot rom for a system with an 82593 based ethernet. The first thing you did was to tell the chip what its MAC address was.
Re: (Score:2)
The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device
It is unique until it is not. I have come across multiple network cards that had the same MAC address. Sure it is not *supposed* to happen, but manufacturing errors do occur. Note that a MAC address is 6 bytes of which the first three are the vendor identification. This leaves the last three bytes or only about 17 million unique addresses per vendor code. If a vendor builds more than 17 million cards (network interface chips), they can probably get another vendor id associated, but some may take a shortcut
Re: (Score:2)
It was particularly common with USB-Ethernet devices.
Re: (Score:2)
Not true. The ability to change a MAC address on a system is a very valuable feature, not a bug.
The MAC address should be editable: How else can you preserve your anonymity on a subnet? There are legitimate requirements to be able to put a system on a network without being tracked, or deploy honeypots in VMs without being easily identifiable to villains: It's needed for security researchers in the free world and for dissidents in the less free world.
Besides that, with software-defined networking how are you
Re: (Score:2)
With IPv6, the MAC address is part of the provisioned IPv6 address
There's already a protocol to use a random local part for an IPv6 address (RFC 4941?), and it's usually enabled by default. And it can even generate a new address every now and then.
I have a Uverse router which caches EVERY IPv6 address a computer has ever used, can report ALL of them for local DNS queries, and there is no apparent way to clear that cache. (this isn't the only quirk in its firmware) This can cause a computer to try (and fail) to connect to an expired IPv6 address, so I have to disable it o
Re: (Score:2)
Editable MAC addresses do have a use when you run high availability clusters though.
As for "privacy" it's only visible on the specific subnet, never over the full internet so it's only when at airports or other public places that the extremely paranoid need to mess with it.
Re: (Score:2)
But I think that what everybody here has missed is that it's a "MAC address". Probably some IP legal mind at Apple saw "MAC" and said "Hey - we own the trademark - let's put an end to this counterfeiting at once!" And some poor schlub of a programmer said "Yes, Boss".
Re: (Score:1)
Absolutely silly.
I guess we'll just ignore that every VM has virtual hardware, created by an OS? Or that a NIC doesn't even have to be a piece of hardware?
Allowing people to edit a MAC, is just allowing people to do what can already be done. And is done.
Re: (Score:2)
The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device.
Duplicate MAC addresses can be useful in active/standby, fault-tolerant, and/or high-availability configurations on individual (non-cluster) systems.
A while ago I was an administrator for a bunch of HP 9000 series systems (3 T-600, 1 K-460, 1 D-380, 3 A-Class, 3 L-Class, 3 N-Class) running HP-UX 11 and several had redundant NICs that could be configured with the same MAC for fail-over conditions. (Several also had redundant SCSI controllers attached to AutoRAID units and EMC-3500 or HP-XP256 storage uni
Re: (Score:2)
Duplicate MAC addresses can be useful in active/standby, fault-tolerant, and/or high-availability configurations on individual (non-cluster) systems.
This. If a device takes over the IP or VIP address of a cluster or failed peer but does not take over its MAC, it will take some time for other devices ARP tables to reflect that change which does not make for a very seamless failover.
You are much more likely to see duplicate MACs on a segment as a result of software or configuration errors than to ever see two real hardware MACs collide.
Re: (Score:2)
The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device
That's a good 1/3rd of an argument. Now you need to come up with why (other than to track users) having this unique value is necessary for a functioning network. When you answer consider the fact that switches and routers dynamically handle this whenever a device is plugged in and that everything else is under the control of administrators.
Re: (Score:1)
The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device.
HAHAHAHAHAHHAHAHAHAHAHAHAHA
MACs have never been unique. People have had MAC collisions in the real world. Comment invalidated due to spectacular ignorance.
Triggered, snowflake? (Score:2)
Facts don't change because you mod down the person who shares them with you. And the fact is that MACs are not and never have been unique, and anyone who thinks they are has no fucking clue what they are on about. They were supposed to be, more or less, but they are not.
Re: (Score:2)
And the fact is that MACs are not and never have been unique
The first one was. Dunno about the second.
Re: (Score:2)
A large chunk of the MAC address space is reserved for local administratively assigned values [wikipedia.org]. That suggests that MAC addresses were always meant to be changeable. If not, why was so much of the address space dedicated to that?
Re: (Score:1)
Re: (Score:2)
We made a lot of mistakes when it comes to protecting privacy, and fixed IDs is one of the biggest.
Re: (Score:2)
The MAC address should have never been editable to begin with because it's a unique value only connected to the physical network device. Allowing the OS to change this value is a mistake and it should have been fixed decades ago.
Android 10 uses random MAC addresses by default.
Works fine on my 2017 MB Air / 10.12 Sierra (Score:4, Interesting)
ether 14:c2:13:35:17:5e
Lappy:~ ch$ su bigboyadmin
Password:
bash-3.2$ sudo ifconfig en0 ether 14:c2:13:12:34:56
*toggled wifi off/on*
bash-3.2$ ifconfig en0 | grep ether
ether 14:c2:13:12:34:56
Re: (Score:3)
Bye Bye Bash (Score:1)
Re: (Score:2)
Re: (Score:2)
Effectively, No One Cares (Score:1)
For the 5% that need to do so, well, those people probably have dual-boot set up with an OS that lets them do what they will.
Re: (Score:2)
Oh boy! If I only had the guts to make that my signature :-)
MacOS allowing MAC adds changes? (Score:2)
And did MacOS stop allowing changes to wifi MAC addresses?
I can change it on my Mid-2014 MBPro, running Mojave 10.14.6. (Yes, I know the article is talking about newer MBPros.)
Can also change it on a Late 2012 Mac Mini, also running Mojave 10.14.6.
So it's clearly not a MacOS limitation.
Re: (Score:2)
Can also change it on a Late 2012 Mac Mini, also running Mojave 10.14.6.
So it's clearly not a MacOS limitation.
This is about a newer version of MacOS, so your anecdotes are inapplicable. Anyway, it looks like it was a real problem, but they fixed it in the very latest version.
Already Fixed (Score:5, Informative)
Re: (Score:1)
Yep, working here on Catalina GM1 (zsh shell)
Peters-MacBook-Pro:~ peterglock$ sudo ifconfig en0
Password:
en0: flags=8863 mtu 1500
options=400
ether f0:18:98:24:31:b2
inet 10.0.9.114 netmask 0xffffff00 broadcast 10.0.9.255
media: autoselect
status: active
Peters-MacBook-Pro:~ hack101$ sudo ifconfig en0 ether f0:18:98:24:31:b3
Peters-MacBook-Pro:~ hack101$ sudo ifconfig en0
e
Re: (Score:2)
It looks like the newest MacOS(Catalina) re-enables changing the MAC on the machines that it wasn’t working on. https://github.com/feross/Spoo... [github.com]
That's good, but Apple should add an option for automatic MAC address randomization. And probably turn it on by default.
It's to prevent spoofing (Score:3)
Re: (Score:1)
> Most WiFi chipset vendors (including Intel) prohibited changing the MAC address in software
Really? Can you name any such vendors? Because they sound like vendors to avoid.
Re: (Score:2)
Considering how crappy most APs are, from APs that make nonce renew trivial to those that "generate" their nonces by simply adding 1 to the previous one, connection riding is a reality with most PSK secured APs today, too.
If my neighbor had his AP turned on more reliably, I would have canceled my ISP contract by now.
Re: (Score:2)
I don't mean to be rude, but can you provide some sort of proof of your statement that "Most WiFi chipset vendors (including Intel) prohibited changing the MAC address in software nearly a decade ago"? This directly conflicts with my lived experience.
I mean, I routinely change the MAC addresses on my personal machines as part of initial setup. I've never once run into a system where this was not possible.
PS: Not inexperienced. I'm a working computer scientist today, and wrote my first code shortly before
MAC addresses have no value outside the LAN (Score:1)
MAC addreesses are unique IN A LOCAL AREA NETWORK (LAN). They are meaningless and of no value (worthless) outside that LAN. Security "researchers" who breathlessly decry sharing MAC addresses are clueless.
This is the real nothing-burger.
E
Been a long time since I cared about this, but ... (Score:3)
I do remember where with some cable modems, it used to be you had to spoof their MAC as the MAC of your router attached to it, if you wanted to successfully share multiple devices on the connection. Of course, that was back in the early days of broadband, where cable providers actually thought most home users would simply be attaching a single PC to the back of the modem to use it. "Advanced users" sharing a house full of devices though it were supposed to pay more for a "business class" combo cable modem and router that would allow it.
But I fail to see why this is a "big deal" if Apple stopped allowing modifying the wi-fi NIC's MAC in the OS? The only recent use-cases I've had for editing a MAC address were on Windows servers running expensive software that had licensing partially linked to the MAC address of the NIC card. When we virtualized those systems or moved them to new physical servers, it was easier to clone the MAC of the previous server than to go through all the hassles involved in requesting a new license key to re-activate the product.
Again, even in edge-cases like these, you're really not talking about the *wireless* adapter. You're dealing with the wired one.
If your concern for editing the wi-fi MAC address on your Mac is simply to get around MAC address filters? Well -- I'd say #1, that must mean you're doing things you're not supposed to be doing on that network, or else your MAC wouldn't be in their block list. But #2, if you do have an occasional to regular need to do such a thing? Sounds like it wouldn't be a terrible idea to just use something like an Apple Airport Express that you could attach via a wired Ethernet connection and let it establish the wi-fi connection for you?
"hard to underestimate" (Score:2)
Implications of permanently fixed MAC addresses on privacy and security are hard to underestimate.
This literally means the implications are so minor that you can hardly underestimate them. Like, so minor that we shouldn't even be discussing them.
Re: (Score:2)
Implications of permanently fixed MAC addresses on privacy and security are hard to underestimate.
This literally means the implications are so minor that you can hardly underestimate them. Like, so minor that we shouldn't even be discussing them.
Well count yourself lucky that I don't have mod points right now!
Re: (Score:2)
hard to underestimate? (Score:2)
Apple broke my nice network setup! Again! (Score:1)
you gotta love Apple users (Score:2)
"I am sad to admit that Microsoft looks like a champion of privacy here."
I am sad to know that you think only MS has an alternative here.
When thinking about privacy, I tend to think about certain OSS OS's.