For more than a decade, copyright holders have been sending ISPs takedown notices to alert them that their subscribers are sharing copyrighted material.

Under US law, providers have to terminate the accounts of repeat infringers “in appropriate circumstances” and increasingly they are being held to this standard.

Earlier this year several major record labels, represented by the RIAA, filed a lawsuit in a Texas District Court, accusing ISP Grande Communications of failing to take action against its pirating subscribers.

The ISP is not happy with the claims and was quick to submit a motion to dismiss the lawsuit. One of the arguments is that the RIAA’s evidence is insufficient.

In its original motion, Grande doesn’t deny receiving millions of takedown notices from piracy tracking company Rightscorp. However, it believes that these notices are flawed as Rightscorp is incapable of monitoring actual copyright infringements.

The RIAA disagreed and pointed out that their evidence is sufficient. They stressed that Rightcorp is able to monitor actual downloads, as opposed to simply checking if a subscriber is offering certain infringing content.

In a response from Grande, late last week, the ISP argues that this isn’t good enough to build a case. While Rightcorp may be able to track the actual infringing downloads to which the RIAA labels hold the copyrights, there is no such evidence provided in the present case, the ISP notes.

“Importantly, Plaintiffs do not allege that Rightscorp has ever recorded an instance of a Grande subscriber actually distributing even one of Plaintiffs’ copyrighted works. Plaintiffs certainly have not alleged any concrete facts regarding such an act,” Grande’s legal team writes (pdf).

According to the ISP, the RIAA’s evidence merely shows that Rightscorp sent notices of alleged infringements on behalf of other copyright holders, who are not involved in the lawsuit.

“Instead, Plaintiffs generally allege that Rightscorp has sent notices regarding ‘various copyrighted works,’ encompassing all of the notices sent by Rightscorp on behalf of entities other than Plaintiffs.”

While the RIAA argues that this circumstantial evidence is sufficient, the ISP believes that there are grounds to have the entire case dismissed.

The record labels can’t hold Grande liable for secondary copyright infringement, without providing concrete evidence that their works were actively distributed by Grande subscribers, the company claims.

“Plaintiffs cannot allege direct infringement without alleging concrete facts which show that a Grande subscriber actually infringed one of Plaintiffs’ copyrights,” Grande’s lawyers note.

“For this reason, it is incredibly misleading for Plaintiffs to repeatedly refer to Grande having received ‘millions’ of notices of alleged infringement, as if those notices all pertained to Plaintiffs’ asserted copyrights.”

The “misleading” copyright infringement evidence argument is only one part of the ISPs defense. The company also notes that it has no control over what its subscribers do, nor do they control the BitTorrent clients that were allegedly used to download content.

If the court ruled otherwise, Grande and other ISPs would essentially be forced to become an “unpaid enforcement agent of the recording industry,” the company’s lawyers note.

The RIAA, however, sees things quite differently.

The music industry group believes that Grande failed to take proper action in response to repeat infringers and should pay damages to compensate the labels. This claim is very similar to the one BMG brought against Cox, where the latter was eventually ordered to pay $25 million.

Source: TF, for the latest info on copyright, file-sharing, torrent sites and ANONYMOUS VPN services.

Source link

Next we have Arpit’s work upgrading Kodi’s add-on backend from Python2 to Python3

Python3 Support – arpitn30

My initial proposal was to support both Python2 and Python3 in Kodi by maintaining two versions of the same libraries and calling the required one depending upon the meta information in the XML files of the add-ons.

JUNE

During the first week of June, I was mostly understanding how everything was being built and what needs to be changed. I initially thought of updating the input to swig so that it can output python3, but I realised that Swig only changed the code to generic ML code which was given as an input to Groovy which with the help of Python Templates outputs Python code. So I cloned the Python templates directory and in the later weeks, I started to study and gradually change the python templates to that of Python3.

Aside from the major unicode string change, Python 3 changed a lot of things at the base level that drastically affected the Python-C API which was used to build the templates. So I went through each and every function and decided if it should return a unicode object or a byte object. I changed all the Python API function names, the module initialization, the Py_TPFLAGS, and changed the char data type in C to wchar data type. I also looked at all the data type which were being converted from C to Python and Python to C and inspected if any changes to data types in Python 3 like ‘map’ returning and iterable instead of lists and also changed the PyInt type which was no longer being used in Python3 API.

During the mid of June, when I started working to support both versions of Python, I was told to test if my code supported was even working with Python3 or not. So I forked my current working branch into 2 branches, one to test if my Python3 templates work correctly (testpy3) and the other to support both Python 2 and 3 (build2n3) and was working on them simultaneously. I also updated the HttpNetworkHandlers to Python3.

In Build2n3 branch, I changed paths of the Python libraries to the new Python3 directory, updated the Cmake files to download dependencies for both and keep them seperate.

