Archive for January 1, 2018

Monday, January 1, 2018

Ad Targeters Are Pulling Data From Your Browser’s Password Manager

Russell Brandom:

The researchers examined two different scripts — AdThink and OnAudience — both of are designed to get identifiable information out of browser-based password managers. The scripts work by injecting invisible login forms in the background of the webpage and scooping up whatever the browsers autofill into the available slots. That information can then be used as a persistent ID to track users from page to page, a potentially valuable tool in targeting advertising.

The plugins focus largely on the usernames, but according to the researchers, there’s no technical measure to stop scripts from collecting passwords the same way. The only robust fix would be to change how password managers work, requiring more explicit approval before submitting information.

Update (2018-01-02): Nick Heer:

I’m not sure if I’ve come across these scripts specifically, but on a few occasions, I have been surprised to see a Face ID indicator appear while visiting a website, without explicitly tapping in a login form.

AgileBits (tweet):

Because 1Password insists on user action to fill a web form, it’s immune to the particular attack from advertising trackers and a large family of related attacks.

But, presumably, a tracking script on the login page would receive the form data.

Gunes Acar et al.:

Publishers, users, and browser vendors can all take steps to prevent autofill data exfiltration. We discuss each in turn.

Publishers can isolate login forms by putting them on a separate subdomain, which prevents autofill from working on non-login pages. This does have drawbacks including an increase in engineering complexity. Alternately they could isolate third parties using frameworks like Safeframe. Safeframe makes it easier for the publisher scripts and iframed scripts to communicate, thus blunting the effect of sandboxing. Any such technique requires additional engineering by the publisher compared to simply dropping a third-party script into the web page.

