iPhones have terrible heat dispersion compared to even a fanless computer like a macbook air. You get a few minutes at full load before thermal throttling kicks in, so you could do the occasional build of your iPhone app on an iPhone but it'd be pretty terrible as a development platform.
At work we had some benchmarking suites that ran on physical devices and even with significant effort put into cooling them they spent more time sleeping waiting to cool off than actually running the benchmarks.
The thing named Rosetta (actually Rosetta 2) for the x86_64 -> ARM transition is technologically completely unrelated to the PPC -> x86 Rosetta, and has none of the problems you mention. There's no user-observable difference between a program using Rosetta and a native program in modern macOS, and porting programs which didn't have any assembly or other CPU-arch-specific code was generally just a matter of wrangling your build system.
This is a desired outcome. The WebPKI ecosystem would really like it if everyone stopped depending on them for internal things because it's actually a pretty different set of requirements. Long-lived certs with an internal CA makes a lot of sense and is often more secure than using a public CA.
Our internally provided certs of various CAs have a TTL of 72 hours and should be renewed every 48 hours.
It's been a huge pain as we have encountered a ton of bugs and missing features in libraries and applications to reload certs like this. And we have some really ugly workarounds in place, because some applications place a "reload a consul client" on the same level of "reload all config, including opening new sockets, adjusting socket parameters, doing TCP connection handover" - all to rebuild a stateless client throwing a few parameters at a standard http client. But oh well.
But I refuse to back down. Reload your certs and your secrets. If we encounter a situation in which we have to mass-revoke and mass-reissue internal certs, it'll be easy for those who do. I don't have time for everyone else.
As is already described by the comment thread we're replying in, "internal use" and "HTTPS" are very compatible. Corporations can run an internal CA, sign whatever internal certs they want, and trust that CA on their devices.
You use the term "internal use" and "corporations" like they're interchangable, but that's definitely not the case. Lots of small businesses, other organizations or even individuals want to have some internal services and having to "set up" a CA and add the certs to all client devices just to access some app on the local network is absurd!
I don't think it's absurd and personally it feels easier to setup an internal CA than some of the alternatives.
In the hackiest of setups, it's a few commands to generate a CA and issue a wildcard certificate for everything. Then a single line in the bootstrap script or documentation for new devices to trust the CA and you're done.
Going a few steps further, setting up something like Hashicorp Vault is not hard and regardless of org size; you need to do secret distribution somehow.
My dad still calls my terminals a "DOS window" and doesn't understand why I don't use GUIs like a normal person. He has his own business. He absolutely cannot just roll out a CA for secure comms with his local printer or whatever. He literally calls me to help with buying a PDF reader
Or ourselves, we're a small business and we're all as tech savvy as it gets. It took me several days to set it up on secure hardware (smartcard), making sure I understand what all the options do and that it's secure for years to come and whatnot, working out what the procedure for issuing should be, etc. Eventually got it done, handed it over to the higher-up who gets to issue certs, distribute the CA cert to everyone... it's never used. We have a wiki page with TLS and SSH fingerprints
We have this, it's not trivial for some small team, and you have to deal with stuff like conda env coming with it's own set of certs so you have to take care of that. It's better then the alternative of fighting with browsers but still it's not without extra complexity
Indeed they are compatible. However HTTPS is often unnecessary, particularly in a smaller organisation, but browsers mandate significant unnecessary complexity there. In that sense, brwosers are not suited to this use in those scenarios.
Cool. And when they invent it, it should have browser parity with respect to which API features and capabilities are available, so that we don't need to use HTTPS just so things like `getUserMedia` work.
A static page that hosts documentation on an internal network does not need encryption.
The added overhead of certificate maintenance (and investigating when it does and will break) is simply not worth the added cost.
Of course the workaround most shops do nowadays is just hide the HTTP servers behind a load balancer doing SSL termination with a wildcard cert. An added layer of complexity (and now single point of failure) just to appease the WebPKI crybabies.
Just about every web server these days supports ACME -- some natively, some via scripts, and you can set up your own internal CA using something like step-ca that speaks ACME if you don't want your certs going out to the transparency log.
The last few companies I've worked at had no http behind the scenes -- everything, including service-to-service communications was handled via https. It's a hard requirement for just about everything financial, healthcare, and sensitive these days.
[proceeds to describe a bunch of new infrastructure and automation you need to setup and monitor]
So when ACME breaks - which it will, because it's not foolproof - the server securely hosting the cafeteria menus is now inaccessible, instead of being susceptible to interception or modification in transit. Because the guy that has owned your core switches is most concerned that everyone will be eating taco salad every day.
Someone that has seized control of your core network such that they were capable of modifying traffic, is not going to waste precious time or access modifying the flags of ls on your man page server. They will focus on more valuable things.
Just because something is possible in theory doesn't make it likely or worth the time invested.
You can put 8 locks on the door to your house but most people suffice with just one.
Someone could remove a piece of mail from your unlocked rural mailbox, modify it and put it back. Do you trust the mail carrier as much as the security of your internal network?
But it's not really a concern worth investing resources into for most.
> Someone that has seized control of your core network such that they were capable of modifying traffic, is not going to waste precious time or access modifying the flags of ls on your man page server. They will focus on more valuable things.
Ah, the "both me and my attackers agree on what's important" fallacy.
What if they modify the man page response to include drive-by malware?
And it is even more trivial in a small organization to install a Trusted Root for internally signed certificates on their handful of machines. Laziness isn’t a browser issue.
I am not saying I‘d do this, but in theory you could deploy a single reverse proxy in front of your HTTP-only devices and restrict traffic accordingly.
Getting my parents to add a CA to their android, iphone, windows laptop and macbook just so they can use my self hosted nextcloud sounds like an absolute nightmare.
The nightmare only intensifies for small businesses that allow their users to bring their own devices (yes, yes, sacrilege but that is how small businesses operate).
Not everything is a massive enterprise with an army of IT support personnel.
Just buy a domain and use dns verification to get real certs for whatever internal addresses you want to serve? Caddy will trivially go get certs for you with one line of config
Do I add the root CA of my router manufacturer so I can visit its web interface on my internal network without having half the page functionality broken because of overbearing browser manufacturers who operate the "web PKI" as a cartel? This nowadays includes things such as basic file downloads.
What do you mean “WebPKI … would like”. The browser vendors want one thing (secure, ubiquitous, etc), the CAs want a very different thing (expensive, confusing, etc)…
The browser policies are set by the same entities doing the CAB voting, and basically every prior change around WebPKI has only been enforced by browsers for CAs in the browser root trust stores. Which is exactly what's defined in this CAB vote as well.
Why would browsers "most likely" enforce this change for internal CAs as well?
'Most likely' - with the exception of Apple enforcing 825-day maximum for private/internal CAs, this change isn't going to affect those internal certificates.
Yeah, my experience with making mistakes on my taxes was that they sent me a bill for the difference, I paid the bill, and that was it. There wasn't even a fine beyond that I had to pay interest on the money I owed.
Sometimes the IRS is wrong, too, and you just mail them proof. Like if you forget to report your cost basis for a stock sale, they'll send you a letter and say "We're assuming the cost basis is zero, so here's what you owe!" and you just respond back with a letter that says "This is the cost basis, and here's a copy of my brokerage statement." and that's that. I've found dealing with the IRS actually quite straightforward and non-scary. As long as you have your paperwork in order. If you're careless about your records, then you're going to have a bad time.
Exactly this. Is what I meant by them working with you. They aren't playing some devilish game of trying to trick you into paying more. They tell you why they say you owe something and what it would take to get them to change that. And are fine if you need time to find it.
If you are actively trying to avoid the calls, I'm sure that is probably not a good idea. But, that is basically in the "actively trying to commit fraud" territory, at that point. No?
? Not really. You can reword it and say that just because google can build it means you shouldn’t try to sell it to them. And google can build pretty much anything at this point if they wanted to.
Google’s budget for software and services I’m sure is in the hundreds of millions if not billions of dollars. So again, obviously false.
It would be a lot less money, but issuers would make money off of credit cards even if every single person in the world paid their bill in full every month. They would distinctly not be bankrupt.
They could probably adapt, but they'd have to really streamline their operations. I doubt there would be as many paper ads in the mail, airport lounges, bonus cashback categories etc.
This isn't a "Don't buy from Amazon" article and the conclusion of the article is that while there's a difference it's quite plausible that they aren't fake.
Yes, I am very surprised to hear that you've had such success with reporting bugs to Apple. That is very unlike my experience. I've had exactly one macOS bug that I reported fixed, and that required going to a WWDC lab, talking to a person on the relevant team in person, and having them dig the bug report out of the backlog for a completely unrelated team that it was incorrectly assigned to.
At work we had some benchmarking suites that ran on physical devices and even with significant effort put into cooling them they spent more time sleeping waiting to cool off than actually running the benchmarks.
reply