Revisiting Android disk encryption - <AUTHOR> http://nelenkov.blogspot.com/2014/10/revisiting-android-disk-encryption.html <comment><USER2> The dreadful "you must enable Javascript for this plain website" layout strikes again. So here is the summary of the article for the fellow plain HTML lovers:

> Android has included full disk encryption (FDE) support since version 3.0, > but versions prior to 4.4 used a fairly easy to bruteforce key derivation > function (PBKDF2 with 2000 iterations). Additionally, because the disk > encryption password is the same as the lockscreen one, most users tend to > use simple PINs or passwords (unless a device administrator enforces > password complexity rules), which further facilitates bruteforcing. Android > 4.4 replaced the disk encryption KDF with scrypt, which is much harder to > crack and cannot be implemented efficiently on off-the-shelf GPU hardware. > In addition to enabling FDE out of the box, Android L is expected to include > hardware protection for disk encryption keys, as well as hardware > acceleration for encrypted disk access. These two features should make FDE > on Android both more secure and much faster.

<comment><USER3> Thing is, scrypt isn't a panacea - there are ways to make it CPU hard instead of memory hard - [http://blog.ircmaxell.com/2014/03/why-i-dont-recommend- scryp...](http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html)

<comment><USER4> Your link repeats again and again (and again) that his criticisms only apply to _password storage_. In his own words _" as a Key Derivation Function, it is still very much useful and secure"_.

As GP said, Android uses it as a disk encryption KDF.

<comment><USER5> But why do they only apply to password storage? In both use cases cracking proceeds by running a lot of possible passwords through the algorithm and doing a cheap verification operation at the end - "does using this hash as a decryption key produce something that looks like ext4" is more expensive than "is this hash equal to the one I have on file", but not by that much. I don't see why a way to compute the hash more efficiently on some class of device would not be a concern for use as a KDF.

</comment></comment></comment></comment><comment><USER6> I wonder if full disk encryption by default will render Android unusable to blind people such as my self? When I encrypted my Nexus 7 2012 running 4.4 it turns out that you are prompted to enter your password before the talkback screen reader starts talking. Needless to say this is a major issue and no one from Google appears to be interested in fixing it as far as I can tell. With my iPhone Voiceover comes up talking and allows me to enter my password while still having the device encrypted.

<comment><USER7> The article seems to say that it won't require a password unlock again, after the boot one.

<comment><USER6> I can enter a normal pin or password if the device is encrypted since the operating system is completely loaded and along with that Talkback is. It's the boot password I can not enter because not enough of the operating system is loaded for Talkback to speak.

</comment></comment></comment><comment><USER8> Coming from iOS, one thing that I didn't really like about Android was how clumsy the decryption process was. The process is detailed here [1] and it involves the framework being put in a special mode that only handles password entry. In this mode, none of the regular services are running, so I'm not sure how incoming calls & SMSes are handled (or if they are even handled). It's like getting stuck at the boot screen with a password prompt.

In iOS, encryption is not performed at the block layer but at the filesystem level, and some files are encrypted with hardware-derived keys (thanks to a unique 256-bit AES key burned into the processor), allowing the OS to be booted normally, but not having access to certain files until the user enters his/her passcode (full details here [2]). Even if you don't immediately enter the passcode after boot, the phone is still in a somewhat functional state.

I'm glad that Android is taking steps to at least implement by-default disk encryption by relying on a hardware-backed key store.

[1] [https://source.android.com/devices/tech/encryption/android_c...](https://source.android.com/devices/tech/encryption/android_crypto_implementation.html)

[2] [https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...](https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2014.pdf)

<comment><USER9> On the other hand, the more system is loaded without user input the greater chance that it can be exploited; also filesystem-level encryption leaks some meta information.

</comment></comment><comment><USER10> Obviously, a strong passcode is a must.

But that's a big ask not just for the obvious reason, but also because the Nexus 5 is the first phone I've ever owned which demands that I unlock it first before I can access the UI to cancel an alarm.

And even then, it's a game of chance (especially when the phone is upside down while you're asleep) whether your swipe is in the correct direction (apparently UI designs actually removed the visual cues which would normally guide the user toward the correct action).

<comment><USER11> I wish it was easier to decouple the passphrase for the key and the passcode to unlock the device...

