6 ms·

> the mail client to check that, if the text of an <a> tag was a url, that the text matched the href field. The use case that this breaks is doing click tracki

by shkkmo 8y ago

> the mail client to check that, if the text of an <a> tag was a url, that the text matched the href field. The use case that this breaks is doing click tracking on links using redirects from a unique url to the actual url (which would be the url displayed in the link text). To avoid breaking this use case, the best remedy would be to prompt the user with a security warning upon clicking a mismatched link prompting them the verify the url in the url bar. The issue, is that doing this selectively teaches the wrong security practice to users: that they can improve their safety by looking at the link text rather than at the url bar after clicking the link.

vorticalbox 8y ago
Yeah but that's annoying and almost every one who isn't "techy" for lack of a better term won't even bother reading it and just press ok. I mean can you honestly tell you read the Google privacy notice or do you just click the down arrow till the ok box appears?
- shkkmo 8y ago
  > Yeah but that's annoying Yes it is annoying. My point is if you want to be annoying, you should be annoying the user when they visit ANY external links as trusting the link text isn't a practice that should taught/encouraged. > almost every one who isn't "techy" for lack of a better term won't even bother reading it and just press ok. That depends on how short and well worded the alert is. However, there is certainly an attention budget that can be used up with pointless / low value alerts (which is why I would assume that Apple did not go this route).
