Non-cooperation options

[vteague]

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.

1. Share logins, perhaps through a pre-existing service such as bugmenot (no idea why they don't have TLS turned on).

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.

2. Automate the process of generating a new account with each view, perhaps via a browser extension (this was suggested by @eleanor-em). Use the '+' convention so you don't actually need a new email account each time - you just generate a new account with [email protected], then [email protected] and so on…

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.

[ghost]

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."

[vteague]

Can you explain AOSP and FDroid? (not familiar, sorry.)

[ghost]

On the browser you would need to block :
google tag manager gtm.js
gigya.js
https://deliver.oztam.com.au/api/meter

and youbora:
https://a-fds.youborafds01.com/data?outputformat=json&system=abcprod&pluginVersion=6.7.6-adapterless-js&requestNumber=0.4691385882342549&timemark=1621917917122

oh and a part of jwplayer:
jwplayer.js: GET https://ssl.p.jwpcdn.com/player/v/8.10.3/jwpsrv.js net::ERR_BLOCKED_BY_CLIENT

use case: Vivaldi browser, full default privacy settings + plugins uBlock origin, Privacy Badger and NoScript currently blocks all ad-tech listed and Four Corners episode plays.

[ghost]

Android Open Source Project = basic, open source android OS ROM, ie LineageOS, no google apps at all.
F-Droid is the open source privacy respecting android app store

[vteague]

Any idea why Firefox blocks some but not all versions of gtm.js?

[ghost]

possibly due to firefox allowing what it thinks are necessary scripts for website functions, see: https://blog.mozilla.org/security/2021/03/23/introducing-smartblock/

this is why i use multiple other plugins

[vteague]

So on the browser I think we have two distinct issues:

1. generic (third party) trackers
2. the specific js for uploading what you've watched (as per @wabzqem 's json screenshot).

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.

[ghost]

1. can be blocked by a proper browser with necessary plugins. Behaviour depends on ABC domains when scripts fail to load or timeout.
2. jwplayer requires continuous timestamping as video files are streamed in mp4 segments. It should still function without the ad-tech garbage.

[vteague]

Hm. So I guess that upload about the things you have actually watched is therefore unavoidable. Which brings me back to an adnauseam-inspired plugin that pretends to watch other things too. Not ideal, but at least somewhat obscuring. I wonder if it's possible to do so without actually downloading the videos?

[ghost]

Also, google search for iview,then click the first result (Ad) creates this server captured url :
https://iview.abc.net.au/?&WT.srch=1&WT.mc_id=Corp_TV%7cAdWords:%2Babc%20%2Biview_b_g_339709145936_&gclid=EAIaIQobChMIy7X87ZTm8AIVRJVLBR0cfQOkEAAYASAAEgKBRvD_BwE&gclsrc=aw.ds

[trissylegs]

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.

[vteague]

Good idea - at the moment I haven't looked at the app at all, but I too would be very interested to know how it sits with Apple's privacy regime.

[king-millez]

My tweet

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.

The app

[king-millez]

Working on this at the moment, even the search bar on iView is riddled with analytics:

{
	"requests": [
		{
			"indexName": "ABC_production_iview_web",
			"params": "highlightPreTag=%3Cais-highlight-0000000000%3E&highlightPostTag=%3C%2Fais-highlight-0000000000%3E&getRankingInfo=true&clickAnalytics=true&analytics=true&userToken=anonymous-60451354-4525-401b-9a54-3e18fa480cd5&facetFilters=playable%3A%20-false&query=s&facets=%5B%5D&tagFilters="
		},
		{
			"indexName": "ABC_production_iview_web",
			"params": "highlightPreTag=%3Cais-highlight-0000000000%3E&highlightPostTag=%3C%2Fais-highlight-0000000000%3E&getRankingInfo=true&clickAnalytics=true&analytics=true&userToken=anonymous-60451354-4525-401b-9a54-3e18fa480cd5&facetFilters=playable%3A%20-false&query=s&hitsPerPage=6&filters=docType%3A%20category%20OR%20docType%3A%20channel&ruleContexts=iview_categories&facets=%5B%5D&tagFilters="
		},
		{
			"indexName": "ABC_production_iview_web",
			"params": "highlightPreTag=%3Cais-highlight-0000000000%3E&highlightPostTag=%3C%2Fais-highlight-0000000000%3E&getRankingInfo=true&clickAnalytics=true&analytics=true&userToken=anonymous-60451354-4525-401b-9a54-3e18fa480cd5&facetFilters=playable%3A%20-false&query=s&hitsPerPage=8&filters=docType%3A%20Program&ruleContexts=iview_programs&page=0&facets=%5B%5D&tagFilters="
		},
		{
			"indexName": "ABC_production_iview_web",
			"params": "highlightPreTag=%3Cais-highlight-0000000000%3E&highlightPostTag=%3C%2Fais-highlight-0000000000%3E&getRankingInfo=true&clickAnalytics=true&analytics=true&userToken=anonymous-60451354-4525-401b-9a54-3e18fa480cd5&facetFilters=playable%3A%20-false&query=s&hitsPerPage=8&filters=docType%3A%20VideoEpisode%20AND%20NOT%20subType%3A%20feature%20AND%20NOT%20subType%3A%20livestream&ruleContexts=iview_episodes&page=0&facets=%5B%5D&tagFilters="
		}
	]
}

This is just for searching the char "s"

[king-millez]

Luckily, you can remove all trackers and it works perfectly fine:

{
        "requests": [
            {
                "indexName": "ABC_production_iview_web",
                "params": "query=doctor who or something"
            }
        ]
    }

[king-millez]

Interestingly, the search response includes the m3u8 playlists for shows.

[king-millez]

Well it works

[king-millez]

SBS on demand content does not require a login to access the content (which is also not locked behind DRM like WideVine):
https://github.com/yt-dlp/yt-dlp/blob/master/yt_dlp/extractor/sbs.py

[ghost]

aight, rolled your node app into an apk and it works. not really sure what to do with it now. will make a release for it at least, but i doubt its going to end up on fdroid until we see what is happening with the logins. also its currently a real low brow app, no proper ui checks etc. min API 22 ;)
https://github.com/kaputnikGo/AndIViewProxy

[vteague]

This looks terrific @king-millez and @kaputnikGo !

I think you might have independently rediscovered the same idea as youtube-dl
I haven't tried it myself but the idea looks very much the same - thanks to @chrisculnane for pointing it out. It claims to support ABC iview in its list of supported sites but of course I'm not sure that will survive past the imposition of compulsory logins. (But perhaps it won't matter.)

[king-millez]

I think you might have independently rediscovered the same idea as youtube-dl

Sort of, I use youtube-dl regularly. The difference is streaming vs archiving, in my case, this app allows direct searching and streaming of iview content, whereas yt-dl is mainly for downloading and storing content.

[vteague]

Huh, terrific, thanks for the clarification. Both are useful, but I agree streaming is a nice feature for those of us not organised in advance.

Great work on the app @king-millez

[king-millez]

Thank you! It looks a bit trash at the moment so give me a day or 2 to review the latest pull request and make styling changes. Then we play the waiting game.

[ghost]

On the android iview app there is this package au.net.abc.seesawsdk
which seems to be an ABC in-house analytics SDK for user profile and video tracking separate to the embedded corporate trackers and duplicating the most basic privacy concerns.

The URL for datasets is https://api.seesaw.abc.net.au/v2/dataset/profile

and the profile dataset contains :
avatar
avatarAccessibilityText
avatarId
birthYear
channelFilter
displayName
isChild

There are currently 12 trackers in their app, all with access to the same basic info and more, especially device info.
The latest Exodus Privacy report is here:
https://reports.exodus-privacy.eu.org/en/reports/182856/