Personal

I first noticed this two years ago (http://www.destructuring.net/2012/03/23/dreamhost-ux-security-flaw/) and contacted Dreamhost. It has yet to be fixed.

If you create a “Private” subversion repository on Dreamhost ( username + password are required to view ) and then add a “One Click Install” of Trac to that private repository ( which is marked as “Private” in their installer ), the Trac instance does not have any security permissions. The entirety of your source code is readable through the Trac browser.

Here’s a illustration:

• Private SVN Repository – http://svn.2xlp.com/ExampleTracSvn/svn
• Default Trac Install – http://svn.2xlp.com/ExampleTracSvn/trac/browser/README.txt

While many people may want to have a Publicly readable repo for ticketing, I think it’s safe to say that most people who use a “One Click Install” are not familiar enough with the intricacies of Trac to know about it’s permissions system.

If you’re affected the easiest fix you can implement, is to add a .htaccess file to your trac directory.

A better fix, is to get off Dreamhost’s OneClickInstall entirely. The Trac One-Click-Install is a halfassed and terrible approach.

Dreamhost did something smart with their Subversion install. Your home directory has a `svn` subdirectory which contains some specific files for each subversion repo:

* RepoName/ ( the actual repo )
* RepoName.access (a .htaccess file for your repo )
* RepoName.passwd ( a htpassed file for the repo’s access file )

It’s a very smart an elegant solution. The Trac install, however, is anything but.

1. Dreamhost installs one version of the Trac library in your home directory for each trac instance. If you have 5 tracs, you have 5 directories like `~/webroot_svn_2xlp_com_ExampleTracSvn_trac_trac`

2. Dreamhost installs the entire Trac environment and database in a web directory. The configuration files, database, everything, are available in an Apache served directory — controlled only by .htaccess files.

A better way to manage Trac, is to create a `~/trac` subdirectory of your home folder, and centralize all your trac projects. You can then use .htaccess files and symlinks to expose the relevant directories to the internet at large.

This will guard you against situations where an erroneous .htaccess file renders your contents as raw-data ( it happens ).

If you have more than one Trac installation, you would probably benefit from installing Trac as a Python library and having multiple projects reference it.

Every so often a file accidentally gets dropped onto my OSX sidebar. Usually I can command-click and `remove from sidebar` via the contextual. If the file has been deleted, no contextual menu pops up.

I tried every trick posted on Apple’s forums to fix this , nothing worked.

Then I had an idea — what if I figured out what the file was, and then replaced that file. Would OSX let me delete it from the sidebar manually ?

It did! FINALLY!

So here’s what did work on my 10.6.8 Macbook :

After a bit of `grep`ping, I found the offending entry in “~/Library/Preferences/com.apple.sidebarlists.plist”

It’s a binary plist, so it’s a pain to edit directly.

Looking at the contents via `more` or `vi` , I found the offending entry along with what looked to be a file path. There was a pointer to the file in “/Users/jvanasco/.Trash/NONEXISTANT_FILENAME”

This worked on first try:

1. `touch /Users/jvanasco/.Trash/NONEXISTANT_FILENAME`
2. restart Finder.app ( “Force Quit” by clicking command+option+esc, then selecting Finder”
3. select the bad item on the sidebar, command-click, and delete via the contextual menu item

A few months ago I got an email from my friend’s startup. It looked something like this:

I immediately saw a problem – the text to the right of the Subject line was the standard “crap” text that people dismiss. He wasn’t optimizing the email for increased open rates.

When I was at IAC/TDB, the legacy email systems had the same issues. When I upgraded vendors, I also had the templates updated to allow for a smarter email marketing strategy.

Instead of using the “If you can’t see this email” message at the top, we changed the text to act as a content-preview that could sell-in some of the other stories within the inbox/list view. Below you can see the difference during the changeover. The difference in value proposition to users for an open is quite clear — and the updated format was very compelling.

How to accomplish this? You just need to understand that most email programs ( Gmail , Apple’s Iphone/Mac Mail, etc) will pull the first few lines of text as a preview. You want to control that and use it to your advantage.

Originally we designed the email to look like this:

An influential person in the company didn’t like that leading text, so it had to be removed.

No worries, the fix was simple, I just had everything wrapped in a custom “invisible” style to make it essentially hidden:

<span style="font-size:1px; color:#fff;height:1px;">Hidden Text Here</span>

The open rates (which were already pretty high) increased substantially. Several readers consciously noticed the format change, and wrote in with gratitude — it helped them not miss stories that mattered.

As a side note, the “nav bar” at the top of the email [Home…Books] disappeared in the second image because an influential person required that to be killed too. I strongly disagreed with that decision – it was a great source of click-throughs and a “best practice” taught to me by multiple of the top email marketers in the industry ( and backed up with analytics + constantly reiterated each time ). The click through rate dipped because of those links leaving ( people did not click elsewhere ), but the overall numbers increased from the open-rate improvements to offset it.

Nobody likes the NSA , or anyone else , spying on their email activities.

Many secure email systems have all shuttered , because they were compelled by courts to invalidate their security or feared that possibility.

Here are two popular models and weaknesses :

1. *Send/Receive unencrypted email , encrypt on server.* This is what Lavabit did. The weakness is that the government is able to compel the provider to copy/clone/divert the unencrypted mail.

2. *Web based mail, encrypted in browser.* Hushmail did this. Their weakness is that the government is able to compel them to deliver a compromised applet/library onto the client side browsers.

In order for email to be reasonably secure, it requires a few key components:

1. *End-to-End Encryption.* Data must be encrypted by the Sender and decrypted by the receiver. Service providers should never be able to access a plaintext version or have the means to decrypt a message.
2. *Full Transparency of Code.* Email clients must publish their source code and libraries, so that any sort of backdoors can be identified. Without open-source and full transparency, Service Providers and Software Vendors can be compelled by courts to offer insecure products.
3. *Required Encryption.* Plaintext emails should not be deliverable at all. This would force widespread adoption of secure email , and keep ‘snoopable’ email off of email servers.

In order to achieve this , I suggest the start of novel improvements to current email as follows:

1. All emails should be encrypted via public-key cryptography within the email client.
– Outbound email is encrypted for the Recipient
– Drafts are encrypted for the Sender
– An email header contains a digest of the key used for encryption
2. SMTP should be extended with new commands and responses ( SSMTP ). Generally speaking :
– SMTP servers should reject unencrypted email
– SMTP servers should reject email with an unknown or expired Public Key

It would be trivial to extend a SMTP server like Exim with those requests. Many mail servers easily connect to SQL or LDAP backends to find delivery information; extending this information with a list of VALID and INVALID public keys for each user is trivial.

A current SMTP example looks like this ( from http://en.wikipedia.org/wiki/SMTP )

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:
S: 250 Ok
C: RCPT TO:
S: 250 Ok
C: RCPT TO: S: 250 Ok
C: DATA
S: 354 End data with .
C: From: “Bob Example”
C: To: “Alice Example”
C: Cc: [email protected]
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

A more secure version would be:

S: 220 smtp.example.com SSMTP Postfix

note that Secure SMTP is required

C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:
S: 250 Ok
C: RCPT TO:
S: 250 Ok
C: PUBLIC KEY: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb
S: 250 Ok

A hash of the public key is provided. It is allowed.

Perhaps the key has been expired ?

C: PUBLIC KEY: ca978112ca1bbdcafac231b39a23dc4da786eff8147c4e72b9807785afee48bb
S: 541 EXPIRED KEY

Assuming we have the key, send the message…

C: RCPT TO: S: 250 Ok
C: DATA
S: 354 End data with .
C: From: “Bob Example”
C: To: “Alice Example”
C: Date: Tue, 15 January 2008 16:02:43 -0500
C: Subject: Test message
C: <<>>
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

The message is encrypted in a payload

There are some caveats with this approach.

1- This greatly complicates multiple recipients — ie , CC and BCC

2- A new Mail format might be needed. Currently, email headers contain a lot of sender/recipient information — as well as the subject lines. In order to be fully secure, the Subject line needs to move into the encrypted payload. Other headers would need to either move or be stripped. at the least, something like this should exist.

MESSAGE
+ unencrypted headers
– to
– from
+ encrypted payload
– headers
. subject
. etc
– body

3- The distribution of Public Keys is troublesome. At first I thought servers could advertise public keys as a directory service, and delivery failures could contain a “New Key” attachment. However, this creates a potential for a man-in-the-middle attack. For example, the NSA could compel an ISP to work with them by advertising an NSA key , decrypting and storing the message, then re-encoding the message with the proper key. It would be possible to identify this with Message Signing , but one or more messages would have been stolen.

Nevertheless, a secure method of distributing and verifying public keys would be needed.

There are complications and weaknesses in this approach, but I feel they are significantly smaller than other approaches I’ve seen lately.

In any event, I don’t think it’s possible to make the current SMTP system reasonably secure — I believe we need to change/extend it.

I like to read recaps of late-night talk show monologues. Craig Ferguson’s really resonated with me ( paraphrased: I’m sick of this shit ).

Then I clicked to this HuffingtonPost article for a recap of Conan O’Brien. It infuriated me. http://huffingtonpost.com/2013/04/16/conan-addresses-boston-marathon-bombing_n_3091426.html?utm_hp_ref=comedy

As I start reading a recap of Conan O’Brien’s monologue, all of the sudden there’s audio coming out of my computer of an incredibly annoying woman talking. WTF?

I’m not watching a video. There’s no ad on the screen. I keep scrolling down several page heights.

And there it is… the Huffington Post has pre-roll video commercials running auto-play as pre-roll to a gallery after the article — more than 2050 pixels down the screen.

This is shitty beyond belief.

* The obvious issue is that I’m hearing an incredibly annoying ad for Dannon yogurt while reading a story about a terrible tragedy. This is not a great moment in content adjacency — this is quite horrible.
* Add the fact that it’s a hidden ad that just started playing , without me triggering anything — and it’s quite offensive.
* This is as horrible a “media buy” as one could imagine.
** Long Pre-Roll ads aren’t a good ad unit. 30 seconds without the ability to skip out is really bad and makes the brand look bad to users.
** Pre-Roll is supposed to be a “premium” ad unit. Selling a premium unit to client — but then delivering it as both an autoplay ad AND on an *incredibly* off screen page element — cheapens the unit beyond worth. This is an antagonistic unit to both the brand and consumer. As a consumer, I had to hunt to look for an ad on the page. As a brand, I pay for impressions and views. AOL/HuffingtonPost created an advertising product that effectively hid the ad unit on screen, keeping people from turning it off — or even actually viewing the ad unit.

Stuff like this doesn’t happen by accident. Having worked in advertising and publishing, some scenarios are the more likely reasons:

* AOL/HuffingtonPost was incredibly shady, and started pumping “premium” ad sales into non-premium units in order to fulfill an inventory order or take advantage of traffic spikes.
* AOL/HuffingtonPost purposefully sold a sub-standard unit to Dannon’s media buying agency, claiming it’s premium inventory.
* AOL/HuffingtonPost and Dannon’s media buying agency colluded to divert a portion of their spend of “premium units” into non-premium units like these.

The least likely scenarios ?

* Dannon’s media buying agency wanted to buy units like this, because they thought it was a great investment for their client.

* This is all just a mistake, and AOL/HuffingtonPost is not greedy or doing anything shady – their technology and advertising teems are just grossly inept.

If I had to choose only one option, I’d guess that AOL/HuffingtonPost is trying to earn extra revenue by hiding “premium” videos on traffic spike ( Boston tragedy related ) pages. Welcome to the wonderful world of online publishing.

I feel sorry for Dannon and am really disgusted by AOL/HuffingtonPost. I can’t seem to figure out who buys digital inventory for Dannon; Havas’ MPG unit ( now Havas ) handled TV media for Dannon as far back as December, but there doesn’t seem to be any mention about online buying.

Attached, a stitched screen…

The blue line is approximately 2050 pixels down the screen; the ad unit is the “embedded gallery” directly below it. The average browser window hight right now is around 750pixels, making that ad unit appear on the 4th page.

I’ve been transferring my domains over to Dreamhost.com after Name.com & GoDaddy.com both turned out to be run by complete assholes. ( reference [Name.com is doing some really sketchy stuff](http://www.destructuring.net/2013/02/28/name-com-is-doing-some-really-sketchy-stuff/) )

During the Dreamhost transfer process, I noticed an odd behavior and brought it up with their Customer Support team. After numerous back & forths, they don’t seem to understand the issue I’ve brought up. Perhaps you will…

When you receive an confirmation request from Dreamhost at the ‘outbound’ registrar’s email address, you’ll read this message:

Re: Transfer of destroybrooklyn.com

New Dream Network, LLC (dba DreamHost.com) has received a request from

jonathan vanasco

via our web administration panel on 2013-03-18 for us to become the new
registrar of record.

You have received this message because you are listed as the
Registered Name Holder or Administrative contact for this domain name
in the WHOIS database.

Please read the following important information about transferring
your domain name:

* You must agree to enter into a new Registration Agreement with
us. You can review the full terms and conditions of the Agreement at
http://dreamhost.com/tos.html

* Once you have entered into the Agreement, the transfer will take
place within five (5) calendar days unless the current registrar of
record denies the request.

* Once a transfer takes place, you will not be able to transfer to
another registrar for 60 days, apart from a transfer back to the
original registrar, in cases where both registrars so agree or where a
decision in the dispute resolution process so directs.

If you WISH TO PROCEED with the transfer, you must respond to this
message via one of the following methods (note if you do not respond
by 2014-03-18, destroybrooklyn.com will not be transferred to us.).

* please go to our website,

https://panel.dreamhost.com/ct.cgi?g=SOME_BIG_NUMBER&d=destroybrooklyn.com

to confirm.

If you DO NOT WANT the transfer to proceed, then don’t respond to this
message.

If you have any questions about this process, please contact
[email protected].

You might have noted that the text of that email just says “Do you want to approve this transfer from Godaddy to Dreamhost?”. It doesn’t say who at Dreamhost initiated the request. It doesn’t give a “Transaction ID” that can link the request I made when starting this Transfer , to this confirmation request.

The webpage you click onto is equally as cryptic:

Attention: [email protected]

Re: Transfer of destroybrooklyn.com

New Dream Network, LLC (dba DreamHost.com) has received a
request on 2013-03-18 08:37:23 for us to become
the new registrar of record.

You have received this message because you are listed as the
Registered Name Holder or Administrative contact for this domain name
in the WHOIS database.

Please read the following important information about transferring
your domain name:

• You must agree to enter into a new Registration Agreement with
  us. You can review the full terms and conditions of the Agreement at
  http://dreamhost.com/tos.html

• Once you have entered into the Agreement, the transfer will take
  place within five (5) calendar days unless the current registrar of
  record denies the request.

• Once a transfer takes place, you will not be able to transfer to
  another registrar for 60 days, apart from a transfer back to the
  original registrar, in cases where both registrars so agree or where a
  decision in the dispute resolution process so directs.

If you WISH TO PROCEED with the transfer, please click “Approve”
below. (Note if you do not respond by 2014-03-18, destroybrooklyn.com will
not be transferred to us.)

If you DO NOT WANT the transfer to proceed, then ignore this page, or click “Deny” above.

If you have any questions about this process, please contact
[email protected].

While both the email and webpage seem to have “SOME_BIG_NUMBER”, they’re a transaction ID that appears on the email as a query_string, is a hidden value on the HTML page, and something I’ve never seen before during my transfer initiation.

Perhaps I’ve become a bit too security-minded in my age, but this scenario really jumps out at me — if someone knew that I was likely to transfer a domain to Dreamhost ( which is something more than a few people have tweeted about ) , another party could ostensibly try and transfer a domain at the same time — and I would have no idea what I’m approving. Granted, one would need to get a Registrar Authorization Code in order to initiate a domain transfer — but there are plenty of stories online involving email hacking, password guessing, and registrar manipulation to get that done. While the email does state my name, if I wanted to trick someone into giving up their domain… I could just use their public whois data ( or their twitter info ) to have that seemingly populated.

An exploit like this is admittedly an edge case… but it’s possible and there’s such a silly little fix to this sort of situation — giving the transaction a unique id ( which is probably already has ) , and making that ID clear to both the account requesting a transfer and the one approving a transfer.

Do you wish to approve the transfer DomainXYZ from GoDaddy to Dreamhost ?

Could so easily be…

Do you wish to approve the transfer DomainXYZ from GoDaddy to Dreamhost, with the TransactionID 12345 ?

Dear Name.com,

Yesterday I noticed, via a typo, that your name servers are performing a “DNS Hijack” on all Third-Level domain queries. If an exact Third-Level domain is not configured , instead of responding with a NXDOMAIN (non-existant domain) status, your servers direct users to a “domain parking page” which you fully control and monetize.

After blogging about your practice of [Hijacking DNS for failed queries yesterday](http://www.destructuring.net/2013/02/28/name-com-is-doing-some-really-sketchy-stuff/) I learned that you have been doing this for years, and have frustrated countless bloggers and consumers on sites such as “Get Satifsaction”. Thanks to it trending on [HackerNews](http://news.ycombinator.com/item?id=5299534) I also learned that many other internet professionals have been subject to your antics over the years ( [even 2 years ago on HackerNews](http://news.ycombinator.com/item?id=2443710 ) )

You’ve defended this practice multiple times as being enabled by your registration services agreement:

* [http://nathanhammond.com/namedotcom-another-unscrupulous-registrar](http://nathanhammond.com/namedotcom-another-unscrupulous-registrar)
* [http://www.name.com/blog/general/domains/2012/01/pro-tip-how-to-get-rid-of-that-pesky-parking-page/](http://www.name.com/blog/general/domains/2012/01/pro-tip-how-to-get-rid-of-that-pesky-parking-page/)

And in your own words you state:

> It is standard practice in the registrar world, and it is spelled out in our TOS.

I have some news for you : this is completely not standard for a registrar. And when I read your TOS more closely, it seems to completely runs afoul of your TOS too.

Let me be clear about this : Your DNS Hijacking is beyond being sketchy and wrong — it is illegal and not covered by your Terms of Service justifications.

Section 21 of your Terms of Service states:

---

>21. Parked domain service

>All domain names registered via Name.com will automatically be provided a Parked Domain Service. All domains will default to our name servers unless and until you modify your default settings. At any time, you may disable the placeholder page by updating, modifying or otherwise changing the name servers for the relevant domain name.

>Domain names using our Parked Domain Service may display a placeholder page for your future website. These placeholder pages may include contextual and/or other advertisements for products or services. Name.com will collect and retain any and all revenue acquired from these advertisements, and you will have no right to any information or funds generated via the Parked Domain Service.

>You agree that we may display our logo and links to our website(s) on pages using the Parked Domain Service.

>Name.com will make no effort to edit, control, monitor, or restrict the content displayed by the Parked Page Service. Any advertising displayed on your parked page may be based on the content of your domain name and may include advertisements of you and/or your competitors. It is your responsibility to ensure that all content placed on the parked page conforms to all local, state, federal, and international laws and regulations.

>It is your obligation to ensure that no third party intellectual or proprietary rights are being violated or infringed due to the content placed on your parked page. Neither Name.com nor our advertising partners will be liable to you for any criminal or civil sanctions imposed as a direct or indirect result of the content or links (or the content of the websites to which the links resolve) displayed on your parked pages.

>As further set forth above, you agree to indemnify and hold Name.com and its affiliated parties harmless for any harm or damages arising from your use of the Parked Domain Service.

---

Let’s focus on what has happened in the context of the first two paragraphs of Section 21 ( and ignore the egregious and abusive language on the rest of the clause , which you should be totally ashamed of) :

* I registered my domain with Name.com
* I updated my DNS record entries with name.com
* You continued to serve “parked pages” and monetize DNS failures

Upon configuring DNS services for my domain by modifying the default settings despite remaining with Name.com, I effectively and legally opted-out of your Parked Domain service for that domain. I literally “unparked” the domain when establishing specific DNS records. Additionally, while my “Domain Name” specifically fell under the “Parked Domain Service” terms which your lawyers explicitly crafted , the third-level domain names which you are monetizing against do not.

There exists no items in your Terms Of Service that state :

* DNS failures will be treated as a parked page and/or monetized
* Third-level domain names will be monetized ( your lawyer specifically identified the “domain names” registered , not the subdomains which fall under the aforementioned domain’s registration )
* Users of Name.com for DNS services will also be covered by a Parked Domain policy

I’d also note that there exists no space on your administration console that notifies users that their unspecified third-level domains are falling under a “parked domain” monetization scheme or that ( according to your blog instructions ) a “*” wildcard entry must be created to disable these monetization pages. And to speak for a moment from a technical standpoint — aside from breaking the RFC describing how DNS should work, your system is completely unable to deliver a NXDOMAIN status code — pushing a wildcard entry to a specific address or TXT entry is not that same thing as saying “I don’t exist”.

Technically, Legally, and Ethically you are completely in the wrong.

At this point, you’ve lost me as a customer. There’s nothing you can say or do — I don’t have enough time in my day for bullshit like this. I’m in the process of finding a new registrar and I would never consider using you again. Your actions and defenses are beyond redeemable. They are underhanded and downright sleazy.

I’m writing you to strongly suggest that you to “Do the right thing” for all your remaining customers – and yourself – and stop this practice immediately. By immediately, I mean “you should really call in your CTO and VP Engineering as you read this , and have turn things off before they go home tonight”.

Your underhanded scheme to generate revenue compromises the security and privacy of every domain under your DNS services. Unless a user knows the bizzarre trick to disable your “Domain Parking” pages , their website is vulnerable to XSS ( Cross Site Scripting ) attacks through your monetization partners. Additionally, unless a consumer’s cookie was locked down to a single Fully Qualified Domain Name, those cookies would be sent to your business partners as well. ( I’d also add that while Name.com suggests you operate these services yourselves , yesterday the domains were displaying logos for Sedo.com. )

If you’re not familiar with DNS Hijacking or all the risks that you’ve put your customers at, I suggest you start reading this [WikiPedia entry on DNS Hijacking](http://en.wikipedia.org/wiki/DNS_hijacking).

Aside from the various privacy concerns this raises, or the laws this breaks in specific jurisdictions — as these “Parked Pages” occur from DNS Failures on domains configured via your systems — the indemnifications and blame shifting available under Clause 21 would likely not be applicable and you would fully liable. I’m not a lawyer, but having dealt with numerous contracts and negotiations on behalf of technology companies , I really can’t imagine any lawyer, judge or jury agreeing that the near-infinite number of “Third Level Domains” (or 4th, 5th, etc) for an explicitly configured “Second Level Domain” fall within the terms of you Domain Parking language , or that any of your claimed rights exist after a DNS entry has been updated.

I’d also note that, until this deceptive and underhanded practice is stopped, every new client signing up for your service is a candidate for a potential class action lawsuit. Your greedy and indefensible attempt at generating negligible revenue has put the security of countless internet users at risk, in addition to exposing your own customers to serious security and legal complications.

Sincerely,
Jonathan Vanasco

---

---

Attention: Name.com Customers,

If you use Name.com for DNS services , [a comment on Hacker News by Machrider]( http://news.ycombinator.com/item?id=5300205 ) suggests a very effective way to quickly address your situation

Quoted below:
> My workaround for this was to add a TXT record for *.mydomain.com that just returns a string like “Unused”. This seems to stop them from hijacking any subdomains, and it’s not an A record so undefined subdomain names do not resolve, just like if you had not defined them in the first place.
> (Workaround shouldn’t be necessary of course, but this kind of bullshit is par for the course with cheap hosting companies.)

In the wake of patent trolling against some Podcasting companies, several House members have devised the SHIELD act to protect people from Patent Trolls.

This is a horrible, terrible bill. I am firmly against it.

If you read the actual bill – http://www.scribd.com/doc/127669554/H-R-845-2013-Shield-Act-re-patent-trolls — it legislates the scenario where a non-original inventor must post a bond covering full court costs in order to litigate a patent claim.

The costs of serious Patent litigation ( not a trolling one ) where it is proven that one party violated another’s patents , averages $3-5 million dollars. Under this law, if an independent inventor wants to sell their invention ( I’m not sure what would happen if a company is acquired ), that invention is no longer covered by the clause and effectively tremendously devalued — requiring bonds that are potentially millions of dollars to be posted if litigation were ever to happen.

The free market effects of this are obvious – it creates an economy where independent inventors have a tremendously reduced ability to sell their innovations , and secondary patent holders can be infringed upon with almost guaranteed impunity.

* Who wants to buy a Patent if you need at least 5 Million dollars to defend it ?
* Why respect a patent if you know the rightsholder won’t be able to raise enough money to sue ?

On top of all this, some of the most notorious Patent Trolls are totally immune from this law. Many of these companies set up co-owned trusts/business entities or licensing schemes where there is joint ownership of the IP Rights with the inventor — enabling them protections under the “original inventor” clause of this bill.

This law does little but ensure that patent litigation can only happen between a David and Goliath, precludes small/medium businesses from exerting patent protections, and seriously undermines the incentive for independent entities or small businesses to support innovation.

It is horribly misguided.

If you want to directly fix the situation, address 35 U.S.C. § 285 : “court in exceptional cases may award reasonable attorney fees to the prevailing party.” Tone down “exceptional” and attorney fees can be awarded when appropriate. Create a USPTO review and recertification process for (oft?) litigated patents. Create a variety of means to directly address the issue of Patent Trolling , without damaging inventors.

Stopping Patent Trolls can – and should – be done… but this law is an attack on individual inventors and the incentive to innovate / fund research & development.