Obviously, nobody is going to outright admit they put profits above security; indeed, they will often state the opposite. But their closely-held beliefs will shine through when it comes time to make decisions and the outcomes of those decisions are exposed to their customers and to the public.
Does Bill or Satya write code anymore? It could very well be that they consider security the top priority but it's a moot point because they're so removed from operations.
Although I would suspect that you're effectively right in that they either don't have it as a top priority or think they do but have a reveal preference of they don't. For example, an engineer that does rigorous security testing and finds nothing as well as launches one project gets promoted less often than an engineer that launches two projects and doesn't do rigorous security testing.
I'm sure there are some companies that realise security (or rather the critical lack of some important aspect of it) can impact profits, but that depends a lot on who their customers are too. Ultimately, if the customers who pay for a vendor's products and services don't value it, then the vendors won't value it either, short of any regulatory or legal requirements that might compel them otherwise. However, given that many large organizations (including governments) are Microsoft customers, it's strange to see in this case. Maybe there's a kind of "it can't happen to us" or "nobody will find out about it" arrogance going on, but they must now be seeing that the reputational damage is likely to have negative impacts, including hurting future profits, down the road.
It really would be nice for all ISPs to provide /56 (or shorter) prefixes by default instead of /64's so that we could properly subnet our internal LANs without having to resort to "solutions" like NAT (or just sticking with IPv4-only forever).
Most of the /64s being allocated are to mobile devices and almost all mobile deployments coming online are IPv6 only and support IPv4 only through something like 464XLAT. Even when they are dual stacked they're only through CGNAT. It's almost impossible to get a publicly routed IPv4 address on a mobile connection.
I couldn't find any such recommendation published by ARIN (the RIR for the US, Canada, and a few other countries nearby), though maybe I haven't searched hard enough yet. I have no experience with ISPs in other places around the world, but perhaps the lack of such a recommendation from ARIN contributes to why I've mostly seen only /64's here.
I'm a dude with an ASN under ARIN, they actually just link to the RIPE best current practices on the matter rather whenever it comes up as having an article just to put the ARIN name on something saying the same thing isn't worth it. E.g. they do it when talking about it here https://www.arin.net/vault/blog/2017/06/19/12-steps-enable-i.... When registering my first IPv6 block with ARIN they actually denied the request and said "Denied, but request again with a (16x in my case) larger block and it will be approved" to make sure I wasn't ever worried about being stingy on downstream allocations. At the my previous employer we got a /32 assignment from ARIN (enough for 4 billion /64s or 16 million /56s) without hassle and they weren't even an ISP. All that is to say, it's really more work to go out and not have enough space and not just use a standard DHCP-PD config than it is to get it right. Some ISPs still mess that up somehow... but they are thankfully a minority of those actually supporting (real, not tunneled) IPv6 in the first place.
It's important to note your router must explicitly ask for more than a /64. Just because the ISP will give you up to a /56 (or /60 sometimes) does not mean every router is just going to receive a flat /56 out of the box. If you don't send the hint then you don't get the delegations and it'll look like the ISP is only giving you one /64 because that's all you asked for.
I found this in a RIPE document on IPv6 best practices [0], and it's indeed worded quite strongly (emphasis theirs):
"Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc."
> "Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs. With a single /64, the end customer CPE will have just one possible network on the LAN side and it will not be possible to subnet, assign VLANs, alternative SSIDs, or have several chained routers in the same customer network, etc."
Am I the only one who thinks that IPv6’s design gets this wrong? Address bits are not free, and IPv6 added 96 bits of address for nowhere near a 2^96-fold expansion of usable space. Instead we end up with a bunch of /48 and /56 prefixes, which honestly seem a bit uncomfortably limiting. With 128-bit addresses, there ought to be an absurd amount of space to go around, and there sort of isn’t.
Beyond that, IPv4 does pretty well being minimally constrained in how networks are laid out. IPv6 makes everything awkward as soon as anyone goes off the beaten /64 path, and I’ve never seen any actual benefit derived from having supposedly stable interface IDs.
A /48 means every possible MAC address can be assigned to have its own block of 65,536 /64 subnets. We haven't come close to exhausting the MAC address space and if we did we could do so 65,000 times and still not have actually needed more than 1 client per subnet. A /32 means an IPv4 worth (4 billion) of ISPs can have an IPv4 worth (4 billion) subnets assigned to customers.
I've actually seen similar arguments that IPv6 addresses should actually have been made shorter based on how ridiculously scalable the number of subnets is. Personally I think it's the right pick - a 64 bit int covers the routed portion and a 2nd 64 bit int covers the subnet portion all with no "extra" bits to fiddle.
On the ISP side, you get a ton of space. As a consumer on residential broadband, you get a limited amount of space. I have a /40 and assign down to a /127 for Point to Point links in a datacenter. IPv6 is still an older standard and a lot of assumptions were built in about a /64 being the smallest subnet. Some routers didn't support a /127 for PtP until recently even though it was an RFC in 2010. I think even NAT66 was discouraged until everyone realized you cann't have a dual-wan setup with two different prefix delegations or everything breaks when one wan goes down and everyone has to get a new DHCP address.
Going smaller than /64 often has hardware consequences beyond just assumptions from old RFCs. E.g. in most all of Broadcom's line of ASICs you can do /127s but doing so requires initializing the ASIC on boot in a way that it has a decent chunk less table space because the IPv6 entries all have to be 128 bits now instead of just 64 bits. Many vendors expose this as a config item but default it to off kind of like the non-standard "allow routes more specific than a local subnet" option. On the software side of lower end gear it can depend on how exactly they implemented the dataplane.
NAT66 (or just NPTv6 in this scenario) is still discouraged today even though sometimes it's easier to just throw hands in the air for dual-wan setups like that. Some still have hopes of a rosy multipath client future but honestly if you know you aren't going to be able to use your own PA space or connecting your SD-WAN to a CDN/Cloud to do the same isn't viable for the use case then it's definitely an "eh, yeah not a great setup but not the end of the world" kind of solution just as bad as the remaining options at this point.
2^56 prefixes seems like plenty. Every person on earth could have millions of them! Also, only 2000::/3 is actually allocated to global unicast, not the entire IPv6 space. If what we're doing today is "wrong" we have several more chances to fix it.
Technically, it does. However, various other IPv6-related standards (like SLAAC, the stateless auto config protocol, often used on local networks instead of DHCP) will break with anything longer than a /64. If you are able to go with an all static configuration, you might be able to get away with longer prefixes.
There are some interesting plots (including future predictions) from the IERS Bulletin A data here showing the insertion of leap seconds over time to balance against changes in the Earth's length of day: https://datacenter.iers.org/singlePlot.php?plotname=Bulletin...
It isn't obvious yet to me that there will certainly be a negative leap second (or even a positive one, for that matter) needed in the upcoming years, but predictions farther into the future here are difficult. However, the changes in the length of day that have kept UT1-UTC so close to zero the past several years are very interesting, and as a result we haven't needed a leap second since the end of 2016!
And since the BIPM decided a few years ago to abandon leap seconds by 2035, if this somehow manages to hold for several more years, it's possible that we may not even see a leap second insertion (or deletion) again.
I wonder how many people would continue to so casually use these services if they understood that, for the most part, there is rarely proper end-to-end encryption of their data with these services. It is awfully disingenuous when these companies' marketing materials describe their services as "encrypted" when it usually just means there are two independent TLS pipes, which both terminate in their "cloud"; this surely gives a false sense of security to end-users who may not understand the implications of such a setup.
Too many. I've consulted with friends who installed "smart" security cameras and other IoT devices. I really spelled it out, saying that there's a very real possibility that one day they'll find out someone's been listening in on all of their private conversations (audio) or watching them through their own cameras.
Responses typically range from "I'm not that interesting" to "I really don't care". I think it's too abstract of a threat for most people to take seriously before it happens to them.
I totally agree with you, but then I put my phone on a qi charger on my nightstand and go to sleep. It's a device with both quality cameras and microphones, so I feel a little hypocritical given that there is a non-zero chance that someone could be listening or watching through my phone.
That's a possibility, but that would require an exploit and smartphones are far more secure and actively updated. I just keep on top of security patches and hope that's enough.
With IoT there often aren't any security patches and your audio & video are just being live streamed to the OEM's cloud waiting for someone to listen in, it doesn't even require a security exploit.
It's easily abused by employees, it even happened at Tesla where they watched their customers through the onboard cameras, taking screenshots of them walking around naked, and sharing them on company Slack channel for laughs.
That's why I find it so mind boggling, the company could incidentally hire a pervert and now you find yourself being watched in your own home by someone who knows your home address. I find this scary because it doesn't require a security exploit, just a deranged mind and those are dime a dozen.
So your issue is with the quality of the firmware on the devices and not the fact that it is a camera in a private place which is connected to the internet?
I agree with everything you're saying, but you may be overstating security patches. Until recently, most Android phones only had a few years of security updates.
I guess what I'm getting at is that if I truly believed in keeping Internet connected cameras outside of private areas I wouldn't have a smart phone at all.
The problem with Teslas wasn't the firmware on the cameras, but rather the infrastructure behind it. Ideally the data would be encrypted on servers and decrypted locally when needed. This doesn't pair nicely with services that perform analytics on video streams, of course, but it's a better option for privacy.
At the end of the day I share your concerns, and I want only devices which are controlled locally. I have been making efforts to make this a reality.
> So your issue is with the quality of the firmware on the devices and not the fact that it is a camera in a private place which is connected to the internet?
I'm just making a distinction between "connected to the internet" and "streaming private data to the cloud 24/7".
Most of us use a smartphone under the assumption that nobody else has access to it, and that it's not going to send all of our data to some cloud. If someone gains that kind of access to my device, I'll have bigger problems to worry about than someone listening to my conversations, like locking down bank accounts, investment accounts and changing dozens of passwords.
> Until recently, most Android phones only had a few years of security updates.
Tell me about it, I begrudgingly buy a new device when the old one runs out of security updates. I'm not a fan of Samsung or Pixel line (which now offer longer support) so I was planning to switch to an iPhone after my current Android device is made obsolete, but I changed my mind with Apple's latest EU meltdown.
I got it running as a VM guest on QEMU+KVM, exposing only a 486 CPU profile with 256 MB RAM, and it was still usable (with terminal, file manager, and some light web browsing). Looking at the system's memory usage though, it appears that going much lower than about 200 MB RAM would probably make it quite difficult to use (at least without relying on swap, which could make it even more miserable depending on the device being used there).
Yeah, that's a good point. As a further experiment, I tried with various "hardware" combinations (from 486's to Pentium II's) in 86Box, which actually performs such emulation, but unfortunately I haven't been able to get it to boot properly (kernel panics during initialization, if it gets that far at all).
This is a good point, and by your example it's obviously feasible to find enough of a "collision" on both ends of the digest to make it look like a match at a careless first glance.
In your particular example, I counted at least 96 bits that match on the ends (in total...from 48 bits on each end), and now I'm curious what kind of hardware you used and how long it took to find this match.
If you have the available RAM/SSD for a birthday attack, you only need 48 bits worth of complexity, which makes this a manageable problem. I suppose the ASICs for bitcoin mining don't have the needed bandwidth to storage devices which would put my guess onto GPUs. Assuming 32 bytes of storage per hash (probably more but you wouldn't store the full hash, instead a hash table with the prefix+postfix up to a certain amount, then of course some hash table management overhead), you'd have to write around 9 PB if you write once, 1 petabyte if you write 64 times, for the raw hashes only.
You don't need to store all the hashes, just the Distinguished Points[1]. It took me a couple of days on a single AMD RX6700XT desktop GPU, using some negligible amount of RAM (it was a few GB of main system memory iirc).
There's a good book, "The Right Stuff" [0] by Tom Wolfe, which goes into quite a bit of detail about the stories and some of the psychology around being a test pilot in those days, and in particular about the men chosen as the Mercury Seven astronauts, many of whom were also later involved in both the Gemini and Apollo programs.