They have _very_ different security properties. Offline brute forcing the unlock passcode is far harder (presumably it's stored in the encrypted fs), so a shorter code is fine. Offline brute forcing of the encryption key passphrase is much easier (as TFA explains), but I'm never going to use a 'good' passphrase there, as it would be far too annoying to have to type it every time I unlock the phone...

<comment><USER7> Google needs to solve that part of the problem. Apple has already solved it with TouchID.

Google needs to do the same and mandate all OEMs must certify for fingerprint scanning technology (that has a high-standard of accuracy and security, not the gimmicks HTC and Samsung have tried before), or at least incorporate the same kind of technology Nymi uses in all Android Wear watches, so you can unlock the phones with that. Google should either acquire or replicate what these guys are doing:

[http://www.getnymi.com/](http://www.getnymi.com/)

<comment><USER12> Touch ID still requires you to type in your password after you boot the phone. Still quite handy, but not a password replacement by any means.

<comment><USER5> I think the idea is that the password (which can be made complex if you don't have to enter it that often) is analogous to the "passphrase for the key", while Touch ID serves as the normal "passcode to unlock the device".

</comment></comment></comment></comment></comment><comment><USER13> > In iOS 8, Apple has expanded the scope of data encryption and now mixes in > the user's passcode when deriving an encryption key, making it harder to > extract data from iOS 8 devices.

Not fully correct. In iOS8, the scope of DP (data protection) was enhanced to cover additional data with specific respect to the builtin Apple applications (SMS, photos, call logs, etc.). DP, since its introduction in iOS4, has always used the user's passcode as part of the encryption secret, and there are APIs available to create files and/or keychain items with data protection on.

Notice that there is an interaction between the multitasking/background system and data protection, as applications running background services will need access to a (part of) filesystem and (part of) keychain to operate. This is why the APIs have a very granular set of ACLs.

</comment><comment><USER14> If you don't have a hardware bound key as part of the KDF then you will be subject to extraction and parallel breaking. It may take more computing power with scrypt but it will be doable. KDFs enforce round constraints relative to the hardware they run on. Being able to extract from that hardware means being able to apply orders of magnitude greater processing and parallelization of that process. Hardware keys like Apple's are the only way to go.

</comment><comment><USER15> Hadn't internalized how essentially trivial it was to brute-force a PIN once you'd copied off the file system blocks.

With Android-L moving key material to trusted execution environments, expect interesting attacks on those. I am curious about state-mandated security holes in TEEs as well, since it's much easier to hide backdoors in chips than in publically reviewable software (I would much prefer to see a dedicated security processor than a "secure mode" of what is essentially the whole SOC).

</comment><comment><USER16> Very interesting. I've always been wary of PBKDF2 for these applications simply because most people will have a 4 digit PIN (although I don't), which is essentially useless against an offline brute force attack, and possibly worse than useless if it gives people a false sense of security.

At least CM11 allows a dedicated FDE password though - Google is really doing its users a disservice by not implementing this in stock Android.</comment>


Studio Briefing re-listed with no comment from Google - <AUTHOR> http://www.fastcompany.com/blog/dan-macsai/popwise/why-did-neutral-google-de-list-webs-oldest-entertainment-publication?partner=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+fastcompany%2Fheadlines+%28Fast+Company+Headlines%29&utm_content=Google+Reader <comment><AUTHOR> I planned to link to the original discussion here on HN, but that thread has been marked dead for some reason. In any case, I think the sudden banning of a site by Google and then re-listing within hours without comment is noteworthy.

This article seems reasonably unbiased, noting the questionable quality of Studio Briefing content, but also noting their length of time in operation.

Edit: Here is the link to the original conversation. <http://news.ycombinator.com/item?id=972583></comment>


The Critical Path for Two-Sided Products - <AUTHOR> http://bigbangtechnology.com/post/the_critical_path_for_two_sided_products

<comment><AUTHOR> Hey everyone, I'm the author of this article. You should read this if you're into lean startups, customer development, or if you're building a two-sided product/service that has both users and distinct paying customers.</comment>


America Soured on My Multiracial Family (2018) - <AUTHOR> https://www.theatlantic.com/family/archive/2018/08/america-soured-on-my-multiracial-family/567994/ <comment><USER2> > claiming that parents adopt to "virtue signal" or simply to ostentatiously > demonstrate their open-mindedness.

That's one of the more annoying type of phrases these days. I feel like people who use the term "virtual signaling" just use it as a filler for "I don't like you or what you do, so I'm just going to claim any good you do is a lie."

There do seem to be occasional narratives that target adoption. I find it very strange as the circumstances that people I know who have adopted their children from seem like situations you would never want a child to be in... but they have felt attacked by the concepts that in adopting they were imposing themselves on another nation or culture and doing something wrong. Meanwhile those children I know who were adopted are receiving love and the best care possible for a number of different challenges due to their earlier lives. What is it the people who make such claims think would happen if these children weren't adopted?

It seems like adoption for some reason fires up some low level responses in lots of different people.</comment>


Show HN: How to Get Root on Rippling for Mac - <AUTHOR> * Examine /opt/rippling/setup/node.json<p>* Inspect the "user" key.<p>* Base64 decode the "hash" key.<p>* This value may be used to login to the "Rippling Admin" account.<p>This should allow you regain full access to your system. Install Linux.  Enjoy. <comment><USER2> Confirmed that I can gain full access to admin account. Is Rippling aware of this?

</comment><comment><USER3> What's rippling?

Abiguious Google results.</comment>


Ask HN: Should I write a book? - <AUTHOR>

I participate in an open source project. Last week, I was contacted by a publisher asking for feedback on a book proposal and outline about this project. I was supportive of the idea, but critical of the execution and outline.
One of my criticisms was about the author's credentials on the subject. He's made three posts to the mailing list, none of them particularly substantive. I could find little else through Google. He appears to have written one other technical book on a different subject, in a different (human) language.
I got a free e-book out of my review and figured that was the last I'd hear.
Today, I received another email from the publishing company saying that a co-author for the book might be a good idea and they wondered if I'd be interested.
I currently have two jobs: a day job and moonlighting for a startup that should be hiring me full time soon. I'll be in this situation for at least another month, though, and even once I am working at the startup full time it may be fairly demanding.
The opportunity sounds exciting, but I'm also concerned that I may be taking on too much. I've never written a book before. I don't even have a blog, though I've been meaning to start one for a long time.
I'd love to hear from anyone who's written a book or who's been in a similar situation. <comment><USER2> My reaction is "RUN!".

If you aren't an experienced writer, you haven't co-written before, your potential co-author is a possible idiot, and you already have two jobs, then NO. Dear heaven, NO.

<comment><USER3> How do you become an experienced writer without writing?

To the OP: I say go for it. Whats a month? I'm sure you can start after get hired by the startup. Make it your pet/weekend project.

</comment></comment><comment><USER4> I've co-authored a book that did OK (Pro VB 6 & XML), and was about halfway through a book (Beginning Ruby) before the publisher (Wrox) went bankrupt and I got next to nothing for my efforts.

I've also been paid to write book chapters that never saw the light of day, and assorted articles for magazines, Web and dead-tree.

Basically, the money is often poor when predictable, but can be OK if a book does well. Overall, if money is the goal, get a job as a waiter; it will probably pay better.

OTOH if your book is among the first on a topic of current interest and doesn't suck you can do alright.

It can be a lot of work. For the VB book I needed to spend some time researching some W3C specs and making sure I had some technical details correct, but much of what else I wrote came from an application I had already written, so it was fairly easy to write about. For better or worse it gave me a falsely rosy picture of book writing. :)

The Ruby book, though, ended up being more work than I expected; documenting a language's behavior is more detailed than describing an app in that language. (Sadly, many language tech books suck because the authors don't actually know how the language works and fall back on loose, often incorrect, assumptions and analogies.)

A book can help build a reputation, get you speaking gigs, and in assorted ways contribute indirectly to income, so book sales alone may not tell the whole story. But it's pretty unpredictable. Books get canceled; hot topics fade away. Maybe you or a coauthor really cannot write.

