For those not reproducing: your device may have to reside CONUS for some of "tar"(-get), "bes"(-tbuy), "wal"(-mart), "wel"(-ls fargo), "old"(-navy?), "sta"(-rbucks), "pla"(-net fitness?) to work. Try local brands, e.g., "Harrods", "Tesco", "Picard", etc. For my country "Gusto", a casual dining franchise, reproduces the issue. List is from [1].
Edit: stopped reproducing here as of 19:11 UTC.
Edit: some people digged into it[2][3], [2] includes partial endpoint URLs. Apparently this was happening for 7+^H^H 10+ hour.
I literally just had a PM tell me "we will talk about that 'tom'". It left me confused for a few seconds. Is it really that hard to use a couple more syllables?
people forget that many acronyms are context sensitive and/or audience sensitive. they just assume everyone across the world has the same shared life experience that they do.
CONUS (can't help but giggle) supposedly stands for Continental United States, as I learnt from a sibling comment here. First time I'm hearing that acronym.
Target is a supermarket chain in USA. I assume Bestbuy is also something like that.
In my browser (Firefox on Android) if I type "tar" it auto-suggests completing the url to "target.com". Useless to me because I'm nowhere close to USA and there's no Target in my country.
Speaking of which, maybe they should have a separate list of autocompletable sites based on the user's location. However, I'm not sure of the privacy implications of that.
Does not crash for me. (US, using “old “.) Safari suggestions on. IOS 15.7 (19H12).
Installing 15.7.1 now to check that version (and because I might as well install it anyway...) Edit: doesn’t crash on 15.7.1 either (though my first test on 15.7.1 was at 17:28 UTC.)
Hm, I am on CONUS and I’ve visited bestbuy.com a lot recently. The bug is not happening to me. Probably because I’m on iOS 15.6 and the bug happens starting with iOS 15.7, according to your Macrumors reference.
Probably I should upgrade even more slowly in the future…
I use my phone as little as possible, I just realized the only 2 things I type into my mobile browser (currently safari) on a regular basis are new(s.ycombinator.com) and old(.reddit.com). Never put that together before, it's been like a decade.
Interesting, I had never heard of this tip before. How do you do this though? Do you just add it at the end like a flag? (e.g. "sparking water -best" ?) In general, I thought these kinds of search engine commands were being phased out, but it looks to me like it would filter out those garbage articles that would bring up results like "top/best 15 brands of sparkling water" etc.
That still works on Google. You can put it anywhere in the query. The "-" is a negation operator that tells the engine to exclude results containing the following word.
They've actually apparently introduced a few new operators since the old days, which I found surprising. For example, $ for prices, # for hashtags, and .. for ranges of numbers. https://support.google.com/websearch/answer/2466433?hl=en
I can only get to bes before it crashes, turning off safari suggestions fixed it. I think it’s maps/shopping related, old navy and Best Buy were the suggestions.
If you "hacked" a system, I would assume the first thing you'd do is patch any of your own known exploits, and others, so you don't lose ownership to some other hacker, right?
Wild! Mine crashed the first try, turned off Safari Suggestions, crash behavior gone.
Turned it back on... still no crash. Search engine makes no difference.
Wonder if it's a cache thing and disabling Suggestions cleared that, removing whatever bad data was hanging around, or if it was a purely server-side bug and they've already fixed it.
[EDIT] Some others saying it stopped happening, so may have been fixed.
I had a bunch of open tabs in Safari, and typing "old" (space) not only crashed Safari but got rid of almost all of the open tabs. It was all stuff I needed to refer back to, and yeah that's not a great way to manage stuff like that. Of course bookmarks would be the right way. But now it's gone.
That's actually an interesting datapoint, it means Safari is crashing so hard it flushes the tab storage; normally "killing" (especially a background kill) Safari won't do that.
how is it a "nightmare scenario"? it's not ideal, but it doesn't sound bad (there are other browsers, workarounds, etc. it's not like these sites are forever gone because of a ransomware or SSL key exploit, etc)
I can't imagine "Old Navy" customer support is going to have much success telling iOS customers to install another browser (I'm not even sure that solves it).
Is old.reddit.com very unstable for everyone else in safari or just me? On my past 3 iphones through multiple iOS versions I can't browse for more than 10 minutes without eventually hanging/crashing safari. It seems to happen most frequently after browsing posts with images
To the point where it feels like they have pretty obviously intentionally gimped the mobile website to drive you to the app - which just makes me way less likely to install it. Page loads take absolutely forever, videos almost never work first try, their image galleries are essentially unusable... None of these are issues on desktop web (on the same network).
New reddit is just harmful to your laptop battery. It fulls one cpu core all the time if you don't block the update websocket. Truly the worst written react app I ever saw.
Can someone contribute more than "lol, me too!" and figure out which API endpoint it's hitting, what it's returning and guess why it's crashing? I don't have an iOS device otherwise I'd do it...
It’s their own “Safari suggestions” service. I don’t know if that’s device local or some Apple API which changed but disabling it prevents the crashes.
I doubt that since it’s their own code but I’d easily believe that it hits an API endpoint which just started malfunctioning. The description is vague but it appears to retrieve a bunch of different kinds of information from some Apple service. Clearly a massive test coverage miss if my speculation is right.
It's partially a joke, but as anyone who has worked with a complex system, things like this can happen. A privacy control is changed somewhere, but not activated until later, and suddenly one day something stops working.
Firefox on iOS uses webview for page rendering, but the url suggestions (which seem to be the cause of the crash) are separate and are handled by firefox's code.
Concur, smells strongly of a server-side change, that it's hitting multiple versions all the sudden. Which might mean it's also relatively quick/easy fix?
Doesn't need to be. Some software nowadays can toggle feature flags clientside behind your back. I know Firefox does (or did?) this. Creepy as all fuck.
It's not universal, my iPhone 14 pro with 16.1 does not crash for any letters I can type, spaces or not. Suggestions work fine for me. Clearly there is another factor not obvious causing the crash. In any case Apple would see a whole influx of crash reports (assuming they are as anal about them as I used to be).
I wonder if a crash log gets generated - Settings -> Privacy -> Analytics & Improvements -> Analytics Data will have it if so. Unfortunately, I can't reproduce the issue on my phone (iOS 16.1, Canada)
Turning off Safari Suggestions is one of the first and most important privacy tweaks on a new iPhone. Otherwise every keystroke you type in the address bar gets sent to Apple in realtime.
“We do not provide any government agency with direct access to our servers, and any government agency requesting customer content must get a court order.”
Either Snowden is lying, or Apple is.
There are lots of potential explanations here. It’s possible and even likely that in an org as large as Apple, the people writing press copy simply are not exposed to all of the details of all of the moving parts that enable realtime surveillance of their userbase. They can also use a different definition of “direct access” (while providing realtime unsupervised access via API, but not via physical (“direct”) entry to a datacenter building).
Apple also claims (in HT202303) that iMessage is end to end encrypted, when for the vast majority of the userbase of iMessage, Apple
has copies (readable to Apple) of the endpoint private keys and can, if they wish, decrypt and read and store anyone’s iMessages in realtime as if they were not encrypted at all. It’s still “end to end encrypted” if there is a key escrow backdoor in the system that defeats the end to end encryption. It’s like putting a $5 gym lock on a cardboard box. It’s not lying to say that you locked it up.
You can make factually accurate statements about certain specific things that paint a picture or strongly imply a state of affairs that is diametrically opposed to the truth. Apple is, as far as I can tell, the best in the world at this type of misdirection. It even fools professional journalists.
For example: if they log the client IP of all requests to the API, the statement you quoted holds true - and yet it is still trivial to make a single query to a) relate all of your API requests together, and b) relate them to your identity via Apple’s many other APIs. The “rotating” implies that it is unlinked, but does not guarantee that it is unlinkable (eg from having client IP and timestamp columns in the data).
Apple is skilled at lying by saying only very specific, true things, as confusing as that may sound.
It is also a mistake to assume
there is no importance because there is no threat model. Even if the data is never linked to you, it is a privacy violation for the keystrokes to leave your device if you don’t want them to. For a contrived example, you don’t need a threat model or ID linkage to not want your neck-down nudes leaked. A non-identifiable privacy violation is still a privacy violation.
> "is associated with a 15-minute random, rotating device-generated identifier"
Can someone clarify why that's done or how it could even be useful? It just seems (to me, naïvely) like if you're going to rotate the identifier every fifteen minutes, why even bother?
“Fail gracefully” for malformed responses. If a JSON API all of a sudden starts returning a cloudflare html error response, you shouldn’t crash your iPhone app.
I try to avoid updating my iPhone for as long as humanly possible. I find updates generally bring bugs, features I don’t want, apps I don’t want, and sometimes taking away things I like.
I don't think 16.1.1 is unaffected. I'm on iOS 16.1.1 and can reproduce it. Blank address bar -> "old " -> crash. The second time I didn't need the space, as others have also reported.
For goodness sake Apple - this takes the cake for weirdest bug since the early Windows 10 Preview build which caused random letters to be missing from text...
It’s not enough to do that. There is something more specific required: a specific version of iOS, a specific language, a particular phone, some setting, something in the search/url history etc.
But it clearly doesn’t reproduce across all devices/versions/settings with iOS Safari. Better repro steps needed.
The repro steps are accurate and sufficient on their own -- following the described steps does crash Safari for the reporting user (and many of us). What is missing is the complete device configuration which is distinct from steps (and would probably be overwhelming, in any case).
Tbf the “steps” in the tweet didn’t even specify where in Safari to enter the text (text area, search bar, anywhere). So even absent the relevant config I’d say it’s a pretty lacking bug report in the steps too.
They're not trolling. I typed it into the search bar. Safari didn't crash.
Is the person who wrote the tweet trolling? Probably not either.
But what type of iOS device do they have? Which version of iOS are they running? Which language and locale?
Those things matter. Other things that apparently shouldn't matter might matter as well: other apps installed or running, notification configuration, how many tabs they have open, whether they're connected via WiFi or 4G, etc.
We don't know any of that stuff. As GP said: better reproduction steps needed.
As it is this bug report is barely above the kind of "hurr durr it dern't work" support ticket that really pisses off everyone in my team, and indeed every support engineer, and software engineer I've ever worked with.
2) The very first thing any actual engineer on Apple's payroll ought to try to reproduce it will work (most recent official iOS, "happy path" settings that have Safari Suggestions turned on)
1) Yes, people use tweets to report bugs all the time. The problem with nitpicking is that anyone can pick your nits back, which leads me to...
2) Yes, they will, but that won't necessarily repro the bug without knowing which type of device it's running on, so at the very least they might need to check several different devices, and even then other factors can come into play that go beyond basic device configuration.
I'm sure, given that this appears to affect at least a significant minority of users, that Apple will be all over it and will find a way to repro it in relatively short order. Yet, at the same time, it's obscure enough to have escaped their no doubt reasonably robust QA processes before release, so it may well be there are some wrinkles to reproduction that aren't immediately apparent.
> 1) Yes, people use tweets to report bugs all the time. The problem with nitpicking is that anyone can pick your nits back, which leads me to...
People might. This one didn't even @ Apple. Jesus, HN (a sentiment the Tweet author has also expressed by now on the tweet thread, as they're apparently reading this and seeing y'all acting like this in public)
> 2) Yes, they will, but that won't necessarily repro the bug without knowing which type of device it's running on, so at the very least they might need to check several different devices, and even then other factors can come into play that go beyond basic device configuration.
Twitter figured this out in like 30 minutes. It's Safari Suggestions on any recent iOS. This may not be the platonic ideal of a bug report but it's not a bug report and also it happens, by chance, to be entirely fine even if it were, because this is super-easy to figure out.
"support ticket that really pisses off everyone in my team, and indeed every support engineer, and software engineer I've ever worked with"
I'm sorry to to be the one to break this to you -- you have only worked with bad engineers.
If you get a bug report like this, where some simple user action like typing three characters is causing client devices to crash, you better be more mad at your busted ass system than a sparse bug report.
I think the suggestion that “X crashes Safari for at least one user” vs “X crashes Safari for all users” is a pretty different severity so the relevance of this story hinges on if it’s some minority of users or a large majority, or even all users.
I don’t think it’s unreasonable to try to narrow it down here simply because the story sort of hinges on the magnitude here.
It's not the user's job to figure out that it only happens in Florida on Tuesdays. They may not even be able to change all the relevant variables.
Apple developers should look at the stack trace that should either be sent automatically when it crashes (if privacy settings allow), or with a problem report sent from the device.
If this is a widespread issue, devs should have already gotten an automated alert.
Edit: stopped reproducing here as of 19:11 UTC.
Edit: some people digged into it[2][3], [2] includes partial endpoint URLs. Apparently this was happening for 7+^H^H 10+ hour.
1: https://www.macrumors.com/2022/11/14/safari-search-crash-bug...
2: https://twitter.com/nejigami/status/1592174411712712706
3: https://twitter.com/take6556/status/1592100775119171584