Archive for March 29, 2016

Tuesday, March 29, 2016

IFTTT Drops Pinboard and App.net, Blames Them

Maciej Ceglowski:

It’s entirely IFTTT’s decision to drop support for Pinboard (along with a bunch of other sites). They are the ones who are going to flip the switch on working code on April 4, and they could just as easily flip the switch back on (or even write an IFTTT recipe that does it for them). Weigh their claims about Pinboard being a beloved service accordingly.

For users left stranded, I recommend taking a look at Zapier or Botize, which offer a similar service, or at one of the dozens of new sites that will spring up next week to capture the market that IFTTT is foolishly abandoning.

Gabe Weatherhead:

I’m probably done with IFTTT. I’ve waited for a business model and instead I get crazy service integrations I’ve never heard of.

zettt:

I somewhat expected IFTTT would go that route. The reason here is that they got so much investment money, that their growth plan has to involve bigger goals. In the end they need to recoup all of that money, because the investors don’t just spend money because they are nice people. The bigger goal probably means that they need to dominate the market in one way or another, and they think that they have to do this kind of thing in order to do so. IFTTT’s business has always been “blurry” to me. Blurry because it’s hard to understand what their ultimate goal is. It’s way too good to be free forever.

To me, the key point is that IFTTT doesn’t care about preserving the workflows that their users have already created. Instead, the customers are pawns to help them bully the services.

Update (2016-03-30): Nick Heer:

Cegłowski in a tweet from about a year and a half ago:

Right now the IFTTT business model is to charge one user $30M, rather than lots of users $2. The challenge will be with recurring payments

I suspect this is not unrelated.

Update (2016-03-31): I received an e-mail from IFTTT:

We’ve made mistakes over the past few days both in communication and judgment. I’d like to apologize for those mistakes and attempt to explain our intentions. I also pledge to do everything we can to keep Pinboard on IFTTT.

[…]

We made a mistake in asking Pinboard to migrate without fully explaining the benefits of our developer platform. It’s our responsibility to prove that value before asking Pinboard to take ownership of their Channel.

[…]

I also want to address Pinboard’s concerns with our Developer Terms of Service. These terms were specific to our platform while in private beta and were intended to give us the flexibility to evolve our platform in close partnership with early developers. We’ve always planned to update and clarify those terms ahead of opening our platform and we are doing so now. We are specifically changing or removing areas around competing with IFTTT, patents, compatibility and content ownership. The language around content ownership is especially confusing, so I’d like to be very clear on this: as a user of IFTTT you own your content.

Update (2016-05-03): See also: Microsoft Flow.

Universal Links Association Files Crashing iOS Apps

Joe Rossignol:

A significant number of iPhone and iPad users on the MacRumors discussion forums, Apple Support Communities, and Twitter have reported an apparent iOS bug that causes Safari, Mail, Messages, Notes, Chrome, and select other preinstalled and third-party apps to crash or freeze after tapping or long-pressing on web links.

Benjamin Mayo:

Since posting our original story, we have heard from a lot of readers that are affected by iOS 9 crashes or app hangs when tapping links, spanning multiple iOS versions (not just 9.3) and devices. In a statement, Apple has now confirmed that they are working on a fix for the problem, coming in a software update (presumably iOS 9.3.1).

[…]

Previously, we pinpointed Bookings.com as a cause of the bug, although noting it affects other apps as well. On Twitter, it was found that their website association file, used by the system for the universal links feature introduced with iOS 9, was many megabytes, grossly oversized. This would essentially overload the daemon that had to parse these files, causing the crashing. The Booking.com app has since corrected its payload file to be a far more reasonable 4 kilobytes. Users of Booking.com should delete and reinstall the app, to refresh the system caches for the URL association file.

[…]

Unfortunately, it is practically impossible to find out which apps are the misdemeanours. In terms of high-profile cases, we have heard that Wikipedia and Eat 24 are among the apps registering too many domains in their universal link directory.

Rosyna Keller:

The bug has existed in every version of iOS 9, from the very beginning. Booking.com just happened to update their association file last week to a version that triggered the bug. It has nothing whatsoever to do with iOS 9.3.

[…]

There’s no need to harbor any ill will towards booking.com for this. The documentation on Universal Links is extremely sparse. It never talks about the limits or best practices. It never even discusses how apple-app-site-association files are updated on iOS devices.

The file itself is completely valid JSON and passes all correctness tests. It’s just that iOS’ swcd daemon doesn’t like it and chokes hard. It’s nigh impossible for developers to test updates to their apple-app-site-association files from anywhere except the iOS simulator, which doesn’t have all the resource limitations a real iOS device has when shared with multiple other iOS apps.

[…]

Eat24 and Wikipedia are not related to this issue. The wikipedia site association file registers 5 paths. The Eat24 site association file registers only 1 (and it’s 156 bytes total). There’s no need to mention apps that are totally unrelated to this issue. All it does is worry people.

Timothy Hatcher:

New in iOS 9.3: Use wildcards for the domain name associations of Universal Links to help reduce duplication.

Update (2016-03-30): John Gruber:

In the meantime, if you’ve been hit by this bug, Ben Collier has a step-by-step workaround guide. (It’s not simple.)

Gruber says that apps were misusing the Universal Links feature, but that’s not clear to me.

Update (2016-03-31): Federico Viticci:

Apple released iOS 9.3.1 earlier today, bringing a fix for a problem related to Universal Links that caused apps to become unresponsive after tapping web links.

Update (2016-04-21): Apple (via Rosyna Keller):

In iOS 9.3.1 and later, the file must be no larger than 128 KB (uncompressed), regardless of whether it is signed.

Restricting Your Cell Carrier’s Use of Your CPNI Data

Adam C. Engst:

CPNI originally referred to anything that might appear on your bill, but now varies widely by service and carrier. With cellular carriers, it might include your data plan and usage, device info, location history, Web browsing history, and even demographic information.

[…]

Are there any actual abuses of CPNI? Yes. Additional research revealed, among many other stories at the Electronic Privacy Information Center (EPIC), that in 2014 Verizon paid a $7.4 million fine for using CPNI for marketing purposes without informing customers. Worse, AT&T had to pay a $25 million fine in 2015 for disclosing personal information (and misusing CPNI data) for almost 280,000 of its U.S. customers, thanks to crooks paying off employees in three AT&T call centers in Mexico, Colombia, and the Philippines to unlock stolen and/or grey market phones.

It’s important to realize that restricting a carrier from using your CPNI doesn’t prevent it from being collected, so opting out might not prevent such information from being swept up in data breaches like AT&T’s, but it certainly can’t hurt. Regardless, the fact that the FCC felt it was important to require telcos to offer such an opt-out makes me think it’s worth doing.