If you're not innately excited about the idea, or don't feel confident in your tech writing skills, you might do well to hold off. Maybe write some blog posts, gauge reader interest, and test market the idea of a book.

</comment><comment><USER5> I've one book under my belt, _Inside ISAPI_.

A couple of high points:

It took literally every free moment I had for 6 months. Every evening, all evening, after I got home from work. Every weekend. And technology goes stale so quickly, your book probably won't have a very long lifespan, so you'll be lucky to get very much money out of it. I probably earned much less than $1/hr if I could figure out all the time spent.

On the other hand, it's one of the best resume builders you can imagine. Going into a potential employer with your book under your arm is worth quite a bit.

<comment><AUTHOR> Thanks for the response. It's really helpful. I'm not really that worried about the money, but it sounds like I do have to consider what my free time is worth to me.

Did you write your book solo or with a co-author?

<comment><USER5> It was with two co-authors. Luckily, we were all coworkers, and friends at that. If you're going into this with someone else, be sure that (a) you can work with them, and (b) you trust them to take the project to completion, so your work isn't wasted.

</comment></comment></comment><comment><USER6> I think that we have been contacted by the same publisher about the same book. And have the same feelings on the book and the offer to co-author it.

<http://news.ycombinator.com/item?id=2926505>

I was also critical of the author and outline. An unknown author with a single book on ruby to his name. The outline was poorly organised, and there wasn't anything that you couldn't get from the publicly available documentation and tutorials on the language.

<comment><AUTHOR> Yep, it definitely sounds like the same book. If you put your email in your profile I'd be interested in emailing you, though I suspect I already know who you are.

<comment><USER6> Just added my email to my profile, feel free to contact me.

</comment></comment></comment><comment><USER7> I almost did a deal to write a book for a well-known technical publisher. (A hurricane intervened.) The advance was only $8k, which would have probably worked out to less than minimum wage. I'd check the advance amount pronto, as that will probably put you off the deal regardless of the dicey co-author problems. Don't expect to get paid more than the advance. (And "advance" is kind of a misnomer, as you'd get this amount after delivering the manuscript.)

</comment><comment><USER8> Writing a book is very good for building your personal brand. IF you are interested in that, and IF you think the book could be fixed without too much effort, you could go for it. Having a starting point, however bad, would make it much easier to write the book.

</comment><comment><USER9> do whatever you want. for $20 an hour I'll do your thinking for you.</comment>


Simplicity is hard to build... - <AUTHOR> http://twitter.com/sacca/statuses/860432283 <comment><USER2> I have my own more literary version (hat tip to Tolstoy). "Crappy websites are all the same; great websites are each unique in their own way."

<comment><USER3> I would say: "All good interfaces resemble one another, each crappy interface is crappy in its own way."

<comment><USER2> On the surface they may resemble each other, but the effort is always in the little niggly details of error messages, page flow, arrangement of things on the page. Whereas crappy interfaces are just CRUD.

<comment><USER4> But that's bastardizing the original Tolstoy quote, which IIRC was "Happy families are all alike; each unhappy family is unhappy in its own way", i.e. success looks the same, but failure is widely varied.

</pedantic>

Applies to startups too. And oh look, there's a Wikipedia article on it too:

<http://en.wikipedia.org/wiki/Anna_Karenina_principle>

<comment><USER2> That page seems to be entirely one author's (Jared Diamond) twist on the original phrase. There's nothing wrong with turning a phrase around - it's akin to irony.

<comment><USER4> The page suggested that it was also used in statistics and ecology. I'd never heard of it before I Googled to make sure I had the quote right, so I'm basically taking Wikipidia's word for it (always a risky thing...)

</comment></comment></comment></comment></comment></comment><comment><USER5> Why is complexity easier to charge for than simplicity? Is it because consumers mistake accidental complexity with real complexity? Does simplicity make a product or service appear of less worth?

<comment><USER6> Because when people see complexity, they assume it was difficult to program. When someone sees simplicity, they assume that's just how computers work. For example, how does Google work? It's an incredibly complicated problem, but Google puts a nice front-end on it that makes it all look like that's just how computers work.

In my job capacity, I often have to create custom search applications. As a whole of the project, this is given very little time and money. What is given time and money are incredibly complex interfaces with lots of options. I have to assume this is because a search interface often has one (or a small number) of inputs (therefore is easy) while an interface dealing with categorization on multiple facets, tags, etc. has lots of complexity (therefore being hard).

Simplicity is hard to charge for because it looks easy. When something looks easy, we don't value it highly. Basically, we understand the work that went into cludgy, complex interfaces because we see it. We* don't understand the complexity of something simple like Google.

*The "we" is meant to be the public, not really people on news.yc.

</comment></comment><comment><USER7> This is true in architecture (building) as well. It's far easier to pile forms together and not worry too much about how they integrate together. Well designed plans are hard to find, but very easy to enjoy when you find them. Radically harder is to integrate the entire work into a unified whole, which is how architecture moves into the world of aesthetics. In the tech world, Apple strives to make this same move - the results speak for themselves.

<comment><USER8> "How Buildings Learn" by Stewart Brand. Highly, highly recommended book. It's about buildings that can adapt because the architecture allows them to. I'd read it again but my 2 loaned out copies have not been returned.

</comment></comment><comment><USER9> Simplicity is really easy to charge for. Tons of people want to pay for Dropbox because it makes getting files places easy when it wasn't before.

 _Simple_ , on the other hand, is very difficult to charge for. If you can't demonstrate a substantial amount of added value, people will want it for free or won't use it at all. And if you do try to charge, competitors will come in and quickly replicate what you've got, but undercut you.

<comment><USER10> I agree with "simplicity is really easy to charge for." People will pay more for a simple path to a result that they value. This makes your demo easier to understand and actual time to adopt faster as well (fewer, easier to follow steps).

</comment></comment><comment><USER8> This reminds me of the classic "Form and Function" ideal

> He admits that every stable object is really a "fiction" posited by the > operations of imagination and sentiment. We always "bestow on the objects a > greater regularity than what is observed in our mere perceptions"

<http://plato.stanford.edu/entries/hume-aesthetics/>

</comment><comment><USER11> Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove. —Antoine de Saint-Exupery

</comment><comment><USER10> I think for most applications this isn't accurate. It is true that simplicity is hard to achieve, but if you can deliver a compelling result without a lot of setup or initialization (e.g. three month professional services engagement) and without large changes in customer behaviour, you can capture much more of the value you are creating for your customer. It's when they have to put their best people on it for weeks to months to make it work (which they include in the calculation of the total cost of acquisition and ownership) that you are imposing additional costs that are subtracted from the value you create.

</comment><comment><USER12> I find this almost profound. Zen-like, even.

Google has been a comfort to me because the gap between simple interface and complex back-end is so incredibly huge.

Their success reminds me every day that hard is not the same as impossible when shooting for simplicity. And, when you achieve this (Google-like) level of elegance and simplicity it can be orders of magnitude better (than a complex solution).

</comment><comment><USER13> Sigh. Obviously, if you're working on a website that is just ludicrously simple, you want to pretend that simplicity is difficult. Get behind the search algorithms at google or the scheduler in Windows NT and tell us about how "hard to build" simplicity is.

<comment><USER14> Pretty hard, right? Isn't that his point?

<comment><USER13> Three people have upmodded you, which means that there are at least three people here incapable of reading and processing very simple sentences:

 _Complexity is easy to build_

That is what I am refering to. The search engine behind google and the scheduler in NT are COMPLEX, and to suggest that they are EASY TO BUILD for that reason is a suggestion of almost blinding stupidity.

<comment><USER14> He's saying simplicity FOR THE USER is tough to build. I'm sure even more so when they are backed by complex logic that make them magic for the user.

Maybe you should work on your own reading comprehension skills before you go insulting other people's.

<comment><USER13> It still doesn't make sense. To extend my example, the interface into all search engines, google or otherwise, is naturally simple. The more complicated interfaces, like that of clusty.com or a9.com, are surely not easier to create.

<comment><USER15> Sure they are! Complicated interfaces make it easy to:

1 - avoid forcing yourself to really prioritize your feature set, something that's really hard to do and requires really understanding your users.

2 - push a bunch of effort from you to the user.

For example, you cited A9.com. If I do a search on A9.com, the search results window is split (by default) into two parts: one that lists web search results and one that lists book search results. At least by default, it appears that both sections are always there.

If I do a search on Google, than Google will usually only display web search results, but if it senses I'm searching for something about a book (example: do a search for "Charles Dickens"), you'll sometimes see some book results up at the top.

Google's method of only showing you book results when it suspects you are looking for something having to do with books is both much less complex for the user and much more difficult to build.

</comment></comment></comment></comment></comment></comment><comment><USER16> What's funny is that good is expressed in infinitely diverse ways, while evil is pretty much expressed in a very narrow range. (Something of an obverse to Tolstoy's observation.)

