Don’t be sorry! This is such a great write up! Thank you for sharing and I hope they realise how lucky they are that you properly disclosed BOTH vulnerabilities with a 30 days notice before public disclosure. I hope they will follow your advice, or else I believe this won’t be the last vuln of this scope to hit them if they chose to ignore good security practice!
How disappointing that they wouldn't even give a simple "Thank you" for you going out of your way to actually inform them. Don't they realize you could've just harvested the user contact info for a quick buck and sold a cracked version of the app for weeks/months before they realized it?
Okay, good job code monkey. Now move along, we have to get back to focusing on our shitty business.
Oh, the guy from support was fairly polite. I cut down his responses a bit for the sake of brevity but I'll clear that up.
For example the initial exchange was:
> Hey Tristan, thanks for reaching out to us about this. We really appreciate you telling us about this. We don't have a bug bounty scheme, but I've forwarded your feedback to our software team. Thanks again, Tristan.
This is super tangential to the content of the post, but can we take a moment to bask in the use of React Native here -- and the fact that it wasn't obvious it was a React Native app until the OP took the app apart?
Solutions like React Native, NativeScript and Flutter are providing real developers alternatives to trudging through bullshit on two separate app platforms just to deliver a similar looking experience to two walled gardens. This makes me happy.
BTW - I'm not even a React fan, I think it's over-engineered/not as simple as it should be. However it is/was a paradigm-shift type project and the divorce from the DOM model to enable support for something like React Native was a great move as well.
You can tell it's react native if it lags (at all). No native app should lag on a modern phone.
I wrote an app that locally loops over 5MB of JSON and then sorts it based on a datetime string (which is converted to a date class) - and it does this every few seconds. You can't tell that this is happening though, because the phone doesn't lag. It doesn't even use a significant amount of battery. It just works.
I wrote the same app in React Native + NativeBase earlier, and even though I implemented that in a smarter way, the app still lagged. Even just a general react native app that doesn't do anything weird just feels "off" sometimes.
Source: Wrote the same app 4 times (Swift, Java, React Native, Flutter) - Flutter was the clear winner, and a joy to work with.
Another really cool thing about how flutter works is that it gives you much more confidence about how things will render and work on iOS -- drawing every pixel would look like insanity to any onlooker before the project existed, but now that they've done it, and basically faithfully recreated Apple's UI, it's more of the process you can do without actually owning an iphone/ios development machine.
The nice thing about React Native is that you can always write native code if necessary. Though, I've used plenty of laggy native apps, so it's more about the software engineering behind it than the technology used.
Additionally, with JS most code runs on the UI thread unlike most native apps. If you use a web worker with RN you'd get similar behavior to your native app.
Not true! Play my game Falcross (https://www.falcross.com) on iOS or Android and tell me if you feel any lag. It's written in React Native. Less than 3% of the UI is native code.
You CAN make highly performant software, even games, with React Native. You just need to take the time to truly understand the platform, and you will reap massive benefits.
Thank you so much for posting this. Did you write about your work anywhere? There are tradeoffs to picking frameworks like React Native & co. but there just aren't enough people writing about their usecases and the performances they saw/tuning they were able to do.
Eventually I'd like to make an example app in ~3 of the alternatives (native, nativescript, flutter) and use appium to do comparisons and various timing.
Here's a very unscientific test (showing GPU usage) I did on the Note 8 switching between menus really quickly. It's barely noticeable (if at all) for me, but it certainly shows on older phones.
(It's also important to note that this isn't noticeable at all on iOS. The app is buttery smooth with a consistent framerate on iOS.)
Other than that, a few nitpicks: The "recently played" icon at the top is clipped for me, the energy/star/circle icons at the top flicker when you switch views, etc.
Things like that basically don't happen if you use "real" native development (or Flutter) with "real" native components.
The big question is "what impact does it have on the bottom line"?
If the react native app is sufficient for it's intended audience, then learning dart/flutter, or 2 native platforms is academic at best, as it's unlikely to sway revenues.
Maybe certain use cases can never be handled in react native, but for most, it's sufficient to not impact revenues.
At the end of the day, the user doesn't care about your programming stack, only results, and react native has been deployed at scale by large corps to demonstrate viability for most, if not all cases
Hi there, thanks so much for the bug reports! Would love to see a screenshot of the clipped icon if you could e-mail it to me at rawrmaan@gmail.com.
The flickering when viewing lightbox/modal views is actually due to my navigation library, react-native-navigation, which is otherwise excellent. I believe they're fixing that in their v2 release, at which point those transitions should be indistinguishable from native.
I've also made a ton of progress on Android performance in the past month, including the mindblowing realization that I had set hardwareAccelerated=false in my app's manifest over a year ago. The game should now be very smooth in all views, even on very low-end Android devices :)
Hey thanks for sharing your experience -- have you written about this anywhere? I'd love to read up on what you've been through. I personally want to go through the process you've gone through (except replace react native with nativescript) to see how it feels.
I like Flutter but I just don't want to commit to dart, but it represents an entry in the hybrid continuum (native -> webview) that can't be ignored because of how it works.
One thing though -- looping through 5MB of JSON doesn't seem like something you should be doing...
[EDIT] - Just saw your other comment with the render comparison pictures -- thanks so much for the input!
I have a few posts about Flutter and app development in general, but they were mostly just to blow off steam (content-light) and aren't exactly well thought out: https://nikhiljha.com/blog
I do plan to write a better comparison about the whole development lifecycle, performance, etc. later though.
I'd also like to urge you to reconsider dart. It feels kind of like a Kotlin-Java hybrid language, and I mean that in the best way possible. It's definitely familiar to anyone who has programmed OOP before, so it was really easy for me to get started with zero experience.
> One thing though -- looping through 5MB of JSON doesn't seem like something you should be doing...
Thanks for the blog link! definitely going to start reading!
Have you seen the Flutter Show[0]? It's actually a pretty good watch, though I'm a little skeptical/suspicious of how hard the marketing team of Flutter is pushing things, it reeks of when subpar/fledgling projects try to advertise/market themselves to greatness. Then again, the way Flutter works is pretty novel for the space so it's clearly not a marketing-only play.
Upfront I want to say that I fully recognize that disregarding dart is a childish thing to do, I mean to try building a not-bad flutter app as early as this weekend (I got my fill of nativescript-vue recently and liked it but want to see what else is out there), also I've watched and read enough about flutter that it's about time that I actually built something with it. Also, I'm not a fan of Java's semantics and ergonomics (though it's better than a large group of other languages), but I do always hear nice things about Kotlin. I've programmed in OOP but don't really want to any more -- structs + methods + interfaces/typeclasses/traits (i.e. golang, haskell and rust) are like 100% of what I want out of "OOP" approaches now, don't want the rest that comes with it in java land.
On that note, what do you think about Reactive programming (relatively recently announced as BLoCs in flutter)? I'm not sure I actually like trying to have primary data processing paradigm for applications, but I know it's a very popular approach -- I find an Observable gets you 99% to where you want to be, and observables are almost (if not completely) equivalent to streams but no one wants to do that, day 2 mobile app data management seems to almost always be "let's add streams".
I'm going to tip my hand here and admit that I upvoted this before ever reading the post simply because I've never seen an IPFS link in the wild before. :)
I've had IPFS support on my website for a while now and figured since one of the top HN posts was about porting a blog to IPFS I'd share the IPFS link.
Yeah, ipns links are pretty slow compared to ipfs links.
The best practice is to have a domain using dnslink[0] which always points to the most recent IPFS hash on a gateway with the content already pinned. I believe this is what the IPFS team does for their blog, using a combination of a static site generator and web hooks.
I just installed ipfs and noticed this as well - ipns performance is pretty terrible. I tried loading a page that was created (and therefore stored) on my node, and it takes a good 10 seconds to load).
The issue with just sharing the /ipfs/ version instead of /ipns/ is that I can no longer update the site and I just made a small edit to clarify some stuff so that link is already out of date.
49 comments
[ 2.8 ms ] story [ 106 ms ] threadhttps://github.com/d4l3k/opendropbike
It's not quite production ready, but does most of the basic things.
Okay, good job code monkey. Now move along, we have to get back to focusing on our shitty business.
For example the initial exchange was:
> Hey Tristan, thanks for reaching out to us about this. We really appreciate you telling us about this. We don't have a bug bounty scheme, but I've forwarded your feedback to our software team. Thanks again, Tristan.
Solutions like React Native, NativeScript and Flutter are providing real developers alternatives to trudging through bullshit on two separate app platforms just to deliver a similar looking experience to two walled gardens. This makes me happy.
BTW - I'm not even a React fan, I think it's over-engineered/not as simple as it should be. However it is/was a paradigm-shift type project and the divorce from the DOM model to enable support for something like React Native was a great move as well.
I wrote an app that locally loops over 5MB of JSON and then sorts it based on a datetime string (which is converted to a date class) - and it does this every few seconds. You can't tell that this is happening though, because the phone doesn't lag. It doesn't even use a significant amount of battery. It just works.
I wrote the same app in React Native + NativeBase earlier, and even though I implemented that in a smarter way, the app still lagged. Even just a general react native app that doesn't do anything weird just feels "off" sometimes.
Source: Wrote the same app 4 times (Swift, Java, React Native, Flutter) - Flutter was the clear winner, and a joy to work with.
But you’re right in general.
Additionally, with JS most code runs on the UI thread unlike most native apps. If you use a web worker with RN you'd get similar behavior to your native app.
https://github.com/devfd/react-native-workers
You CAN make highly performant software, even games, with React Native. You just need to take the time to truly understand the platform, and you will reap massive benefits.
Eventually I'd like to make an example app in ~3 of the alternatives (native, nativescript, flutter) and use appium to do comparisons and various timing.
Here's a very unscientific test (showing GPU usage) I did on the Note 8 switching between menus really quickly. It's barely noticeable (if at all) for me, but it certainly shows on older phones.
Canvas for Android (Native): https://i.imgur.com/5mWueG7.png Falcross Menu: https://i.imgur.com/DpKVNDK.jpg
(It's also important to note that this isn't noticeable at all on iOS. The app is buttery smooth with a consistent framerate on iOS.)
Other than that, a few nitpicks: The "recently played" icon at the top is clipped for me, the energy/star/circle icons at the top flicker when you switch views, etc.
Things like that basically don't happen if you use "real" native development (or Flutter) with "real" native components.
If the react native app is sufficient for it's intended audience, then learning dart/flutter, or 2 native platforms is academic at best, as it's unlikely to sway revenues.
Maybe certain use cases can never be handled in react native, but for most, it's sufficient to not impact revenues.
At the end of the day, the user doesn't care about your programming stack, only results, and react native has been deployed at scale by large corps to demonstrate viability for most, if not all cases
The flickering when viewing lightbox/modal views is actually due to my navigation library, react-native-navigation, which is otherwise excellent. I believe they're fixing that in their v2 release, at which point those transitions should be indistinguishable from native.
I've also made a ton of progress on Android performance in the past month, including the mindblowing realization that I had set hardwareAccelerated=false in my app's manifest over a year ago. The game should now be very smooth in all views, even on very low-end Android devices :)
I like Flutter but I just don't want to commit to dart, but it represents an entry in the hybrid continuum (native -> webview) that can't be ignored because of how it works.
One thing though -- looping through 5MB of JSON doesn't seem like something you should be doing...
[EDIT] - Just saw your other comment with the render comparison pictures -- thanks so much for the input!
I do plan to write a better comparison about the whole development lifecycle, performance, etc. later though.
I'd also like to urge you to reconsider dart. It feels kind of like a Kotlin-Java hybrid language, and I mean that in the best way possible. It's definitely familiar to anyone who has programmed OOP before, so it was really easy for me to get started with zero experience.
> One thing though -- looping through 5MB of JSON doesn't seem like something you should be doing...
I agree. I should get to fixing that.
Have you seen the Flutter Show[0]? It's actually a pretty good watch, though I'm a little skeptical/suspicious of how hard the marketing team of Flutter is pushing things, it reeks of when subpar/fledgling projects try to advertise/market themselves to greatness. Then again, the way Flutter works is pretty novel for the space so it's clearly not a marketing-only play.
Upfront I want to say that I fully recognize that disregarding dart is a childish thing to do, I mean to try building a not-bad flutter app as early as this weekend (I got my fill of nativescript-vue recently and liked it but want to see what else is out there), also I've watched and read enough about flutter that it's about time that I actually built something with it. Also, I'm not a fan of Java's semantics and ergonomics (though it's better than a large group of other languages), but I do always hear nice things about Kotlin. I've programmed in OOP but don't really want to any more -- structs + methods + interfaces/typeclasses/traits (i.e. golang, haskell and rust) are like 100% of what I want out of "OOP" approaches now, don't want the rest that comes with it in java land.
On that note, what do you think about Reactive programming (relatively recently announced as BLoCs in flutter)? I'm not sure I actually like trying to have primary data processing paradigm for applications, but I know it's a very popular approach -- I find an Observable gets you 99% to where you want to be, and observables are almost (if not completely) equivalent to streams but no one wants to do that, day 2 mobile app data management seems to almost always be "let's add streams".
[0]: https://www.youtube.com/playlist?list=PLOU2XLYxmsIK0r_D-zWcm...
[EDIT] - I particularly like these two posts in sequence on your blog:
- https://nikhiljha.com/blog/how-to-write-android-apps-in-2018
- https://nikhiljha.com/blog/a-reflection-how-to-actually-writ...
It also has that big red 'Google built this' flag, opensource not withstanding. Feels way riskier using it than any of the first 2 or even the 3rd.
Dropbike - send this candidate an email saying “You, sir, are hired”.
I've had IPFS support on my website for a while now and figured since one of the top HN posts was about porting a blog to IPFS I'd share the IPFS link.
The best practice is to have a domain using dnslink[0] which always points to the most recent IPFS hash on a gateway with the content already pinned. I believe this is what the IPFS team does for their blog, using a combination of a static site generator and web hooks.
[0]: https://github.com/ipfs/go-dnslink
edit: looks like this might be relevant: https://github.com/ipfs/go-ipfs/issues/3860
As an alternative, I'd recommend either my website: https://fn.lc/post/dropbike/ or the cloudflare AMP cache https://fn-lc.amp.cloudflare.com/c/s/fn.lc/post/dropbike/