frenchy 8y ago
> The use case that this breaks is doing click tracking on links I, personally, would be quite happy for this use case to break.
- shkkmo 8y ago
  > I, personally, would be quite happy for this use case to break. Why? If you don't want to be tracked it is pretty easy to avoid. You should already only be getting/opening emails you care about. Emails you don't care about should be unsubscribed from and reported as spam. Granted that links should only be tracked in email you do care about, why do you not want those people to have the information they need to refine and improve these emails so they can better serve and inform you? I would assume that happiness depends on how this use case is broken. Would you be happy if the email just doesn't show up or gets shunted to spam? Even if it is a password reset email or a email verification email? Would you be happy if the link just failed to open, forcing you to copy and paste the link text manually? Why not just do that on your own anyway? No need to have the email client block this for everyone just to suite your tastes. This leaves us with just the behavior I mentioned above and my argument against it.
  - luckylion 8y ago
    > Why? If you don't want to be tracked it is pretty easy to avoid. If you want to track clicks, why not use a subdomain instead of something.weird3rdparty.com? And why would the link text look like a URL? I don't see why <a href="https://possiblephishing.com/n1bfsd?j1h7d8Sda">www.ebay.com/viewOrder</a> makes more sense than <a href="https://www.ebay.com/viewOrder">view your order</a> . > Even if it is a password reset email or a email verification email? Why would you want to share password reset info with a third party? I get the "easy tracking" argument for newsletters (but I'm pretty sure most are not GDPR compliant), but for password reset emails? why? > Would you be happy if the link just failed to open Why would it? You can put a working link in the email directly - you've proven that by putting a different link in the email than the one you pretend you're linking to.
    - shkkmo 8y ago
      > If you want to track clicks, why not use a subdomain instead of something.weird3rdparty.com? I don't see what relevance a subdomain has here. As the original issue was described, it was blocking any links where the url doesn't match the link text (if the link text is a url). This means that even tracking that is done on the same domain (e.g. example.com/emailTracking/{{unique_string}} redirects to example.com/viewOrder/412) would be blocked. If you start only blocking those links if the domains don't match, things become more complicated to implement and test, especially once you consider subdomains, etc. The question remains, what is the point of this and is it worth it? Are we really promoting good security practices or just adding security theater cruft? > Why would you want to share password reset info with a third party? Who said anything about a third party? As you mention above, this blocks people who are doing their own tracking on the same domain. I don't have any numbers, but I assume that ESPs like MailGun and SendGrid are probably the most common third parties used to track email link clicks (since they will automatically substitute link urls with trackable rediracts if you enable it.) In this case, that third party already has access to the entire content and metadata of the email and giving them link click data is a relatively small addition. > Why would it? You can put a working link in the email directly - you've proven that by putting a different link in the email than the one you pretend you're linking to. Email links already work one way, perhaps if Apple implemented this feature eventually every email sender out there would switch to links that would work in Apple mail again. In the mean time, Apple has to deal with confused and dissatisfied users wondering why links in their emails don't work. How would you implement link url / text mismatch blocking? Have you thought through the consequences for your users and their understanding of security or satisfaction with your product?
mobjack 8y ago
Email marketers would just stop having text in <a> tags that dont look like URLs to get around it. They already do that anyways for the most part. Phishing attempts will mimic real emails, so they will do the same.

by shkkmo 8y ago

vorticalbox 8y ago

Yeah but that's annoying and almost every one who isn't "techy" for lack of a better term won't even bother reading it and just press ok. I mean can you honestly tell you read the Google privacy notice or do you just click the down arrow till the ok box appears?

shkkmo 8y ago
> Yeah but that's annoying Yes it is annoying. My point is if you want to be annoying, you should be annoying the user when they visit ANY external links as trusting the link text isn't a practice that should taught/encouraged. > almost every one who isn't "techy" for lack of a better term won't even bother reading it and just press ok. That depends on how short and well worded the alert is. However, there is certainly an attention budget that can be used up with pointless / low value alerts (which is why I would assume that Apple did not go this route).

frenchy 8y ago

> The use case that this breaks is doing click tracking on links I, personally, would be quite happy for this use case to break.

shkkmo 8y ago
> I, personally, would be quite happy for this use case to break. Why? If you don't want to be tracked it is pretty easy to avoid. You should already only be getting/opening emails you care about. Emails you don't care about should be unsubscribed from and reported as spam. Granted that links should only be tracked in email you do care about, why do you not want those people to have the information they need to refine and improve these emails so they can better serve and inform you? I would assume that happiness depends on how this use case is broken. Would you be happy if the email just doesn't show up or gets shunted to spam? Even if it is a password reset email or a email verification email? Would you be happy if the link just failed to open, forcing you to copy and paste the link text manually? Why not just do that on your own anyway? No need to have the email client block this for everyone just to suite your tastes. This leaves us with just the behavior I mentioned above and my argument against it.
- luckylion 8y ago
  > Why? If you don't want to be tracked it is pretty easy to avoid. If you want to track clicks, why not use a subdomain instead of something.weird3rdparty.com? And why would the link text look like a URL? I don't see why <a href="https://possiblephishing.com/n1bfsd?j1h7d8Sda">www.ebay.com/viewOrder</a> makes more sense than <a href="https://www.ebay.com/viewOrder">view your order</a> . > Even if it is a password reset email or a email verification email? Why would you want to share password reset info with a third party? I get the "easy tracking" argument for newsletters (but I'm pretty sure most are not GDPR compliant), but for password reset emails? why? > Would you be happy if the link just failed to open Why would it? You can put a working link in the email directly - you've proven that by putting a different link in the email than the one you pretend you're linking to.
  - shkkmo 8y ago
    > If you want to track clicks, why not use a subdomain instead of something.weird3rdparty.com? I don't see what relevance a subdomain has here. As the original issue was described, it was blocking any links where the url doesn't match the link text (if the link text is a url). This means that even tracking that is done on the same domain (e.g. example.com/emailTracking/{{unique_string}} redirects to example.com/viewOrder/412) would be blocked. If you start only blocking those links if the domains don't match, things become more complicated to implement and test, especially once you consider subdomains, etc. The question remains, what is the point of this and is it worth it? Are we really promoting good security practices or just adding security theater cruft? > Why would you want to share password reset info with a third party? Who said anything about a third party? As you mention above, this blocks people who are doing their own tracking on the same domain. I don't have any numbers, but I assume that ESPs like MailGun and SendGrid are probably the most common third parties used to track email link clicks (since they will automatically substitute link urls with trackable rediracts if you enable it.) In this case, that third party already has access to the entire content and metadata of the email and giving them link click data is a relatively small addition. > Why would it? You can put a working link in the email directly - you've proven that by putting a different link in the email than the one you pretend you're linking to. Email links already work one way, perhaps if Apple implemented this feature eventually every email sender out there would switch to links that would work in Apple mail again. In the mean time, Apple has to deal with confused and dissatisfied users wondering why links in their emails don't work. How would you implement link url / text mismatch blocking? Have you thought through the consequences for your users and their understanding of security or satisfaction with your product?

mobjack 8y ago

Email marketers would just stop having text in <a> tags that dont look like URLs to get around it. They already do that anyways for the most part. Phishing attempts will mimic real emails, so they will do the same.