</comment><comment><USER17> Is it ironic that I got the fail whale when I went there?

</comment><comment><USER18> I don't think it's quite that binary in reality.

<comment><USER19> Reality rarely fits into 140 characters.

<comment><USER20> That's often true, but the ability to express an idea succinctly can also be a sign that the author has thought through the idea and his words very carefully.

("I would have written a shorter letter, but I did not have the time." Blaise Pascal.)

<comment><USER19> Which I think this tweet did. It captured a whole lot of wisdom and experience into a small package, but it didn't match every situation. Rules of thumb like this one are usually like this.

</comment></comment></comment></comment><comment><USER21> Simplicity is easy to build.

Simplicity _without_ _drawbacks_ is hard to build (to verify only in the long term).

There has been found a term for that phenomenon: its spelling seems to be: wisdom.

(They even wrote a book about it, the most printed -- yet less read book ever: yes, _exactly_ _that_ one).</comment>


VLC developer takes a stand against DRM enforcement in Apple's App Store  - <AUTHOR> http://www.fsf.org/blogs/licensing/vlc-enforcement

<comment><USER3> As a major VLC developer, I have to say that the FSF is pushing bad faith and FUD.

The matter is way more complex, and it seems that the latest Apple Store terms are indeed compatible with the GPLv2 if you use a few precautions.

See <http://www.apple.com/legal/itunes/us/terms.html#APPS> "LICENSE OF APP STORE PRODUCTS" part

"You agree that the terms of the Licensed Application End User License Agreement will apply to each Apple Product and to each Third-Party Product that you license through the App Store Service, unless the App Store Product is covered by a valid end user license agreement entered into between you and the licensor of the App Store Product (the "Licensor"), in which case the Licensor's end user license agreement will apply to that App Store Product."

Read the unless part...

Oh, of course, it is better to make a political statement that doesn't even read the AppStore terms... Not to mention that VLC is GPLv2 not GPLv3...

<comment><USER4> That's the end user license. What's relevant is the app store developer agreement, and what app submitters agree to.

<comment><USER3> App submitter and developer agreement signing person are not related to the VideoLAN project.

The problem the FSF is rising is about users rights, nothing else... I don't see your point, I am afraid.

<comment><USER4> The submitter agreed for the app to be distributed in the App Store way, as is pretty well understood at this point.

If the FSF has a problem, they should take it up with the app's submitter, not Apple.

Did VideoLan _misrepresent_ the app _to Apple_ as being compatible with the App Store? That's the crux of the matter.

<comment><USER3> VideoLAN did not submit any application. A company named Applidium did.

<comment><USER4> Then it's Applidium's problem.

</comment></comment></comment></comment></comment></comment><comment><USER5> "That's because we went through a similar enforcement action against Apple when we learned that a port of GNU Go (which is copyrighted by the FSF) was being distributed through the App Store. Unfortunately, Apple chose to make the issue go away by simply removing the software from the App Store".

The FSF told Apple that distributing a port of GNU Go on the Apple store violated the copyright of GNU Go. Apple stopped distributing it. It is pretty ridiculous of the FSF to say it is "unfortunate" that Apple chose to stop distributing it.

<comment><USER6> Of course it is unfortunate. Apple had two choices; stop distributing it, or distribute it in a way which complies with the license. The FSF would prefer the latter; they are disappointed when people choose the former. Telling people to stop distributing it because it is infringing copyright to do so is the stick, and the software distributed under the proper license is the carrot, to try and promote software freedom. The FSF would much rather have people be able to run GNU Go under the terms of the GPL, than not be able to run it at all.

