HN user
When I started watching the video, I thought "yep, this clip is a perfect example of uncanny valley" and kept waiting for them to switch to a clip that was actually photorealistic.
Nope, turns out they seem to think the splash video is realistic. The whole video has tons of obvious flaws and overall feels wrong.
I don't know if I have superman vision or what here...
Many times, total throughput roses with the number of connections.
I can see the argument why one might not want it - total time to getting an app to play with can be increased.
What I really can't understand is why they pause all download activiry while installing an app. That's truly maddening.
Apple does have roughly twice the revenue as Google, when it comes to all sales. But Google is a huge driver of ads in free apps. So Google has a pretty meaningful reason for making the store solid.
When you search, you can't sort by rating, by price, etc. This is stuff Amazon was doing in the 90s.
Honestly, it feels like Google has some hidden agenda on how they weight search results...
The database that assumes people access google from multiple different time frames?
Look at the context. I think google is not trusting ntp or the client system time.
Histogram: Android.StrictMode.CheckGooglePlayServicesTime recorded 15 samples, mean = 4.5 (flags = 0x1) 0 ... 2 ------------------------------------------------O (4 = 26.7%) {0.0%} 3 ------------------------------------------------------------------------O (6 = 40.0%) {26.7%} 4 ------------O (1 = 6.7%) {66.7%} 5 ------------O (1 = 6.7%) {73.3%} 6 ... 8 ------------O (2 = 13.3%) {80.0%} 10 ... 14 ----O (1 = 6.7%) {93.3%} 17 ...
Histogram: Android.StrictMode.CheckGoogleSignedTime recorded 1 samples, mean = 256.0 (flags = 0x1) 0 ... 226 ------------------------------------------------------------------------O (1 = 100.0%) {0.0%} 268 ...
Ah - I had not considered SendGrid.
From an absolute security perspective, using some sort of hash or similar unique ID then referencing a database seems like the strongest solution.
But you are right, at large scale encoding the data in the URL plus some sort of HMAC would provide strong security with no database overhead, which I'm sure becomes significant at scale.
Might be interesting to try and reverse engineer their approach. Hash algorithms have a rather long history of being proven weaker than hoped... Especially down the road this could lead to some interesting possible exploits, mostly if the link was related to some kind of account a little more sensitive than meetup.com
Thanks for clarifying my thinking on this matter...