As far as I've been able to research, these typesquatting domain traps started at the same time as Spamhaus CSS blacklist which was actually a company called Deteque.
If the MX has a large number of Hetzner IPs as mailservers, then it's probably Spamhaus.
> The reality is likely to be: they make a very small amount from ads and user donations that might, if they're lucky, cover the costs of hosting
Opensubtitles has a VIP program at $15 a year.
It's quite easy to find the person who runs the site and, according to their CV, this is basically their job. That'd make Opensubtitles a for-profit piracy site, i guess.
If in order for opensubtitles to fulfill its envisioned role needs full-time attention, it is legit to pay yourself or hire an employee, paid by the ad and or subscription money. That's what also happens on all registered non-profit organizations.
I don't think they're implying the subtitles themselves are piracy, but the users of opensubtitles.org are overwhelmingly using them for pirated media. The subs are all indexed against scene versions of the video files (as you can tell from their names), and that's what most users are using it for. After all, streaming services, DVDs, and other legitimate ways of consuming these shows/movies already come with subtitles.
No, the 0.1% of subs for obscure indie shows that didn't have native subs doesn't change that.
It takes hours of work to translate one hour of movie, so when a translated subtitle is copied, it is most certainly piracy. If you are faster than that please consider becoming a translator for sites like the TED foundation.
I think the problem with these products is that they build on the assumptions a file is a file and not that a folder can be a file and a file can be a folder.
The assumptions you need to do to make a folder into a file requires a lot of extra work.
An example of a folder that is actually a file could be a folder named "A Good Movie" with a bunch of .rar files in it.
I've built a streaming plugin for deluge that tries to work around these assumptions but only for a playback scenario and not an indexing scenario. That allows streaming of multi-rar file torrents.
There's also the problem that many rar parsing libraries reads the beginning and end of each part of a split .rar file. That can cause a lot of latency with e.g. 100 files.
Edit: all this applies only to rar files with no compression. With compression you can't do much with regards to seeking and whatnot.
Google charges money (to verify your identity I assume, it's quite cheap) if you wanted to make actual apps for chromecast, I assume you can sidestep that with this.
I made a transcoding proxy for Chromecast, for it to work, I'd have to piggyback the url-player (without selling my identity). I don't like stuff like that.
> Google charges money (to verify your identity I assume, it's quite cheap) if you wanted to make actual apps for chromecast
It's $5, but just FYI, you don't have to pay or register your app if you make a Default Media Receiver. You don't get on-TV UI, but that's probably fine if you're just transcoding and displaying video.
I work for a small company and we get catered lunch delivered every day. They never ask about if we liked it and if the amount we received fit our consumption. So, some way to inform them about which dishes we liked and how much food we threw away.
The irony is that in that situation http with ssl and a randomly generated cert will be more secure than HTTPS which uses the CA's Cert, hell I'd like the HTTPS to use the CA's cert for identity but use a self-signed cert for actual data transfers.
Don't worry, you just don't understand how TLS works :-)
The CA never gets the private key. Instead they get a certificate signing request (CSR), which only contains the public key part. They sign that.
Oh, and then there is perfect forward secrecy, which basically means that even the servers private key is not the one used to encrypt the actual data (after the initial handshaking, and only for suitable cipher suites, subject to downgrade attacks).
Disclaimer: at least, thats how its properly done. Some CAs offer a "send us your cert and we'll sign it", and dumb people who shouldn't be admins use it because it's (slightly) easier to use.
But you got the conclusion right, the notion of CAs is problematic.
This is what kills CA security. Anyone at a employer with over 5 people in the IT dept probably has someone who can insert a CDROM but has no idea how to set up CA and SSL stuff installing intranet internal servers using https and a self signed cert.
So we're carefully raising a whole generation of users programmed to accept any self signed cert, after all "thats how the benefits website is at work" or "thats how the source code mgmt site is at work". Then they go home, and oddly enough their bank presents a new self signed cert, or at least they think its their bank, and much as they have to click thru 10 times a day at work, they click thru the same popup at home and then enter their uname pword and ...
Paradoxically as a budget weapon its excellent because you probably have good enough physical security at work and frankly its usually not something worth protecting anyway, but it is incredibly annoying so you can bring up at budget meetings that IT can't afford to fix the SSL cert errors on some meaningless server because they can't afford it, etc. Not technically true but J Random MBA managing something he knows nothing about, can't figure it out, so its a great budget weapon. Highly annoying but doesn't really hurt anything.
To fix this you'd need something like an enterprise programers union standard union contract rule that enterprise programmers will never, ever, ship enterprise software that allows a self signed key. Good luck defining enterprise software, I suppose.
And in the spirit of idiot proofing leads to better idiots, requiring no self signed keys means idiots will create their own root and train users to import any root they ever see anytime they see one. Then distribute a non-self signed key signed by the imaginary "Innitech CA services" root. What could possibly go wrong with training users to do that?
In the spirit of "idiot proofing leads to better idiots" of course that will not happen.
In fairness if you have a heterogeneous network of legacy windows, some macs for real work, legacy blackberry and both real smartphones, distributing it "everywhere" can get kinda hard.
Yes, but they can also do so if you use a self-signed certificate, by just self-signing their own. There's no way that's less secure than a CA-signed cert.
As far as I know, self-signed certs have to be approved on a case-by-case basis in most browsers. Thus if a site is hit by MITM, the cert will change and the browser will warn. Of course, that's assuming you've visited the site before and care to pay attention to the warning.
Besides geococcyxc's remark, how are you to know that the first certificate is legitimate? How are you to know that the new certificate after the old one has expired is legitimate?
Care to elaborate? I do not think you will get a warning if the MITM is done with a certificate signed by a valid CA, even if you have approved some self-signed certificate before for that site. At least I have never seen this in any browser.
I got an abuse mail from Hetzner once (they mistyped my ip).
The original complaint was something autodetected by their own system, mailed to themselves. The original complaint was attached, header and all. Something about malware on an IP similar to mine.
Also, when will this be in effect, the server i tested from had no problems connecting.
12 INTELSAT-IN.car1.NewYork1.Level3.net (64.156.82.14) 127.129 ms 121.898 ms 121.857 ms
13 209.159.170.215 (209.159.170.215) 214.763 ms 196.291 ms 210.602 ms
14 202.72.96.6 (202.72.96.6) 697.258 ms 711.336 ms 693.061 ms
15 175.45.177.217 (175.45.177.217) 696.368 ms 699.046 ms 702.013 ms
My route, from the US, was one hell of a world trip. Bounced around the US a bit then back and forth between NYC and Frankfurt, finally down to Nigeria (appears to be a satellite uplink), over to Cambodia and then into NK.
From a Verizon FiOS connection in Massachusetts, I get:
$ traceroute thepiratebay.se
traceroute to thepiratebay.se (194.71.107.15), 64 hops max, 52 byte packets
... snip ...
3 ae0-0.bos-bb-rtr2.verizon-gni.net (130.81.209.94) 4.940 ms 3.924 ms 4.962 ms
4 0.xe-8-0-0.br3.nyc4.alter.net (152.63.23.241) 13.551 ms 15.600 ms 14.553 ms
5 204.255.169.234 (204.255.169.234) 14.996 ms 13.661 ms 15.424 ms
6 ae-2.r23.nycmny01.us.bb.gin.ntt.net (129.250.4.148) 14.953 ms 16.048 ms 14.726 ms
7 ae-6.r21.frnkge03.de.bb.gin.ntt.net (129.250.3.181) 109.988 ms 106.394 ms 107.488 ms
8 ae-1.r02.frnkge03.de.bb.gin.ntt.net (129.250.4.163) 105.110 ms 108.378 ms 104.977 ms
9 xe-3-2.r00.dsdfge02.de.bb.gin.ntt.net (129.250.5.61) 129.906 ms 141.522 ms 141.731 ms
10 213.198.77.122 (213.198.77.122) 105.035 ms 104.582 ms 105.151 ms
11 * * *
12 * xe-0-1-0-3.r02.frnkge03.de.bb.gin.ntt.net (129.250.5.62) 143.231 ms *
13 xe-0.level3.frnkge03.de.bb.gin.ntt.net (129.250.8.202) 161.436 ms 125.598 ms 159.774 ms
14 * vlan90.csw4.frankfurt1.level3.net (4.69.154.254) 262.171 ms 270.225 ms
15 ae-82-82.ebr2.frankfurt1.level3.net (4.69.140.25) 197.361 ms 214.021 ms 272.423 ms
16 ae-61-61.csw1.newyork1.level3.net (4.69.134.66) 219.914 ms 244.709 ms 214.996 ms
17 ae-21-70.car1.newyork1.level3.net (4.69.155.67) 232.323 ms * 203.640 ms
18 intelsat-in.car1.newyork1.level3.net (64.156.82.14) 319.879 ms * 219.131 ms
19 rvs-rt0003_fe-0-0 .intelsatone.net (209.159.170.215) 289.920 ms 357.010 ms 332.387 ms
20 202.72.96.6 (202.72.96.6) 832.528 ms 844.070 ms *
21 175.45.177.217 (175.45.177.217) 797.110 ms 839.233 ms 859.813 ms
... snip ...
40 * *^C
$ whois 175.45.177.217
... snip ...
inetnum: 175.45.176.0 - 175.45.179.255
netname: STAR-KP
descr: Ryugyong-dong
descr: Potong-gang District
country: KP
admin-c: SJVC1-AP
tech-c: SJVC1-AP
status: ALLOCATED PORTABLE
mnt-by: APNIC-HM
mnt-lower: MAINT-STAR-KP
mnt-routes: MAINT-STAR-KP
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks: This object can only be updated by APNIC hostmasters.
remarks: To update this object, please contact APNIC
remarks: hostmasters and include your organisation's account
remarks: name in the subject line.
remarks: -+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
changed: hm-changed@apnic.net 20091221
source: APNIC
role: STAR JOINT VENTURE CO LTD - network administrat
address: Ryugyong-dong Potong-gang District
country: KP
phone: +66 81 208 7602
fax-no: +66 2 240 3180
e-mail: sahayod@loxley.co.th
admin-c: SJVC1-AP
tech-c: SJVC1-AP
nic-hdl: SJVC1-AP
mnt-by: MAINT-STAR-KP
changed: hm-changed@apnic.net 20091214
source: APNIC
$
KP is North Korea. And their IP, 194.71.107.15, is indeed German. And telephone country code 66 is Thailand.
Hmm, tracepath and traceroute give me differing results. With traceroute the last hop I get is 202.72.96.6 which is apparently Cambodia. traceroute takes me from London to Germany to New York to Cambodia. It's a strange route.
As far as I've been able to research, these typesquatting domain traps started at the same time as Spamhaus CSS blacklist which was actually a company called Deteque.
If the MX has a large number of Hetzner IPs as mailservers, then it's probably Spamhaus.