jordoh

Code delivery happens in desktop apps too, when you download the binary from evilsite.com, or when you receive an auto-update, they can give you a different binary than the security professionals reviewed. That's assuming the professionals even reviewed the binary, and not the source evilsite.com claimed it was built from.

It would also be difficult for said professionals to detect IP-(range)-specific backdoors (with as much obfuscation as you like; only send on Tuesdays; encrypted using a string constant elsewhere in the binary), in App Store delivered binaries that are harder to vary per downloader.

Some web apps - [Cryptee](https://crypt.ee/threat-model) is a notable example - address this with a "trust on first use" approach, that makes any change to the (web) code require approval, but that's in the same realm as a desktop app, where you've trusted it on the first download, and trust it to have actually followed through on that promise.

That's certainly credible evidence for past use I overlooked, though it remains unlikely to be useful with the advent of per-origin cache isolation.

The Last-Modified header can be used in exactly the same way, and isn't blocked by this extension, which harkens back to my original point: this is an extension that appears to see significant use by non-technical users, yet it breaks a browser feature by default. There are plenty of other methods of identifying a unique user that it doesn't prevent, so this seems like a pretty unexpected feature users should take note of.

We use the ETag header to make use of browser caching - not just for performance, but as a component of offline support. Yes, we could add an additional header with the same information to work around this specific extension for application-specific functionality using it, but that would leave the browser-based features broken.

While the ETag header may have been usable for cross site tracking at some point in the past [1], browser caches are isolated per-origin in Firefox, so there's no longer a cross-site tracking concern. That leaves it usable to identify you across sessions only in a first-party context, just like cookies, IP addresses (to a lesser extent), the Last-Modified header, and any number of other identification techniques ClearURLs doesn't block.

[1] I'd be interested to see any credible evidence of ETag headers being used for tracking in the wild - I've only seen theorizing that it _could_ be used as such, prior to cache isolation being implemented in Firefox and Chrome.

It should be noted that this extension strips ETag headers from all responses by default, which can break sites in surprising ways. As a developer of a web application that relies on ETag headers for vital functionality, I see not-infrequent support inquiries from ClearURLs users who don't understand the technical ramifications of this feature - nor do they understand why so many of the websites they use are so broken.

For better or worse, providing multiple ways to do the same thing is part of ruby's philosophy. [1]

[1] https://www.artima.com/intv/ruby.html

`_` being assigned the result of the last statement evaluated is an IRB feature [1], not a ruby feature - hence the note that it is not a universal solution.

[1] https://github.com/ruby/irb/blob/master/lib/irb/context.rb#L...

It's used in Rails to reduce the likelihood of un-sanitized user input in SQL fragments [1]. I think it would see a lot more use if additional input sources were marked as tainted [2].

[1] https://api.rubyonrails.org/classes/ActiveRecord/Base.html#c...

[2] http://www.jkfill.com/2012/03/10/preventing-mass-assignment-...

I tried running the source images through FineReader Online, but the images with handwriting resulted in "was not processed: the recognized document contains errors". The website image worked, but was missing a few elements, like the other headings on the line with "Minimalist editor".

Running tesseract (4.0.0 using the LSTM engine) on the same images leaves a lot to be desired for handwriting, but does well on the (non-handwriting) website image (the source images are linked in the "OCR Image Processing Results" section).

Have a specific image you'd be interested in seeing tested? The article only contains a few examples that could be freely used, but images with sparse random text (e.g. [1]) do tend to have good results across all the services.

[1] https://www.gettyimages.com/detail/news-photo/ken-griffey-jr...

That's a good point not explained in the article: there are a huge number of use cases for OCR. In this case, the use is extracting words that can be used in full-text search, so structural extraction isn't a key criteria.

Edit: and now it's hopefully clarified in the article itself. :)

There could be such a service flying under the radar, but third-party AdWords resellers are required by the TOS to only use one account per client.

Do you have evidence to support the assertion that it isn't purely percentage based? Perhaps there is some account out there that has the same ratio of prohibited items as knife-depot, but has not been banned?

Whether AdWords should allow "assisted open knife" ads is beside the point. Correct or not, AdWords is counting those as prohibited, the allegation of the OP is that AdWords banning criteria are applied differently to large accounts. I'm suggesting that the criteria is applied _exactly the same_, based on a percentage.

What I'm describing is also how Google Product Listing Ads get moderated: if X% of your items are in violation, your account is automatically shut down, pending appeal. Google sends a warning when you reach (X - Y)%, and another email when you reach X% and your account is shut down. I administrate 30,000+ PLA accounts and deal with this on a daily basis. This banning process is completely automated.

How do you level the playing field in this case? One account has 50% disallowed items (50 of 100) and another account has 0.005% disallowed items (50 of 1,000,000). You could bias _against_ large accounts by banning when they reach a fixed number of disallowed items - but then you let little guys (or any big guy that makes lots of small accounts) skate by under some arbitrary limit.

This seems like a pretty clear-cut case of assuming that there is some intentional malice or favoritism in actions that are the result of an automated system.

- Google adds some terms like "assisted opening knife" and "assist folding knife" so they are recognized as prohibited knife ads. Adding these terms could very well have been automated based on the terms having a strong association with other terms found alongside prohibited items.

- knife-depots' account suddenly contains X% disallowed knife ads, based on the new terms - where X is relatively large percentage. Account automatically disabled.

- Amazon and Walmart also have X% disallowed knife ads, but X is an extremely small percent of their overall number of items. Accounts remain active.

Fortunately, AdWords is one of the few Google properties where you can actually get a human on the phone and have them intervene with the automated results (though it can certainly take a lot of back and forth, in my personal experience).

In a more general sense, this is something that you constantly run in to if you have your automated systems performing any action that a user could view as punitive. I've yet to see a site that was open about automated actions being such - likely because they don't want to make it too easy to automate getting around the automated rules - but it does seem like there is a reasonable amount of explanation of the system that could diffuse these assumptions of persecution.

The writing has been on the wall for a while about the end of XNA development by MS - none of the development tools for XNA have been updated to work in Visual Studio 2012. Fortunately, there's an open source replacement that run on a much broader range of platforms: https://github.com/mono/MonoGame

I wonder how this will work with SSH keys. I've been using Git Extensions (http://code.google.com/p/gitextensions/) with VS 2010 for a while now and have been pretty happy with it, but it has taken a long time for the SSH key support to get to a usable place.

There are a couple assumptions here that seem like they could be pretty faulty:

1. Whoever touched a line of code last is most familiar with that line of code. I just moved a method to a different module, so following this assumption I am now the person most familiar with every line contained in that method.

2. The line of code triggering the exception is actually at fault. I just changed a value in a configuration file and it triggered an exception off in some code that creates a network connection - code I've never touched.

How faulty these assumptions are probably varies pretty wildly from organization to organization.

Even if you make it easy to unsubscribe (one click, no sign-in, prominent link), sending an email to any large number of people will still result in "mark as spam" being used on a surprisingly large percent of messages.

Where I work, we send mail through Amazon SES, so we get digests of all the messages that have been marked as spam (stripped of identifying email headers). We see it used on (marketing) newsletters of course, but also on welcome messages; transactional messages (both the "action required to receive money" and "you owe us money" type, though the latter get marked as spam much more frequently); password reset messages; and pretty much anything else we've sent out more than some middling-to-large number of times.

To help deal with this, we include a token in each message and process the digests so marking a message as spam will unsubscribe you (or disable the notification). It's not ideal from our point of view - because we are presumably getting dinged by the mail provider when someone marks a message as spam - but hopefully it helps in the long run since we don't send more messages that will likely just get marked as spam.

When I mark something as spam, I'm doing it to penalize the sender. Whether they made it hard for me to unsubscribe, bought my email from someone else to spam me (hooray for "+blah" gmail aliases), or whatever else - I see it as a different action than unsubscribing. I'm not sure, however, that this difference is commonly perceived. It seems like there are a lot of people out there that use it much less judiciously.

Occasionally I will mark a message as spam in Gmail and get a dialog asking if I want to unsubscribe instead of mark as spam; though I only recall this happening with messages from Google properties. It would be nice (though possibly ripe for abuse) if there was some way to let Gmail know where the unsubscribe link is in the message, so third parties could take advantage of this feature. That way the user could be a little clearer about whether they are punishing the sender, or just want the message to go away.

Great to know about 1.9 - just looked through the 1.9 changelog and saw it described as "Newlines allowed before ternary colon operator (:) and method call dot operator (.)", so it does seem like they are encouraging this specific formatting style.

I agree that the fully indented code is much easier to visually parse - whether that outweighs the refactoring cost is certainly going to vary depending on the team (in addition to personal preference, as you mention).

This seems to be a popular style in javascript (particularly when using jQuery), but it's not actually valid ruby (edit: ruby 1.8.7, that is - see reply). The first line forms a valid statement, so the dots would need to be at the end of each line to indicate a line continuation. So it would need to be:

  names.select { |name| name.start_with?("S") }.
        map    { |name| name.upcase }.
        sort.
        join(', ')

This also creates a mild headache when refactoring, as any change to the length of the "names" variable would force you to re-align the entire chain. You could do something like:

  names.
    select { |name| name.start_with?("S") }.
    map    { |name| name.upcase }.
    sort.
    join(', ')

How long has it been since you used MonoTouch? I first used it a little over a year ago: debugging over the wire worked just fine (though you can debug over a network connection), the API was only ever behind on major iOS updates (it's also not hard to call an Obj-C API from MT yourself, without waiting for them to put out a new release of MT), and all the compilation was handled by command line programs called by the MT MonoDevelop plugin - you could call them from make/Rake/whatever, should you prefer to.

Using a vector representation may be a more practical approach as retina-style screens become more pervasive. Microsoft Research has an interesting paper on this from last year's SIGGRAPH: http://research.microsoft.com/en-us/um/people/kopf/pixelart/

That said, once you switch over to more advanced scaling, the artist loses a lot of the fine control over the result that can really make pixel art shine.