Why do you think this is ridiculous?

<comment><USER7> I'm curious as to how you think that _Apple_ could provide the source code to a 3rd-party application. Would you care to explain?

<comment><USER5> The problem isn't lack of source. Most GPL programs that have appeared on the App Store have included a way to get the source satisfactory for GPL purposes.

The problem is with the terms of use of the store. When an end user tries to use the store, the end user has to agree to certain terms, including that they will not reverse engineer anything they download, they will not copy it, and other terms of that kind.

When a developer offers his program through the store, he provides a copy to Apple. When an end user purchases the program, _Apple_ makes a copy and provides it to the user. Hence, from a copyright point of view, Apple is making and distributing copies of the program, and so Apple needs permission of the copyright owner.

If the program is GPL, Apple has to obey GPL to get that permission. GPL prohibits imposing additional restrictions on the GPL code you distribute. Apple's end user terms of service are additional terms.

Hence, it is not possible to distribute GPL code through the Apple store unless you grant Apple an exception allowing them to impose their additional terms. If it is the copyright owner who is making the app, that is not a problem. However, if they use anyone else's GPL code, and that third party coder has not granted Apple an exception, then the app cannot be distributed via the store.

</comment></comment></comment></comment><comment><USER8> _All they would have to do is follow the license's conditions to help keep the software free. Instead, Apple has decided that they prefer to impose Digital Restrictions Management (DRM) and proprietary legal terms on all programs in the App Store, and they'd rather kick out GPLed software than change their own rules. Their obstinance prevents you from having this great software on Apple devices—not the GPL or the people enforcing it._

I don't think Apple is the only one being obstinate here. The App Store definitely defines strict terms about how an app can be distributed, but so does the GPL.

<comment><USER6> The GPLs rules are only about preserving end-user freedom (including the freedom to modify and redistribute software). Saying that the GPL has "strict rules" and is thus the same as the App Store is like saying that putting someone in jail for kidnapping is just as bad as kidnapping in the first place, because you're restricting someone's freedom. Yes, laws and jail for kidnappers restrict their freedom, but they only constrain you from taking someone else's freedom away.

Likewise, the GPL only restricts you from things you do that take away other people's freedom. If Apple just allowed its end users to have the freedom required by the GPL, there would be no conflict.

<comment><USER9> No, the GPL defines explicit restrictions about what the end user can and can't do with the software. In my book, that's less freedom.

Now, my tenet is just as flimsy as your tenet -- can't you see that your definition of "freedom" is flexible between people and that your freedom may not be another person's freedom? Because degrees of freedom are a subjective and relative interpretation all we can say objectively is that both the GPL and the App Store's EULA have restrictions and they both attempt to preserve an ecosystem that they see to be beneficial.

<comment><USER10> The GPL doesn't say anything at all about what the end user can do. In fact that's "rule 0":

<http://www.gnu.org/philosophy/free-sw.html>

The restrictions are on _distributing_ the software which is quite different from use of the software.

<comment><USER9> Distributing software is something you "do" with the software. If I meant restricting the use of the software I would have said restricting the use of the software.

<comment><USER6> The GPL doesn't restrict distributing software. Copyright does; without the GPL, you would not be allowed to copy the software at all, due to copyright laws that cover all creative works from the moment they are created, regardless of whether anyone opts in. The GPL grants you additional freedom to distribute the software, as long as you follow their rules.

Now, it doesn't grant as much additional freedom as, say, the MIT license, but the only freedoms it fails to grant you are the freedom to take someone else's freedom away. You can do anything you want with the software, as long as you don't do something that limits someone else's freedom to do the same.

</comment></comment></comment></comment></comment></comment><comment><USER11> This isn't much of a stand, IMO. Apple will just pull it unceremoniously.

Those who loved having it on their devices lose. VLC loses "customers." The GPL loses by looking worse than Apple's own rules. Apple loses by looking as if their approval process failed to catch yet another edge case.

Everyone loses.

<comment><USER6> So, you would rather have Apple win, and everyone else lose, by allowing Apple to simply distribute any software the want under their own terms, without regard to the licensing terms its creator licenses it under? You would rather have Apple win, and users lose, by Apple getting free software to distribute on their platform while still being allowed to lock their users down?

