Yeah but maybe it would be nice for users to keep that extra time in order to maximize the probability that they have actually updated software at disclosure time.
Disclosing in advance is a bad policy, it will just incentive good behaving vendors that update fast to delay full description of their changelog for security reasons because you put their users at unnecessary risks.
Security researchers have to assume that if they've found a vulnerability, it's only a matter of time before the evil people will find it as well - that is if they haven't found it already.
That's why all disclosures come with window - if they don't, the companies aren't under any pressure to update their systems, the exploit start being used in the wild, etc. The window is not ideal, but it is better than no window.
And there isn't much point arguing over 30 vs 90 vs 120 vs 365 days. 90 is reasonable, enough for even the largest mainstream software companies to issue a patch release.
Still make no sense, I agree the window is a good policy to force lazy vendors to act as they should.
But what’s the point of reducing the window for nice vendors who quickly delivered a patch?
This is totally counter productive. In order to incentivize vendors to deliver patches more and more quickly, good actors should profits from that extra time to secure their user base. In a ideal world that might even permit to reduce the windows in the futur when everyone behave well.
This is just jerking around and sending bad signal unless of course that anticipated disclosure date was decided together with the vendor.
I think patching is firmly in your hands now, and this data may help you choose to upgrade if you were holding off for some reason. Imagine your favorite iOS game was broken by the release that fixes this, so you've been ignoring the update. Now that you know your phone can be bricked by a malicious text message, you may decide "I guess I won't be playing that game for a while" and upgrade. The point is, pretty much everyone that applies every update (which is automatic) has the update now. The last few stragglers are probably waiting for information exactly like this. Now they have it.
The patch itself reveals the vulnerability. Attackers analyze these things to see what they’ve fixed. If you release a patch but don’t announce the vulnerability that was patched, then you’re just hiding it from good guys who don’t have time to dig through the patch.
I wouldn't be terribly surprised if the vendor asked for it to be disclosed late in the afternoon before a long holiday weekend (in the US) with the hope that mainstream press outlets would not notice.
Your incentive line in no way matches reality. In the past every vendor that is given an unlimited open timeline on patching has not. This includes Microsoft, Apple, Oracle and most of the other large vendors. Most of them are better at patching, but this is mostly because of the risk at of someone zero daying the patch and destroying the userbase.
Security is not an ideal world, in fact I would say it is the opposite.
Microsoft (employees) has repeatedly argued that 90d can be unreasonable for Windows due to the development and testing cycle, which also has to align with “patch Tuesday”. I haven’t heard the complaints recently so maybe they’ve streamlined part of the process.
Windows 10 might be the largest enterprise codebase at over 50 million lines of code. It probably takes 30 days alone just to browse to the file that has the bug
The other side is that the moment a patch is released, people will diff it to the previous version making it much more likely this issue is found by a lot of independent people who might seek to exploit it.
That sounds like a logic flaw because iPhones and most other devices like it will normally auto update after a short while. I think more people will rely on that feature than browse, uh, bugs.chromium.org...
This view of it will assist hackers in getting a head start before the auto update cycle gets to your device and you're notified. And if you're hit but something like this before that, your iPhone will no longer be able to update and apply the fix.
Of course, there's no way to find an objectively "correct" time frame since update cycles vary, but a month or two ought to give plenty of time for the updates to roll out and users to be made aware.
Sounds good in theory. In reality, the vast majority of iPhone users are not aware that this bug exists and never will be. The best action for user safety is to wait until the period has elapsed or the exploit has been seen in the wild already.
Alternatively, they could publish the gist of the exploit without providing enough detail to actually perform the exploit.
Publishing it like this will make them more likely to be aware of it. They may not read Hacker News but it spreads to Facebook user groups etc.
The bad guys (many enough of them) will anyway figure it out right away after the patches have been published, because with every patch, people will (and should) ask "why".
Reading (dis)assembly is a skill many in our profession are required to learn. It’s common in OS & security fields. Heck, when developing Windows on ARM we were told Friday that we’d come to work Monday with a mandatory “no source” debugging session where we had up to an hour to describe a hanged program’s intended behavior and why it was hanged. One of my colleagues also refused my symbols when I asked for help debugging a program. He was more comfortable in ASM than the latest C++
http://gs.statcounter.com/ios-version-market-share/mobile-ta... shows 12.3 at around 50%, so the question for me would be what percentage of that long tail would upgrade within any reasonable extension period. Public news might actually accelerate that since it gives people a reason not to procrastinate hitting that button.
I’m not sure of the stats honestly but there’s still going to be a huge long tail of people on earlier versions for months afterwards. I was surprised that I was still on iOS 12.2.
Disclosing in advance is a bad policy, it will just incentive good behaving vendors that update fast to delay full description of their changelog for security reasons because you put their users at unnecessary risks.