In testpy3 branch, my main focus was to run the environment with as minimal changes as possible. So I removed 2 python template directories and made python3 the main directory. I had to change all the cmake files though to the updated dependency structure. After all the kinks had been removed Kodi was able to run with Python3 at the end of Phase 1 but the add-ons weren’t working yet.

JULY

The first thing I needed to do after the end of Phase 1 was to get the Python3 version of Kodi working, so that I could know if my code was working or not. The major trouble was that there wasn’t any way to know the error except the for only Log Entry of PythonModules not found. I skimmed through each and every documentation to figure out the changes which were made and the difference between them.

I found that the threads and GIL in Python3 are implemented differently than Python2. The acquirelock and releaselock functions are now deprecated and had to be changed with acquirethread which needed to have a saved state beforehand.

But the problem about the threads was still not solved. After a lot of testing and help from Paxxi and Rechi, we were able to identify the problem which was due to the duplication of state of _PyThreadState_current by Kodi and Python Bindings which resulted in the thread state being lost mid execution and we solved the problem by changing the cmake file in templates and adding the python binding directly to the xbmc core library.

After that, I started working on Build2n3 branch to apply the changes which were done in testpy3 branch and to figure out if it was possible to create two versions of libraries with the different implementation of threads even though it meant building Kodi twice while I was still looking into the ModuleNotFound error in the other branch which was still not resolved.

So I started working on Build2n3 branch. The problem I was having was with the env variables like PythonLibs and Python_include_dirs which can be only set to one of the versions at a time so we had to unset the variables after they were used and set them to the python3 directory. 

The main point now was if it was practical to go for a version that supports both Python 2 and 3 or skip a version and release just a python3 version whle giving the developers time to port. Changing a major amount of code just to support Python 2 and 3 only to revert it back to the current code one or two versions later seemed impractical if not impossible due to changing the implementation of handling of threads. Taking in account the time it took, just to find the bug and get just the Python3 version right, Razze asked me to focus on just Python3 version for now.

So going back to testpy3 branch, after searching for several days, we found out that the function which initialized the modules did not add it to the built-in modules in Python3 which wasn’t mentioned in most of the Python3 Porting guides. So we added statements to explicitly add it to built-in modules. And finally the ModuleNotFound error was gone.

After fixing a few bugs like correcting the charset conversion to wchar, updating the execution script, Python 3 Kodi was finally working with the built-on Kodi libraries being perfectly imported. 

In the next week, I checked the best way to make Kodi add-ons compatible with both versions of Python either by using __future__ packages or by using sys.major_version condition and I decided to go with the latter. I also made the versioncheck addon compatible with Python3 and added a pr to it. The addon was working perfectly with current version of Kodi as well as the Python3 version of Kodi.

Lastly, I decided to update the Python3 branch with the changes which were later made in the templates while working to support just Python3. So if we decide to go for a version to support both Python2 and 3, we can just fork from there. 

I also added the PyFile function into Kodi itself thus removing the dependency on Py3c fileshim.h.

I also tested the debug and release versions of Python3 Kodi on Windows 64 bit and it worked without any problems.

The Future

I’ve tested my code with Ubuntu using the natively installed packages and it seems to work. And after a few days, I’ve been able to build the master branch in Linux using the target packages only. I intend to finish updating the files for target version for Posix systems by the end of next week. I will port some of the add-ons to Python3 later on, and I need some time to clean up the code as well. Although I removed the commented code which I left behind from Python2, I still have to give it a final review before submitting my code. 

Source link

Any company in the security game can be expected to play up threats among its customer base in order to get sales.

Sellers of CCTV equipment, for example, would have us believe that criminals don’t want to be photographed and will often go elsewhere in the face of that. Car alarm companies warn us that since X thousand cars are stolen every minute, an expensive Immobilizer is an anti-theft must.

Of course, they’re absolutely right to point these things out. People want to know about these offline risks since they affect our quality of life. The same can be said of those that occur in the online world too.

We ARE all at risk of horrible malware that will trash our computers and steal our banking information so we should all be running adequate protection. That being said, how many times do our anti-virus programs actually trap a piece of nasty-ware in a year? Once? Twice? Ten times? Almost never?

The truth is we all need to be informed but it should be done in a measured way. That’s why an article just published by security firm ESET on the subject of torrents strikes a couple of bad chords, particularly with people who like torrents. It’s titled “Why you should view torrents as a threat” and predictably proceeds to outline why.

“Despite their popularity among users, torrents are very risky ‘business’,” it begins.

“Apart from the obvious legal trouble you could face for violating the copyright of musicians, filmmakers or software developers, there are security issues linked to downloading them that could put you or your computer in the crosshairs of the black hats.”

Aside from the use of the phrase “very risky” (‘some risk’ is a better description), there’s probably very little to complain about in this opening shot. However, things soon go downhill.

“Merely downloading the newest version of BitTorrent clients – software necessary for any user who wants to download or seed files from this ‘ecosystem’ – could infect your machine and irreversibly damage your files,” ESET writes.

