WebMIDI usage is missed due to obfuscated function call

[bgrins]

I wanted to share something I came across digging into data from https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2022/capabilities/fugu.sql

https://shopee.co.th/shopeeth loads a script https://deo.shopeemobile.com/shopee/web-sdk/js/live/613832263d29374ef4cd566434d8f268cb15367d.js with the following:

var fD=fC[yO(0x3c4,'QQOo')+'or'][yN(0x95b,'qQOo')+'MIDIAcc'+yN(0x318,'QqQQ')]()

Which is turning into a call to navigator.requestMIDIAccess() at runtime. Obviously this is missed from the check of /navigator\.requestMIDIAccess\s*\(/g, at

custom-metrics/dist/fugu-apis.js

Lines 149 to 156 in 0cf4937

	'WebMIDI': {
	regEx: /navigator\.requestMIDIAccess\s*\(/g,
	where: 'JavaScript',
	supported: (async () => 'requestMIDIAccess' in navigator)(),
	featureDetection: `(async () => 'requestMIDIAccess' in navigator)()`,
	documentation:
	'https://developer.mozilla.org/en-US/docs/Web/API/Web_MIDI_API',
	blinkFeatureID: 2029,

I think this might just be a fundamentally unfixable problem, but I thought I'd raise it to see if anyone had ideas on how to better detect sites using these types of APIs at runtime in a way that would result in fewer false negatives in the custom metric.

[pmeenan]

Do the blink feature usage counters catch the webMIDI usage? If so, that may be another way to get it in the existing data without the need for a custom metric or detecting cases like this.

…

On Tue, Oct 18, 2022 at 6:40 PM Brian Grinstead ***@***.***> wrote: I wanted to share something I came across digging into data from https://github.com/HTTPArchive/almanac.httparchive.org/blob/main/sql/2022/capabilities/fugu.sql https://shopee.co.th/shopeeth loads a script https://deo.shopeemobile.com/shopee/web-sdk/js/live/613832263d29374ef4cd566434d8f268cb15367d.js with the following: var fD=fC[yO(0x3c4,'QQOo')+'or'][yN(0x95b,'qQOo')+'MIDIAcc'+yN(0x318,'QqQQ')]() Which is turning into a call to navigator.requestMIDIAccess() at runtime. Obviously this is missed from the check of /navigator\.requestMIDIAccess\s*\(/g, at https://github.com/HTTPArchive/custom-metrics/blob/0cf4937507e926382050d88dcece4723d1f13448/dist/fugu-apis.js#L149-L156 I think this might just be a fundamentally unfixable problem, but I thought I'd raise it to see if anyone had ideas on how to better detect sites using these types of APIs at runtime in a way that would result in fewer false negatives in the custom metric. — Reply to this email directly, view it on GitHub <#53>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADMOBMGXWJJBALHHLBJQQDWD4RO7ANCNFSM6AAAAAARIRHZPI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bgrins]

I don’t know the answer but that’s an interesting idea and would certainly be more accurate. Separately: I didn’t realize that webpagetest had a way to ingest usage counters after a page is loaded. That seems useful and I’d be interested in exposing this type of diagnostic information to the API from Firefox as well (if we don’t already do it).

[tomayac]

Hi @bgrins, @tomayac here, author of the detector script from your initial comment. Obfuscated code is indeed a problem, and there's no solution unfortunately. What @pmeenan suggests might work for your use case, this is the UseCounter for opening a MIDI port, which correlates well with actual usage: https://chromestatus.com/metrics/feature/timeline/popularity/2029.

[rviscomi]

We've started implementing a solution that adds observers to a set of global objects. So regardless of any obfuscation in the source code, we'd be able to detect that a given function was called or property accessed. We could even log the arguments and call stack.

We had to disable it due to edge cases that caused pages not to load properly, but I'd love to revisit that idea. It'd help with this use case of tracking Fugu API usage. I've filed #54 to track this.