[HN Gopher] Is Apple Banning Free Analytics SDKs?
___________________________________________________________________
Is Apple Banning Free Analytics SDKs?
Author : ch_sm
Score : 98 points
Date : 2021-02-10 11:34 UTC (11 hours ago)
(HTM) web link (steamclock.com)
(TXT) w3m dump (steamclock.com)
| ppetty wrote:
| This really seems like an OSS opportunity for someone or some
| organization to create an ad-free analytics SDK for "in app"
| usage & engagement. But I agree with other posts that Apple
| doesn't seem to imply they'll forbid any SDKs ... they're going
| to have an impact, though, on any information gathering & sharing
| that involves PII.
| kall wrote:
| Posthog (https://posthog.com) looks pretty cool in this space
| nerdjon wrote:
| I would not be mad if the Facebook SDK was outright banned, it
| collects way too much data.
|
| But I will take being able to stop them from tracking every time
| I open third party apps even if I don't log in with Facebook.
| Even if I have to be prompted every time I install an app.
|
| But maybe similar too what happened with iOS 14 and the clipboard
| alerts, this will force a change on the App Store and finally
| remove Facebook and Google's stronghold on the web and apps.
| tabs_masterrace wrote:
| For those who have the freedom to decide what to use, I recommend
| looking into rolling your own. Especially if you're writing back-
| end services for your app anyway. After Google shutdown
| Fabric.io, we asked ourselves why even rely on 3rd parties for
| analytics. All we really wanted to know is basic usage
| statistics, like uniques, sessions, events. Turns out to be just
| a few days of work for what amounts to a CRUD service with a
| worker. Small bootstrapped HTML page to view the stats, no pretty
| graphs or anything, just numbers. The client code is around 300
| lines, basically a simple network request queue. For comparison
| the latest libGoogleAnalyticsServices.a comes in at ~35mb (wtf?).
| jrochkind1 wrote:
| It's weird if the policy is you can do whatever you want as
| powerful as you want if you roll your own, but you can't do
| anything no matter how simple if you use a free third-party
| SDK, but... is that what it looks like?
| simonh wrote:
| No sorry, that isn't it at all but it's easy to see how you
| would think so.
|
| You can do whatever tracking you like, however you like using
| whatever SDK you like, as long as you obey basically two
| rules:
|
| * If you are tracking identifiable information you must
| present an opt-in dialog. It doesn't matter if you roll your
| own or use an SDK to do it.
|
| * If you are doing 3rd party tracking, and generally these
| SDKs are designed to do that, you must indicate this in the
| App's privacy information.
|
| Honestly, that's all there is to it. The whole article, and
| the "de-factor ban' narrative being pushed so hard on this
| forum are predicated on the assumption that doing either of
| these things is simply inconceivable. However if you are
| willing to do them, all the restrictions melt away. It's
| really as simple as that. Ask the users and tell them the
| truth. That's all that's being required.
|
| The only complications come if you want to weasel your way
| out of doing these things. That's why the blog post author,
| and the 'de-facto ban' crowd here think this is such a
| fiendishly difficult problem.
| m3kw9 wrote:
| Waiting for a open source GitHub version
| e2021 wrote:
| collecting the data isn't the problem, its the analysis thats
| annoying. ie. this only gets you so far:
|
| > Small bootstrapped HTML page to view the stats, no pretty
| graphs or anything, just numbers.
|
| Maybe I want to see the number of some custom event per week,
| ok, now show me number per session, then break it down by
| country etc etc. I guess you could export the data to some BI
| tool and create a bunch of reports, but that is a bit of a
| hassle, especially since in anything but a very small company
| the people who most want to do this analysis are going to be
| non-technical. Are you going to assign engineering resources to
| sit around making reports full time? Much easier to just use
| google which 1) has all this built in 2) people already know
| how to use
| webmobdev wrote:
| > Maybe I want to see the number of some custom event per
| week, ok, now show me number per session, then break it down
| by country etc etc.
|
| There's this thing called SQL that the oldies used to
| generate such reports ... Jokes apart, I agree with the
| suggestion to build your own analytics, or host one using
| some popular open source analytic software. There is more
| privacy awareness among users now, and sharing your data with
| Google or Microsoft or Facebook is the easiest way to hurt
| your reputation with these individuals. Has everyone forgot
| that webservers still generate their own visitors logs?
| Moreover, if you think the data is important enough to
| collect and analyse, it seems quite foolish to trust a third-
| party with it, especially a free one.
| pianoben wrote:
| Analytics tools like Amplitude give you vastly more and more-
| useful information than just sessions and events. Sure, it's
| one thing to capture events, but fast and easy search and
| segmentation of those events? Building ad-hoc funnels and
| visualizing behavior of cohorts over those funnels? This is
| real and significant value.
|
| There's a reason that there are profitable companies dedicated
| to building stuff like this. It's really hard to get right in a
| scalable way.
|
| Unless you're already a multi-billion dollar corp (and how did
| you get that big without analytics), it's a no-brainer - this
| is something to buy, not to build.
| dubcanada wrote:
| While I do agree, this stuff is vastly more complex then just
| what the OP said.
|
| But funnels are nothing more then how many people did Y after
| X.
|
| If you record everything (say every single web request) you
| could easily do a query to find out that type of data and
| shove it in a table.
| alexdean wrote:
| Agree, building this in 2021 is not a good use of data
| engineering time.
|
| As well as the SaaS packages like Amplitude and Mixpanel, you
| also have great open-source tools and platforms for mobile
| and product analytics like PostHog (https://posthog.com/),
| Countly (https://count.ly/) and Snowplow
| (https://snowplowanalytics.com/).
|
| Disclosure: Snowplow co-founder.
| johnchristopher wrote:
| I regularly see a lot of GA analytics on HN.
|
| How does your solution compare to Matomo ? I feel the
| interface is extremely dated and not intuitive but that
| just might be me.
|
| Why is Matomo so rarely cited ?
| waynesonfire wrote:
| cofounder of analytics company says it's not worth building
| an analytics solution.
|
| I welcome the competition.
| ohreallysteve wrote:
| From my understanding, the iOS permission to track prompt is only
| if your app uses user device data for the purpose of targeted
| advertising by accessing the IDFA. There shouldn't be a problem
| if you disable the collection of IDFA and you can configure
| exactly that via Firebase Google Analytics [1]. I don't see a
| whole sale banning of free analytics SDKs but I do see a positive
| shift in forcing developers to have more awareness about what
| data is collected and what it is used for.
|
| Edit: Per Apple's definitions of tracking, it also includes
| sharing user or device data with data brokers.[2]
|
| [1]https://firebase.google.com/docs/analytics/configure-data-
| co...
|
| [2]https://developer.apple.com/app-store/user-privacy-and-
| data-...
| Aaargh20318 wrote:
| > the iOS permission to track prompt is only if your app uses
| user device data for the purpose of targeted advertising by
| accessing the IDFA.
|
| And that shouldn't be an issue for analytics anyway because
| using the IDFA for anything other than advertising has always
| been prohibited. IIRC Apple checks if your app accesses this
| value and your app will be rejected if your app does and not
| contain any ads.
| Reason077 wrote:
| > _" There shouldn't be a problem if you disable the collection
| of IDFA"_
|
| Exactly. I hope this is true as this is exactly what I'm
| planning to do.
| K0nserv wrote:
| If you stop collecting IDFA and don't replace it with some
| other device identifier you are fine. If you create a new
| identifier i.e. some sort of fingerprinting you still needs
| user consent for that via the AppTransparency framework.
| kruuuder wrote:
| Apple says "you'll need to receive the user's permission
| through the AppTrackingTransparency framework to track them
| or access their device's advertising identifier". So if the
| SDK uses any information at all (e.g. the IP address) to
| track the user, you need the user's permission.
|
| Do you think Google will do some kind of tracking with the
| user's IP address? I'd bet on "Yes".
| nulbyte wrote:
| Apple defines tracking to mean something specific:
|
| > Tracking refers to the act of linking user or device data
| collected from your app with user or device data collected
| from other companies' apps, websites, or offline properties
| for targeted advertising or advertising measurement
| purposes.
|
| How will Apple enforce this? You can, for example, turn off
| data sharing in Google Analytics to disallow Google to use
| the data you collect for their own advertising purposes.
| jrochkind1 wrote:
| > iOS apps currently using the Google Analytics, Flurry, and
| Firebase SDKs may need to migrate off of them promptly
|
| I don't develop in this space, but... Firebase is considered an
| analytics/tracking API? What happened?
| Kimmo_Hintikka wrote:
| Well google bought them years back and while I think main use
| of firebase is still realtime data and authentication there are
| more and more people loading firebase analytics as well.
|
| Still I dont understand discussion that these would be banned
| they are still different binaries for different service
| allthough for super lazy people there is this one mega binary
| loading the "whole firebase"
| apike wrote:
| Firebase includes a wide umbrella of services, which include
| what used to be Fabric Analytics and Crashlytics. From Apple's
| perspective, sharing data with these services may count as
| "sharing data with entities who display third-party ads" since
| Google owns the service, and Google displays ads. Or maybe not.
| theshrike79 wrote:
| Betteridge's Law at work again [1]
|
| But, putting "Apple Banning XXX" in a headline is a sure-fire way
| to get clicks, so...
|
| [1]
| https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
| gowld wrote:
| Where's the "ban"? OP us quoting Apple policy as requiring user
| opt-in to tracking analytics.
| maccard wrote:
| This is a bit of a stretch - the gist is that Apple is requiring
| opt-in consent to 3rd party tracking, and will start failing
| review for people apps that don't provide an opt in.
|
| This isn't a ban on Free analyics SDKs at all.
| akmarinov wrote:
| It's not a ban, but since all these 3rd party tracking
| platforms use the user's data to power ads, you have to show
| the opt in, which of course people will say no to, leading to
| the SDKs being mostly useless in your binary.
|
| Compare that to Mixpanel for example, where they don't power
| ads, you can skip showing the opt in and have a useful
| analytics SDK.
|
| Effectively the free SDKs need the data to make money for their
| owners, the opt in kills that and it might as well be a ban.
| cassianoleal wrote:
| > Compare that to Mixpanel for example, where they don't
| power ads, you can skip showing the opt in
|
| Is this really the only criterion for requiring an opt-in?
| Tracking is bad for many other reasons other than selling
| targeted ads.
| tinus_hn wrote:
| Why do these SDKs 'need the data to make money for their
| owners'?
| simonh wrote:
| The owners provide the SDKs for free, the only value they
| get from them is the analytics data.
| tinus_hn wrote:
| That depends on how creative you are. They could sell
| support for their SDK, exploit network effects, gain
| exposure and developer mindshare, or, you know, just
| provide something to the community for free with no
| strings attached.
| simonh wrote:
| None of that changes the fact of how they use these SDKs
| are intended to get value at the moment.
| Viliam1234 wrote:
| > you have to show the opt in, which of course people will
| say no to
|
| Oh no, people are allowed to decide what their computers do,
| instead of being spied on without knowing. The horror!
|
| What's next, people being allowed to uninstall the app?
|
| Seriously, if your business model depends on doing things the
| user is not aware of and wouldn't agree with, you deserve to
| fail.
| Pet_Ant wrote:
| > Effectively the free SDKs need the data to make money for
| their owners, the opt in kills that and it might as well be a
| ban.
|
| It's not a ban on the usage of SDKs, what it is, is a "ban"
| on their business model, and if you don't provide enough
| value to users for them to pay for then it's a "ban" on your
| business model. Basically, it just means that your service is
| asking too high a price (the user's privacy) for the market
| bear. This is only giving user's agency and insight and after
| that the market functioning as intended.
| laurent92 wrote:
| But he's not allowed to withdraw the service if customers
| don't agree. Therefore his business model, which was an
| exchange (not even taking users' data, only displaying
| relevant ads), is required to become a donation from him to
| a good share of his customers, if he wants to keep the
| other ones who agree to advertising tracking.
| snowwrestler wrote:
| The goal is to shift the ad industry away from intrusive
| tracking, not to ban ads as a business model.
|
| The answer will be to show ads that are made relevant
| using signals other than collecting personal data. I get
| that the digital ad industry is not set up well to do
| that now, but the idea is to force them to adapt. They
| will have to eventually if major applications of personal
| data are closed to them by changes like Apple's.
| threeseed wrote:
| And also moving to everything being explicit.
|
| Many of us are actually okay with first-party data
| collection. But it is ridiculous how user data is being
| packaged and sold to so many faceless third parties whose
| you don't know and whose policies are not clear.
| simonh wrote:
| Displaying relevant ads requires taking users' data, and
| there's no way to know if that data is also used for
| other purposes, which it almost always is.
|
| Yes this makes some business models harder.
| madeofpalk wrote:
| Who is "he"? I lost who we are talking about here...
| simonh wrote:
| It really isn't a ban though, not in any sense. It's simply a
| requirement to ask for opt-in. Apple is making no decision
| about the use of IDFA, they are simply allowing users to make
| that decision. The truth is users are against this behaviour,
| but Facebook, Google, and the author of that blog don't like
| to face up to that fact, so they will assiduously blame Apple
| for this not the people actually making the decision to cut
| them out - users.
| lapcatsoftware wrote:
| > the author of that blog don't like to face up to that
| fact, so they will assiduously blame Apple for this
|
| Could you please quote the relevant section of the article
| you're referring to?
|
| If it's just "the article title", that seems to be quite a
| stretch to me.
| simonh wrote:
| Sure, fourth paragraph:
|
| "Apple is also enacting a de-facto ban on these free
| analytics SDKs. The setup looks like this:"
| lapcatsoftware wrote:
| Is it accurate to say that your only evidence that this
| article constitutes "Apple bashing" is the word "ban"?
|
| If so, that seems hypersensitive and defensive IMO.
|
| A "de facto ban" is not a "de jure ban", so it's already
| a pretty weak statement.
| threeseed wrote:
| It's not a de-facto ban either. In fact it's not a ban.
| Period.
|
| Advertisers could invest time and money in explaining to
| users what their data is being used for and the benefits
| it brings. Making it seem like Apple is preventing
| analytics by simply asking users what they want is
| disingenuous at best.
| lapcatsoftware wrote:
| Eddie Izzard: "I'm simply asking people, cake or death?
| It's disingenuous to suggest that this is a loaded
| question. After all, people _could_ choose death. I 'm
| only presenting the options."
| simonh wrote:
| Yes a choice is being made. Yes it's killing scummy
| tracking behaviour. It's the users making the choice
| though, not Apple.
| Spivak wrote:
| I like how strongly people seem to be reacting to having
| to ask permission to digitally follow someone around,
| write down everything they do, and then use it to send
| them ads. Guess that means the new rule isn't toothless
| after all.
| lapcatsoftware wrote:
| > I like how strongly people seem to be reacting to
| having to ask permission to digitally follow someone
| around
|
| I don't have any analytics whatsoever in my apps.
|
| When I make the "cake or death?" analogy, do you
| seriously believe I'm defending the "death" option?
|
| But if we continue with this analogy, it's important to
| remember that Apple has been allowing "death" in its App
| Store for 12 years and is only now getting around to
| asking users whether they want death. Moreover, the App
| Store "race to the bottom" intentionally undermined the
| previous business model of selling upfront paid software.
| App Store devalued software and propped up the
| alternative of making everything free and turning
| customers into products. Apple has a lot of "blood" on
| its hands in this matter.
|
| I personally install Little Snitch on my Mac to block
| apps from phoning home. Yet Apple doesn't allow a similar
| tool on iOS. So I don't buy Apple's "privacy" BS for one
| second, because they don't allow me to protect my own
| privacy.
| simonh wrote:
| Then why are you complaining about them implementing
| privacy controls?
| ed25519FUUU wrote:
| > _Apple announced last summer that they will soon require users
| to opt in before apps can get the infamous "IDFA" tracking
| identifier for that user._
|
| I absolutely LOVE that apple is slowly turning the screws on
| advertisers with these pro-privacy moves. It's been slow and
| incremental, but also increasingly hostile towards people and
| services that attempt to identify and market to end-users.
| fmajid wrote:
| It's a red herring. In addition to the IDFA, Apple has something
| called the IDFV (identifierForVendor). This ID is unique to a
| publisher, i.e. if a user has 3 of your apps installed, all three
| will share the same IDFV, so you can even do cross-app or cross-
| selling analytics. What you cannot do by design is use IDFV to
| build a cross-publisher dossier on users, or target users based
| on that ID other than on your own apps.
|
| Apple hasn't put any restrictions on IDFV, only on IDFA, which
| was designed, well, for advertising and needs to be reined-in due
| to abuses in the Wild West everything goes world of the AdTech
| surveillance-industrial complex. In fact the existing opt-out
| "Limit Ad Tracking" setting that already implements what will
| become opt-in with iOS 14.5 does not apply to IDFVs.
|
| Back in 2010 Steve Jobs himself had banned analytics altogether
| when Flurry's VP of Marketing blabbed and disclosed the existence
| of the then secret iPad:
|
| https://venturebeat.com/2010/06/02/apple-flurry-ipad/
| apike wrote:
| Yes, but - Apple's documentation says that the upcoming opt-in
| requirement is for more than for IDFA-based tracking.
| https://developer.apple.com/app-store/user-privacy-and-data-...
|
| According to Apple, the opt-in API is also required for other
| activities, including:
|
| > Placing a third-party SDK in your app that combines user data
| from your app with user data from other developers' apps to
| target advertising or measure advertising efficiency, _even if
| you don't use the SDK for these purposes_. For example, using
| an analytics SDK that repurposes the data it collects from your
| app to enable targeted advertising in other developers' apps.
|
| So as a developer, you need to ask: even though we don't use
| IDFA, is this analytics SDK repurposing our data to fingerprint
| and target our users? Certainly for the default setups of these
| adtech-backed free analytics SDKs the answer is "presumably
| yes?". But we don't yet have a clear answer from Apple or the
| vendors as to what _exactly_ will trigger an App Review
| rejection here, and what _exactly_ the SDKs do with the data
| they receive in different circumstances.
|
| Hence the uncertainty.
| Spivak wrote:
| The world where people are just dropping huge opaque blobs of
| code into their own apps that betray your users privacy,
| probably, we didn't actually check, is awful. How is the
| person releasing the app not ultimately responsible for every
| line of code in it?
| stationfrocks wrote:
| The question is: will it be possible to use facebook and firebase
| sdk's without the opt-in consent, provided that no use of the
| idfa is made? My understanding is that as long as the opt-in
| popup isn't shown, the device won't allow access to the idfa, and
| as such the sdk you're using does not matter. Both facebook and
| firebase's sdks seem to have fallbacks in place for when the idfa
| is not available.
|
| This is to be taken with a grain of salt, and I'd love to see
| somebody more savvy on the matter confirm this...
| swiley wrote:
| I would have been happy if facebook's stuff weren't usable by
| iOS developers without at least something user visible. I
| already gave up on the platform and switched to something sane
| though.
| m_eiman wrote:
| I suppose it's not just the idfa, it's any personal information
| you share with third parties.
| Nextgrid wrote:
| Something as simple as an IP address is considered personal
| data in Europe, and something that can uniquely identify a
| user with a reasonable degree of accuracy (device
| fingerprint, which Facebook does collect) would also be
| included.
| graftak wrote:
| Yes it will technically be possible but at the same be a
| violation of the App Store guidelines, meaning it will likely
| lead to a ban.
| djrogers wrote:
| From Apple: "you'll need to receive the user's permission
| through the AppTrackingTransparency framework to track them or
| access their device's advertising identifier".
|
| _OR_ access IDFA being the key there. If you can 't honestly
| and easily answer the question "does this 3rd party SDK track
| my users?" then you probably should not be using it.
| waynesonfire wrote:
| This is great news for users and platforms that don't abuse user
| data.
| random5634 wrote:
| Always the same apple bashing for doing what their users would or
| will probably like
| lapcatsoftware wrote:
| Where do you see Apple bashing in the article? It was an
| article targeted at app developers, offering them advice on how
| to adapt to the new rules.
| simonh wrote:
| The Apple bashing is in the title and in the text, calling
| this a "def-facto ban" by Apple. No it's not, it's giving the
| option to the users. The fact that users generally abhor and
| detest this sort of tracking and want nothing to do with it
| is hardly Apple's fault.
| lapcatsoftware wrote:
| If, as you say, the preference of users is obvious and
| predictable, and Apple gives an option to users with a
| completely predictable outcome that will prevent analytics
| SDKs from being viable, then I think it's fair to say that
| this is a de facto ban.
|
| Whether that's good or bad is a subject for separate
| debate. But the main question of the article is whether
| developers can still use these SDKs, and the author
| speculates that it will no longer be possible for
| developers to use them. That sounds like a de facto ban to
| me. Again, I'm not even commenting whether that's good or
| bad.
|
| If you read other comments here, some people would be very
| happy with an outright explicit ban. Are they "Apple
| bashing"? No, of course not. I still don't see how talking
| about a de facto ban is bashing, it's just a natural
| consequence of the iOS changes, at least according to the
| article author.
| simonh wrote:
| "But the main question of the article is whether
| developers can still use these SDKs, and the author
| speculates that it will no longer be possible for
| developers to use them."
|
| OMG. I can't believe you just wrote that, you're just
| proving my case for me.
|
| Yes, developers will be able to use whatever SDKs they
| like, Apple won't lift a finger to stop them, in fact
| it's extremely simple for developers to use those SDKs.
| Not impossible at all. All they will have to do is
| indicate third party tracking in the App description and
| present an opt-in dialog.
|
| But apparently, this option of letting users decide
| appears to be literally inconceivable. Under the new
| rules "...it will no longer be possible to use them". No
| rhetorical device is too contrived to direct the
| responsibility to Apple rather than the people actually
| choosing not to enable tracking - users.
| lapcatsoftware wrote:
| From the article: "In the coming weeks, iOS 14.5 will
| require apps that engage in "3rd Party Tracking" to ask
| explicit permission, which most users will opt out of."
|
| If most users opt out, then an analytics SDK becomes
| effectively useless. You're ranting about the
| _possibility_ of using an analytics SDK - which nobody is
| denying, because it 's a "de facto" ban, not a "de jure"
| ban. But an analytics SDK that gathers almost no
| analytics is not even worth having. So in effect, it's a
| ban.
|
| > All they will have to do is indicate third party
| tracking in the App description and present an opt-in
| dialog.
|
| Oh, that's all. And then get no analytics. But they can
| still "use" the analytics SDK... to do nothing.
|
| You know, I don't even have any analytics whatsoever in
| my apps. I have no horse in this race. But I've got no
| problem with the phrase "de facto ban". It seems like a
| reasonable description of the situation. And again, some
| people would love a de jure ban, so it's not like the
| author of the article is using a "naughty" word.
| sofixa wrote:
| In the same way that people bash the EU for cookie banners,
| people will bash Apple for extra work on both sides (
| developer and user) to comply with new, better rules around
| privacy.
| jeroenhd wrote:
| I strongly dislike Apple's business practices, the vendor lock-
| in they continue to create and the way they design their
| software and hardware, but this is undoubtedly a move in the
| right direction.
|
| As a user, I want to have the option to globally disable all
| tracking. Random advertiser IDs every time one is requested, no
| sharing of vendor IDs, just quit it. Gather your statistics
| from people who don't care about privacy or people too tech-
| illiterate to disable the checkbox, but don't force your
| terrible tracking down the customer's throat. Or rather,
| disable the tracking by default, make it opt-in per app. If
| your app is crap but useful enough, people will want to improve
| it.
|
| Now, if Apple did that, all the Silicon Valley startups around
| app optimisation would cry foul, Facebook and Google would sue
| Apple and there'd be a massive PR campaign against Apple, so
| they can't do ever what I'd like them to do.
|
| Lots of developers seem to act as if they have a god-given
| right to track people to gather analytics rather than doing
| some costly end-user research. These were probably the same
| developers who proclaimed that the GDPR would end all computing
| as we know it because now they have the legal obligation to
| care about their customers' privacy.
___________________________________________________________________
(page generated 2021-02-10 23:03 UTC)