Both query the same servers, both use the same name, and both return the same information.
A reasonable person might believe that, having followed Apple's instructions for disabling "Spotlight Suggestions" (the Spotlight kind), they'd disabled "Spotlight Suggestions" (the Safari kind) -- especially if you didn't actually see any suggestions appear in Safari (I didn't!).
There needs to be a single checkbox: "Do not share my Spotlight data with Apple".
There's already a single checkbox for "Diagnostics & Usage Data", and that should be respected too. The network query posted here is actually a search metrics POST, not a live search query, and it's used as metrics for local and remote search performance.
p.s. It was also just pointed out to me that, having selected a specific search engine, a user would not be remiss in believing that their searches would be sent to the only the search engine they had selected.
I've just about wrapped up support for correlating connections with the local responsible program (see branch macosx-process-info); I also need to put some thought into how to handle non-TCP traffic.
I'll be posting Yosemite setup instructions later today; my plan is to collect a corpus of data from a default installation. One thing I could really use help with is providing a web-based visualization of that data.
If you're referring to the POODLE SSLv3 bug, it doesn't break authentication/key exchange or MAC, but instead, confidentiality of the symmetric encryption.
In other words (assuming an attacker can modify a sufficient amount of SSL traffic in transit), they could decrypt the python source code, but they can't insert new data without triggering a MAC validation failure on the client.
Thanks for the feedback; I committed a rephrasing of the trademark disclaimer (https://github.com/fix-macosx/fix-macosx) and I'll push that out when I next have the chance.
Just to clarify, the submission's title of "No Privacy, by Design" doesn't represent my own position; it's not a phrase that's used on fix-macosx.com.
> I applaud them for publicizing the implications of the default privacy settings for Spotlight, but hyperbolic titles like the one used here hurt their credibility unnecessarily.
That particular title seems to be an editorial flourish on the part of the submitter -- that phrase does not appear on the actual site.
Howdy. Author here. By way of introduction, I'm also the author of PLCrashReporter (https://www.plcrashreporter.org/), ported Java 6 to Mac OS X (a.k.a Soylatte), and -- this might lower some folk's estimation of me here -- started the MacPorts project almost 15 years ago at Apple, along with co-workers Jordan Hubbard and Kevin Van Vechten.
That slightly snarky disclaimer you quoted actually has a serious backstory; the language came from https://fixubuntu.com (whose AGPL code was used here), and it was added after Ubuntu sent a legal demand that "Ubuntu" be removed from the fixubuntu domain name and website:
I actually toned down the snark -- just slightly -- from the original disclaimer.
It's remarkably easy to miss Spotlight's privacy disclosure in Yosemite -- the instant you start typing in the Spotlight search box, the disclosure disappears, and seemingly stays gone. There's no single "local search only" toggle, and you have to cross-reference the documentation provided in System Preferences against the list of "Search Results" to figure out which of the options actually sends your queries to Apple.
I wanted something simple, that I knew worked, and I could just tell family to run themselves, so I put this together. It's a convenient way to apply the settings, a jumping-off point for a more involved effort to resolve some of the other remaining privacy issues on Yosemite, and a handy way to get the privacy message across.
If you're interested in chipping in on the OS X privacy front, there's a lot more to look at than just Spotlight; my next goal is to get https://github.com/fix-macosx/sslsplit transparently capturing traffic in a Yosemite VM so that we can start nailing down exactly what is being sent from the myriad of daemons (and spotlight!) that are sending data outwards in a default configuration.
I'm very sympathetic to the "random internet code" issue, so I struck a balance by:
1) Displaying the source inline in the page (of course, there's no guarantee that it matches the downloaded code, but the goal here is to highlight the important of knowing what you're running).
2) Making the actual script URL a clickable link, so that folks that don't blindly execute curl scripts (myself included) can easily download the script and examine it.
3) Used a variation of the usual pipe approach (curl -O … && ./…) so that anyone downloading it would actually have a copy of what they just ran.