There was considerable controversy in the comment thread of “Something in the Milk” about whether emails could be tracked as my correspondent described, and how such a thing would work. So on the evening of Valentine’s Day, she and I decided to test it out: she sent me an email, I forwarded it to others and she told me what we had done. The results convinced me, and I think they’ll convince you as well. The tracking utility is called Readnotify, and though it isn’t free the cost is small. Normally there is a notification in the email that shows it’s being tracked, but in “silent” mode this information is hidden from recipients. Note that all ISPs and the names of local towns have been disguised to protect privacy.
This email was initially opened on IP 40.8.23.254:12345; the device it was opened on has specific software specifications, listed under “Browser”. This shows the brand and version of the browser agent that was used when opening my email; these specifications are unique to each machine as updates are not always installed. I can see that this user is showing MSOffice in the browser info, so this user receives email via Outlook more than likely.
Opened | |
Opened | 3-Feb-14 at 23:58:55pm (UTC -5:00) – 59mins46secs after sending |
Location | Middle, Nowhere, United States (86% likelihood) |
Opened on | (40.8.23.254:12345) |
Browser | used by recipient: Moz/4.0 (MSIE 7.0; WinNT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12) |
This information by itself is meaningless; you can’t determine a user, a physical location, or anything else other than the IP information and the browser info. But what this information can provide is a “dog tag” for a device; as you compare it to other email tracking data that you receive, you can begin to notice whether any single “dog tag” appears in the circulation of any other emails that you are tracking. Now Reader 1 reopens the mail; only the end of the IP is different, you will see that change with reopens.
Re-Opened | |
Opened | 4-Feb-14 at 00:20:32am (UTC -5:00) – 1hour21mins23secs after sending |
Location | Middle, Nowhere, United States (86% likelihood) |
Opened on | (40.8.23.254:67890) |
Browser | used by recipient: Moz/4.0 (MSIE 7.0; WinNT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12) |
Last log | No more activity after 4-Feb-14 at 00:21:12am (UTC -5:00) – Log data indicates email was read for at least 40secs (approx.) |
Now for Reader 2:
Forwarded/opened on different computer | |
Opened | 4-Feb-14 at 00:21:24am (UTC -5:00) – 1hour22mins15secs after sending |
Location | Redmond, Washington, United States (86% likelihood) |
Opened on | (22.56.123.91:12345) |
Language | of recipient’s PC: en-ca (English/Canada), en (English), en (English) |
Browser | used by recipient: Moz/5.0 (WinNT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 |
Last log | No more activity after 4-Feb-14 at 00:22:52am (UTC -5:00) – Log data indicates email was read for at least 1min28secs (approx.) |
This recipient is using a Canadian English setting and running Firefox version 26. I am doubtful as to location as Redmond comes up often and seems to be the location of an ISP. Mountain View, California, where Google proxy servers are located, also comes up often. Though I am not mentioning all of them, each individual identifier in the report will match when a “dog tag” reappears.
Moving on to Reader 3:
Forwarded/opened on different computer | |
Opened | 4-Feb-14 at 00:24:40am (UTC -5:00) – 1hour25mins31secs after sending |
Location | Bacontown, Nova Scotia, Canada (86% likelihood) |
Opened on | (407.81.23.715:56789) |
Language | of recipient’s PC: en-US (English/United States), en;q=0.5 (English) |
Browser | used by recipient: Moz/5.0 (WinNT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 |
Accepts | Files browser can open: i/png,i/*;q=0.8,*/*;q=0.5 |
This one appears to be in Bacontown, Nova Scotia, and the ISP is Eastlink Ca, running Firefox version 26. Wait, it appears that Reader 2 has opened my email again from the same device.
Re-opened (by earlier reader #2) | |
Opened | 4-Feb-14 at 00:24:49am (UTC -5:00) – 1hour25mins40secs after sending |
Location | Redmond, Washington, United States (86% likelihood) |
Opened on | (22.56.123.91:24680) |
Language | of recipient’s PC: en-ca (English/Canada), en (English), en (English) |
Browser | used by recipient: Moz/5.0 (WinNT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 |
Now the original reader is taking a third look:
Re-opened (by earlier reader #1) | |
Opened | 4-Feb-14 at 00:59:25am (UTC -5:00) – 2hours16secs after sending |
Location | Middle, Nowhere, United States (86% likelihood) |
Opened on | (40.8.23.254:54321) |
Browser | used by recipient: Moz/4.0 (MSIE 7.0; WinNT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12) |
Last log | No more activity after 4-Feb-14 at 01:00:09am (UTC -5:00) – Log data indicates email was read for at least 44secs (approx.) |
Now we arrive at a 4th device that appears to be a mobile phone. I say that because it is showing a Google proxy; this is a new way Google is protecting phones from malware by opening images on a proxy for view. That proxy shows up as Mountain View, California. In this case we are viewing Google proxy info, and that “dog tag” will match any other proxy lookup so it is pretty useless for significant matching.
Forwarded/opened on different computer | |
Opened | 4-Feb-14 at 01:00:36am (UTC -5:00) – 2hours1min27secs after sending |
Location | Mountain View, California, United States (86% likelihood) |
Opened on | google-proxy-11-234-56-78.google.com (11.234.56.78:98765) |
Browser | used by recipient: Moz/5.0 (Win; U; Windows NT 5.1; de; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7 (via ggpht.com GoogleImageProxy) |
Last log | No more activity after 4-Feb-14 at 01:01:49am (UTC -5:00) – Log data indicates email was read for at least 1min13secs (approx.) |
Reader 5:
Forwarded/opened on different computer | |
Opened | 4-Feb-14 at 01:11:13am (UTC -5:00) – 2hours12mins4secs after sending |
Location | Beachville, California, United States (86% likelihood) |
Opened on | (66.111.77.88:09876) |
Language | of recipient’s PC: en-us (English/United States) |
Browser | used by recipient: Moz/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Mobile/11B554a |
Looks like an iPad running a mobile version of something opened it.
Reader 6
Forwarded/opened on different computer | |
Opened | 4-Feb-14 at 01:11:23am (UTC -5:00) – 2hours12mins14secs after sending |
Location | Beachville, California, United States (86% likelihood) |
Opened on | (66.111.77.88:09877) |
Language | of recipient’s PC: en-us (English/United States) |
Browser | used by recipient: Moz/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) |
Last log | No more activity after 4-Feb-14 at 01:11:39am (UTC -5:00) – Log data indicates email was read for at least 16secs (approx.) |
Interesting. Only the last digit of the IP is different. It is also an iPad running the same versions except for the mobile part. I am guessing it is either a second device on a home network, or a non-mobile email agent causing a difference in the reverse name resolution. Now Device 5 appears again showing the mobile version and another slight difference in the reverse name resolution.
Re-opened (by earlier reader #5) | |
Opened | 4-Feb-14 at 01:12:53am (UTC -5:00) – 2hours13mins44secs after sending |
Location | Beachville, California, United States (86% likelihood) |
Opened on | (66.111.77.88:09885) |
Language | of recipient’s PC: en-us (English/United States) |
Browser | used by recipient: Moz/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Mobile/11B554 |
Now Reader 7:
Forwarded/opened on different computer | |
Opened | 4-Feb-14 at 01:14:26am (UTC -5:00) – 2hours15mins17secs after sending |
Location | Middle, Nowhere, United States (86% likelihood) |
Opened on | (40.8.23.254:87654) |
Language | of recipient’s PC: en-US (English/United States), en;q=0.5 (English) |
Browser | used by recipient: Moz/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
Accepts | Files browser can open: i/png,i/*;q=0.8,*/*;q=0.5 |
Last log | No more activity after 4-Feb-14 at 01:16:47am (UTC -5:00) – Log data indicates email was read for at least 2mins21secs (approx.) |
Reader 7 is on the same network as reader 1. It is a different device though, operating Linux i686 Thunderbird/24.3.0 I would guess this is a second device on either a home or office networked computer. Next Reader 5 opens it on the iPad again using the mobile version.
Re-opened (by earlier reader #5) | |
Opened | 4-Feb-14 at 01:17:44am (UTC -5:00) – 2hours18mins35secs after sending |
Location | Beachville, California, United States (86% likelihood) |
Opened on | (66.111.77.88:11223) |
Language | of recipient’s PC: en-us (English/United States) |
Browser | used by recipient: Moz/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Mobile/11B554a |
Now Reader 7 opens it again on the same device:
Re-opened (by earlier reader #7) | |
Opened | 4-Feb-14 at 10:39:06am (UTC -5:00) – 11hours39mins57secs after sending |
Location | Middle, Nowhere, United States (86% likelihood) |
Opened on | (40.8.23.254:12548) |
Language | of recipient’s PC: en-US (English/United States), en;q=0.5 (English) |
Browser | used by recipient: Moz/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
Accepts | Files browser can open: i/png,i/*;q=0.8,*/*;q=0.5 |
Last log | No more activity after 4-Feb-14 at 10:57:31am (UTC -5:00) – Log data indicates email was open for at least 18mins25secs (approx.) |
Then Reader 7 decided to get a little tricky, and though they used the same device, they opened it on a different browser. Not Linux, they went with Moz4.0 with an MS Office tag indicating it was opened thru Outlook perhaps.
Opened | 4-Feb-14 at 11:49:57am (UTC -5:00) – 12hours50mins48secs after sending |
Location | Middle, Nowhere, United States (86% likelihood) |
Opened on | (40.8.23.254:31285) |
Browser | used by recipient: Moz/4.0 (MSIE 7.0; WinNT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12) |
Finally, the activity with this email concludes with one final open on the iPad in Beachville, California, mobile version:
Re-opened (by earlier reader #5) | |
Opened | 4-Feb-14 at 21:07:02pm (UTC -5:00) – 22hours7mins53secs after sending |
Location | Beachville, California, United States (86% likelihood) |
Opened on | (66.111.77.88:11705) |
Language | of recipient’s PC: en-us (English/United States) |
Browser | used by recipient: Moz/5.0 (iPad; CPU OS 7_0_4 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Mobile/11B554a |
Ending Summary
Summary – as at 5-Feb-14 at 16:29:00pm (UTC -5:00) – 1day17hours29mins51secs after sending | |
Total | Opened 15 times by 7 readers |
Reader #1 | Opened 4 times for 1min24secs total |
Reader #2 | Opened 2 times for 1min28secs total |
Reader #3 | Opened 1 time |
Reader #4 | Opened 1 time for 1min13secs total |
Reader #5 | Opened 4 times |
Reader #6 | Opened 1 time for 16secs total |
Reader #7 | Opened 2 times for 20mins46secs total |
Now, if this were a client interaction I would have concerns. Why would our interactions be shared so many times? And with whom were they shared? I would then begin to scan other email reports to see if any dog tags from this individual match any dog tags from any unrelated (or supposedly unrelated) emails match these. By comparing dog tags, you can identify when a network of devices are constantly sending you emails then circulating your replies through the network. In comparison, most email tracking reports say opened 1 time by 1 reader, or 2 times by 2 readers (two devices). Even 15 times is ridiculously high, as we see in this test but take a look at a recent summary of the activity on the email that I wrote about in “Something in the Milk”:
Summary – as at 5-Feb-14 at 16:36:41pm (UTC -5:00) – 22days19hours12mins46secs after sending | |
Total | Opened 134 times by 4 readers |
Reader #1 | Opened 124 times for 28mins8secs total |
Reader #2 | Opened 7 times for 22mins23secs total |
Reader #3 | Opened 2 times for 15mins3secs total |
Reader #4 | Opened 1 time |
The last entry on the log shows my email still being opened more than 20 days later; the dog tags on his report match dog tags on four other contacts all claiming to be in different parts of Florida and one in New Orleans. Why would this P411 member be forwarding my emails to a network of individuals centered in Orlando who are all responding to my Eros ad?
Her tracking and conclusions were spot on. I opened the email, then asked Aspasia and Kevin Wilson if they’d help; when they agreed I re-opened it and forwarded it to them (Middle, Nowhere is where my DSL service originates from). Soon afterward my husband returned my call and agreed to participate; he’s working in California right now and did open the mail on two devices in three ways, then forwarded it to a different email address of his and opened that one. Meanwhile, Grace was opening it as well, and when I read this report to her she laughed and said that she had indeed tried to trick the software as described.
Interesting. It seems nobody uses the least bit of caution when reading email and hence this type of tracking seems to work pretty well in practice.
The basis of this massive security issue is of course that web-browsers are misused as email readers and that this is done with the most insecure settings available (which seem to be the default these days). What happens here is that basically the email reader opens a web-page or web-elements automatically. This is really bad, as that means that when the web-browser has any vulnerability, your system can be compromised just by sending you an email that does not even need to contain any attack or malware in itself. This is also the reason there is “browser” information in the tracking given by Maggie. In a secure configuration, no web-browser would ever see the email in the first place.
Note that if you sent that email to me, you would have gotten exactly no information about forwards and only the information that the email was received regarding the delivery itself. (At least if I did not botch the settings. There is always that risk. If you still have that service it might be interesting to try…) Maybe you would also have gotten an answer by me that says that I do not read HTML email and to please send plain ASCII instead.
So, let me assert that in a world where people care about email security, this would not be working. Apparently we live in a world where despite decades of email-based malware and web-browser vulnerabilities, security of email reading mechanisms sucks badly. I wonder whether this is part of the NSA’s war on security and privacy.
I will freely admit that apparently I have been sheltered security-wise and have used practices as a matter of routine which seem to be alien to most people. Thereby I seem to have acquired a pretty unrealistic estimation of what is going on in the real world. Sorry about that. With this test, the claimed reading and forwarding history in the original story becomes entirely plausible.
On the meta-security side, it should be noted that this is an one-sided mechanism: If somebody is reading email with insecure settings, you will get reads and forwards. If, however, you do not get them, that tells you nothing. If your suspected predator is more careful and competent, you may not get any warning at all with this mechanism. I think this is a serious caveat for the use described in the original article.
Still, I am impressed this works so well. It should not. But it explains a lot.
I asked about that; if someone’s using secure settings what you get is a message saying that ReadNotify can’t give you any information. Which, unless your client represents himself to be an IT guy, is information in itself.
That is only partially accurate. It is possible and not too difficult to make sure readnotify gets its one apparent tracking instance (which is faked) and then deny them all others. Fortunately, even many IT people will mess this up or not manage to do this at all. (Incompetence coupled with arrogance runs rampart in the IT industry…)
I agree that while not perfect, this gives an additional level of protection.
Oh, and before I forget: Kudos for actually trying this! That is the right approach.
I have Thunderbird set never to display images in an incoming message, unless the sender is in my address book. If your app can detect that fact, I’d like to know how it does it.
“It seems nobody uses the least bit of caution when reading email and hence this type of tracking seems to work pretty well in practice.The basis of this massive security issue is of course that web-browsers are misused as email readers and that this is done with the most insecure settings available”
I can’t second this enough. Cramming all internet services through the browser is one of the most ill-advised “innovations” to come out of the 21st century. That being said, a lot of real email clients will cheerfully load external resources in a trackable way too. Or would last time I was stuck using one.
“Note that if you sent that email to me, you would have gotten exactly no information about forwards and only the information that the email was received regarding the delivery itself. (At least if I did not botch the settings. There is always that risk. If you still have that service it might be interesting to try…) Maybe you would also have gotten an answer by me that says that I do not read HTML email and to please send plain ASCII instead.”
Can this too be tested?
Normally, delivery status notifications are only available to other users of the same mail system, and then only in tightly controlled “enterprise” mail environments, such as Lotus Notes or Microsoft Exchange deployments. I would not expect to receive any information at all unless the delivery failed completely.
Even then, some mail servers are configured to discard undeliverable mail silently for capacity reasons or to avoid providing assistance to spammers attempting to find working email accounts.
I may be able to provide assistance in testing specific scenarios.
Whoa!
Explain this to me – even if Celo’s email is iron-tight, as he asserts – if he forwards that email to someone whose email isn’t as secure – you’ll get a notification right?
What’s the impact of TOR when it’s used?
Also – you DO know that I get a notification sometimes when you open an email from me right? I’m thinking this is some kind of setting on YOUR email client – as I don’t have any settings like that on mine. I don’t get notifications like that from anyone else. I don’t think I always get it from you either – just the times when you blow me off and don’t respond!! 😛
I’m just joking!
If the original HTML email is forwarded, the tracking keeps working. If only the text is forwarded (which is what I would do), it fails. So for any mechanism an ordinary person would use to forward, if the email is opened on a different computer, this is visible. (It does not really track forwarding, but close enough.)
And no, my email is not “iron-tight”, it just uses sensible settings. (Of course, what a security experts thinks is “sensible”, may look utterly paranoid to other people. Maybe less so post-Snowden.) For example, I have not even tried things like readnotify on it and I do not scrubbing at all. That gives me at best a medium security level, definitely not a high one.
TOR would hide your location effectively, but not anything else and it would be obvious that you use TOR as the traffic comes from a TOR exit relay. I expect readnotify can detect that and tell you. This would also compromise your TOR session, as your identity goes through the session, or at least something that readnotify can reverse.
Depending on your settings, it is however likely that the browser-misused-as-email-reader would not go over TOR in the first place and nothing changes. For example, with the TOR browser bundle, only the traffic from the TOR browser goes over TOR.
Krulac, the impact of using Tor varies considerably. If Tor is used securely with a package such as the Tor Browser Bundle, it’s very good, although not perfect. This is a very good summary of how the security of Tor users can be attacked, modulated with the information we now have on precisely how Tor users have been attacked in the past: http://www.theguardian.com/world/2013/oct/04/tor-attacks-nsa-users-online-anonymity
One specific item that was most likely left out for length is the FBI attack on both Tor users and a core piece of the Tor network as it existed some months back: http://www.wired.com/threatlevel/2013/08/freedom-hosting/
I visited the project page for the Tor Browser Bundle in hopes that they had an explanation of why it’s all-but-necessary, but I didn’t see one. In summary, browsers leak a great deal of information, largely by design.
For example, if I used Tor from a coffee shop, and I had hand-configured my browser’s proxy settings, there’s a reasonable chance that I would end up leaking DNS transactions. Anyone else sitting in the coffee shop would see every request translating, for instance, “www.microsoft.com” into an IP address. Just on its face, this would provide records of all the sites I visited, with an only slightly imperfect timeline.
Going slightly farther, you could match this sort of information with the times that I made posts on various sorts of websites, then make a highly educated guess as to which posts were mine. If I posted to some sort of unmoderated message board, the accuracy would be quite excellent.
Just btw, Norman Lindsay, author and illustrator of The Magic Pudding (1st picture) was a fine artist of erotic art. See https://www.google.com.au/search?q=Norman+Lindsay&safe=off&tbm=isch
The Redmond, Wash., locations are for Hotmail (Microsoft), and the Mountain View, Calif., locations are for Gmail (Google). This is one of the issues with these two email services in that the ISP locations are those of Hotmail and Gmail, respectively, and it makes it impossible to track geolocations of correspondents using them. Checking out someone’s veracity as to their location thus is impeded by these deliberate blocks put in by those two services.
If you use an email tracker such as the one below, the same issue arises:
http://whatismyipaddress.com/trace-email
The other information provided by this Readnotify is very interesting and potentially very useful. But with so many people using Hotmail and Gmail, the geographic chain in a widely circulated message is going to be broken more times than not.
My guess would be this is one effect of using webmail. A proper email client attached via IMAP or POP should not behave like that. With webmail you are effectively opening the email on the server and that is what gets tracked.
Incidentally
– 40.8.23.254 is Indianapolis (?) by provider Eli Lilly And Company
– 407.81.23.715 is not an IP address at all (typos?).
@Celos: Well, dunno, but every time I go to trace an email originating from Gmail, and virtually everytime with Hotmail, it shows Mountain View, Calif., and Redmond, Wash., respectively. Yahoo! addresses used to do this, too, tracing to one of Yahoo!’s regional nodes, but for a long time now I can usually trace Yahoo! emails to the sender’s IP address.
I have proprietary email addresses on my own domains, but use webmail access, refusing to use a client which risks serving as a vector for sending trojans, and my emails normally trace to my local IP address and not that of my email provider.
Again, I think there are lots of ways, intended and unintended, of concealing one’s actual location, but the idea of seeing how many times a message is forwarded and opened is certainly instructional on its own.
Those numbers are as gobbledygook as “Middle, Nowhere” and “Bacontown, Nova Scotia”. I just typed numbers over the real ones.
Ah, good to know. Just some info: IP addresses have 0-255 in each of their four places, no other numbers allowed. If you want to make it clear they are bogus, you can use 10.*.*.* IP addresses, they are not globally routed.
Wouldn’t have worked; I wanted to show that the same IPs repeated, which wouldn’t have been possible with a bunch of asterisks.
To amplify, the network range 10.0.0.0 through 10.255.255.255 is reserved for “internal” use, and packets arriving from or destined for this network will be discarded by properly configured Internet routers.
There are several other reserved networks, such as 192.168.0.0 – 192.168.255.255, 0.0.0.0 – 0.255.255.255, and 127.0.0.0 – 127.255.255.255.
As a point of interest, there are three far smaller networks reserved by the Internet Assigned Numbers Authority for the explicit purpose of serving as examples in documentation and discussion. They are described at http://tools.ietf.org/html/rfc5737 , and to my knowledge they have never been used for that purpose…
Nice. The reason is probably that nobody knows about these example ranges. I certainly did not.
@Maggie: Sorry about the “asterixes”, which are actually wildcards, i.e. placeholders for any value {0, …, 255}. Sometimes it is hard to remember to explain all conventions used.
The full list of all network ranges, unusual and otherwise, is here: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
Sometimes, reading all that dry documentation comes in handy. In this case, it’s a dandy guide to all the reserved networks that your firewall product is most probably not configured to discard. As you say, no one knows about them.
This brings up a point. Were the apparent original addresses in any of those reserved ranges? Certain reserved addresses are *very* commonly repeated on different local networks, like 192.168.0.100, and the tracking software might be reporting local addresses rather than public ones.
That should not be happening as the requests will need to come from globally routed IP addresses in order to reach the tracking server. Remember that the IP address detection is not done in the email client, but in the server serving the picture and by the IP address that requests the picture from said server. It associates this IP with the email by its URL, which contains some key identifying the original email. What can happen is that the only thing you see IP wise is something like the “Google image cache/proxy” or the IP of some NAT gateway.
My guess is that it matters not that much, it seems more important how often the email is looked at and with what timing. If somebody obsesses over the email or forwards it (and it is not really important to distinguish the two, just to see that there more email opening than is “normal”), that somebody is suspicious. It then becomes a question of balancing a potential business opportunity against a fuzzily specified risk and maybe doing more research on the potential customer.
Of course, having never worked in the field we discuss here, I can only speculate about what is “suspicious” and what not.
It seems to me to be more than just the forwards. I understand “dog tag” to be more specific than a random forward. I took it to mean that it can identify a specific machine.
I’m curious to know the exact meaning that “dog tag” has in this discussion.
Maggie, can you explain how you’re using the phrase?
Web browsers and email clients can and do leak very useful data. Normally, I would explain how unreliable it can be, but the targets in this discussion seem to be rather careless.
For a demonstration, see the EFF’s “Panopticlick” project: https://panopticlick.eff.org/
Note that a service such as ReadNotify can’t see most of this data. Still, it doesn’t take much to get a target to visit an openly or covertly malicious web server, these days…
Yeah but – networks are an issue too – you’ll get the ip location of the network. When I’m in the arctic my real ip is coming from Sweden.
Yay for experiments! I had a feeling that she wasn’t making that up.
Gmail was the safest option but a few years Hotmail decided to hide ip-addresses too. I remember in 2008 they didnt and because of that I lost 500 million neopoints that I worked 3 years to get. Fuck microsoft. I should have used gmail from the start.
Generally speaking most other email providers are not safe. My webhost used Roundcube and i inputted the header into a email header tracking website (tons of those exist) and gave me my ip-address. Only gmail didnt, back in 2008.
To both summarize and underline how Celos is avoiding email tracking: he doesn’t load “external” images in emails, which is how most email clients and webmail services phrase it.
That’s all.
It’s nothing extraordinary, and most mass-mailing services are aware of that. I can still receive and view newsletters and other updates from the services that I use; most have a link at the top reading “Having trouble viewing this email? Click here.” that becomes visible if the externally hosted images weren’t loaded.
If you do click the link, your visit will still be recorded with whatever retailer or service you use, or possibly a third-party “communication management” firm, so don’t click without looking at the URL.
@Celos: Have you ever experimented to see if webmail can be bugged with external WOFF fonts? I don’t know of any browsers or email services that treat them as potential threats.
@Maggie: As you demonstrated, Google’s new image proxying service has certain shortcomings. The best advice still stands: don’t view images in emails.
@Maggie & Celos: I can’t think of a single guide anywhere that neatly summarizes the last ten or fifteen years of advice on using the Internet safely. If such a guide did exist, I would expect to find that the credentials of the authors were rather oversold, as with most mass-market security advice. Perhaps it’s time to create one.
I have no idea how webmail can typically be attacked in practice. I do not use it except occasionally on a customer supplied laptop for their internal mail.
In principle anything loaded externally is a risk, whether on server-side or client side. Both can happen in webmail. A secure webmail implementation will make sure to rewrite all external links and to only load very specific things, and give some of them to the client only on request. An insecure webmail implementation can be arbitrary bad.
What I use is mutt as text-only mailer with less as text-only pager. less couldn’t care less (pun not intended) about HTML and its elements. I only very occasionally have people sending me HTML email and if it is something I consider worthwhile, I look at it with lynx (text-only web-browser). This is because I usually do an ssh remote-login to my mail-server, no graphics in there. A few years back I expected that at some point everybody would send HTML email and I would have problems, but not so far. There are basically just a few newsletters that I do not care about anyways that use HTML.
As to a current guide to Internet security for users, there really is nothing good. One problem is that it is a moving target. Another is that some of the technologies involved are rather complicated, and unless you understand them you do not get good security (bad design, I know). Currently, with all the sabotage the NSA is doing, it gets more and more difficult. For example the advice to “use Linux” is worth far less today than a few years back.
Because I’m no more willing to use terminal-only web and mail clients than the average Internet user, I rely on liberal use of security tools and my knowledge of secure settings.
In that case, I may conduct my own experiments with WOFF fonts. I’ve stirred my own curiosity.
You’re quite correct that security is a moving target. The first lesson I learned from my mentor was that security is a thing that never stops, and can’t be bought in a box. Fortunately, I take an acute and active interest in the tools and methods.
“Use Linux” or any similar advice to discard familiar tools has ever been a poor thing to recommend. Although difficult, it’s possible to achieve reasonable security on other major operating systems.
However, your point is well-taken. I have spoken to Linux users secure in the knowledge that their choice of tool makes them invincible. Few stop to consider that the cheap appliance they purchased to connect their computers to the Internet contains frightening vulnerabilities, or that their wireless inkjet printer might be a springboard into their network.
Don’t most routers these days run Linux as well? (And printers, and TVs, and phones, and…)
It’s still a simple fact that UNIXs are more secure than anything else out there (Linux and OSX being the ones you’re likely to actually run into), the fact that the gap is getting a few inchs smaller by the year doesn’t really change things much when the gap was 3 miles wide to start with.
Personally, the reason I always give the advice of “use linux” is because when people use it, they normally have to get under the hood a little more (and Linux makes it far easier to do so than anything else I’ve come across), and once people stop seeing a magic box, and start seeing a machine, and start finding that *they* can fix things (it doesn’t take a magic technician with 50 different incantations), they start to pay more attention to keeping it running safely and well.
It’s not a magic bullet: It’s an education.
Yes, most cheap, commodity routers run Linux. Many “smart” devices do as well, although some extremely cheap devices (including routers) with too little ROM or RAM still use VxWorks or other operating systems with the smallest possible footprint.
It’s not a fact that UNIXes are more secure than anything else. As you say, there’s no magic bullet. Like all other operating systems I’ve secured or attempted to secure, they were written by developers usually more focused on getting them to run with as few flaws as possible, rather than any specific focus on security. Sometimes, the acceptable minimum number of flaws was raised surprisingly high by budgetary or time constraints, or via design by committee. Some of these flaws are not exploitable by attackers. Many are.
Perhaps you’re not aware of the recently-discovered hair-raising SSL/TLS iOS/OSX flaws dubbed “#gotofail”: https://gotofail.com/
Or there’s the embedded Linux devices–embedded devices in general–no matter how expensive they are or who they’re marketed to: http://arstechnica.com/security/2014/02/dear-asus-router-user-youve-been-pwned-thanks-to-easily-exploited-flaw/
There are no good, easy choices. One of the few things in the present security landscape that can be described as “inherent” is the insecurity of nearly the entire embedded device ecosystem, from mobile phones to IP cameras to HVAC systems. On top of any security the underlying OSes may have had upon a time, single developers or tiny teams build highly customized code used nowhere else, in a rush, then abandon it immediately to work on the next product.
Here’s the latest mass compromise: http://www.reddit.com/r/technology/comments/1zgjtf/hackers_hijack_300000plus_wireless_routers_make/
@Celos: I waive consecutive translation. This could be written in Greek (which I do not speak to any notable degree) and I would not understand it any less.
The one thing I do understand I also agree with, which is this:
“As to a current guide to Internet security for users, there really is nothing good.”
@Celos: Writing my own, freely available guide is something that I’ve toyed with for the last few years. I suspect that I’d learn more interesting things while researching it, and I’d feel good about sharing this kind of knowledge with a broader audience.
I’m still weighing pros and cons. Apart from the sheer effort involved, I’m dismayed by the reigning lack of interest in both IT and non-IT circles. The most frequent theme continues to be “No one is interested in breaking into my computer,” despite masses of evidence that this is not true.
(In the IT world, the theme is frequently “But we have a firewall,” as if it’s some kind of infallible talisman.)
If I could attract enough genuine interest from a potential audience with a real stake in security and privacy, that might finally tip my decision-making in favor of committing to such a project.
So one would have to conculde that in this instance P411 was not doing due diligence in following up this person’s complaint?
As a very general comment, I find that many or most service providers do not take security concerns seriously. To be as clear as possible, I mean providers of any service. I have encountered insurmountable difficulties in convincing most to take basic steps to secure their services. Among the list of providers who have discarded–frequently with contempt–any concerns that I shared, I can count small and major banks, other credit card issuers, vendors and makers of computer network devices, and even makers of “antivirus” software.
Examples of my concerns include disclosing passwords in plain text via email and failing to employ encryption–correctly or at all–on “secure” websites.
I hear a familiar refrain in “Gina’s” argument that “IPs” are not evidence of anything. I imagine that most operators of large websites are used to receiving missives from people who have half-remembered some security advice or even watched a Hollywood movie with “hacking” and become convinced that they are victims of imaginary attacks.
However, the information Maggie relays in “Something in the Milk” does sound highly suspicious, and perhaps typical of police departments that have also learned what they know about information security from movies or that neighbor who fiddles with computers. Maggie is contributing real analysis and serious thought to the bare information she presents. “Gina” is far too hasty in discounting either the information or the analysis.
In conclusion, I’m not certain that it’s possible to assign any particular motivations to “Gina” without direct evidence. Rather than dwell on that, I would underscore the crucial point that the motivation behind a security failing does not ever matter.
The security is what matters.
I think that is a fair summary.
It is indeed the security that comes out of the process that counts. Whether that is lower than desired is due to incompetence, greed, stupidity, indifference or some other reason is besides the point.
It should however also be noted that a provider of any service with some real users is getting countless complaints, many of them baseless. (I have seen a relevant analysis sheet with real cases from a bank once. You would not believe what people claim…) That can be overwhelming. The important thing is to consider filtering them adequately a priority and to be able to recognize those that are not baseless and do something about them. Anybody that cannot do that should do the honorable thing and either get help to fix the process or close down their business.
We can argue the relevance and accuracy of the IP tracking for ever and most likely will never agree. However when an email is opened over 130 times it is very suspicious to say the least. My thought is that if you promote yourself and your website to be a protector of providers and clients, you would have to think this to be suspicious behavior. If you don’t and flatly deny the possibility of it being suspicious then both you and your website are frauds. If I had hired a security company to protect my home or business and found evidence of someone looking in my windows 130 times, I would be furious if their response was one of dismissal of any risk. At the least they should warn me of a risk even if it was one of their employees looking in my windows.
As a fellow IT person, I’d like to second what Celos has to say in this thread.
One thing seems missing. Lots of tracking from clients, but I gather from Something in the Milk that your contact also exchanged email with Gina. Were *those* emails successfully tracked, and if so, what did it turn up?
Good question.
I have also noticed no response from Gina now that there seems to be substance to the claims. Somehow she always finds and replies to articles and complaints, but apparently only when she can use the old “It’s my word against ‘ a disgruntled provider’ or ‘a disgruntled client’.”
In many other responses I’ve seen she simply says I’ve already responded to this. But when?
I haven’t seen her responses. I’ve seen a lot of dismissing the allegation, but no real explanation of her lack of action.
I’d like to see the correspondents answer regarding ginas emails being tracked.
All in favor?
From my source:
In other words, ReadNotify showed Gina forwarding her complaint email to one of the other devices that the fake client forwarded their interaction to. Conclusive? No, because we don’t know who that particular “dog tag” belongs to. But a confidential email about a business complaint was still shared with some third party, which in itself is a privacy violation. And I don’t think one needs to use too much imagination to guess the nature of the entity who was interested in both a sex worker’s communication with a police plant and a complaint about said communication.
I assume that the forward was read on a machine not likely to belong to any employee of P411. If so, it does represent at least a major ethical breach.
I don’t know anything about P411’s operational structure, so I’m taking care not to speak from ignorance.
Separately, it occurs to me that this entire conversation is likely to lead to a tightening of operational security on the part of P411 or any law enforcement that P411 may be partnering with.
Maybe, but I doubt it; cops are sloppy and often rather stupid.
Here’s hoping. That concern aside, it’s encouraging to see the results of your work. The best security happens in public, and it’s the result of ingrained curiosity and skepticism. After reading your work for some time, it’s clear to me that you have both.
Please be aware that I don’t constantly search the web for posts about P411, I only address that which is brought to my attention. So unless someone brings a thread to my attention, chances are very good that I have no clue it exists. Today, this thread was brought to my attention, and I’ll do my best to answer the charges (again).
The provider who started all of this, had contacted me with similar “information” in the past. That previous information was incorrect, although because it was in the same state that we later on did have an incident, she took that as proof of her abilities. The thing is, that state (Colorado) is one of our largest markets, with thousands of client accounts, and the account she has been reporting to me was in no way involved in the incident.
I had also had been privy to other, incorrect, LE reports originating from her information. So I, because of my experience with her, do not consider her a credible source of information. Not to mention, I do not hold the belief that because an email was forwarded x times, the reason must be because it’s LE.
In my experience, LE exclusively uses Gmail (although in the early 2000s it was AOL) because it is difficult to track and provides anonymity. I also know that the operations, 99.99% of the time are same day hit and run. The set up a couple of hotel rooms, and start contacting as many providers as possible for that day or evening. Whomever shows up, is going to jail.
The idea that they spend days or weeks forwarding emails around to other LE is just not how it works.
If a provider believes that read-notify or ip tracking tells her something important, that’s fine with me. However, I do not hold the same opinion of that information. As I told the provider, I do not consider it PROOF of anything, although I always make notes and keep an eye on the account for any other suspicious activity.
That she then decided that my opinion meant that I was “working with the FBI”, which only confirms (to me, anyway) that chances were pretty good that I was dealing with a person who was not operating with a full deck.
This statement really is true:
“I imagine that most operators of large websites are used to receiving missives from people who have half-remembered some security advice or even watched a Hollywood movie with “hacking” and become convinced that they are victims of imaginary attacks.”
And as far as where my email was forwarded…. I forward or BCC emails P411 staff who need to be aware or involved for one reason or another. That this is again being used as “proof” of my affiliation with LE, is another reason why I don’t entertain this type of thing.
I wish no one any harm, and I really wish that the lies and malicious gossip would stop.
Always,
Gina