Following that scary statement, some readers will have already vowed never to use a torrent again and moved on without reading any more, but the details are really important.

To support its claim, ESET points to two incidents in 2016 (which to its great credit the company actually discovered) which involved the Transmission torrent client. Both involved deliberate third-party infection and in the latter hackers attacked Transmission’s servers and embedded malware in its OSX client before distribution to the public.

No doubt these were both miserable incidents (to which the Transmission team quickly responded) but to characterize this as a torrent client problem seems somewhat unfair.

People intent on spreading viruses and malware do not discriminate and will happily infect ANY piece of computer software they can. Sadly, many non-technical people reading the ESET post won’t read beyond the claim that installing torrent clients can “infect your machine and irreversibly damage your files.”

That’s a huge disservice to the hundreds of millions of torrent client installations that have taken place over a decade and a half and were absolutely trouble free. On a similar basis, we could argue that installing Windows is the main initial problem for people getting viruses from the Internet. It’s true but it’s also not the full picture.

Finally, the piece goes on to detail other incidents over the years where torrents have been found to contain malware. The several cases highlighted by ESET are both real and pretty unpleasant for victims but the important thing to note here is torrent users are no different to any other online user, no matter how they use the Internet.

People who download files from the Internet, from ALL untrusted sources, are putting themselves at risk of getting a virus or other malware. Whether that content is obtained from a website or a P2P network, the risks are ever-present and only a foolish person would do so without decent security software (such as ESET’s) protecting them.

The take home point here is to be aware of security risks and put them into perspective. It’s hard to put a percentage on these things but of the hundreds of millions of torrent and torrent client downloads that have taken place since their inception 15 years ago, the overwhelming majority have been absolutely fine.

Security situations do arise and we need to be aware of them, but presenting things in a way that spreads unnecessary concern in a particular sector isn’t necessary to sell products.

The AV-TEST Institute registers around 390,000 new malicious programs every day that don’t involve torrents, plenty for any anti-virus firm to deal with.

Source: TF, for the latest info on copyright, file-sharing, torrent sites and ANONYMOUS VPN services.

Source link

Back in the summer of 2003 a group of developers debuted a new torrent client, which they called Azureus.

BitTorrent itself was still a relatively new technology at the time and users were eager to find new tools to transfer their files. The feature-rich Azureus client, which later rebranded to Vuze, delivered just that.

In recent years, however, things have gone relatively quiet, up to a point where Vuze development appears to have stalled completely. Perhaps not surprising, as two of the core developers, parg and TuxPaper, have left the project and moved on to something new.

“We are no longer involved in Vuze or Azureus Software, Inc. We can not speak to what their intentions are with the development of their product,” they inform us.

The developers, who were also part of the original Azureus team, are not saying farewell to their code though. While they are no longer working on Vuze, the pair have started a new Azureus branch, one they will actively maintain.

“We have invested such a large amount of our lives in the endeavor that we feel the need to keep the open source project active, for both our and our users’ enjoyment!” parg and TuxPaper tell us.

BiglyBT, as they have named their new client, will continue where Vuze development stalled. In addition to optimizing the code and releasing new features, BiglyBT is determined to keep the open source project alive, without any commercial interests.

“Our main goals for BiglyBT is to keep it ad-free and open source, and to continue to develop it into an even better torrent client. We also hope that a community will form again around the product.”

BiglyBT main window (large)

People who try the new client will notice that it’s indeed very similar to Vuze, but without the ads and some other ‘cluttering’ features, such as DVD-burning.

While BiglyBT looks and operates in a similar manner to Vuze, in the future the developers will work on a new set of features, a new style, and various other changes that will set it apart from its older brother.

“Our first release is mostly a name change, but we have removed some of the things that we know users don’t particularly want or use, such as the content network, games promotions, DVD burning, the huge ad in the corner of the app, and the offers in the installer.”

While Vuze appears to have downsized its development efforts, BiglyBT promises to go full steam ahead. The new client will also stay true to the Open Source nature. Previously, some people complained that Vuze included proprietary code, resulting in more restrictive license terms. BiglyBT is purely GPL, and will remain so.

The client is currently available on all major desktop platforms, including Windows, MacOS and Linux. An open source Android app, forked from Vuze remote, will follow in a few weeks.

BiglyBT should appeal to a wide range of users, especially the more seasoned torrent user who wants a client they can configure to their liking.

“Our target users are people who love to delve into the world of torrenting. People who like to tinker and watch torrents do their thing. Hoarders who like to seed, automate, categorize and contribute back to the torrenting community,” the developers note.

People who are interested in giving BiglyBT a spin can download the latest version from the official site. The application is free and won’t install any other applications or adware. Instead, it’s solely supported by donations from the public.

Source: TF, for the latest info on copyright, file-sharing, torrent sites and ANONYMOUS VPN services.

Source link