Users can install ad blockers or tracking protection extensions to prevent tracking by invasive third-party scripts. The domains used to serve the two scripts ( and are blocked by the EasyPrivacy blocklist.

Now we turn to browsers. The simplest defense is to allow users to disable login autofill.

Unfortunately, if you disable automatic AutoFill in Safari, you cannot then invoke it manually when you know you’re on a login page. The “AutoFill Form” command in the Edit menu is disabled.

See also: the 1Password blog post.

Update (2018-01-24): Ricky Mondello:

Safari Technology Preview 48 changes how Password AutoFill works. Safari will no longer automatically fill user names and passwords into forms shortly after page load to prevent sharing information without user consent.

Pressing the Side Button to Confirm Payments on iPhone X

John Gruber:

These remarks caught my attention because a technically-savvy family member was confused by the same thing the first time they tried to buy an app on their new iPhone X. They showed me the phone with the “Double Click to Pay” animation and asked me, “What am I supposed to double click here? It doesn’t work.” What they had tried was double tapping on the “Double Click to Pay” label on screen. When I explained that the animation was pointing to the physical side button, the proverbial light bulb went off.

This is an interesting design dilemma. The reason why Apple requires you to press the physical side button to confirm a purchase with Apple Pay or in the App Store is because pressing the side button can’t be faked by an app. If it was an on-screen button, a nefarious app could present a fake Apple Pay button. With any normal app, clicking the side button once will always lock the screen, and double-clicking will put you in Apple Pay mode. Only Apple’s own software can override the side button like this. Double clicking the side button to confirm a purchase effectively guarantees that it was a legitimate payment experience.

I’m sure there must be a good reason, but I don’t understand what problem this is solving. A fake payment button is not actually going to charge me. And prior to Touch ID, payment confirmations used regular software buttons.

Update (2018-01-01): Tanner Bennett:

I had this question too. Consider this scenario:

Say the payment UI uses an on-screen button. A malicious app presents a fake IAP dialog that looks just like the real one. When you try to use Face ID, what it really does is use ARKit to detect your face then fakes the Face ID popup and tells you it couldn’t recognize your face. Now, when you hit the blue Install button, it will ask for your iTunes password.

So, it doesn’t apply to Apple Pay so much as it applies to phishing for your iTunes password.

All of this could be faked, except the Double-Click to Confirm, which would either lock the phone or trigger Wallet.

identityservicesd: What If Anyone Can Be You?

Khaos Tian (tweet):

Remember that super convenient, magical feature that allows you to send SMS on your Mac through your phone? It turned out the “it just works” part is only possible because your phone will just process any command send to it asking it to send SMS from the current number. And our beloved personal assistant, Siri? It’s also a dummy that just processes command without checking the command is from you. Both daemons don’t verify message origin and process the request when IDS delivered the request to them.


How are we suppose to separate individual identity away from the device that suppose to be your identity? Should individual be blamed for things their device did without the owner’s knowledge? I mean, with the SMS issue, one can literally put words in other’s mouth. All records will show the messages were sent by the owner of the device when the reality is that the device send those without the owner’s consent. The SMS is even logged on the victim’s device which cannot be achieved with traditional SMS spoofing techniques.


I found the IDS bypass issue on Dec 15th, then spent Dec 16th on scoping the affected daemons. Since I don’t want to do all the work free for Apple, I sent product-security an email asking about if I can get an invitation to join their security bounty program so I can report this one with some guarantee of the submission will be a bounty submission. […] Then the next day they fixed the issue from server side and said nope again.

Previously: Explanation of HomeKit Vulnerability.

Gruber on the iPhone X

John Gruber (tweet, Hacker News):

With the iPhone X, Apple is attempting something I believe to be unprecedented — a complete ground-up rethinking of a fabulously popular and successful platform, without a disruptive, painful transition.


Apple hasn’t called attention to this, but effectively there are two versions of iOS 11 — I’ll call them “iOS 11 X”, which runs only on iPhone X, and “iOS 11 Classic”, which runs on everything else.


The iPhone X display does not, alas, offer the ProMotion feature introduced with the latest iPad Pros, which allows for dynamic screen refresh rates of up to 120 Hz. But it does track touch input at 120 Hz, double the rate of all other iPhones. The result of this is that the animations for gestures track your finger better. It feels less like an animation that is playing in response to your touch and more like your finger is actually manipulating and moving things on screen as though they are real objects.


Thanks to Face ID, no-PIN “slide to unlock” is back. This, to me, epitomizes the iPhone X. In ways small and large, it changes fundamental aspects of using an iPhone. But it does so in ways that are faithful to the spirit of the original iPhone.


When an alarm from the built-in Clock app fires, it fades out in volume as soon as you look at the display. This is utterly charming.


I would love to see Apple introduce a smaller iPhone SE-sized phone with all the same features and design elements. I’m not holding my breath, but I’d love to see it. I’m not even saying I personally would prefer it (but I’d give it a try) — but it would be great for people who value one-handed reachability.


Why not bring more of what’s different on iPhone X to the other iPhones running iOS 11? iPhone X needs these gestures because it doesn’t have a home button. Classic iPhones could have supported them though — there’s no reason Apple couldn’t have added the swipe-up-from-bottom-to-go-home gesture to all iOS devices. And they could have then moved Control Center to a swipe down from the top right corner on all devices, too.

Previously: iPhone X Buttons and Gestures.

Update (2018-01-09): Riccardo Mori:

When now I read that the iPhone X is ‘the future of the smartphone’ or that ‘the future is here’, it just rings hollow. Why is it the future of the smartphone? The only feature that feels mildly futuristic is Face ID. As for the rest, what about it? It has very good specifications, very good cameras, a very good display… But I don’t understand what the big deal is, essentially. iPhone X users will probably say that the device is more than just the sum of its parts; that it’s the overall experience that ultimately makes the difference. But I still don’t see what makes the experience on this device truly stand out compared with, say, an iPhone 8.

Entering a FastMail Account Using a QR Code

Neil Jenkins:

Unfortunately, setting up your account can be tricky and error-prone. Proper support for autodiscovery of server settings is sadly missing still in most apps including Apple’s (despite the fact they literally wrote the spec…) and you have to set up mail, contacts and calendar syncing separately.

However, now there is a better way thanks to a feature Apple provides called configuration profiles. A profile is a file which bundles all the settings needed for your account, and can easily be installed or removed from your phone or Mac.