These two weeks went really quickly. All of a sudden, it is already end of the month.
There are basically two improvements worth recording.
1. In the readpeer team, we tried to do daily scrum meeting at 11am. We're clearer about the goals and we've effectively fixed miner bugs for the API as well as the App/Plugin workflow. Now, the bugs are mostly cleared and the APIs are mostly well-tested after two weeks' trials and errors. The iOS app is also progressing well, mostly because of Zijian's passion and smartness. Hopefully, we can have a demo next week for both the iOS app and the browser plugin. However, the Android app is slightly lagging. We just started integrating the APIs in the Android app. From the API design and implementation experience, I started to realize the potential security issues out there for the apps.
For Android app, it is actually pretty easy to be decompiled into codes. It's pretty dangerous to simply put the app_api_key and app_api_secret in the app without further authentication schemes. The current authentication method we use is to pass the predefined app_api_key, app_api_secret and username+password to get an unique access_token which is associated with a unique user session. Apps request for the APIs by providing the correct access_token. It seems to be useless to add on encryptions for the access_token and other keys when the app can be decompiled. Hackers can easily see the encryption methods. A more secure approach would be to add on timestamp to the access_token and cron the access_tokens in the backend every few minutes. However, that is also not good enough. What other web services, like Parse.com do is to add app identifiers,etc as additional authentication schemes. That would be nicer, however, it is also hackable especially for Android apps. We've added SSL support for web app, however, after knowing that SSL packages also can be hacked, I realize that security can be a big issue in the long run. However, security is not the most critical thing at this moment, but the features and the UX.
We also try to create more data by ourselves on the system to make the system more appealing. That's a common trick most UGC driven companies do to make their customers more involved.
Bad thing: The network in NUS goes down very often these days, which affects our service quite a lot. Recently, the internet in the lab server is disabled by school because the owner of the subdomain gets graduated and the server cannot connect to the internet again. I've tried to persuade the prof to use DigitalOcean, however, he recently prefers to buy clustered cubietruck mini PCs partly because of the funding criteria. Honestly, that's not a wise way to go.
2. Our Pair Diary app is progressing well. I've stayed in school for quite a few times/week to work with Qiyue and Zenan. Qiyue is really really busy with lots of projects. Hope he really gets some days off to enjoy his life. Definitely, Qiyue and Zenan are very good hackers. They'll become super good in the long run. For our clockie app, Apple is reviewing it and hopefully we'll get it on app store ASAP. Can't wait any longer.
Some other stuffs worth recording: I introduced a good job to the senior designer in Beijing to come here to work. He has already passed two rounds of interviews and will fly here tomorrow to take the final interview. It's promising that he'll get the job and maybe we will work together someday to make great projects to change the world.
There are basically two improvements worth recording.
1. In the readpeer team, we tried to do daily scrum meeting at 11am. We're clearer about the goals and we've effectively fixed miner bugs for the API as well as the App/Plugin workflow. Now, the bugs are mostly cleared and the APIs are mostly well-tested after two weeks' trials and errors. The iOS app is also progressing well, mostly because of Zijian's passion and smartness. Hopefully, we can have a demo next week for both the iOS app and the browser plugin. However, the Android app is slightly lagging. We just started integrating the APIs in the Android app. From the API design and implementation experience, I started to realize the potential security issues out there for the apps.
For Android app, it is actually pretty easy to be decompiled into codes. It's pretty dangerous to simply put the app_api_key and app_api_secret in the app without further authentication schemes. The current authentication method we use is to pass the predefined app_api_key, app_api_secret and username+password to get an unique access_token which is associated with a unique user session. Apps request for the APIs by providing the correct access_token. It seems to be useless to add on encryptions for the access_token and other keys when the app can be decompiled. Hackers can easily see the encryption methods. A more secure approach would be to add on timestamp to the access_token and cron the access_tokens in the backend every few minutes. However, that is also not good enough. What other web services, like Parse.com do is to add app identifiers,etc as additional authentication schemes. That would be nicer, however, it is also hackable especially for Android apps. We've added SSL support for web app, however, after knowing that SSL packages also can be hacked, I realize that security can be a big issue in the long run. However, security is not the most critical thing at this moment, but the features and the UX.
We also try to create more data by ourselves on the system to make the system more appealing. That's a common trick most UGC driven companies do to make their customers more involved.
Bad thing: The network in NUS goes down very often these days, which affects our service quite a lot. Recently, the internet in the lab server is disabled by school because the owner of the subdomain gets graduated and the server cannot connect to the internet again. I've tried to persuade the prof to use DigitalOcean, however, he recently prefers to buy clustered cubietruck mini PCs partly because of the funding criteria. Honestly, that's not a wise way to go.
2. Our Pair Diary app is progressing well. I've stayed in school for quite a few times/week to work with Qiyue and Zenan. Qiyue is really really busy with lots of projects. Hope he really gets some days off to enjoy his life. Definitely, Qiyue and Zenan are very good hackers. They'll become super good in the long run. For our clockie app, Apple is reviewing it and hopefully we'll get it on app store ASAP. Can't wait any longer.
Some other stuffs worth recording: I introduced a good job to the senior designer in Beijing to come here to work. He has already passed two rounds of interviews and will fly here tomorrow to take the final interview. It's promising that he'll get the job and maybe we will work together someday to make great projects to change the world.
Comments
Post a Comment