PHPHOST BLOG

Web Hosting Related Articles You May Need

How is my password stored in Linux?

Background

People that use Linux on a daily basis probably are completely oblivious to the actual mechanisms being used to store their passwords safely and securely on a given Linux system. Oh they might guess that their password is stored in the /etc/passwd file (they’d be wrong by the way) but most probably never even gave it a passing thought. So I thought I’d take the opportunity to shed some light on how Linux systems “stash” your precious password away.

Solution

So if your password isn’t actually stored in the /etc/passwd file then where does it get stored?

Answer: the /etc/shadow file.

This file is where all the keys to each user’s account are kept for safe keeping. Obviously only the root user can peer inside this file so all the commands we’ll be dealing with in this post, it should be assumed that you’ll need to either be root, or use sudo to run.

/etc/shadow

A typical /etc/shadow entry:

1
root:$6$bbmDJwcZHy5bgEDz$kFO.W/T7nUqcszZWl5RglxoDDAcDxevWpHVfN3v3f.Cx2ZeMcn5PX23VvnnkgtNWZf8hYtqsL0pPkZqyj50NY/:14362:0:33333:7:::

NOTE1: Don’t get too excited, the above isn’t really my entry, I made this one up.
NOTE2: Each field is separated by a colon (:) & we’re only concerned with the first two columns!

dissecting the hash

The key pieces to notice in that line of what looks like gibberish is the following:

  • The first column, root is the user whom this entry belongs to from the /etc/passwd file.
  • The second column, $6$..... is essentially the user’s hashed password.

Taking the second column apart further you should start to notice that’s it’s not complete gibberish after all.

For example:

  • the first couple of characters, $6$, is a mark that tells the system what type of hashing was used to hash the password.
  • The text between the next set of dollar signs, $bbmDJwcZHy5bgEDz$, is the actual salt that was used to hash your password.
  • Everything else after, is your password + salt hashed using whatever hash function was specified at the beginning, $6$, in our example here.

Specifically if you look at the man page for the crypt command, man 3 crypt there is a section that discusses what the $6$ notation means:

So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.

NOTE: So in our case the password + salt is being hashed using the SHA-512 scheme.

design details

For reference purposes here’s the rest of that excerpt from the crypt man page:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
If salt is a character string starting with the characters "$id$" followed by a
string terminated by "$":
 
       $id$salt$encrypted
 
then instead of using the DES machine, id identifies the encryption method used
and this then determines how the rest of the password string is interpreted.
The following values of id are supported:
 
       ID  | Method
       ─────────────────────────────────────────────────────────
       1   | MD5
       2a  | Blowfish (not in mainline glibc; added in some
           | Linux distributions)
       5   | SHA-256 (since glibc 2.7)
       6   | SHA-512 (since glibc 2.7)
 
So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an
SHA-512 encoded one.
 
"salt" stands for the up to 16 characters following "$id$" in the salt. The
encrypted part of the password string is  the actual computed password. The
size of this string is fixed:
 
MD5     | 22 characters
SHA-256 | 43 characters
SHA-512 | 86 characters
 
The characters in "salt" and "encrypted" are drawn from the set [a–zA–Z0–9./].
In the MD5 and SHA implementations the entire key is significant (instead of
only the first 8 bytes in DES).
Now what?

So by now you’re probably saying to yourself. OK, big deal, my password is hashed with some salt and stored in /etc/shadow. What else?

generating the hash manually using mkpasswd

For starters you can generate the $6$... string yourself manually using the mkpasswd command:

1
2
$ mkpasswd -m sha-512 password saltsalt
$6$saltsalt$qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/

In the above command we’re specifying that we want to use the SHA-512 hash, our password is the string password and our salt string is saltsalt. As before we can see in our resulting string the following components:

  • $6$ – which hash function was used
  • saltsalt – the string “saltsalt” was used
  • qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/ – password + salt hashed using SHA-512
generating the hash manually using Python

I came across the following nice Python one-liner that effectively does the same thing as the mkpasswd command discussed above.

1
2
3
$ python -c "import crypt, getpass, pwd; \
             print crypt.crypt('password', '\$6\$saltsalt\$')"
$6$saltsalt$qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/
generating the hash manually using Perl
1
2
$ perl -e 'print crypt("password","\$6\$saltsalt\$") . "\n"'
$6$saltsalt$qFmFH.bQmmtXzyBY0s9v7Oicd2z4XSIecDzlB5KiA2/jctKu9YterLp8wwnSq.qc.eoxqOmSuNp2xS0ktL3nh/
authconfig

Before I wrap up I thought I’d mention one final tool authconfig that’s included on Red Hat distros such as Fedora, CentOS, and RHEL. This tool allows you to change what hash algorithm is being used on a particular system. The command to change a system to use SHA-512 would be as follows:

1
authconfig –passalgo sha512 –update

See the man page for authconfig for more details.

conclusions

And with that you are now a little more in the know as to how Linux systems take your password and store them in the /etc/shadow file.

