5vforest

Your cited source literally says the opposite:

> While Trenton and Paterson saw spikes this year, other cities like Newark and Jersey City haven’t seen much of a change.

The `href` attribute of the visible mole could pass the data back to the server.

We use Percy.io for this and can't recommend it enough. It integrates with your CI workflow, which makes a whole lot more sense to me than waiting until production. (Or to be fair, staging.)

Good info! I really have no clue what I'm doing. Just trying to help coworkers figure out if they need to uninstall any apps, really :)

Augmented it with a bit of Ruby in order to find the "SUFeedURL", which if using the `http` protocol, means that an application is vulnerable.

https://gist.github.com/ajb/876107d0edc0f2c11779

## The Department of Better Technology - http://www.dobt.co/ - REMOTE

Our one-sentence tagline: We are dedicated to making great software that helps governments and non-profits better serve their communities.

If you've ready some of the recent posts about US Digital Service or 18F, we're doing similar stuff, but from the outside-in, with mostly SaaS products. (Our flagship product, Screendoor: http://www.dobt.co/screendoor)

We're bootstrapped, profitable, and we'd love to find folks who are passionate about this kind of work. Stack is Rails / Postgres / JS -- nothing too fancy, but we're serious about the quality of our code. We're big on open-source, too: github.com/dobtco/

If you're interested in hearing more, email me at adam (at) dobt (dot) co

Half of the post is about how the new technique is vulnerable to clickjacking.

Ruby Developer to Fix America Department of Better Technology Headquarters: USA http://www.dobt.co

About us

We’re the Department of Better Technology, a Knight Foundation-funded startup that’s digging into the guts of government and trying to fix it with technology.

Job Details

We're hiring a web developer to help us revolutionize the world of government IT. We started this company after being embedded inside government and seeing first-hand the horrors of the technology that these folks have to use everyday. We worked on a project called RFP-EZ that made it super simple to view and bid on government contracts. It wasn't anything amazing -- just a simple Bootstrap site, but just by making this process easier to understand for web firms who don't specialize in government contracting, we were able to save the federal government an average of 30%.

We've been in business for a just under a year, and have already created dozens of success stories - governments who are using our software to save staff time, save money, and provide better experiences for citizens. We're looking to grow our team and help us scale this success to governments across the country.

Experience

We're looking to bring on a developer who fits the following:

You are experienced in Ruby and ideally, Rails You have strong knowledge of SQL/Postgres You have a passion for good user experience and are excited about frontend development, too You are comfortable working with a 100% distributed team And last, but perhaps most important, you are as passionate as we are about our mission to revolutionize government IT

Our Culture

For many people in the technology industry, DOBT is a different kind of place to work, and a different set of people work here. Usually, they’re people who value time more than they value money. While from time to time, circumstances may call for it, you aren’t going to see a lot of 80 hour weeks, and depending on your time zone you might see some people who clock out at around 6.

You’re probably not going to be in a work environment that has a foosball table, catered lunches, and its own mass transportation either. That’s because we’re a fully remote firm. While some people may opt to work together in the same space, we want people to work from wherever they feel like it. So if you’ve always wanted to live in Japan, now’s your chance.

Diversity

DOBT is an equal opportunity employer. We will not discriminate and will take measures to ensure against discrimination in employment, recruitment, advertisements for employment, compensation, termination, upgrading, promotions, and other conditions of employment against any employee or job applicant on the bases of race, creed, color, national origin, or sex. We are committed in all areas to providing a work environment that is free from harassment.

How to apply

Fill out the form on Screendoor: https://screendoor.dobt.co/dobt/developer-hiring/ (yay for dogfooding!) Alternatively, send a note to [email protected]. USA/Canada only, sorry. Recruiters and agencies will be marked as spam.

Wow. I'm surprised at how big they were able to scale, while still pushing most commits directly to master and having a test suite that took 1hr to run.

> Rails version 1.1.6 is supported in the default directory

So yes, I doubt anyone is still using GoDaddy for Rails hosting.

We're trying to make sure that Healthcare.gov never happens again.

dobt.co

> Passenger sometimes gets the date wrong when appending the http Date header to responses. This happens when the week-based year differs from the calendar year. It happens because it uses %G to print the year when it should be using %Y (see this commit: 15ed1d4).

Took me a few hours to track this down -- and it's probably affecting a large majority of the Rails apps that are using a Passenger server.

Hopefully getting the word out can save some folks a few hours of banging their heads on their desks.

Neat. I also like this one (Coffeescript): https://gist.github.com/rjz/3610858

Valleywag is the TMZ of Silicon Valley. Remind yourself of that when reading it, and you'll be fine.

On one hand: it's cool to read something so "unfiltered".

On the other, If I was a potential client of Dockyard's and saw this, I would run for the hills. This is not the kind of stuff that belongs on a company blog. Or any blog, for that matter.

Wow, right as I clicked reply to say "kudos for admitting this", the original post was deleted. What's up?

sync is amazing. just wanted to say thank you :)

Seems to me like this solution, or checking for `request.xhr?` are the best suggestions so far.

You're right, will update now.

Here's a quick summary:

There's a Rails design pattern where you send an AJAX request to your controller, and it returns a bunch of Javascript that gets eval'd by the page you're on. This is used for say, infinite scroll. You'll click the 'load more' button, the server will render a partial containing your new records, and return something like:

    $('#itemsList').append('<li>My new item</li><li>another new item</li>')

So guess what? This is susceptible to XSS-ish attacks.

Let's imagine that instead of a simple list item, this request was returning some sensitive information or a CSRF token. (Egor points to various examples of this.) Normally, executing a GET request from an unauthorized domain will not be allowed because of CORS. This is what prevents me from instructing the users of my website to make an AJAX request to gmail.com, allowing me to see all of their emails.

But "wait", you say, "the content type of this request is application/javascript."

So open developer tools and type this: (using jQuery for conciseness)

    $.ajax({
      url: 'https://basecamp.com/[BASECAMP_PROJECT_ID]/progress.js', 
      dataType: 'jsonp'
    })

And boom, you have a bunch of sensitive information about your Basecamp project, accessible via JSONP request from any domain.