3 ms·
I found this article incredibly naive. A recent stint in ad tech showed just how deep the multi-company coordination and orchestration go. Assuming that linki
by Ensorceled 7y ago
I found this article incredibly naive. A recent stint in ad tech showed just how deep the multi-company coordination and orchestration go. Assuming that linking to Google's fonts or images doesn't expose your users or that Adobe's Typekit isn't part of Adobe's Advertising Cloud seems like putting your head in the sand.
Particularly pollyannish is the author's handwaving Google Analytics away with an "only for counting conversions". Holy Crap!
- ineedasername 7y agoPrecisely. The article seems to take the tone of "All of this stuff isn't really for tracking" when that's not strictly true. Instead, He doesn't use it for tracking, but that doesn't mean the data isn't still generated and used by some of the third parties. Even if I grant him the necessity of doing things this way, as he seems to claim, that just bolsters the argument that invasive tracking is baked in to nearly everything, that you simply can't do business like this without it happening.
- Ensorceled 7y agoThat's an excellent point, the article focuses on stratechery.com intent while not understanding the privacy disaster they are happily participating in.
- TeMPOraL 7y agoAsking to trust him because he don't use it for tracking is much like a kid telling their parents that they want the PC "for education!". Sure, maybe some do.
- Bartweiss 7y ago> Even if I grant him the necessity of doing things this way, as he seems to claim, that just bolsters the argument that invasive tracking is baked in to nearly everything, that you simply can't do business like this without it happening. It's much the same problem as (among other examples) mobile device permissions. Things have improved somewhat, but for years every Android app asked for permissions like "view and edit the files on your device". 99% of the time that was innocuous. Saving a single user setting could require creating and viewing a file. It's easy to see why devs with no good alternative would have been frustrated to hear "hey, why do you want permission to see all my stuff?!" But that didn't make it good or secure. Flashlight apps would get file permissions to save a single setting, then hoover up as much data as they could get with that permission. The problem was precisely that the innocent, 'right' way of using permissions was potentially a channel for abuse. If people object that loading a single font from Typekit is inherently a violation of privacy, maybe they're fundamentalists. But in practice, what I see people point out is that it creates a threat to privacy, that the entire ecosystem of data access in inseparable from the ecosystem of tracking and advertising. And that's absolutely true.
- contextfree 7y agoWhat about desktop apps? Every Win32 app has permissions to view and edit all the user's files and data, arbitrarily snoop on and hook into other processes running as the user, etc. The situation on Mac and Linux for most users is similar, except for sandboxed Mac App Store apps. On Windows there is a modern app model (UWP) that provides for app isolation and more granular permissions but the push to get software moved over to it seems to have stalled.
- Fr0styMatt88 7y agoWith regards to Android apps asking for permissions like "view and edit the files on your device" -- I only recently stumbled into something about this while helping a friend with understanding app submission. There is/was a long-standing bug on Android that as far as I can tell Google never completely fixed (though I might be wrong). For apps that have both an .APK and .OBB file, the Play Store would save the .OBB file to the user's device with the incorrect file owner. This would cause the app to fail (or at least the app wouldn't see the .OBB file already there and would, I think, re-download it). The workaround involved requiring the app developer to ask for this permission, even though their actual app didn't need it, in order to avoid this issue. ANother workaround was to ask users to reboot their phone, since (I think) the permission would be corrected after a reboot (not sure, didn't delve too deeply into that in particular). For those that are unfamiliar - .APK files are the application packages and they're limited in size by the Google Play Store. To get around the size limit, developers can create a larger .OBB file that they could host on Play (I think?) but then have to download. Google then implemented automatic downloading of the .OBB file by the Play Store, but as far as I can tell never got it right. The whole thing seems to be getting superceded by a new format called AAB (Android Application Bundle). See: https://issuetracker.google.com/issues/37544273 https://issuetracker.google.com/issues/37544273 Followed by: https://issuetracker.google.com/issues/37075181 https://issuetracker.google.com/issues/37075181 For some context: https://forum.unity.com/threads/android-app-bundle-how-to-upload-game-larger-than-100-mb.623104/#post-4716944 https://forum.unity.com/threads/android-app-bundle-how-to-up...
- SahAssar 7y agoTypekit, not Typescript. Just thought it'd be good to clarify.
- Ensorceled 7y agoDoh! Thanks, fixed.