New Feature: Proposals

BuySellAds is excited to announce our latest tool to help publishers: proposals.

You might have noticed this new feature’s appearance in the drop down menu in the upper right-hand corner of your account after we gave our interface a little makeover. If you’re unsure of how you can utilize proposals to advance your website’s success, don’t worry! We made a short video explaining what the proposals feature is, when you would use it, and how you would use it with a step by step guide.

Try drafting up a proposal today, and get in touch if you have any questions.

Slated to launch in June, Kantar Media will publish the BuySellAds catalog of directly sold ad inventory within SRDS.com, giving media planners access to buy inventory directly from publishers through a programmatic insertion order and proposal system.

BuySellAds’ publisher inventory will now gain additional exposure among all major US agencies who use the SRDS.com platform to plan digital media campaigns, including those at the four largest advertising holding companies. The synchronization of BuySellAds’ publisher inventory to 3rd party buying and planning tools is the next logical step in solidifying BuySellAds as a “central hub” for publishers to manage their directly sold digital ad inventory.

Once this is live, we’ll share some screenshots of the integration. This is great news for BSA publishers, and there’s no extra effort required to take advantage of this additional exposure for your available inventory.

Nathan Wong is the co-founder and head of the tech side of BSA. He wrote an informative piece about some changes with password security at BuySellAds. You can see the original post, and Nathan’s other writings, over at Nathan.ca

Lock

Image courtesy of WickedVT

As of this morning we have officially migrated everyone’s password at BuySellAds over to bcrypt. I’m almost ashamed it took us so long – especially since it turned out to be so straight-forward to switch. If you still believe MD5 or SHA-1 is sufficient for passwords, read this post and get to work.

The final push that motivated us to switch to bcrypt was Kickstarter’s security breach. I was watching our always-endearing tech community lambast them for storing nearly-plaintext passwords when it hit me: we’re storing nearly-plaintext passwords. Damn!

The next day I put in an open-ended ticket to figure out a migration plan for switching to bcrypt. One of our developers, Jon Hehir, handled most of it from there.

The premise is simple: in order to avoid having any MD5-hashed passwords in the database at all, simply bcrypt the old hashes, and continue to double-hash passwords when new ones come in. This is in contrast to the common advice to “version” passwords and only update them when people login (i.e. when you have a plaintext version of the password on hand). It’s highly likely that you have older users who will never login again, though, and they deserve their password to be stored properly too.

In PHP, handling bcrypted passwords is easy:

  • Use password_hash($input, PASSWORD_BCRYPT, array('cost' => 13)); to encode the given password that you want to store in the database.
  • Use password_verify($input, $storedhash); to compare whether the given password matches the hash you stored in the database.
  • If you aren’t on PHP 5.5 yet, include the compatibility library too.

Coupled with the migration strategy above, that’s all you need to know. The above functions handle hashing, salting, storing the salt, versioning, and everything else you need. It really is that easy – arguably simpler than what we had before – so there are no excuses.

In our case, we did run into one additional snag where we were storing cookies that contained a hash of a login salt and the user’s hashed password. We’ve since switched to storing a unique random hash in the cookie instead. This did, however, delay our ability to remove the old passwords from the database for users who we knew had logged in recently. This meant we had to wait until we knew their cookies had all expired to avoid logging them out prematurely.

Nonetheless, I’m extremely relieved to know that we no longer have any nearly-plaintext passwords in our database or in our cookies. I expect to sleep a little better tonight. If you’re still using MD5 or SHA-1, what are you waiting for? Go switch to bcrypt now!

iubenda is a privacy policy generator that automatically updates your site’s privacy policy to conform with current laws and best practices. You never have to update or keep track of these changes, since iubenda does it for you. This is why BuySellAds decided to partner with them. Simon Schmid of iubenda has written a short piece to introduce our publishers to privacy policies and explain why they’re important.

At iubenda we are constantly adding new clauses and observing the international privacy policy landscape. We host and automatically send updates to our users’ policies when global changes are needed.

As of a recent update iubenda’s privacy policy generator now has a clause for BuySellAds users. Therefore it’s now as easy as a click of a button to disclose your use of advertising technology to your users and display an appropriate privacy policy on your site along with the ads.

To celebrate this occasion we’ve decided to give BuySellAds users an introductory offer, for 50% off on their first year subscription with iubenda. You can claim your offer by using this coupon code.

iubenda BuySellAds Privacy Policy

There’s another thing that I would like to talk about now that we’ve made this offer. Even if you’re not taking us up on it, you may find it interesting to hear about some of the latest developments in the “Do Not Track” discussions that Todd Garland had written about earlier (FTC’s Proposed ‘Do Not Track’ List).

Do Not Track is a proposed technology that essentially allows users to tell websites they don’t want their browsing behavior tracked. Wikipedia defines DNT as follows in technical terms:

The Do Not Track (DNT) header is the proposed HTTP header field DNT that requests that a web application disable either its tracking or cross-site user tracking (the ambiguity remains unresolved) of an individual user. (…)”.

Until now there is no legal requirement for website operators to use DNT.

California, however, recently introduced Do Not Track amendments to their existing privacy regulations via Assembly Bill no. 370. This change affects everyone who either operates their site from California or who has users/consumers that reside in California. The CalOPPA now states:

(5) Disclose how the operator responds to Web browser “do not track” signals or other mechanisms that provide consumers the ability to exercise choice regarding the collection of personally identifiable information about an individual consumer’s online activities over time and across third-party Web sites or online services, if the operator engages in that collection. 

In other words, this change doesn’t bring a requirement to sites to implement Do Not Track technology, but a requirement to inform if you are in fact making use of DNT technology, or not. Therefore If you are making use of the technology, make sure that you outline exactly what this means for the user and how his DNT request is being honored.

These kind of changes are exactly why users have found iubenda helpful. It is both time-consuming and risky to track all the legal changes required of sites in today’s society, everything is moving too fast and is too disputed. Give iubenda a try, and see how easy it is to let them keep you at the top of your game.

Going to SXSW?

So are we! If you’re interested in meeting one of us in real life, tweet at Marc (@marcman), or Andrew (@AndrewDertinger) and we’ll do our best to catch up with you.

We’ll be there from early afternoon Friday, to Tuesday morning.

SXSW Interactive 2014