Replies: 7 comments 24 replies
-
Email login spoofing is probably not very effective to protect PII as the ABC apk has analytics SDKs and plugins from Facebook, Nielsen, Oztam, Tealium, Snowplow, Youbora and Gigya. These all have their own get device ID / advert ID / user ID routines. ie "Youbora collects data about your viewers as they interact with your videos and more detail about them through your other connected marketing channels." |
Beta Was this translation helpful? Give feedback.
-
So on the browser I think we have two distinct issues:
I assume (1) has generic solutions (though probably only somewhat-successful ones). It occurs to me that I am making (2) much harder than it needs to be - you don't have to actually watch the shows (not even via your browser when you're not actually watching), you just have to intercept the json upload and modify it, right? I wonder how hard that is. |
Beta Was this translation helpful? Give feedback.
-
Also, google search for iview,then click the first result (Ad) creates this server captured url : |
Beta Was this translation helpful? Give feedback.
-
I'd ask someone to check on iOS with all the new Privacy features. To see what you can prevent. Of course if have to login they still get a lot. |
Beta Was this translation helpful? Give feedback.
-
I don't think "restreaming" is an issue. As long as the playlists are able to be served cross-origin, then you can watch shows on iview outside of iview, tracker and account free. If playlists return a 403 if a user is not logged in, then an access token must be provided, either in a query string or through a cookie. I can hack together a Node implementation of this today or tomorrow and link it here. |
Beta Was this translation helpful? Give feedback.
-
SBS on demand content does not require a login to access the content (which is also not locked behind DRM like WideVine): |
Beta Was this translation helpful? Give feedback.
-
On the android iview app there is this package au.net.abc.seesawsdk The URL for datasets is https://api.seesaw.abc.net.au/v2/dataset/profile and the profile dataset contains : There are currently 12 trackers in their app, all with access to the same basic info and more, especially device info. |
Beta Was this translation helpful? Give feedback.
-
The scientific literature on data privacy is full of options for deliberate obfuscation in situations like these.
Ad nauseam by Howe and Nissenbaum is my favourite example, but there are many.
Like anything else in security and privacy, it depends a lot on your attacker model and security goals. It's not hard to obstruct a naive data-collection algorithm, but it's hard to defeat a determined attacker without getting your clever plugin blocked.
So here are some imperfect-but-worth-trying examples of non-cooperation that have been suggested to me for dealing with the ABC's data gathering.
Obviously, this doesn't help against an adversary who looks up the bugmenot page and cancels those accounts. It's also not clear whether multiple people can use the same account at the same time.
Obviously, this doesn't help against an adversary who ignores the +string suffix when testing whether the email address has been used before. Also, you probably still have to go in to your email and click on the setup link, so it's not fully automated.
These two options could be combined of course: generate a series of +a, +b, ... accounts using a burner email address, then share them on bugmenot.
Any suggestions for improvements, or alternatives that are more robust, are most welcome. Please add them to the discussion here.
Beta Was this translation helpful? Give feedback.
All reactions