References

links
Posted in encryption, linux, passwords, Security, SHA-512, shadow, Syndicated, sysadmin, tutorials | Leave a comment

How to rsync certain files, exclude the rest, all while ignoring .svn directories?

I came across this question on the Stack Exchange site Unix & Linux. The question interested me so I answered it but thought I’d cross post it on my blog as well, given I took a pretty significant amount of time to put together a test case and write-up of how the solution ultimately worked.

Problem

I’m using rsync to copy some files from a share to another.

Recursively, I need to:

- delete files at the destination that are deleted in the origin
- Only sync php and js files
- exclude de rest of file types
- Don’t delete .svn/ directory in the destination

If I use this:

rsync -zavC --delete --include='*.php' --include='*.js' --exclude="*" /media/datacod/Test/ /home/lucas/Desktop/rsync/

Then rsync is not recursive because exclude=”*” excludes all files but also folders

If I add --include="*/" then the .svn/ directory gets deleted (it also gets included)

How can I solve this mind blasting dilemma?

Solution

The solution I ultimately came up with made use of a little known feature, at least to me, called filters. Filters allow you to play games with the includes/excludes by protecting portions based on regular expressions. Read on, I’ll discuss them further down.

1
2
rsync -avzC --filter='-rs_*/.svn*' --include="*/" --include='*.js' --include='*.php' \
     --exclude="*" --delete dir1/ dir2/

test data

To help determine if my solution was going to work or not I created some sample data so that I could test it out. For starters I wrote a script that would generate the data. Here’s that script, setup_svn_sample.bash:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#!/bin/bash
 
# setup .svn dirs
mkdir -p dir{1,2}/dir{1,2,3,4}/.svn
 
# fake data under .svn
mkdir -p dir1/dir{1,2,3,4}/.svn/origdir
mkdir -p dir2/dir{1,2,3,4}/.svn/keepdir
 
# files to not sync
touch dir1/dir{1,2,3,4}/file{1,2}
 
# files to sync
touch dir1/dir{1,2,3,4}/file1.js
touch dir1/dir{1,2,3,4}/file1.php

Running the above script produces the following directories (dir1 & dir2):

source dir

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
$ tree -a dir1
dir1
|-- dir1
|   |-- file1
|   |-- file1.js
|   |-- file1.php
|   |-- file2
|   `-- .svn
|       `-- origdir
|-- dir2
|   |-- file1
|   |-- file1.js
|   |-- file1.php
|   |-- file2
|   `-- .svn
|       `-- origdir
|-- dir3
|   |-- file1
|   |-- file1.js
|   |-- file1.php
|   |-- file2
|   `-- .svn
|       `-- origdir
`-- dir4
    |-- file1
    |-- file1.js
    |-- file1.php
    |-- file2
    `-- .svn
        `-- origdir

destination dir

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ tree -a dir2
dir2
|-- dir1
|   `-- .svn
|       `-- keepdir
|-- dir2
|   `-- .svn
|       `-- keepdir
|-- dir3
|   `-- .svn
|       `-- keepdir
`-- dir4
    `-- .svn
        `-- keepdir

Running the above rsync command which includes the --filter below we can see that it’s only syncing the files that match the --include patterns:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
rsync -avzC --filter='-rs_*/.svn*' --include="*/" --include='*.js' --include='*.php' \
     --exclude="*" --delete dir1/ dir2/
sending incremental file list
dir1/file1.js
dir1/file1.php
dir2/file1.js
dir2/file1.php
dir3/file1.js
dir3/file1.php
dir4/file1.js
dir4/file1.php
 
sent 480 bytes  received 168 bytes  1296.00 bytes/sec
total size is 0  speedup is 0.00

