It seems like either the Saturday night crew at Dropbox has made a major mistake, or this is some kind of new phishing attack that came pretty close to succeeding.
The same thing happened to me. There is information in the e-mail that I’m pretty sure no one but me and Dropbox would know. So I think the e-mail is legitimate, which is pretty strange.
I don’t think Apple has ever promoted Helvetica Neue as being more legible than, say, Lucida Grande. Apple has moved to Helvetica because it’s more attractive, and, with modern display resolutions (especially retina displays), Helvetica is legible enough. One may fairly argue that legibility should always trump aesthetics — but one could argue thus for all font choices, not just UI fonts.
The same was true of Mac OS X 10.0’s pervasive system-wide anti-aliasing. It was less legible but more aesthetically pleasing. In the long run, as displays got better and better, people stopped complaining about it.
If I’m complaining less, it’s only because I’ve lost hope that Apple is ever going to make legibility a priority. Retina displays are not yet widely available on Macs. Even where they are available, Apple has found ways to reduce legibility.
Update (2014-08-19): David Barnard:
I’m just not sure I can ever get on board with the new “to hell with legibility” Apple.
Update (2014-08-23): Ken Segall:
That’s not the only crime against fonts committed in this video. It opens with the following screen, featuring text over an image.
Thin white type over a light image? Unless this was designed to be some kind of eye test, it is in gross violation of Apple readability standards.
Now let’s ignore the fact that you’ve just leaked your key request to an untrusted server via HTTP. At the end of this process you should have the right key with high reliability. Right?
Except maybe not: if you happen to do this with GnuPG 2.0.18 -- one version off from the very latest GnuPG -- the client won’t actually bother to check the fingerprint of the received key.
[…]
Adding forward secrecy to asynchronous offline email is a much bigger challenge, but fundamentally it’s at least possible to some degree. While securing the initial ‘introduction’ message between two participants may be challenging, each subsequent reply can carry a new ephemeral key to be used in future communications. However this requires breaking changes to the PGP protocol and to clients -- changes that aren’t likely to happen in a world where webmail providers have doubled down on the PGP model.
[…]
I realize I sound a bit cranky about this stuff. But as they say: a PGP critic is just a PGP user who’s actually used the software for a while. At this point so much potential in this area and so many opportunities to do better. It’s time for us to adopt those ideas and stop looking backwards.
What I need is a notification system that reliably alerts me when things aren’t normal. Such a system would receive those periodic email notifications from my various apps and utilities, and would notify me whenever they didn’t receive them on the expected periodicity.
Beginning with OS X version 10.9.5, there will be changes in how OS X recognizes signed apps. Version 1 signatures created with OS X versions prior to Mavericks will no longer be recognized by Gatekeeper and are considered obsolete.
Important: For your apps to run on updated versions of OS X they must be signed on OS X version 10.9 or later and thus have a version 2 signature.
[…]
Do not use the --resource-rules flag or ResourceRules.plist. They have been obsoleted and will be rejected.
Apple does not seem to have given any reason for why such a big change—breaking many third-party applications—is so important that it needs to be introduced in a maintenance update of the OS. Is there a danger for people using 10.6–10.8, which presumably will not be updated?
I’ve been burned too many times by default code signing behaviors, so I long ago switched to an approach which many will consider too complicated, but which has nonetheless saved my bacon on repeated occasions. The “resource rules” change from Apple wouldn’t have even registered on my radar, because the final code signing of all my bundled frameworks, plugins, XPC services … every darned executable, is controlled by a custom build phase which is run very late in my apps’ build process, right before the final code signing of the overall app that Xcode handles at the very end.
[…]
A common kind of customization you might want to make is to e.g. add arguments to codesign that will cause the preservation of entitlements, so that e.g. an XPC service with its own entitlements will not have those blown away by your re-signing of the app. See “man codesign” for more information about the “-preserve-metadata” option and other flags.
I take this a step further and do all of my code signing in a shell script that runs after Xcode finishes its build and my other build scripts have run. It’s annoying to have to maintain this script, but the alternative—leaving it to Xcode’s built-in code signing support—has never seemed to work. A version-controlled script lets me see exactly what’s happening and in what order. I’m less subject to Xcode’s whims and can easily share logic among my applications.
However, for a variety of reasons many of us either need to build with older versions of Mac OS X or Xcode. We face a conundrum that can be solved by signing (or more accurately, re-signing) the apps on 10.9, ensuring that the signature is up to snuff even if the code was compiled and the app was assembled with earlier tools.
This is a fairly straight-forward process, but there are some gotchas and you should be aware of what effect running codesign with various flags will have on your finished product.
[…]
In my tests I ran into some issues having to do with the fact that some of my apps have custom “designated requirements.” I have ironed out all the kinks yet but it seems to help in this scenario to re-establish all the code signing for the bundle first and then as a final icing on the cake, re-sign the app package with the custom designated requirement.
Currently I have to build parts of Remote Buddy in Xcode 3 running on OS X 10.6.8.
[…]
The only way to obtain a v2 signature is by code signing under 10.9, but since Xcode 3 doesn’t run on anything newer than 10.6.8, I’ll have to separate the build process from the signing, packaging and submission process.
As TN2206 indicates, custom resource rules no longer work on 10.9.5 or Yosemite Developer Preview 5. The effect, for us, is that none of our shipping apps will currently be accepted by Gatekeeper on those versions of OS X. This was quite a shock. Fortunately, there is a “happy” ending to the story. We needed a solution to the problem quickly, and ideally a solution that didn’t require us to completely rearrange our source code repository. The potent combination of desperation and brilliance, if I may be so modest, led me to the solution.
[…]
I’m not going to make any editorial comments here on the change to Gatekeeper in 10.9.5, because this post is intended for developers, to aid them in their work. And my comments would be NSFW.
If developers don’t act quickly, large numbers of common apps could be affected. Developer John Bafford published a command-line script on GitHub Gist that identifies the signature version of all programs in a Mac’s applications folder.
Including Apple’s own applications, it looks like about two-thirds of the ones I have installed are using version 1 signatures.
I suppose this makes a certain kind of sense, but it reeks of what a former manager of mine calls a “double bank shot.” Amazon seems to be arguing that through this rather convoluted chain of events, all of which carry significant challenges and risks that are outside Amazon’s expertise (content creation, ecosystem development, etc.), they will be better placed to increase e-commerce’s share of retail.
Here’s my question: why not spend all that money – and time and executive attention – on simply growing e-commerce? Instead of pushing for the Prime Rube Goldberg machine, how about simply advertising Prime? And instead of pursuing a separate ecosystem, with all of the challenges and incentive risk that implies, why not focus on both building better apps and on creating partnerships with Apple in particular (who certainly has no intention of competing in e-commerce; Google is obviously much more of a competitor)?
Moreover, I’m concerned about the internal incentives that Amazon is creating for itself. Amazon is increasingly competing with its suppliers, particularly in the digital space, and I just noted that potential partners like Apple are instead rivals. More concerning is the effect of devices on the company’s overall strategy.
I think it’s pretty simple: Android + Google Shopping Express + mobile payments completely shut Amazon out of customer engagement.
I don’t really understand the argument that this is a threat to Amazon. Or that, if it is, that this is a response that would work.
