331–340 of 464 posts
Earlier quoted context omitted.
Just curious, what kind of compilation error are you getting?
'init(machServiceName:options:)' is unavailable in iOS
Earlier quoted context omitted.
it depends on your free storage. if it is less than X % they will try to download it one go. the resumable download will download all in chunks and than concat them.
Just tried it again. I have 70GB available. Got on the hotspot, started the download, unplugged the laptop, waited for it to go to sleep, woke it up - same result. I had to accept the EULAs again and it started to download from about 50mb. Having attempted (unsuccessfully) to write a resumable HTTP/HTTPS downloader, which is what I suspect nsurlsessiond is using behind the scenes - it's really hard to get it right. M…
https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requ...
And if they need to get more clever than that, why not have a BitTorrent-like map of chunk hashes. So you download the update, check the hash of the whole thing and if it fails the hash check, download the chunk hashes which will be say a 256 bit hash for every individual 32 MB chunk of the file. And for any chunk that fails the hash check, use a HTTP range request to download it again.
Earlier quoted context omitted.
It's hardly 'perfect historical proof', not to diminish the seriousness of the vulnerability. But more importantly, the mechanism matters a great deal. This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation. This leaves a trace and exposes the attacker to consequences. No (statistically speaking) app producer with any interest in continuing to use the p…
> No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it. Except Facebook. Or another behemoth that felt they could weather Apple's wrath if it ever came to it. Or a company that Apple had granted special permission to do this, like they did with Uber.
The point isn't that this isn't a serious vulnerability or is somehow unexploitable. It's just that there's a great deal of friction in exploiting it for relatively paltry returns. Nobody is going to get into a spat with Apple and invite regulatory and law enforcement attention to traceably and with undeniable intent steal your contact list. Nobody is going to (like another commented hypothesized) launch a supply chain attack to steal your contact list with this vuln. At that point you'd find a better vuln. This one isn't all that much better than just misleading people into giving you contact list permission.
The OP is saying it's somehow worse than drive-by or low-interaction vulns that own up entire devices and have been repeatedly found in the wild. I don't think that holds up.
Earlier quoted context omitted.
> the zero click iMessages one floored me. In case there is any confusion, there has been at least one of those a year for the past 3 years.
What is dumb about it to me is that the solution in my mind is simple: don’t give Messages.app private API access. They get access other messaging apps from the App Store can’t have and that’s what’s causing these vulnerabilities, but all they need is APNS and access to the SMS service (which is private but shouldn’t be dangerous… right?).
It’s extremely common for an attacker to find a way to exploit a maliciously crafted image. Take a look at libpng, https://www.cvedetails.com/vulnerability-list/vendor_id-7294...
If your annual revenue is above $100M, you should be held accountable to a strict version of GPDR enforced by an ombudsman, that requires you to patch all data leaking vulnerabilities within 90 days, or pay out everyone who bought your product. I just updated to iOS 15 and it now tells you which sites you have been compromised on, or had your passwords/info compromised on. To be clear, I use a password manager with a…
God, I would HATE if the US follows the EU with this craziness. I'm already sick of the cookie popups, now layer on the GDPR insanity and we will definitely lose the privacy fight to users who will be sick of this nonsense as well. I've seen studies that show crap like GDPR (which makes basically all normal interaction cumbersome) has like 10% of folks clicking around to "opt-out" while 90% can't be bothered. And of…
GDPR restricts companies from using data however they want, makes you able to obtain a copy, and makes you able to require it deleted. It also required the company to document, provide a person responsible to contact, etc.
It only benefits you as a consumer, and the downside in proper uses is that the webpage/app might have a page somewhere with data processing information should you be curious. Nothing major.
Any nuisance are poor implementations or because companies can no longer do terrible unexpected things, like selling your data to hundreds of companies just by accessing a page, without permission, because it is nonsense no one would expect or want.
And with everyone clicking "no" (which must be at least as easy as clicking "yes" as determined in court), the practice would die eventually.
Earlier quoted context omitted.
> crap like GDPR (which makes basically all normal interaction cumbersome) Only if you count "tracking users on first visit before they do anything else" as normal. Otherwise, there isn't a banner needed; sites could simply have a link to opt-in to tracking in the header or footer, and not track unless the user opts in. This is like passing a law making it illegal to just hit people in the street, requiring you have…
What’s the incentive for a user to opt-in to tracking?
I've never met anyone in real life who wasn't creeped out by a targeted ad. Everyone nowadays has a story about how they were having a conversation with someone about something, and then one of their devices served them an advertisement for the thing they were talking about.
Everyone finds that creepy as hell, but it's hard to attribute it to any particular device/company, and even if you find out that it's your Alexa that's spying on you, it's hard to throw it out. Not only is it a waste of money, it's a loss of a convenience, and there's some social pressure involved. Like do you really want to be seen as that one paranoid weirdo who doesn't trust technology that everyone else is using?
Earlier quoted context omitted.
This is a part of our industry I do not follow beyond headlines. A lot of those headlines are about hackers trying to be responsible getting screwed out of supposed bounties that to my mind already appear quite small. Also responsible companies doing very little to quickly close them. Does anyone have any insight into how the market for vulnerabilities operates? Is there is a significant disparity in price between of…
So most public companies don't even run bug bounties. The ones that do may or may not acknowledge your disclosure, and they decide what your vulnerabilities are worth regardless of any scales they might post on a blog. So in a best case scenario, you get maybe 10-100k for a world ending RCE + escalation but most of the time you get no response or <1k. On the gray market, though, something like that will easily sell f…
With these Apple-related vulnerability annoucements on HN, usually we see response from a satisified Apple owner along the lines of "This is fixed in [some new version number]". The thing is, the problem isnt whether something is fixed, its that it was broken to begin with. It passed "QA" at a trillion dollar company and its a pre-installed fixture^1 on some relatively expensive hardware item. If there is such an "it…
No, the issue is despite disclosure two of them still aren't fixed.
Earlier quoted context omitted.
Don’t update your apps till after Apple releases a patch. The first two are API calls that apps can make. An exploit wishing to exploit these vulnerabilities has to be coded to make these calls. Most apps don’t dynamically construct arbitrary API calls. In fact, you can’t do that in Swift AFAIK. You have to drop to Objective-C or C to do that. So most apps need to be updated to exploit the vulnerability. The only exc…
The whole point of Swift is to be next generation Objective-C and C on Apple platforms, no need to drop down to other languages. In fact, the prof of concepts shown in the article are all written in Swift.
Earlier quoted context omitted.
Do you have any evidence that Apple has been checking for these vulnerabilities in apps? I mean, if you tried now, sure, I'm guessing you'd get caught (or will be soon). But these have been around a long time.
No, I mean if you try it now.