Resulting dir2 afterwards:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ tree -a dir2
dir2
|-- dir1
|   |-- file1.js
|   |-- file1.php
|   `-- .svn
|       `-- keepdir
|-- dir2
|   |-- file1.js
|   |-- file1.php
|   `-- .svn
|       `-- keepdir
|-- dir3
|   |-- file1.js
|   |-- file1.php
|   `-- .svn
|       `-- keepdir
`-- dir4
    |-- file1.js
    |-- file1.php
    `-- .svn
        `-- keepdir

Why does it work?

The key piece to this script is to make use of the filters capability of rsync. Filters allow you to remove files from the matched set at various points in the command. So in our case we’re filtering any files that match the pattern */.svn*. The modifiers -rs_ tell the filter that we want to filter on both the source side as well as the target side.

excerpt from the FILTER NOTES section of rsync’s man page

- An s is used to indicate that the rule applies to the sending side. When a rule affects the sending side, it prevents files from being
transferred. The default is for a rule to affect both sides unless --delete-excluded was specified, in which case default rules become sender-side only. See also the hide (H) and show (S) rules, which are an alternate way to specify sending-side includes/excludes.

- An r is used to indicate that the rule applies to the receiving side. When a rule affects the receiving side, it prevents files from being deleted. See the s modifier for more info. See also the protect (P) and risk ® rules, which are an alternate way to specify receiver-side includes/excludes.

See man rsync for more details.

Tips for figuring this out (hint using --dry-run)

While describing how to do this I thought I’d mention the --dry-run switch to rsync. It’ extremely useful in seeing what will happen without having the rsync actually take place.

For Example

Using the following command will do a test run and show us the decision logic behind rsync:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
rsync --dry-run -avvzC --filter='-rs_*/.svn*' --include="*/" \
     --include='*.js' --include='*.php' --exclude="*" --delete dir1/ dir2/
sending incremental file list
[sender] showing directory dir3 because of pattern */
[sender] showing directory dir2 because of pattern */
[sender] showing directory dir4 because of pattern */
[sender] showing directory dir1 because of pattern */
[sender] hiding file dir1/file1 because of pattern *
[sender] showing file dir1/file1.js because of pattern *.js
[sender] hiding file dir1/file2 because of pattern *
[sender] showing file dir1/file1.php because of pattern *.php
[sender] hiding directory dir1/.svn because of pattern */.svn*
[sender] hiding file dir2/file1 because of pattern *
[sender] showing file dir2/file1.js because of pattern *.js
[sender] hiding file dir2/file2 because of pattern *
[sender] showing file dir2/file1.php because of pattern *.php
[sender] hiding directory dir2/.svn because of pattern */.svn*
[sender] hiding file dir3/file1 because of pattern *
[sender] showing file dir3/file1.js because of pattern *.js
[sender] hiding file dir3/file2 because of pattern *
[sender] showing file dir3/file1.php because of pattern *.php
[sender] hiding directory dir3/.svn because of pattern */.svn*
[sender] hiding file dir4/file1 because of pattern *
[sender] showing file dir4/file1.js because of pattern *.js
[sender] hiding file dir4/file2 because of pattern *
[sender] showing file dir4/file1.php because of pattern *.php
[sender] hiding directory dir4/.svn because of pattern */.svn*
delta-transmission disabled for local transfer or --whole-file
[generator] risking directory dir3 because of pattern */
[generator] risking directory dir2 because of pattern */
[generator] risking directory dir4 because of pattern */
[generator] risking directory dir1 because of pattern */
[generator] protecting directory dir1/.svn because of pattern */.svn*
dir1/file1.js
dir1/file1.php
[generator] protecting directory dir2/.svn because of pattern */.svn*
dir2/file1.js
dir2/file1.php
[generator] protecting directory dir3/.svn because of pattern */.svn*
dir3/file1.js
dir3/file1.php
[generator] protecting directory dir4/.svn because of pattern */.svn*
dir4/file1.js
dir4/file1.php
total: matches=0  hash_hits=0  false_alarms=0 data=0
 
sent 231 bytes  received 55 bytes  572.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)

In the above output you can see that the ./svn directories are being protected by our filter rule. Valuable insight for debugging the rsync.

References

- Delete extraneous files from dest dir via rsync?
- Above scripts in a tarball

Posted in rsync, script, Syndicated, tutorials | Leave a comment

Slider with Sliding Backgrounds

Among the many super nice design features of the Yahoo! Weather app for iOS is the transition between city screens. The background image doesn’t just move away as the screen moves from one screen to the next, the background image itself slides. It appears to be hiding some of the “old” screen and revealing more of the “new” screen those closer you have it to being in full view.

Let’s try and pull it off on the web.

The HTML

Like any slider, there are three main components:

  • The container that holds everything into shape
  • A sliding container that is as wide as all the slides in a row
  • Each individual side container

We won’t bother too much with content inside the slide. I’ll just add the temperature to show each slide can indeed hold content on top.

<div class="slider" id="slider">
  <div class="holder">
    <div class="slide" id="slide-0"><span class="temp">74°</span></div>
    <div class="slide" id="slide-1"><span class="temp">64°</span></div>
    <div class="slide" id="slide-2"><span class="temp">82°</span></div>
  </div>
</div>

The container might be a <section>, slides might be <article>. It really depends. I’ll let you make the semantic choices for your own needs.

The layout plan is like this:

The CSS

The “slider” (visual container) and the slides need to have explicity the same size. We’ll use pixels here but you could make it work with anything.

.slider {
  width: 300px;
  height: 500px;
  overflow-x: scroll;
}
.slide {
  float: left;
  width: 300px;
  height: 500px;
}

Floating those slides to the left isn’t going to make them line up in a row, because the parent element of the slides isn’t wide enough to let them do that. That’s one of the reasons we need the holder element. It will be 300% wide (Num. of slides × 100%) which will fit three slides exactly.

.holder {
  width: 300%;
}

Each one of our slides has a unique ID. This is useful because, if we choose, we can create anchor links that link to those ID’s and the slider will “jump” to those slides. We’ll add JavaScript to do some actual “sliding”, but our slider will work even without that. ID’s make that possible, so let’s use them here to drop in some lovely background images.

#slide-0 {
  background-image: url(http://farm8.staticflickr.com/7347/8731666710_34d07e709e_z.jpg);
}
#slide-1 {
  background-image: url(http://farm8.staticflickr.com/7384/8730654121_05bca33388_z.jpg);
}
#slide-2 {
  background-image: url(http://farm8.staticflickr.com/7382/8732044638_9337082fc6_z.jpg);
}

With all this in place, our layout comes into shape:

The CSS (black fading)

Just as a small detail, the temperature set in white may be in danger of not being visible depending on the photo behind it. To ensure that it is, we can make the photo subtly fade to black toward the bottom. A pseudo element will do nicely.

.slide:before {
  content: "";
  position: absolute;
  bottom: 0;
  left: 0;
  width: 100%;
  height: 40%;
  background: linear-gradient(transparent, black);
}

A picture explanation is in order here:

The JavaScript (background sliding)

We’re going to use jQuery here because we love life. Our goal is the adjust the background-position of the slides as we scroll. We can set background-position in percentages in CSS, but that alone doesn’t do the cool hide/reveal more effect we’re looking for. Based the amount scrolled (which we can measure in JavaScript), we’ll adjust the background-position. Alone, that would look something like this:

$("#slider").on("scroll", function() {
  $(".slides").css({
    "background-position": $(this).scrollLeft()/6-100+ "px 0"
  });
});

The “6″ and “-100″ in there are magic numbers. Not CSS magic numbers that are prone to frailty, but traditional magic numbers. Just some numbers that happen to make the effect work. A bummer, perhaps, but not that big of a deal. Design-y things are sometimes like that. Perhaps best to leave a comment in the code to that effect. These particular numbers are based on the images I used and their size and what looked good.

The effect here is the background shifting we’re after:

Notice the less of the yellow streetcar is visible when the slide is almost out of view.

The JavaScript (imparting structure)

That little snippet of JavaScript looks lonely up there without any structure behind it. A slider is a great excuse to look at a simple way to structure JavaScript.

We can make everything slider-related one object.

var slider = {

};

Then we’ll group up the related elements into one area, bind our events together, and write little functions that do very specific things.

var slider = {

  el: {
    slider: $("#slider"),
    allSlides: $(".slide")
  },

  init: function() {
    // manual scrolling
    this.el.slider.on("scroll", function(event) {
      slider.moveSlidePosition(event);
    });
  },

  moveSlidePosition: function(event) {
    // Magic Numbers
    this.el.allSlides.css({
      "background-position": $(event.target).scrollLeft()/6-100+ "px 0"
    });
  }

};

slider.init();

The HTML (adding navigation)

Adding swipe stuff would be super (super) sweet (hint). But for now let’s add little press-able links to change slides, rather than relying on the scrollbar. You might even remove the scrollbar in real life (straight up overflow: hidden; on the container). What we need is anchor links that link to the ID’s of the individual slides.

<nav class="slider-nav">
  <a href="#slide-0" class="active">Slide 0</a>
  <a href="#slide-1">Slide 1</a>
  <a href="#slide-2">Slide 2</a>
</nav>

Style those as you will. For the demo, I make them little tiny gray circles with the text hidden.

The JavaScript (adding navigation)

Our structure is more useful now. We simply add a few more elements we’re dealing with, add a new event we’re watching for (clicks on nav), and write a little function to deal with that event.

We know how far to animate the scroll position when a nav link is clicked from the ID on the link itself. The link might be href=”#slide-1″, which we can get “1″ from easily. Then the position we need to scroll to is (1 × width of slide), so 300 in our case. We’ll store that 300 value right in the JavaScript.

var slider = {

  el: {
    slider: $("#slider"),
    allSlides: $(".slide"),
    sliderNav: $(".slider-nav"),
    allNavButtons: $(".slider-nav > a")
  },

  timing: 800,
  slideWidth: 300, // could measure this

  init: function() {
    // You can either manually scroll...
    this.el.slider.on("scroll", function(event) {
      slider.moveSlidePosition(event);
    });
    // ... or click a thing
    this.el.sliderNav.on("click", "a", function(event) {
      slider.handleNavClick(event, this);
    });
  },

  moveSlidePosition: function(event) {
    // Magic Numbers
    this.el.allSlides.css({
      "background-position": $(event.target).scrollLeft()/6-100+ "px 0"
    });
  },

  handleNavClick: function(event, el) {
    // Don't change URL to a hash, remove if you want that
    event.preventDefault();

    // Get "1" from "#slide-1", for example
    var position = $(el).attr("href").split("-").pop();

    this.el.slider.animate({
      scrollLeft: position * this.slideWidth
    }, this.timing);

    this.changeActiveNav(el);
  },

  changeActiveNav: function(el) {
    // Remove active from all links
    this.el.allNavButtons.removeClass("active");
    // Add back to the one that was pressed
    $(el).addClass("active");
  }

};

slider.init();

We have an “active” class on the nav links just to use in CSS to visually indicate which slide is active. We handle that by removing “active” from all links and then adding it back to the one that was clicked.

Demo!

Check out this Pen!

Slider with Sliding Backgrounds is a post from CSS-Tricks

Posted in Article, Syndicated | Leave a comment

Using MvcScaffolding Packages to Generate Repositories for your LoB Applications

ASP.NET MVC’s tooling support goes a long way in making it a LOB Application friendly platform. However the default Controller scaffold contains direct references to the DBContext. This is a little smelly when it comes to separation of concerns and can often lead to ending up with ‘fat-controllers’. Instead, if our Scaffolder could generate a Repository Interface and its corresponding

Posted in ASP.NET MVC, Syndicated | Leave a comment

Using MvcScaffolding Packages to Generate Repositories for your LoB Applications

ASP.NET MVC’s tooling support goes a long way in making it a LOB Application friendly platform. However the default Controller scaffold contains direct references to the DBContext. This is a little smelly when it comes to separation of concerns and can often lead to ending up with ‘fat-controllers’. Instead, if our Scaffolder could generate a Repository Interface and its corresponding

Posted in ASP.NET MVC, Syndicated | Leave a comment

Implementing Pagination in ASP.NET Web API using OData operators

ASP.NET Web API is a framework that makes it easy to build HTTP services for various types of clients from Microsoft to Non-Microsoft technologies. The new programming model of developing over HTTP is made simple and flexible by using WebAPI. We can design services which can be accessible from a broad range of clients, including browsers and mobile devices.

One of the most frequent

Posted in ASP.Net, ASP.NET Web API, Syndicated | Leave a comment

Appeal Over Former RIAA Lobbyist Judge Allowing Prenda To Get Info On Over 1,000 John Does Moves Forward

You may recall Judge Beryl Howell, the former RIAA lobbyist who helped author the DMCA, and also went against a very large number of other judges dealing with copyright trolling lawsuits by ruling that it was perfectly fine to lump over 1,000 John Doe defendants into a single lawsuit and then get discovery on them for the purpose of shaking them down for payment. While so many other courts have ruled that such lumping together is an abuse of the legal system in misjoining unrelated parties, Howell not only stuck to her guns, but then proceeded to blame ISPs for copyright trolls, suggesting that if they just did more to crack down on infringing, trolls wouldn’t be a problem.

What you may not remember is that the key case in which Howell did this happens to be a case involving… you guessed it… AF Holdings and its “law firm” Prenda Law. Oh, and the “copyright assignment” that AF Holdings is using for this case was one of those supposedly signed by… Alan Cooper. While Judge Howell may be well served to pay attention to Judge Otis Wright in California and his actual investigation into Prenda/AF Holdings/Alan Cooper, the case is out of her hands for now, as the various ISPs who have the info in this particular case have appealed Howell’s ruling and the EFF, ACLU, Public Citizen and Public Knowledge have stepped in as well with additional arguments in an amicus brief.

Both briefs are well worth reading, though you might be surprised that the amicus brief is probably the more reserved of the two. The ISPs who took part include: Bright House, Cox, Verizon, AT&T and Comcast — with most of them (Verizon and Comcast being the exceptions) not even providing service in the jurisdiction of the district court: Washington DC. Comcast joining in is interesting, given that they own NBC, but we’ll leave that aside for now. To put it mildly, the ISPs think the appeals court should put an end to these kinds of cases, noting that a majority of other courts have refused to allow joinder on so many defendants, and have blocked the discovery process. It points out, of course, that these cases are almost never taken to court, but are usually just used to reveal names and then offer settlement demands. Specifically, they feel that Howell made a pretty big legal mistake, in that a showing of “good cause” is required for discovery, and Howell ignored that.


The district court’s conclusion that rules governing personal jurisdiction and
venue provide no impediment to pre-Rule 26 discovery of the ISPs is legal error.
A showing of “good cause,” which is required for discovery ostensibly intended to
identify defendants, requires an evaluation of whether the information sought from
the ISPs would be used to name and serve defendants in the forum. See, e.g.,
Oppenheimer Fund, Inc. v. Sanders, 437 U.S. 340, 352-53 & n.17 (1978) (where
“the purpose of a discovery request is to gather information for use in proceedings
other than the pending suit, discovery properly is denied”). The Copyright Act and
the District of Columbia’s long-arm statute limit the court’s reach to defendants
who reside in the district. And the uncontroverted evidence before the district
court showed that few, if any, of the targeted Internet subscribers reside in the
District of Columbia—as publicly available geolocation software used by
Plaintiff’s counsel in other cases confirms. The district court’s decision to defer
any consideration of personal jurisdiction or venue until after the subscribers’
personal information had been disclosed to Plaintiff requires reversal.

The court’s decision to permit discovery of the ISPs before deciding whether
the 1,000-plus “Does” are misjoined provides an additional basis for reversal.
Plaintiff, by routinely declining to name and serve defendants after obtaining the
subscribers’ personal information, virtually ensures that Rule 20’s requirements for
joinder will go unaddressed if not evaluated at the outset. And as a growing
majority of courts have concluded, deferring a ruling on joinder deprives the courts
of filing fees and encourages a proliferation of improperly coercive lawsuits.
Given the groundswell of published opinions that disagree with the lower court and
have severed or dismissed non-resident “Does” or all Does except for “Doe No. 1,”
deferring a ruling on joinder in a suit that seeks nationwide subscriber information
also encourages forum shopping—as the record here shows persuasively.

The ISPs also, quite reasonably, point out that if mass joinder and discovery is allowed in this case, the trolls will descend on the DC Circuit courts in a mass forum shopping situation:


The record
reflects that Plaintiff’s counsel’s cases have migrated across the country, with the
venues selected, not by the locus of the parties or situs of harm, but based on
counsel’s perceptions of which forum is most likely to authorize the greatest
discovery, at the lowest cost, with the least judicial oversight.

The specter of intra-district, judge-specific shopping in Plaintiff’s counsel’s
cases further underscores the problem with the lower court’s approach. The ISPs
raised below Plaintiff’s counsel’s practice of filing complaints and dismissing them
vel non based on the judicial assignment—only to re-file in another court. When presented with the same facts, Judge Wilkins quoted with approval Judge Huvelle’s finding: “Plaintiff’s actions a[re] akin to ‘judge
shopping.’… This Court could not agree more.” …

The ISPs respectfully submit that the district courts in this Circuit should not
be the destination for 1,000-plus Doe cases that are brought primarily to compile
mailing lists—not to adjudicate actual cases or controversies
.

The ISPs also go through, in detail, the accusations against Team Prenda, and the claims of Alan Cooper. As it notes:


AF Holdings and its counsel owe a duty of candor to the Court, and a duty of
fairness to appellants…. The serious issues concerning attorney misconduct and potentially forged
documents were not identified for the court below; they necessarily affect the
“good cause” analysis and provide an alternative basis for reversal to address the
evidence now being considered in the pending disciplinary proceedings in the
Central District of California.

The EFF/ACLU/PK/PC filing is more focused on the specific errors in Howell’s ruling, concerning the “good faith” standard for discovery and the mass joinder of over 1,000 people. They also point out the jurisdiction problems of the defendants who are clearly outside the jurisdiction of a DC court — and the fact that these cases rarely end up in actual lawsuits means that the question of proper venue will not be “cured” later. Finally, the brief argues that Howell ignored key First Amendment issues concerning revealing anonymous internet users, and the higher standard for them to be revealed. This argument wasn’t made by the ISPs, so we’ll focus on that one here. It points to the key Dendrite standard we’ve discussed many times before concerning the revealing of anonymous users. This does not mean that you cannot identify those accused of copyright infringement, but rather that you can’t go on a random fishing expedition to get names, as many copyright trolls have done.


Specifically, in a series of cases beginning with Dendrite Int’l, Inc. v. Doe
No. 3, 775 A.2d 756, 760-61, 342 N.J. Super. 134 (App. Div. 2001), courts have
adopted a balancing standard to assess requests for early discovery to identify
anonymous online speakers that protects the right to speak anonymously while at
the same time ensuring that plaintiffs who have valid claims are able to pursue
them. Without such a standard, abusive plaintiffs could too easily use extrajudicial
means against defendants from whom they could not, in the end, obtain judicial
redress. See Levy, Litigating Civil Subpoenas to Identify Anonymous Internet
Speakers, 37 Litigation No. 3 (Spring 2011).

The use of BitTorrent to select and share movies is expressive and,
therefore, protected by the First Amendment. Call of the Wild Movie, 770 F. Supp.
2d at 350 (“[F]ile-sharers are engaged in expressive activity, on some level, when
they share files on BitTorrent, and their First Amendment rights must be
considered before the Court allows the plaintiffs to override the putative
defendants’ anonymity.”).

Although the expressive aspect of the conduct alleged here – the posting of
copyrighted movies to BitTorrent – is somewhat minimal, that does not mean that
discovery to identify the anonymous user without adequate initial evidence that
individual Doe Defendants committed the alleged infringement. The weakness of
AF Holdings’ assertions of personal jurisdiction and proper joinder means that
First Amendment concerns weigh more strongly here in favor of quashing the
subpoenas. Certainly it was not appropriate for the district court to ignore the
question altogether.

It will be interesting not only to see how the appeals court deals with it… but also Prenda’s argument, since they seem to be getting more and more wacky lately.

Permalink | Comments | Email This Story





Posted in Syndicated | Leave a comment

Eric Holder Claims Terrorists Are Involved In ‘IP Theft’

You may have heard about a fair bit about Attorney General Eric Holder testifying before the House Judiciary Committee on Wednesday morning. He was — quite reasonably — raked over the coals by members of both parties for the incredible decision to obtain phone records from AP reporters, under very questionable circumstances.

There was one other odd tidbit that might be worth discussing around here as well. Suddenly, in the middle of all the questions about the Associated Press, Rep. Mel Watt — who, during the SOPA markup famously declared that he didn’t understand the technology, or why tech people were concerned, but also that he didn’t care and wanted to pass SOPA without bothering to understand — started asking questions about copyright and “enforcement.” Yes, Mel Watt is the ranking member on the IP subcommittee (scary enough in its own right), but it seemed completely off topic.

Most of the coverage on Watt’s questioning has focused on the fact that he did most of his questioning with his two-year-old grandson on his lap, who interrupts the questioning at one point. But the questions were ridiculous, as were the answers, and deserve some scrutiny. First, despite it being soundly rejected when SOPA went down in flames, Watt asks Holder if Congress should make online streaming of infringing material a felony, rather than the misdemeanor that it currently is. There are all sorts of problems with this idea, as we’ve discussed in the past, but Holder embraced the idea wholeheartedly, saying that the Justice Department would love to have “another tool,” ignoring just how widely the DOJ has abused existing tools to shut down legitimate companies and websites.

And then Watt directly asks about a connection to terrorism:


Watt: Are there increasing indications of links between this problem and terrorism? Have you found any of those links and would you describe them for the committee?

Holder: Yes, that’s a very good question. It’s something that’s very worrisome. As we saw organized crime get into a variety of other businesses in order to support their efforts, we’re now seeing terrorist groups getting into the theft of intellectual property. Again, to generate money to support what they’re trying to do for their terrorist means. So we have to broaden our enforcement efforts, broaden the investigative efforts that we take, to examine what are the precise reasons why people are engaging in this kind of intellectual property thievery. And to consider whether or not there’s a terrorist connection to it. This is a relatively new phenomenon, but one we have to be aware of.

Watt then asks about things that Congress can do to help, and Holder says he’s “particularly concerned” about this problem, and he asks for “enhanced penalties” for “intellectual property theft.”




That all sounds very interesting. And it might be, if there were any truth to it at all. Unfortunately, there’s not. We’ve yet to see a single piece of evidence supporting the idea that terrorists are involved in infringement. The claim has been around for years, and we’ve asked for evidence for years, and none has ever been provided. Because it doesn’t exist. Researcher Joe Karaganis looked into the issue a few years ago and found that there were some very vague reports of organized crime being involved in counterfeit CDs/DVDs in the 80s and 90s. But that was small and short-lived — in large part because online infringement basically made that business obsolete:


Arguing that piracy is integral to such networks [organized crime and terrorism] means ignoring the dramatic changes in the technology and organizational structure of the pirate market over the past decade. By necessity, evidentiary standards become very loose. Decades-old stories are recycled as proof of contemporary terrorist connections, anecdotes stand in as evidence of wider systemic linkages, and the threshold for what counts as organized crime is set very low. The RAND study, which reprises and builds on earlier IFPI and Interpol reporting, is constructed almost entirely around such practices. Prominent stories about IRA involvement in movie piracy and Hezbollah involvement in DVD and software piracy date, respectively, to the 1980s and 1990s. Street vendor networks in Mexico City–a subject we treat at length in the Mexico chapter–are mischaracterized as criminal gangs connected with the drug trade. Piracy in Russia is attributed to criminal mafias rather than to the chronically porous boundary between licit and illicit enterprise. The Pakistani criminal gang D-Company, far from “forging a clear pirate monopoly” in Bollywood, in RAND’s words, plays a small and diminishing part in Indian DVD piracy–its smuggling networks dwarfed by local production.

The US record isn’t more convincing in this regard. Jeffrey McIllwain examined the Department of Justice’s IP-related prosecutions between 2000 and 2004 and found that only 49 out of the 105 cases alleged that the defendant operated within larger, organized networks. Nearly all of these were “warez” distribution groups for pirated software–hacker communities that are explicitly and often fiercely non-commercial in orientation. McIllwain found “no overt references to professional organized crime groups” in any of the DOJ’s criminal charges (McIllwain 2005:27). If organized crime is a serious problem in these contexts, it should not be difficult to produce a stronger evidentiary record.

In other words, Rep. Mel Watt, a well known supporter of Hollywood’s position on copyright, tossed a bogus softball FUD talking point to Eric Holder in the middle of an important hearing about a very different subject, and Holder proceeded to make claims to Congress that have been made for decades without a single bit of evidence to support it.

Holder has plenty of other serious issues to deal with these days, but it makes me incredibly uncomfortable to see our Attorney General appear to be spreading known scare stories that have been proven bogus from decades ago as if they’re new, despite a single bit of evidence concerning any modern connection to terrorism.

Permalink | Comments | Email This Story





Posted in Syndicated | Leave a comment

UK Recording Industry Looks To Censor More Sites With No Trial Or Conviction

Once the UK recording industry realized that UK courts would order ISPs to block websites it didn’t like, it appears that the industry, led by BPI and PPL began putting together a list of over two dozen sites that they’re asking to have blocked by all UK ISPs, even though many of the sites on the list have never been tried in a court of law or convicted of copyright infringement. Included on the list, for example, is Grooveshark, who has been sued, but has not yet been found to violate copyright laws. It may very well be true that there is infringement on many, if not all of those sites. But, generally speaking, there’s this thing called due process that allows a site to defend itself before being censored from an entire country. Just because a site has some infringing content does not mean that the entire site should be blocked — or you’d have absolutely no user generated content sites online, because the liability would be too high. The UK courts started down this slippery slope by allowing sites to be blocked, and now the record labels are just going to keep piling the list higher and higher.

Permalink | Comments | Email This Story





Posted in Syndicated | Leave a comment

Kiwis Want To Spy On All Communications, VPNs, And Be Able To Use Secret Evidence Against You

Although New Zealand’s decision not to allow patents for programs “as such” was welcome, other moves there have been more problematic. For example, after it became clear that the New Zealand intelligence service, the Government Communications Security Bureau (GCSB), illegally wiretapped and spied on Kim Dotcom, the New Zealand government announced that it would change the law so as to make it legal in the future to snoop on New Zealanders as well as on foreigners. Judging by a major new bill that has been unveiled, that was just the start of a thoroughgoing plan to put in place the capability to spy on every New Zealander’s Internet activity at any moment.

Here’s an excellent analysis of what the bill proposes, from Thomas Beagle, co-founder of the New Zealand digital rights organization Tech Liberty:


The TICS [Telecommunications (Interception Capability and Security)] Bill is a replacement for the Telecommunications (Interception Capability) Act 2004. This law forced communications providers (ISPs, telcos, data networks, etc) to provide “lawful intercept” capabilities so that the Police, SIS and GCSB could access communications once they had a suitable warrant. The new bill expands and clarifies these requirements.

However, the addition of the word “security” is the key to what has changed. The new bill now gives the GCSB sweeping powers of oversight and control over the design, deployment and operation of all data and telecommunications networks run by network providers in New Zealand. The stated reasons are to both protect New Zealand’s infrastructure and to ensure that surveillance agencies can spy on traffic when required. As part of this, the GCSB will have the power to stop network providers from reselling overseas services that do not provide these capabilities.

As Beagle goes on to explain, this will have a number of implications, including a requirement to build backdoors into all telecoms networks:


From the Bill:

A network operator must ensure that every public telecommunications network that the operator owns, controls, or operates, and every telecommunications service that the operator provides in New Zealand, has full interception capability.

Note that the surveillance agencies still need to have a legally issued warrant (under the Search & Surveillance Act, NZ SIS Act, or GCSB Act) to actually intercept any communications and there are obligations to avoid capturing communications that are not covered by the warrant.

Here’s one way that could dramatically impact Internet users in New Zealand:


It then goes on to give the Minister the power to ban the resale of an off-shore telecommunications service in New Zealand if it does not provide interception capabilities. This could stop the resale of foreign-hosted VPNs, instant message services, email, etc.

Another clause could have major implications for Megaupload:


Network operators must decrypt the intercepted communications if they have provided the encryption, but there is no obligation to do so if the encryption is provided by others.

What does this mean for providers such as Mega (file locker) or LastPass (password storage) who have a business model based on the fact that they supply a cloud product that uses encryption but have deliberately designed it so that they can not decrypt the files themselves? This gives users the assurance that they can trust them with their data. Will the government close them down unless they provide a backdoor into the system?

One deeply troubling aspect is the following:


There is also a provision that allows the courts to receive classified information in a court case in the absence of the defendant or the defendant’s lawyer. This applies to information that might reveal details of the interception methods used by the surveillance agency or is about particular operations in relation to any of the functions of the surveillance agency, or is provided as secret information from the surveillance agencies of another country. It can also be used if that disclosure would prejudice security of NZ, prejudice the maintenance of law, or endanger the safety of any person.

As Beagle notes:


particularly offensive to civil liberties are the provisions for convicting people based on secret evidence. How can you defend yourself fairly when you can’t even find out the evidence presented against you?

He concludes with an important point:


One must ask where the justification for this expansion of power is coming from. Has New Zealand already been materially affected by attacks on our communications infrastructure? It seems clear that while the GCSB may not be that competent at exercising the powers they already have, they have done a fine job of convincing the government that they can handle a lot more.

That’s a question that needs to be put to the governments of other countries, like the US and UK, that are also seeking to extend massively their ability to spy on their own citizens. What evidence do they have that such extreme, liberty-threatening powers are actually necessary, and will make the public safer, rather than simply being a convenient way for governments to identify whistleblowers who expose their incompetence and corruption, say, or to spy on those who dare to oppose them?

Follow me @glynmoody on Twitter or identi.ca, and on Google+

Permalink | Comments | Email This Story





Posted in Syndicated | Leave a comment