Why programming is hard (2006) - <AUTHOR> https://www.mail-archive.com/kragen-tol%40canonical.org/msg00168.html <comment><USER2> I dont want to be a smug asshole but personally I find programming really easy and natural. I wrote my first code ever in March 2012 (I was almost 30) I took to it immediately and have been working in the industry for about a year and a half now.

<comment><USER3> I think that 'hard' really needs qualification here.

Programming languages are designed to allow us to do what we need to. It might be difficult to perform incredibly complex tasks, but that's because the task is complex.

For example, cycling is easy. Cycling at high speed sustained is hard. Or rather it requires masses of training, discipline, etc.

I have also always found programming to be 'easy', but that doesn't mean I can somehow instantly solve any problem, or that everything is tractable, just that the actual tools have always seemed reasonably natural/sensible to me.</comment></comment>


AMD's Recent Struggles in Market May Be Ending Soon with Vega and Zen Releases - <AUTHOR> https://blog.parsec.tv/amds-recent-struggles-in-marketshare-may-be-ending-soon-with-vega-and-zen-releases-6e61b78b8131#.l29xlyybh <comment><AUTHOR> More data from PCPartPicker showing the recent struggles of AMD versus Nvidia. The last post generated a great conversation. What do you all think about the information presented here and will Zen and Vega releases change anything for AMD?</comment>


MIT 6.858 Computer Systems Security Final Projects - <AUTHOR> http://css.csail.mit.edu/6.858/2014/projects.html <comment><USER2> Here's the full course (20+ lectures) on youtube if anyone's interested:

[https://www.youtube.com/results?search_query=6.858+Fall+2014](https://www.youtube.com/results?search_query=6.858+Fall+2014)

<comment><USER3> Thanks. Videos in a playlist.

[https://www.youtube.com/watch?v=mffhPgsl8Ws&list=PLP941GogrX...](https://www.youtube.com/watch?v=mffhPgsl8Ws&list=PLP941GogrXs2akp7053CtkfEM3yw8fObm)

</comment></comment><comment><USER4> From Pretty Good Chat:

"We consider the case of the private key being stolen as very unlikely. The users themselves are not able to access it outside the app, and no other adversary will be able to either"

<comment><USER5> Not a very good starting point to consider phone app storage a reliable secure black box...

<comment><USER6> True, but you can increase that reliability with encrypted sqlite. Gonna have to pay for it, though.

<comment><USER7> Why? [https://www.zetetic.net/sqlcipher/](https://www.zetetic.net/sqlcipher/)

</comment></comment></comment></comment><comment><USER8> Interesting how 4 of the 25 projects are related to Bitcoin. It just goes show that the cryptocurrency inspires a good fraction of computer & network security people:

CheckBits: [http://css.csail.mit.edu/6.858/2014/projects/adat-bschang- er...](http://css.csail.mit.edu/6.858/2014/projects/adat-bschang-ericadu- ptew.pdf)

TorCoin: [http://css.csail.mit.edu/6.858/2014/projects/bchrobot- ynnad1...](http://css.csail.mit.edu/6.858/2014/projects/bchrobot- ynnad19-dereklax.pdf)

Dryer21, a Bitcoin Anonymizer Service: [http://css.csail.mit.edu/6.858/2014/projects/asuhl- dannybd-s...](http://css.csail.mit.edu/6.858/2014/projects/asuhl-dannybd- snp.pdf)

Merkelized Abstract Syntax Trees: [http://css.csail.mit.edu/6.858/2014/projects/jlrubin- mnaik-n...](http://css.csail.mit.edu/6.858/2014/projects/jlrubin-mnaik- nityas.pdf)

<comment><USER9> No doubt influenced by the MIT Bitcoin Project [1] that gave $100 in BTC to every MIT undergrad this fall.

[1] [http://mitbitcoinproject.org/](http://mitbitcoinproject.org/)

<comment><USER10> I'll note that OP is a founder of the MIT Bitcoin Project.

<comment><AUTHOR> Correct. Also in connection to the post, I'm an author of Merkelized Abstract Syntax Trees project for what it's worth.

</comment></comment></comment></comment><comment><USER11> I'd like to congratulate all the students for all of their hard work. 6.858 always produces new, original results, and this year is no different.

</comment><comment><USER12> I was a consultant for MIT and a student decided his final project would be to hack the custom LMS system we were working on. To our surprise, he figured out at least two ways before letting us know he was working on a final project. Gotta love MIT.

</comment><comment><USER13> If anyone has taken the time to go through all/all projects of a certain category, I'd love to hear some impressions/TL;DRs.

<comment><USER14> I can try to offer some impressions on the encrypted filesystems, as I went through all of those. Perhaps it's a bad choice, as it is the "default" project, but it's the area I am most interested in. I am not an expert in encrypted file systems, but I am a developer for a private cloud storage provider, and have some passing familiarity with the subject.

* Paranoia: Another Encrypted File System

They make repeated statements about relying on the server to protect the file from access such as "We depend on the server to correctly process ACLs and serve files that the user is authorized to view." and "If the server can be trusted to enforce the ACLs,no malicious user, perhaps named Mallory, can be permitted to read Alice's files." but since the premise of these projects is to deny trust to the server it seems odd to trust the server with anything. They do make sure that file contents cannot be read by the server without the client key, however I'm not sure why they went ahead and implemented a server except as a learning exercise or perhaps to provide an end-to-end solution. Inspection of the GitHub code raised some odd practices, such as explicit calls to sys.path.insert(0, '/home/henchill/Documents/Workspace/encrypted_file_system/server'), which makes me think perhaps it wasn't packaged correctly. At least they put it on GitHub, some of the other project were shipped as tar.gz.

* FyreBox - Encrypted File System

"Our filesystem is made up of 3 components: the client, the server, and a trusted cloud service." A trusted cloud service for the keys? I don't know why you would trust a cloud service and not the server. GitHub code seems reasonably clean, but requiring trusted cloud service seems like a dealbreaker.

* KBox: An Encrypted File System

I see a lot of math and LaTex, and security seems well considered, but I have to wonder about usability. The solution seems to store so much on the client side, including information needed to reconstruct the root directory and file names, that access from multiple clients or using it for sharing files seems untenable. However, I could have misunderstood. Noticed mixed tabs and spaces in the Python code, as well as cleartext password and private key in the code. Even if it is for testing, seems like bad practice.

* DarkFS - An Encrypted File System

I think I actually liked this one the best. They start right out by saying they do not trust the server for anything, and implemented their solution against the Dropbox API. They insert and encrypt the permissions/ACLs with the file data. However, these permissions are enforced by the client, so I wonder if a malicious client implementation could sidestep the permissions checking entirely. It is unclear if the permissions are enforced by the nature and sequence of the encryption itself. They also mention that had some issues with the Dropbox API, specifically being unable to encode file sharing data. I wonder if they would have been better served to implement their solution against the Amazon S3 API, as it supports file metadata and is quickly become the standard for file storage. S3 API is implemented by OpenStack Swift, EMC Atmos, Hitachi HCP, etc. Their code seemed well organized and the writers seemed familiar with Python. Would have preferred to see it on GitHub.

I was also a bit disappointed not to see anything here about distributed filesystems, leveraging torrents or other distributed infrastructure so that no server has the whole picture. There was interesting work done in projects such as Tahoe-LAFS years ago, nothing in these MIT projects seems radically innovative.

</comment></comment><comment><USER15> To compare with previous years ([http://css.csail.mit.edu/6.858/2013/projects.html](http://css.csail.mit.edu/6.858/2013/projects.html)):

2013 vs 2014

2/35 vs 4/25 - Bitcoin Projects

12/35 vs 4/25 - Encrypted Filesystems

2/35 vs 1/25 - Privilege Separation

</comment><comment><USER16> The reference materials page is also worth checking out: [http://css.csail.mit.edu/6.858/2014/reference.html](http://css.csail.mit.edu/6.858/2014/reference.html)

</comment><comment><USER17> There should be a final project like this to make distributed systems. It's a new area and could disrupt major players.

<comment><USER15> There's actually another course (6.824, [http://css.csail.mit.edu/6.824/2014/](http://css.csail.mit.edu/6.824/2014/)) that runs in the Spring that focuses on distributed systems, and also has had a number of interesting final projects. While we haven't released project writeups in the past, its possible we'll do something similar to 6.858 and put them up online at the end of the class for 2015.

</comment></comment><comment><USER18> That's a lot of encrypted filesystems :)

<comment><USER15> Yeah, we made that the default project for teams to work on.

</comment></comment><comment><USER19> I want to know about the Hacking MIT writeup! It's not available yet, I wonder what they achieved?

<comment><AUTHOR> They asked for a delay on release so that affected services can be patched.

</comment></comment><comment><USER20> I really want to see the package manager security paper when it's out.

</comment><comment><USER21> MAST looks interesring.

As to Kerby, all I have to say is Xposed.</comment>


Ask HN: What's your favorite monitor for dev work? - <AUTHOR> I use a 2016 13" MacBook Pro and I've been looking at the 21.5" 4k LG and 27" 5k LG Ultrafine displays that Apple sells, along with a Dell 27" Ultrasharp U2715H. I'm unsure what screen size/resolution would be best for dev work, as I've never used anything apart from laptop screens until now. What displays do y'all use? <comment><USER2> I use a 27" apple Thunderbolt monitor for graphics or the application and a 34" curved Samsung wide screen (3440x1440) for my IDE. The 34" is perfect for displaying 2 code pages side by side or a GUI and the source for it.

</comment><comment><USER3> DevOps Engineer, I have two 27" Cinema displays.

Is it a bit much? Probably. Do I _need_ it? Absolutely not.

Nobody was using the second monitor and my team lead didn't care.

So here I am. 17" MBP, and 2 27" displays.

It's glorious and excessive. But mostly glorious.</comment>


A guide to Oauth2 - <AUTHOR> https://milapneupane.com.np/2019/09/02/a-complete-guide-to-oauth2-protocol/ <comment><USER2> I'm currently in the middle of implementing an OAuth 2.0 authorization server following the RFC draft of the best current practice [1].

It's been a huge pain navigating all the interlinked (and sometimes contradicting) RFCs around, especially with a distinct lack of resources for actually _implementing_ an authorization server. RFC6749 does not suffice on its own since it says nothing about authentication or tokens payload (not that it should). I did discover the whole RFC universe which are mostly fascinating and very well written.

Most google searches end up to Auth0 (nice SEO!), which I'm sure is a fine product, but usually only gives a very high-level overview of the corresponding spec and ends up like "see how this is all complicated? there's a SAAS for that...".

I'm seriously considering implementing a fully spec-compliant OAuth 2.0 + OpenID Connect Core 1.0 reference server implementation in Typescript, with full documentation quoted straight from the RFCs. The HOW is actually pretty straight-forward once you've figured out the WHAT and WHY.

[1] [https://tools.ietf.org/html/draft-ietf-oauth-security- topics](https://tools.ietf.org/html/draft-ietf-oauth-security-topics)

<comment><USER3> I'm actually working on the same thing but in Rust. If you ever want to compare notes sometime, give me a shout out.

I'm actually kind of glad the documentation found via google searches (save one collection of Medium articles) has been disappointing. It has motivated me to look directly at the specification which I've found to be the most valuable resource thus far.

<comment><USER2> Oh yeah definitely!

Rust would be awesome but I think I'd want it to be as accessible as possible. Tagged unions and proper error handling would make it much saner though that's for sure.

<comment><USER3> I was initially going to do it in TypeScript, as the clients that will be interacting with it are TypeScript. Can't really go wrong either way, but yeah, I've enjoyed exploiting Rust's type system!

<comment><USER4> Be careful to do the hard stuff in workers, otherwise your throughput will be limited by one core.

Sorry if that's so basic of a consideration that it's insulting, but I've seen it done before.

</comment></comment></comment></comment></comment><comment><USER5> It's worth mentioning that it's a bad idea to invalidate refresh_token grants ever during the lifetime of an authorization. I've seen APIs do this immediately upon sending the response to the token endpoint, which makes the system unusable due to the frequency of network transmission errors that would result in having to contact the resource owner to grant access again. Even an expiry after days and years is only likely to result in more support requests to the API maintainer without increasing security enough to justify it.

The reason this bad practice is common is that it is allowed by the spec in [https://tools.ietf.org/html/rfc6749#section-6](https://tools.ietf.org/html/rfc6749#section-6) as an optional action to take on refresh grants. Please, do not do this.

<comment><USER6> I've always believed it should be the responsibility of the consumer (perhaps with the aid of client libraries) to properly handle the refresh lifecycle. I'm not a fan of password rotation, generally speaking, but it's because humans are terrible at remembering and creating complex passwords. Software processes don't have the same problem.

</comment></comment><comment><USER7> > You want to add all your contacts in Gmail who are in skype

Never once in my lifetime I wanted to do that. For any two services.

<comment><USER8> Above that I think this is rude to my contacts: _You can't just go and upload random people's data on plattforms of your choice_.

I _get_ it – people feel like it is _their_ contacts because they collected them, but they are not. This should be illegal.

<comment><USER9> So you don't store numbers of any of your contacts? You must have some insane memory ... but then again ... maybe memorizing random people's data should also be illegal... I mean did the people who told you those details give you permission to memorize it? I think not. And when you enter those memorized details into your browser or phone ... who gave you permission to do that?! Blatant GDPR violations.

<comment><USER8> If only there was some way to store contacts without uploading them..

Has it really come to this? If you open your phone now you usually have two offline options: to store contacts on the SIM card and to store them on the phone.

If you want backups and comfort without betraying your contacts you run your own nextcloud instance and store them automatically on there.

</comment></comment></comment></comment><comment><USER10> OAuth2 isn't a standard protocol. A real standard protocol is one where you can build a library around it and then use that to communicate with anyone else who conforms to the standard. OAuth2 is more of a description of the various homegrown authentication methods different websites have tried to create. None of those websites want to reimplement their auth to conform to the standards, so they just add their auth to the standard. This is standards conforming to practice, not practice conforming to standards.

Can you imagine if the HTTPS standard had to have 100 different variations to connect to 100 different sites on the net, with no way to detect which one was in use, so that you had to have the variations hardcoded for every site you visit? Because that's where we are with OAuth.

Worse, some of the practices which are now RFCs are complete garbage. The grant type Resource Owner Password Credentials[1], for example, requires that the third party server ask the user for their username and password. _This defeats the entire purpose of OAuth._ Don't give me some crap about this being useful for first-party servers: there are way simpler and more secure ways to authenticate first party servers. OAuth is for authenticating users with _third-party servers_ , and you should absolutely, unequivocally _not_ be letting third party servers ask the user for their username and password. This normalizes putting your passwords for one site into another site for nontechnical, which is outright irresponsible and unethical.

Yet in the handful of times I've authenticated with OAuth as a third party, more than one of the first-party sites I was authenticating with used this method, putting the onus on _me_ to correctly handle _their_ usernames and passwords. The reasons are obvious: 1. Doing it the insecure way is easier because it allows sites to avoid implementing an SSO portal to handle their own passwords and grant initial access (which, incidentally, isn't included in the standard protocol at all AFAIK, despite being necessary to make it work) and 2. The IETF somehow thought it was a good idea to give this awful security practice an air of validity with an RFC.

The OAuth2 protocol standard is a tire fire which is unsalvageable at this point. We need a new standard that is actually a fully-specified standard, with a single, clear path from start to finish, including the initial use of passwords to obtain tokens, which serves the single purpose of allowing third party services to authenticate in a _secure_ way.

[1] [https://tools.ietf.org/html/rfc6749#section-1.3.3](https://tools.ietf.org/html/rfc6749#section-1.3.3)

<comment><USER11> FYI, the IETF plans to deprecate the Resource Owner Password Credentials Grant you are talking about [1].

[1] [https://tools.ietf.org/html/draft-ietf-oauth-security- topics](https://tools.ietf.org/html/draft-ietf-oauth-security-topics)

<comment><USER10> Okay, but why was this ever put into a standards track in the first place? This isn't an obscure error, it's the kind of glaring error that shows that a security standard is being designed by people who know next-to-nothing about security. Recently, when I implemented authentication to a site that used Resource Owner Password Credentials, my client's CTO reported it as a bug because he (correctly) noticed the security flaw. If you're making this sort of error, you have no business writing production authentication code, let alone _standards_ for production authentication code.

And this is only the most glaring error. Another example: there's no specification for how to generate tokens, and I've implemented OAuth for platforms that return tokens which look suspiciously like UUIDs. Not only are UUIDs explicitly recommended against as credentials by RFC4122[1] because people could reverse engineer your UUID generation, but collisions have occurred in practice[2] without any reverse engineering, meaning that a user could authenticate as another user without even hacking.

And to clear, I'm not a security auditor and I've never done a security audit of any OAuth implementations except my own. These are problems I discovered by treating other people's OAuth implementations as black boxes, all of them compliant to the so-called "standard". Security is hard, and with so little specified, I imagine the majority of OAuth implementations in the wild are actually not secure.

[1] [https://tools.ietf.org/html/rfc4122#page-16](https://tools.ietf.org/html/rfc4122#page-16)

[2] [https://en.wikipedia.org/wiki/Universally_unique_identifier#...](https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions)

</comment></comment></comment><comment><USER12> This is far from a complete guide to the OAuth 2 protocol. I would recommend anyone wanting to communicate with, or implement a OAuth 2 server, to use the official RFC's as a reference.

</comment><comment><USER13> What I've never been able to get a clear answer to is: how do I troubleshoot an Oauth workflow? I set up all the Oauth stuff on my end just as the documentation says, and the Google server (for example) returns an error. Now what? They don't let me see their logs. The error message isn't descriptive enough to know what to change. Google isn't running an open source server where I can just spin up an instance myself to try it. The documentation seems to be out of date, or otherwise doesn't match what I'm seeing.

This is everything I hate about using remote APIs, squared. I've never been able to make even the simplest example work.

<comment><USER14> I was trying to use Oauth to log in to an internal SharePoint site with VBA, and I _did_ get some example code to work after a lot of messing around, but then it mysteriously stopped working a week later,* so I gave up and went back to scripting a browser.

*possibly because some system administrator noticed abnormal traffic and blocked it

</comment></comment><comment><USER15> Are there similar posts like this for UI best practices for implementing OAuth 2.0 as an authorization server? I've been looking for guides on how best to display the scopes and client details to the user, but I've basically had to rely on other authorization servers themselves for inspiration (Google, Github, etc.).

Has anyone written a blog post about OAuth authorization server UI design?

</comment><comment><USER16> If you like diagrams, I've found that @darutk on Medium has some really good explanations of Oauth2 and OpenID. Example: [https://medium.com/@darutk/diagrams-of-all-the-openid- connec...](https://medium.com/@darutk/diagrams-of-all-the-openid-connect- flows-6968e3990660)

<comment><USER17> Such great content now hostage to that website, what a pity.

Also look at their nice django-oauth-server: [https://github.com/authlete/django-oauth- server](https://github.com/authlete/django-oauth-server)

</comment></comment><comment><USER18> My experience using OpenID + OAuth2 was fantastic. I'd recommend delegating the responsibility of authentication to a third party like Cognito, Auth0 or Okta.

They can be pricey at scale, but as long as you follow the protocol without cramming more functionality into authentication than belongs there, you can swap them out for a self hosted solution.

</comment><comment><USER19> Im not sure there ever will be a complete complete oauth2 considering everyone who implement it have their own flavor of it.

<comment><USER20> Yeah this is far from complete. It doesn't even mention OAuth scopes or standard flows. A more appropriate title would be "A Beginner's intro to OAuth2". This is way better:

[https://medium.com/@darutk/diagrams-and-movies-of-all-the- oa...](https://medium.com/@darutk/diagrams-and-movies-of-all-the- oauth-2-0-flows-194f3c3ade85)</comment></comment>


How the Virus Got Out - <AUTHOR> https://www.nytimes.com/interactive/2020/03/22/world/coronavirus-spread.html <comment><USER2> Nice graphics.

This is the best site I've found for finding up to date stats and viewing time history per country (and in the US, per state): [https://www.worldometers.info/coronavirus/#countries](https://www.worldometers.info/coronavirus/#countries)

I marvel that China has so effectively stopped its spread. It seems like China has flattened the curve to near zero such that reportedly they are closing the corona-specific ICUs they had hastily put up. But what is the long term plan? Keep everyone clamped down until a vaccine or cure is developed? The vast majority of people still haven't been exposed so more explosive outbreaks will occur.

Just like controlled burns are a risky but effective strategy to prevent worst case wildfires, it seems to my ignorant self that ideally just enough mixing would be allowed so that new infections occur at a rate just below the level the medical system can handle, and while that occurs, the production of critical resources and infrastructure can be ramped up in case the controlled burn gets too active.

What am I missing?</comment>


55% of news stories placed? - <AUTHOR> http://www.boingboing.net/2010/03/15/study-finds-55-perce.html?utm_source=feedburner&amp;utm_medium=feed&amp;utm_campaign=Feed:+boingboing/iBag+(Boing+Boing) <comment><USER2> Obligatory refresher course for those just joining the HN party. <http://www.paulgraham.com/submarine.html>

</comment><comment><AUTHOR> Presumably the PR firm for the researchers didn't place this one.</comment>


Compression Streams – JavaScript APIs to compress and decompress binary data - <AUTHOR> https://wicg.github.io/compression/ <comment><USER2> I just use brotli compression in fastify to stream JSON (or anything really) to the browser

This is an interesting spec though. Kinda weak they only have gzip and deflate that have been around for DECADES. At least support some newer specs like brotli that have better compression. It already exists in the browser goddamnit!

[https://www.fastify.io/](https://www.fastify.io/)

<comment><AUTHOR> I think having gzip available for sending text and json POST data could be really good. In some testing I found that it can help squeeze some requests into a single packet.</comment></comment>


Shopsense raises seed round from Kae Capital - <AUTHOR> http://www.iamwire.com/2013/09/shopsense-raises-seed-kae-capital/ Mumbai based Shopsense, has raised seed round led by Kae Capital . <comment><USER2> Ya i heard they are building some cool stuffs, Will try today night to have a look on their site.

</comment><comment><USER3> Great to see indian startupss working on it</comment>


Whoisi: Follow your friends on the Internet. - <AUTHOR> http://www.0xdeadbeef.com/weblog/?p=348 <comment><USER3> _"... First and foremost the site is organized around people. Everyone has an entry that gives an overview of what they are doing on the internet - <USER2> posts, flickr photos, etc. But that entry is created entirely like a wiki. Anyone can edit anything. ..."_

Interesting because you don't really control your own Feed account. It is at the moment editable by anyone in a wiki-like way. If it is people based I can see the same sort of editing & ownership problems that plague Wikipedia. I'm at ~ <http://whoisi.com/p/2487></comment>


Sunsetting MetroTwit: all good things must come to an end - <AUTHOR> http://www.metrotwit.com/2014/03/sunsetting-metrotwit-all-good-things-must-come-to-an-end/

<comment><USER2> MetroTwit is/was the best windows 8 desktop client. twitter's api token policy is just sad.</comment>


UK spy agencies have collected bulk personal data since 1990s - <AUTHOR> http://www.theguardian.com/world/2016/apr/21/uk-spy-agencies-collected-bulk-personal-data-since-1990s <comment><USER2> "For example, a newsletter circulated in September 2011 by the Secret Intelligence Agency (SIS), better known as MI6, cautioned against staff misuse. "We've seen a few instances recently of individuals crossing the line with their database use … looking up addresses in order to send birthday cards, checking passport details to organise personal travel, checking details of family members for personal convenience," it says.

"Another area of concern is the use of the database as a 'convenient way' to check the personal details of colleagues when filling out service forms on their behalf. Please remember that every search has the potential to invade the privacy of individuals, including individuals who are not the main subject of your search, so please make sure you always have a business need to conduct that search and that the search is proportionate to the level of intrusion involved." Better where possible to use "less intrusive" means, it adds.

There has been disciplinary action. Between 2014 and 2016, two MI5 and three MI6 officers were disciplined for mishandling bulk personal data. Last year, it was reported that a member of GCHQ's staff had been sacked for making unauthorised searches.

The papers show that data handling errors remain a problem. Government lawyers have admitted in responses to Privacy International that between 1 June 2014 and 9 February this year, "47 instances of non-compliance either with the MI5 closed section 94 handling arrangements or internal guidance or the communications data code of practice were detected." Four errors involved "necessity and proportionality" issues; 43 related to mistransposed digits, material that did not relate to the subject of investigation or duplicated requests."</comment>


Install Google Play Store in an Android Emulator - <AUTHOR> https://proandroiddev.com/install-google-play-store-in-an-android-emulator-82cd183fefed <comment><USER2> This is very detailed. Nice</comment>


Want to be a technical co-founder?  - <AUTHOR>

Hey guys! Looking for someone cool willing to relocate to SF for the summer.
I'm Rory, a current Harvard student.
I've been working on Glyphic: https://itunes.apple.com/us/app/glyphic/id814910853?mt=8
for the past year, raised 75k, and looking to build a strong team.
Anyone interested in talking?
Feel free to drop me a line on twitter @RoryBro <comment><USER2> In order to help Rory out a bit with his recruitment efforts:

He is likely looking for someone experienced in mobile development. Some backend knowledge wouldn't hurt either. Relocation would mainly involve Americans (foreigners will need H1B, which Rory can't sponsor). Exp. in years not a requirement, simply showcase all the mobile apps you have built so far. Pay won't be great, but Rory is headed to a place where money will be easier to get.

As far as Rorys idea goes, it won't "change the world", but if you compare it to: imgur, reddit, snapchat, instagram.

This idea does have potential to be big.

Rory should also consider New York as an option, but the Valley will be the best place to build glyphic, raise capital and eventually exit the venture.

Good luck Rory!!!

<comment><AUTHOR> ahahahah this was good. Thanks Phantom ;)

<comment><USER2> Good luck Rory. Remember my 6% share when you sell to Google/Facebook/Twitter.

I am your Sean Parker. Just remove the "The". :P

</comment></comment></comment><comment><USER3> I would like to here more about it @chintan39</comment>


F-22 stealth's computers crash at the int'l date line - <AUTHOR> http://www.defensetech.org/archives/003315.html <comment><USER2> I thought the first comment was pretty funny. "What about some enemy hacking into the software and uploading a virus? ... To me, this sounds like a case of too much technology and too little common sense...."

Seriously though, it seems they would have used a framework that wouldn't allow an error like that, especially if it was in just a few lines of code, to propagate to all of the systems. They definitely weren't using erlang (couldn't resist).</comment>