Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96)

@adamroach 
> [...] the execution environment I'm proposing is identical to the execution environment PAC files run in: no network access and a unique origin. This has been implemented in browsers for decades.

While it *has* been implemented in browsers for decades, a quick google search for "pac file attack" makes me doubt that this is proof that it works, security-wise. On the first page, I get the following hits:

- [Attacks on HTTPS via malicious PAC files](https://www.contextis.com/resources/blog/attacks-https-malicious-pac-files/)
- [Example of Targeted Attack Through a Proxy PAC File](https://isc.sans.edu/diary/Example%2Bof%2BTargeted%2BAttack%2BThrough%2Ba%2BProxy%2BPAC%2BFile/21405)
- [Attackers Using Malicious PAC Files in Phishing Attacks](https://threatpost.com/attackers-using-malicious-pac-files-phishing-attacks-041410/73827/)
- [New attack bypasses HTTPS protection on Macs, Windows, and Linux](https://arstechnica.com/security/2016/07/new-attack-that-cripples-https-crypto-works-on-macs-windows-and-linux/)
- [How to check for malicious Proxy Auto-Config files in Windows](http://www.ghacks.net/2014/03/14/check-malicious-proxy-auto-config-files-windows/)
- etc, etc...

Further reading on the subject suggests that the way to stay secure w.r.t. PAC files boils down to "for god's sake, don't let PAC files from a non-trusted source onto your system", rather than "don't worry, the browser's sandbox will keep you safe". Do we think we can make our function more secure than this? My gut feeling says that it's not possible to do this in a way that's absolutely and demonstrably bulletproof.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-275353662