dozy

mParticle | https://www.mparticle.com/ | Remote (US timezones) | Full time

mParticle serves as critical data infrastructure for engineering and product teams across the Fortune 500. Developers use mParticle as an abstraction layer on top of hundreds of tools, and to enforce data privacy and data quality. Come help us build for the future of data connectivity!

Product demo: https://demo.mparticle.com/ Github: https://github.com/mparticle

Our engineering team is growing fast! Come join us:

- Backend/Distributed Systems: https://www.mparticle.com/careers?gh_jid=3077965

- Mobile Engineering: https://www.mparticle.com/careers?gh_jid=2458665

- Fullstack: https://www.mparticle.com/careers?gh_jid=3009752

- Cloud Systems Operations: https://www.mparticle.com/careers?gh_jid=1219209

- SRE: https://www.mparticle.com/careers?gh_jid=3007392

- Engineering Manager: https://www.mparticle.com/careers?gh_jid=3076185

- Technical Writing: https://www.mparticle.com/careers?gh_jid=2986067

- DevTestOps: https://www.mparticle.com/careers?gh_jid=2591613

- Integrations Engineering: https://www.mparticle.com/careers?gh_jid=3044244

- All roles listed here: https://www.mparticle.com/careers

If you're interested please apply at the links above or shoot me a note (contact info in my profile).

In case it's useful to any - here's a diff of what Apple changed since the last update in March: https://gist.github.com/samdozor/637d21424cc3240b25fe5cd7007...

Agreed. I was commenting on this workaround's viability to be used by a bad actor attempting to compromise the game and other players of it.

Patching an APK like this would break parts of the app, specifically the parts that are arguably the most crucial to be followed by pinned API calls. For example, in-app purchases via Google Play that validate the app's signing would all fail. Similarly restoring any previous in app purchases would also fail. Finally, you wouldn't be able to install this APK without uninstalling the valid production APK first, again due to signature/signing mismatch.

Yep definitely, Urban is a great option.

Appboy, Kahuna, or (shameless plug) mParticle if you want multiple options :)

Parse authenticates with GCM using the API key that you provide, as do all other services AFAIK. So, all developers need to do is use that same key in their new push provider, and their push tokens will work.

The tricky part is actually making sure that all of your push tokens that are in the Parse database are migrated to the push provider that you've chosen.

EDIT: I stand corrected, looks like you have the option to use their key as you said, my apologies! Should have figured the founder of OneSignal would know ;-)

The Soda Ban is NYC-only, in response to the city's childhood obesity epidemic. Albany is a long way from the NYC mayor's office, both geographically and politically ;)

Been having fun playing with Lambda to power various Amazon Echo skills[1]. Definitely easier than having to deploy with something like Elastic Beanstalk, or even App Engine.

We're also using this at mParticle Inc. to allow anybody to add themselves as an integration[2]. The point being that Lambda is a super-easy way to write _some_ server logic, even if it only serves as a proxy to something more complex.

[1] https://developer.amazon.com/public/solutions/alexa/alexa-sk...

[2] https://github.com/mParticle/mparticle-sdk-java

Also, the improved 808 SoC at 20nm manufacturing process should offer better battery life over the 800 in the N5, even if they had the same battery capacity (which they don't, so it's a double-whammy there).

Though hard to say if this is true, it seemed their argument during the presentation was that the bigger sensor/pixels in both devices make up for the lack of OIS, and they specifically compared performance against the Nexus 6.

renders it more dangerous than not having it

If I were your friend, I would tell you that this is still dubious owing to the fact that without it, many people might use very weak passwords that never change. You gotta weigh that and the vulnerability it presents for large-scale remote attacks/leaks, against the likelihood of these guys getting local access to your machine (i think?) for this exploit.

Worth noting that Apple releasing Apple Music on Android is the exception to the rule - what other 1st-party Apple software/apps are available on Android?

Also, Apple Music on Android isn't even released yet :-/

not on Verizon :-(

In Android it's all been rolled into the Intent/IPC system since day 1. Apps are composed of Activities, and Activities can defined Intent filters. Intent filters describe what the Activity can handle, including but not limited to URLs.

Through this system, any app can register for any url (IIRC you can filter by scheme, host, and/or path). When a url is invoked, the system asks the user which app should handle it if there are several that can. You can also set a default app for the given url, etc - the whole system, though very flexible, has been widely criticized as having mediocre UX (though IMO it mostly works just fine).

In Android M (unreleased), they've added a similar feature as in iOS 9 whereby you can ensure that URLs you define and own are always handled by your app. Essentially you host a json file at your domain, served over https, that specifies the SHA256 fingerprint of your app's signing cert. Your app defines the url filter similar to before and the system makes sure that you match the fingerprint.

Android being Android, you can still tweak the default handling of intents even if apps do this, but it's pretty hidden.

It's still pretty top-of-the line, I love mine. Best Android device in my opinion with the possible exception of the Moto X, which is very similar (just smaller and slower). The longer I have the N6, the more the size is an asset, rather than a liability.

I've seen things like this before

It's actually pretty common in Android. Methinks you're an iOS user :)

