3 ms·
We will work diligently today to find a way to say something in our app store descriptions in terms of a better disclosure -- will likely have something up by t
by yegg 4y ago
We will work diligently today to find a way to say something in our app store descriptions in terms of a better disclosure -- will likely have something up by the end of the day.
In terms of our app and multi-pronged protection, it isn't mumbo jumbo. Our app is way more than just a browser (and increasingly so). For example, the app tracking protection mentioned for Android blocks trackers in all your other apps. The email tracking protection blocks trackers in your email (that you read in your regular email client/app).
I understand the concern here that we are working to address in a variety of ways, but to be clear no app will provide 100% protection for a variety of reasons, and the scripts in question here do currently have significant protection on them in our browser. From the comment "That is, the privacy thing most people talk about on the web (blocking 3rd party cookies) applies here to MSFT. We also have a lot of other web protections that also apply to MSFT-owned properties as well, e.g., GPC, first-party cookie expiration, fingerprinting protection, referrer header trimming, cookie consent handling, fire button data clearing, etc."
- colechristensen 4y ago"multi-pronged privacy", "easy button", "capabilities", and repeated use of the word "protection" are all signals that what is being said is an attempt to sell me something and that the salesman should be doubted. What's actually happening is you're forced to allow Microsoft scripts which do indeed do telemetry on users despite some restrictions you put on them, and they're still effective because fingerprinting works. That fact is embarrassing for a product you're trying to sell as promoting privacy so there's this mildly deceptive attempt to hide what's going on with lots of words and claims of protection instead of straightforward disclosure.
- thrwawy283 4y agoStill coming to my own conclusion here, but I wouldn't dismiss "easy button" as marketing. We keep hoping for easy buttons and reasonable default settings in things like openssl or pgp. I do like organizations that understand an easy button is the safest default. Is that what we have here?
- colechristensen 4y agoI'm commenting only on the rhetoric, calling it an "easy button" stinks of marketing BS. People desiring simple straightforward tools is a separate subject.
- leokennis 4y agoOf course it’s marketing. My mom doesn’t want to set up uBlock and a script blocker and a Pihole. She’d love to click a button and be safer. What’s the issue here?
- colechristensen 4y agoThat I am on HN and someone trying to convince me their company isn't being shady is using evasive marketing speak instead of candor to an audience that clearly knows better than to believe the weasel words.
- xchip 4y agoWe have a new marketing word: "multi-pronged protection"
- FabHK 4y ago"Defense in depth" strikes me as a legitimate security technique. https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/defense-in-depth https://www.cisa.gov/uscert/bsi/articles/knowledge/principle...
- tedivm 4y agoThe thread by the security engineer shows that the scripts are communicating back to the servers. That means your multi-pronged protection has failed, unless you've suddenly discovered a way for browsers to block IP addresses from being sent by scripts (and since they can be extracted from the request itself that doesn't seem likely). That's why the ad blockers that stop the scripts from loading to begin with will always due a much better job than the extra "mumbo jumbo" you're relying on. That stuff should be a fallback for when scripts slip through the filters, not the primary means of protection.