The FSF (and the VLC developers in question) would rather have their software distributed in the App Store, as long as Apple complies with the terms of the license. The Android Market has no problems with this (and even if it did, you can install apps that you don't get from the Market on an Android phone).

By locking users down, not allowing them to install their own software except through the App Store, and not allowing applications to be distributed under licenses of their creators choosing in the App Store, Apple is limiting the software that users can use on their phone. Apple seems to have a policy of ignoring free software licenses in their app review process, until the developer actually complains, but the fact that they ignored and violated the license despite their draconian review process, and only pulling software once someone complains, seems calculated to allow them to blame the developers for the app's removal (as you are doing) rather than the blame being placed on their own policies, which are the real reason that users's freedom is restricted.

<comment><USER11> Apple does not agree to abide by _your_ terms. Instead, by clicking "I Agree" when you submit a new app, _you_ (app submitter) is agreeing to abide by _Apple's_ terms. That's an important distinction in this case. It's irrelevant if you'd like Apple to change their polices. (Though they may some day - they've changed and relaxed many things over the years.) The point is that someone told Apple they had all legal permissions required to allow Apple to distribute it the way they do, and since there was an actual legal contract involved, Apple trusted that person. That person was apparently mistaken. It is that person whom the FSF and/or the VLC dev should be angry about - <USER2> Apple. (At least in this case.)

Yes, Apple's policies _are_ calculated. That doesn't make them evil nor does it make them necessarily wrong. It sounds to me like you want _your_ (GPL, etc) rules to trump Apple's rules. What gives you that right? The App Store is huge, popular, and everyone wants a piece of it. Apple created that success for themselves. You (or anyone else) has no basis to rush in and claim they _deserve_ their own little slice of it _just because_. You play by Apple's rules until Apple changes their rules or don't play at all. Don't like it? Go somewhere else - that's your right which is given in exchange for Apple having the right to make their own rules.

<comment><USER6> No, it is Apple you should be upset at. They're the ones who set up the store which requires everything to be distributed under their EULA, and they're the ones who don't allow you to install any software in any other way.

If you take away one of those restrictions, great! If the App Store isn't the only way of getting software onto my own hardware, then they can have whatever policies they want; I can just get the software from elsewhere (see, for instance, Android). Or, if they actually abided by the terms of any free software licenses for software they distributed, well, less fine (I still would like to be able to get my software from elsewhere), but they're at least complying with the terms of those licenses.

So yes, it's disappointing that someone clicked "agree" to something they couldn't legally agree to, because it violated the terms under which they were distributing free software. But Apple is the one here who is significantly restricting end-user freedom; and the point of this sort of enforcement of the GPL is to get the point across that free software developer will not let Apple benefit from being able to distribute said free software without complying with the terms of the license.

Apple benefits from having a better selection of software in the App Store; if I can play my videos on an Android phone, but not an iPhone, that might help me decide in favor of Android. They shouldn't be able to benefit from this without complying with the terms of the license. There are several free software packages (like VLC, GNU Go, and more) that they could benefit from, but should not be able to until they stop restricting end user freedom.

I am not trying to get "my" rules to trump Apples. I am trying to say that if Apple wants to benefit from my work, then they must play by my rules. I don't use or develop for iPhone for just this reason; because Apple isn't willing to play by a set of rules that I agree with. I have an Android phone; while it isn't perfect in respecting end-user freedom (it doesn't come with root, and rooting it voids your warranty), it is a heck of a lot better (I also use a Mac, for instance, which while much of the software is not free, Apple does not restrict what software I can an cannot run on my own machine, which I consider an acceptable compromise).

</comment></comment></comment></comment><comment><USER12> He's "taking a stand against Apple", but ISTM the real offender here is about the company that built an app with his code and submitted it to the store in breach of his license.

<comment><USER13> The point is that the developer wants developers to build apps with his code and distribute it. So he's complaining about the entity responsible for limiting distribution. He has no problem with the company that built the app.

Of course reading motives into people's heads is prone to error, but it's implied by his choice of the GPL...

<comment><USER14> Maybe he has no problem with the company that built the application, but the company submitted the application to the App Store knowing that the App Store's conditions would violate the GPL.

You cannot force GPL down Apple's throat. It is their application store. If their terms are not compatible with your license, change your license or live with it. By picking the GPL you are excluding some distribution venues.

In the meanwhile, the VideoLAN project is still endorsing the iOS application on their website. So, they are sending copyright infringement notices, while at the same time encouraging people to buy it?

<http://www.videolan.org/vlc/download-ios.html>

<comment><USER13> _or live with it_.

Which is exactly what he's doing. He could have let the original infringement slip quietly by, but instead he's using it to make a political point. Everybody loses short term, but he's hoping for long term gains.

</comment></comment></comment></comment><comment><USER15> Someone who submitted the app agreed that Apple's terms were fine and the developer could legally distribute the software in the manner the app store does. It probably would have been better not to submit it at all.

</comment><comment><USER16> It's very unfortunate that some devs spent much of their time porting vlc on iOS so it could be yanked by another dev kicking up a fuss over a technicality, in my opinion...

I hate apple's fascism as much as the next guy, but I don't see how the app store practically violates the GPL. Is it because it has no "download source" button? You can get it easily enough at the dev's site...

<comment><USER17> There may be other complexities to it, but I never thought the GPL v2 explicitly forbad DRM signed apps. Also it was my understanding that providing the source could be a URL, which is the easiest for everyone involved, but you could also provide it upon request by mailing a CDR and still be compliant. The GPL does not require that the source be included with the distribution of the program, just that the source is available to anyone who gets the compiled program.

<comment><USER16> I think so too, but I'm not sure.

</comment></comment></comment><comment><USER18> For the confused:

* VLC for iOS was ported by a 3rd party, not by the VLC developers

* VLC and most included libraries are licensed under GPLv2 which has specific requirements around redistribution and rights of users/developers

* Apple's app store policies are in violation of the terms outlined in GPLv3 (see: anti-Tivoization clauses) so software with any GPLv3 components can not be released in the app store

* Apple's app store policies also used to (and may still) be in violation of the terms outlined in GPLv2 so software with any GPLv2 components can not be released in the app store. The FSF did an analysis of the older App Store rules and determined that they were incompatible with v2 and v3 licensed code. They have not re-examined the new policy but some developers believe it is still incompatible with v2 as well as v3.

* The code in VLC itself is not owned by a VLC organization. Like most GPL projects, it is owned by the individual contributors.

* Rémi Denis-Courmont has written code that is included in VLC and is used in the iOS port and believes this was done in violation of GPLv2 (and, thus, copyright law). Some other VLC developers agree with him.

* Some VLC developers disagree with Rémi's interpretation

* Some VLC members have been accused of trying to censor Rémi's posts on the topic by removing his RSS feed from the VLC meta-feed

* For those unfamiliar with the details and goals of the GPL, Wikipedia is a good place to start: <http://en.wikipedia.org/wiki/GNU_General_Public_License>

Anything missing?

<comment><USER14> VLC endorses the iOS application in the App Store (at the time of linking): <http://www.videolan.org/vlc/download-ios.html>

<comment><USER18> It would be more accurate to state that "the VLC website maintainers have linked to it". It is disingenuous to say VLC "approves" of it as some developers, including Rémi Denis-Courmont, do not and see it as a GPL and copyright violation. Remember, Rémi is one of the core developers (and the top contributor to VLC according to Ohloh's stats: <https://www.ohloh.net/p/vlc/contributors> ), so saying 'VLC approves of the iOS port' is just incorrect.

<comment><USER14> I know that in an open source project there are individual opinions. But you would think that if something is listed on the website, it is trustable information, provided by the project. If not, what is the project's official source of information?

<comment><USER18> The opinion of the operator of the website is not necessarily representative of the developers. And the project leaders don't own the copyright to Remi's thousands of contributions, so they can't choose to re-license it or give Apple permission to release the app under any additional licensing or obligations above and beyond the exact stipulations of the GPL.

</comment></comment></comment></comment></comment><comment><USER19> So, where else does the FSF suggest we get our apps if we are supposed to avoid the App Store?

<comment><AUTHOR> The FSF would not recommend using an iPhone at all, in its present state. They have instead recommended phones such as the FreeRunner: <http://www.openmoko.com/freerunner.html>

</comment></comment><comment><USER20> I'm not familliar with the AppStore's terms, but VLC is licensed under the GPLv2. This means that the distribution of a derived work must be accompanied by a copy of the license text, and a reference to a place where the recipient (the user) can download the source code.

If the app submitted to the AppStore does both of these things, I don't see any violation.

Of course, you can't just change the source code and then run the modified app on your iPhone, but you can't do that for a Linux-based router either.

I'm not sure what's the problem here, really.

</comment><comment><USER21> I saw that coming the very day VLC was approved on the AppStore, looks like I was right:

<http://news.ycombinator.com/item?id=1709912>

<http://news.ycombinator.com/item?id=1710045>

</comment><comment><USER22> _The GPL gives Apple permission to distribute this software through the App Store. All they would have to do is follow the license's conditions to help keep the software free._

vs.

 _"Apple gives developers the ability to distribute this software through the AppStore. All they would have to do is follow the EULA's conditions to help keep the software free"_

Reminds me of the US political system. Opposing philosophical views but the they're both using the same tactics. Follow our rules because we know what's best for you.

<comment><USER4> Because Apple has nothing better to do than to deal with developers submitting apps with all kinds of idiosyncratic hoops for Apple to jump through.

"Oh, you can distribute this, as long as you do x, y, and z to be in compliance with the GPL license." "Oh, you can distribute this, as long as you put the app icon on theh apple.com front page." "Oh, you can distribute this, as long as you send Richard Stallman a signed glossy photo of Steve Jobs." "Oh, you can distribute my app, Apple just has to distribute my source code on the Lion install disk."

<comment><USER23> > _Because Apple has nothing better to do than to deal with developers > submitting apps with all kinds of idiosyncratic hoops for Apple to jump > through._

And how would those nasty developers like it if _Apple_ suddenly introduced all kinds of idiosyncratic hoops to the app submission process for the _developers_ to jump through?

Why, they'd have no grounds to complain, that's for sure!

<comment><USER4> It's Apple's store, they get to set the rules for their store. I have no problem with that. I may grumble at the rules they choose, but I'm not going to cry about it.

Little developers don't have much leverage. That's life. BFD. In the grand scheme of things, it's not a big deal. If the worst thing that happens in your life this year is that your app falls afoul of some persnickety little Apple rule, you're still living better than the vast majority of the humans on the planet who would LOVE to be so afflicted.

<comment><USER23> > _It's Apple's store, they get to set the rules for their store. I have no > problem with that. I may grumble at the rules they choose, but I'm not going > to cry about it._

Conversely, a GPL'd program is the author's work, and if some other developer submits it to the app store, the author is perfectly within his rights to waste Apple's time and demand either GPL compliance or removal.

> _Little developers don't have much leverage._

Except when they do; such as when Alice submits Bob's GPL'd program to the App Store. If Bob cares more about enforcing his rights than having his program in Apple's virtual toy store, he's got plenty of leverage.

And if Apple has to spend time and money taking down apps as a cost of maintaining its own bizarre and finicky rules (which cost 3rd-party developers plenty of time and money), then it's _exactly_ what Apple deserves. Poetic justice, even.

> _That's life. BFD. In the grand scheme of things, it's not a big deal._

In the grand scheme of things, humans are a tiny dot in an infinite cosmos. In the _human_ scheme of things, it may matter a great deal whether we end up with neutered app dongles instead of _real computers_ in our pockets.

> _If the worst thing that happens in your life this year is that your app > falls afoul of some persnickety little Apple rule, you're still living > better than the vast majority of the humans on the planet who would LOVE to > be so afflicted._

There are (at least!) two fallacies in your argument: Apple's bad behavior is justified (1) because there are worse things; (2) because the harm it does to anyone is not sufficient to reduce them to desperate, third-world, dollar-a- day, tapeworms,-warlords,-and-cholera-level poverty.

I maintain that Apple's behavior is _not_ justified, and I choose to forgo their iOS platform and its attendant riches. So far, I've been able to subsist on more than a dollar a day, cholera-free!</comment></comment></comment></comment></comment>


Show HN: A conversational bot to treat anxiety - <AUTHOR> https://www.pocketcoach.co <comment><AUTHOR> Pocketcoach is a digital therapist that helps you overcome anxiety stress or panic built on Facebook messenger

<comment><USER2> Hi Phil! I like that you are trying to help people with their anxiety and stress. I think CBT is interesting and as far as I know, CBT is one of the top recommended approaches today.

I'm curious why you decided to use a chatbot?

<comment><AUTHOR> Hey Devin, thanks! We really love the feedback so far. the format of conversational therapy was a perfect fit for a chat bot. Also it's really simply to to get started, we want to move towards an app eventually.</comment></comment></comment>


At the Top of His Game - <AUTHOR> http://www.nytimes.com/2008/05/25/jobs/25boss.html?partner=rssnyt&emc=rss#

<comment><USER2> BREAKING NEWS:

Geeky teenager conceives ridiculously complex fantasy game!

</comment><comment><USER3> Reinforces the fact that it's all about the connections.

</comment><comment><USER4> I wouldn't call it a card game, but rather a board game. After all, that's what product it was being compared to. Still, it sounds pretty cool that the kid is being taken seriously.</comment>


People On YouTube Make A Lot Of Money  - <AUTHOR> http://finance.yahoo.com/tech-ticker/meet-the-youtube-stars-making-100000-plus-per-year-535349.html?tickers=goog,

<comment><AUTHOR> So, we work with these guys and I can tell you that right now this is definitely low in terms of an estimate of the money they are making.

In addition to what they make from ads, a lot of YouTubers will get paid to make videos that involve a product, etc. For some (most?) that is actually a larger source of income than the AdSense.

Also there are many many more than 10 YouTubers who are doing very well from their channel.

<comment><USER2> I agree from what I have heard from people working with similar YT stars. What is surprising is the incredible amount of cross promotion done between seemingly unaffiliated stars in an effort to gain subscribers/viewers. From the rough description I heard about, it seemed somewhat scammy/gross to me but I don't know enough to make a definitive judgment. Do you have any thoughts or information about that?

<comment><USER3> YouTubers definitely cross promote each other, but it's not nearly as disgusting as you would think. In many ways, growing a new YouTube channel is very similar to growing a startup (these people are essentially startups themselves). At this point in the game, it's almost necessary to know someone more popular than you in order for your channel to get noticed.

I've worked with many YouTubers (I'm Ryan's co-founder), and can honestly say that they are nice people who appreciate each other's talents and want to help others like them succeed. They have a very strong sense of community, and they all know (or at least know OF) each other. Of course there are a few who do nasty things to try to get ahead, but those are by far the minority, and generally don't do well in the long run.

</comment></comment></comment><comment><USER4> Watching one episode of The Annoying Orange has taught me that predicting what will be popular content is incredibly difficult.

In other words, there's no accounting for taste.

<comment><USER5> Lol...just watched one, its was funny. I think its more like we don't know what will make us laugh sometimes. I don't consider this bad taste, look at Napolean Dynamite, i really hated it but i have friends that loved it and it is now one of those cult movies. I would say that there is no accounting for the extremes of taste.

That being said i will not be tuning in to the annoying little orange again.

</comment></comment><comment><USER6> the amount of "niche" hilarious/awesome/interesting video on YT and other video sites is a huge factor (along with blogs and HN/Reddit-like sites) why I don't watch traditional TV anymore. It tends to be better, I'm not forced to watch ads, it tends to be edgier/uncensored, it's more personal and interactive, and it's also more asynchronous and on-demand, easier to time- shift, place-shift and device-shift to suit the moment.

</comment><comment><USER7> Just be cute (preferably hot), either very smart and/or funny or... very dumb yet funny. But in order of being dumb you must qualify for the first criteria. Yup. CASH!

</comment><comment><USER8> Red vs. Blue made $250k through Blip.tv

</comment><comment><USER6> lesson: be very very cute and/or funny and/or creative -- ideally all three; now record yourself and post to YT; profit!

</comment><comment><USER9> How is that what seems to me to be the worst content is constantly touted as "featured" content? Is this a reflection of what people are actually interested in or is there something else going on behind the scenes?

</comment><comment><USER10> This doesn't seem like a lot of money to me. If there's only 10 people on one of the top 10 biggest websites in the world who are breaking 100K for creating content, which is the site's value, then the only ones making out are the owners of the site (google).

Conversely, take the app store as a content platform. There's hundreds of iphone developers who are breaking 100K. Granted, the skills required are different, but ROI on the iphone platform seems much better.

</comment><comment><USER11> People On YouTube Make Great Videos.

The article just observes the (almost expected) result.

<comment><USER12> I'm not sure there's a lot of correlation between the two. It seems to have more to do with networks dynamics and timing than the quality of the video. Of course, those matter in any market, but YouTube seems to be _particularly_ fickle--- hits are determined by whether you're one day early or late to a particular trend, by whether the first 5 people to see a submission to reddit voted it up or down, etc.

</comment></comment><comment><USER13> I think it is telling that those are the most popular youtube channels. Hint : if you like watching people acting retarded or treating you as if you were retarded, then you probably are.</comment>


Ask HN: Which is better ,career wise? iOS or Android application development? - <AUTHOR>

<comment><USER2> I think the better question would be:

What is best for your career given that the future is -- by definition -- not knowable and that the past and present are not necessarily indicative of the future?

After all, what is better today may not be better tomorrow and what is better tomorrow may not be better the day after. We live in a world where all technologies are in a state of decay, and our environment is rife with disruption and innovation.

Go deep (specialize) just enough to be unquestionably proficient, but not enough to be one of the world's foremost experts. Go broad (generalize) just enough to be learned (well-informed) in discordant technologies, but not enough to be omniscient (all-knowing). I call this type of a person a "genspec", a generalist-specialist.

For example:

1\. It's more useful to learn functional programming, object-oriented programming, procedural programming, etc., than to learn e.g., 3 different object-oriented programming languages.

2\. It's more useful to learn embedded development, mobile development, web development, etc., than to learn e.g., three different mobile development platforms.

3\. It's more useful to learn e.g., 3 different OSs than to learn e.g., 3 different distributions of a single OS.

Optimize yourself for change, adaptability, and continual learning of many materially dissimilar topics.

That's what's best for your career.

</comment><comment><USER3> I'm going to jump in here with an actual answer since I rarely see mobile development job posts where html5/lua is an acceptable alternative. iOS is currently more in demand and likely will be for the near future. Most companies go iOS first even if they plan on releasing for android, so even if you're skilled with bost it'll probably be easier to market yourself as an iOS developer.

<comment><USER4> I do both iOS and Android and get a lot of interest from companies and recruiters. Except for one company, everyone is more interested in iOS skills. They'd love to have both but iOS is in bigger demand and higher shortage.

</comment></comment><comment><USER5> Both. Learn both Objective-C AND Java. Learn cross platform development languages and techniques as well - javascript and Lua.

Whether you are looking for employment with someone else or starting your own company, having a broad set of skills is always valuable.

</comment><comment><USER6> The one that you enjoy!

There is nothing worse than doing something you don't like, no matter how good you are paid for.

Do what you enjoy and will be a great for your career!

</comment><comment><USER7> Why not develop cross-platform applications? As Zenst said, you could go the HTML5 route and use something like Phonegap. Personally, I'm a Corona SDK user. I can't comment on Phonegap, as I've never used it, but Corona makes it trivial to develop cross-platform apps written in Lua.

</comment><comment><USER8> iOS. Here is my completely unscientific observations from a fairly wealthy place in the USA.. People see apple and assume that they will have to pay lots of [real money] to use those things. Apple has put a ridiculous amount of effort into making "Mac" and "iPhone" into luxury goods. Now all the trophy- wives and cougars have iPhones.

I want android or something more open to win. They don't have the brand though.

</comment><comment><USER9> If i'm honest I'd say HTML5 as that is the common denominator and were everything will end up. So might as well beat the rush.</comment>