any app could register to listen to those addresses

This is core to the Android IPC design. Apps/Activities describe what they can handle (Intents, actions, filters), and I think it works pretty well. Android will ask you if you want the given app to be the default or not, and you can always un-set the default. Also, if you have a new app that can handle the given link, the next time you try to launch that link you'll be prompted to see if you want to use the new app, and your previous selected default will be highlighted as a reminder.

Also, I'm generally a believer that if an app is registering for an Intent action filter that it does not handle well/shouldn't handle at all, then users will give it a lot of bad review feedback, and apps will trend towards doing the right thing.

read a message from a glance at a wrist

Do you expect to read all messages you get from a glance? How about emails? In fact, many messages you get won't be fully visible on the screen at one time - so what's the difference? Crucially - who is to say that text is all that can be conveyed when "glancing" at a watch? These things are not kindles.

I'll tell ya, I've owned both a square and a round Android Wear device. Forgetting the comparison to the Apple Watch, I much prefer the round Moto 360 to the square LG. Aside from the aesthetics - ironically, the circular display seems like it fits more on the screen, not less.

Luckily with Android you've got a choice, and the Android Wear team has built great APIs to handle both screen types.

Yes, you can scroll.

You can scroll that card to see the rest of it. I fail to see how this is a problem.

this reminded me of an interesting New Yorker summary of a study on 'filler words' and how our ability to speak and explain efficiently develops: http://www.newyorker.com/culture/cultural-comment/conscienti...

good point, if you can't even get to the domain, who cares what the file name is.

Little nitpick - the line linked to is /googleanalytics.js, which I believe in most situations will do absolutely nothing. It's the lines referring to "analytics.js" and "ga.js" that actually matter.

EDIT: For clarification, analytics.js and ga.js are in indeed listed, as are many other analytics services, bugsnag and kissmetrics to name a few.

It is against the terms of service of Google analytics to pass any PII such that you can track an event back to any particular person. On top of that, the code for Google Analytics js is available for your review, along with its network requests, such that you can hold them to their word.

Sounds like an excuse to me.

But, 'ready for production' is a relative term that must be considered in context. Apple is encouraging developers to submit apps with Swift, so clearly they think it's 'ready for production' in some contexts.

If you're building an app for which an obscure, swift-specific bug may cause a critical security or safety issue for your customers then perhaps go with objective-c to sleep better at night. Although my impression is that Swift is stable enough even for this category of apps.

But, I'd wager that vast majority of apps out there do not fall under that category.

I love CyanogenMod (or at least the concept...I'm over dealing with the headache in practice), but the reason I used it was certainly not for improved stability and security.

Not that I particularly trust OEMs/carriers, but the only way I'd feel more secure with CyanogenMod is if I had time to audit the source and build the kernel and OS binaries myself, and that includes whatever code is used to root and unlock your device in the first place. If you do that though, more power to ya.

Also, disabling permissions at runtime is a foolproof way to make an app crash, as the vast majority of apps will assume they're granted the permissions hardcoded in the manifest at compile time.

One last point - rooting your phone and granting apps root access just to disable crucial permissions such as holding a wakelock seems pretty reckless - have you personally seen the source code for that app? At least the dev's website seems legit: http://www.findsdk.com/

EDIT: Even better, looks like the author of App Ops, or at least the owner if the findsdk.com domain, is in China :) https://who.is/whois/findsdk

How about the Bruce Schneier-built Password Safe?

https://www.schneier.com/blog/archives/2014/09/security_of_p...

Although, in addition to being a non-cloud-based option, it seems he only vouches for the original, Windows-compatible version. That said, the Android and iOS versions do seem to be open source, so at least you can build inspect them for yourself.

I'll take it! Good to know.

I was very excited when I saw this headline, as for a while I've hosted various things on s3 and have wanted an easy way to track when/how/by whom those things have been downloaded. Alas, that isn't a supported...I'm looking for something like: "s3:ObjectViewed:Get". Or am I mistaken and that already exists in some other form...?

Doesn't the Gmail app on iOS use a push-system for delivery? Why would you want to use EAS for Gmail? Seems reasonably (and positively Apple-like) for Google to push people into the Gmail app where they control the experience and can surface first-party Gmail paradigms more readily.

Admittedly I'm an Android user with limit experience with stock iOS mail app. Is the iOS mail app really that much better than the Gmail app?