masonlee

This reminds me of "the most popular reddit ad ever" the "Magic Internet Money" MS Paint wizard.

https://medium.com/@paulbars/magic-internet-money-how-a-redd...

Does this dispute imply that Apple backdoors its own iMessage end-to-end encryption on states' request?

College is running an ad campaign, one of your co-workers saw it (consciously or unconsciously) earlier in the day, and that is what lead to the college coming up in conversation?

Are the founders hoping for additional kitten games? It seems that the game art is protected by copyright and trademark. And the breeding game itself is possibly covered by a patent. But what about representing this kitten data as cats elsewhere? I can't tell from the Terms of Use if this is encouraged or discouraged.

https://www.cryptokitties.co/terms-of-use

"A. You acknowledge and agree that we (or, as applicable, our licensors) own all legal right, title and interest in and to all elements of the App, and all intellectual property rights therein. The visual interfaces, graphics, design, systems, methods, information, computer code, software, services, “look and feel”, organization, compilation of the content, code, data, and all other elements of the App (collectively, the “Axiom Materials”) are owned by Axiom Zen, and are protected by copyright, trade dress, patent, and trademark laws, international conventions, other relevant intellectual property and proprietary rights, and applicable laws."

This is a cool scheme to address the problem of URL-impermanance due to the fact that DNS name ownership/control can change over time. It allows you to specify a URL plus a date.

I wrote a short blog post about the problem a few years back, and the Tag URI scheme ended up being one of the best solutions I came across, which is how I know about it. Some links in that post and comments may be of interest to people: https://masonlee.org/2009/08/21/is-the-web-sticky-enough/

I thought this was an excellent reading of Tim Cook's letter: "Apple is signaling to us that the real problem here is the use of the All Writs Act."

Interesting to think about for sure. Facebook's algorithmic solution seems to be that to the extent that any post is a true draw to Facebook, that post will get more likes and thereby be more likely to percolate up into other users' main feeds. Boosting that post will therefore cost less. This provides sort of a sliding scale without pricing tiers.

Yeah, getting the main feed right is a general issue for Facebook.

If someone really wants to know about a few bands in particular, liking some of their posts will cause more of their stuff to percolate up into the main feed. But they have to keep liking.

To see all posts from bands one can make an "Interest List" containing the bands. Posts from members of that list will show chronologically. But I don't think showing all posts is the solution to getting users the info they want.

What happens if a band page creates a Facebook event? Does the event get recommended to likers nearby the event? That could be an approach.

Author is probably correct in that Facebook needs clear guidance here.

"Then you suddenly changed the way Posts are seen by people who have already followed a musician’s page to the net effect that an average post is seen by a tiny fraction of the people who have liked the musician."

As Facebook user and band-liker, I don't want to see every post from a band-- just the posts that are relevant to me.

I'd expect that Facebook's current post "boosting" mechanism should work excellently for self-managed, touring musicians: Make a post about a local show, then pay just a couple dollars to "boost" that post specifically to users who like your page and live in the area of the show. The UI for boosting and targeting posts is super easy already, and we should expect it will just keep getting better.

Is the author asking for automation of the posting/boosting for multiple tour dates?

And it's pants all the way down! Can we even trust our chips? But we stagger on.

This song made its biggest splash three years ago on Boing Boing: http://boingboing.net/2009/12/17/gibberish-rock-song.html

(Google trends graph http://www.google.com/trends/explore#q=Prisencolinensinainci... )

I would think it's that SMS and telephone features don't map well to multiple users. Would you share them across accounts or block them for all but one user? It's just weird.

"Of course, it's not handcrafted" LOL

Textie Messaging on iOS and Android is all SSL and doesn't scrape your address book. It can also text with people that don't have Textie by sending free SMS or email.

Unfortunately, there's no way to differentiate between an app using the address book locally and an app uploading the address book to its servers. Both actions require the same permission.

It would be really cool if Apple provided some new "sandboxed" UI elements for displaying contact names and photos locally without allowing general programmatic access to that data, and thereby not requiring a permission. E.g. "Show sandboxed contact image for local contact with email address foo@example.com, or default image if none."

Is this an argument that future web services may depend more heavily on identity/reputation services?

It would be sweet for trusted computing if developers were able to submit source directly to an app store for the app store to compile, sign, and make available along with the binaries.

While the security of the hash itself can be a concern, the technique is always valuable:

1. In particular, the domain of email addresses is less vulnerable to rainbow tables than the domain of phone numbers.

2. Using salts and a slow hash function improves security by requiring custom rainbow tables that take longer to build.

3. In a B2C situation, an easy appeal to justice can be made that a business should not be making a concerted effort to break its own customer privacy protection. This would not look good in court.

4. If additional consumer protection laws are needed, one-way hashing for the purpose of privacy could be considered a form of pro-consumer DRM. In that realm we have precedents for anti-circumvention laws and contracts.

I would recommend sending hashed canonical values like we do in Textie. I posted this explanation for our users and anyone interested:

http://blog.textie.me/post/17261989750/keeping-your-address-...

I agree that some prominent privacy statements would be very helpful given that the target audience hates being targeted for junk mail.

I wrote this post. We have opt-in, hash-based address book comparison working in a fairly popular consumer app, if anyone is interested in sharing experiences. I recommend it as the way to go.

Phone numbers are easy to canonicalize: convert to international form.

Email addresses can be effectively canonicalized by lower casing. Not many mail servers are case sensitive these days. Additionally, for the local part, you can generally strip off anything after a "+", and with gmail, you can drop any period in the local part. (Granted, it's not perfect-- so make sure that's not a security concern.)

These techniques have been working fine so far in my app for my "Find My Friends" feature.

Beluga, Kik Messenger, Path, Hipster... Who else?

One can fuel a lot of user engagement by scraping the address book and notifying users every time one of their contacts signs up.

The "Beluga" app did this, without user permission or warning, and it boomed ahead of competition that did not. "Kik" did something similar. "Industry best practice" indeed.

Sadly, it's a winning strategy, and will continue to be until someone fixes the rules of the game.

The addresses from the user's address book should be hashed before sending to the server and compared to hashed addresses on the server. Then only positive matches are registered, and the server doesn't see more private information than it needs.

Twitter should be paying attention to this experiment.

Could they tie Android Market comments to Google+ identities? Would that fix anything?

Great post!

Perhaps it is not banal to say "INTERNETS" if you are indeed writing about the problem of network fragmentation?

Anyone know if they Amazon is actually hijacking "http://market.android.com/... " links, or are they just taking over the "market://..." url protocol handler? Huge difference.