ericlaw talks about security, the web, and software in general
Microsoft publicly revealed the IE/Edge team’s size: ~300 people in an article with some fun profiles of a few of them: http://microsoftjobsblog.com/team-shapes-the-future-of-internet-browsing-with-microsoft-edge/.
Of course, my favorite profile story remains Zeke’s.
Unfortunately, many PNG image generators opt for minimum compression time, failing to achieve maximum compression. Even worse, the most popular PNG generation tools often include huge amounts of unnecessary metadata that can bloat images by thousands of percent!
Fiddler now includes PngDistill, a simple tool that removes unnecessary metadata chunks and recompresses PNG image data streams using the Zopfli compression engine. Zopfli-based recompression often shaves 10% or more from the size of PNG files. You can access the PngDistill tool from the context menu of Fiddler’s ImageView inspector:
While it is well-integrated into Fiddler, PngDistill, which is installed to C:\program files (x86)\Fiddler2\Tools folder, only requires PngDistill.exe (a .NET application) and zopfli.exe to run; you can use these tools without using Fiddler.
To run PngDistill against an entire local folder of images, you can do so from the command prompt:
for /f "delims=|" %f in ('dir /b *.png') do PngDistill "%f" replace
This script runs PngDistill on every image in the current folder, replacing any image for which the distillation process saved bytes. You can then update the images on your server with the optimized images.
Running PngDistill.exe without any arguments will show the usage instructions:
-Eric
The folks @Wired would like to remind you that viewing their website in any browser violates of their terms-of-use.
All web browsers cache content, by-design. And I’m pretty sure that “reading” is one just one of many ways that the material might be “otherwise used.”
For an otherwise forward-looking publication, seeing this garbage on the homepage is a depressing failure.
-E
Last night, I wrote up a quick post on the importance of iOS9’s introduction of a content-filtering API.
Naturally, there have been a variety of reactions to this post, so I’d like to address some of those and provide some additional context.
First, I’d like to point out that while there are many important factors in the evolution of technology, ignore economics at your peril. My first-hand experience with this was watching the “race to the bottom” in the Certificate Authority market; anyone with even a passing examination of the economics behind CAs could have seen it coming many years before it actually happened.
Second, I’ll point out that I wrote a much longer and more popular blog post on ad-blocking almost five years ago. Beyond showing how to block many web ads, I also provided some examples of what happens when ad-blocking becomes prevalent enough for sites to respond; generally, it’s not pretty. Go give it a quick skim, especially starting at the section Evaluation of Blocking Mechanisms. If you didn’t read between the lines, the tl;dr subtext of the post is “Hey, all of y’all evangelizing mass adoption of ad-blockers—knock it off, or you’re going to ruin it for us.”
Third, I maintain a Tracking Protection List for IE9 to IE11 that blocks many web advertisements.
@mattapperson noted that iOS isn’t shipping with an ad-blocker, only a filtering API, and that’s true. As I noted, however, there are significant short- and long-term strategic benefits for Apple if their new API is broadly used to block web ads. Mike and @steve228uk think the new API won’t be a game-changer and only power-users will block ads. That’s a possibility for sure, but again, it’s absolutely in Apple’s interest to ensure the API is broadly used.
@reganwald implies that ad-blocking won’t damage the open web, only its monetization. This is that pesky “ignore the economics” fallacy; the web grew not only because it was super neat, but also because there was plenty of money available. Shut off the money spigot and the attention and investment will move elsewhere.
@thomask77 observes that ads will simply get integrated into the first-party HTML and obfuscated; you could imagine technology like ShapeSecurity getting used for this. That’s certainly a possibility, but it overlooks some technical complexity and other problems (e.g. harder for ad networks to root out fraudulent clicks, which are already a huge problem). But yes, one outcome of widespread adoption of ad blockers will be a further blurring of “content” and “ads”, in the same way that American Idol judges guzzle Coke out of big cups and the singers croon at Fords parked on stage.
Several commenters, including @theodorejb opined that sites just need “to move beyond ads to other forms of revenue.” It’s a fine idea, but the genius of Apple’s position here is that the easiest move is for the publisher to build an iOS app and leave their existing ad investments intact.
On April Fools day in 2011, I proposed a new specification, P5P, the Pretty Please Platform for Participating Publishers. While this was mostly a tongue-in-cheek takedown of the Do Not Track request header, I also took some shots like this one:
NO-ADS-IM-SURE-YOU-WILL-FIGURE-OUT-ANOTHER-BUSINESS-MODEL
This token indicates that the user does not wish to be shown any form of advertising content, and expresses their earnest belief that the web publisher will find some way to remain in business without an income stream.
Note: This preference appears to be far more common than the related NO-ADS-HERE-IS-MY-BILLING-INFO-INSTEAD value.
@joshin4colours points out that some sites may be overlooking obvious revenue opportunities; I’m sure this is true in some cases, but again, the inertia is going to be for the blockee to simply kick the user over to their unconstrained iOS app.
One alternative revenue model is “tipping.” For instance, http://virtualglobetrotting.com/ detects blocked ads and allows users to send support via Bitcoin or Litecoin:
I support Virtual Globetrotting by using the Amazon Affiliates link to shop (and I buy quite a bit on Amazon), but I suspect that ad-blocking is still revenue negative for the developer.
@MaxenceBouret observes that widespread use of Safari’s content blocker could backfire and lead to users being asked to switch out of Safari to Chrome instead of using an iOS app. It’s a possibility, but I think it’s not the likely outcome.
@jdev1977 and others point out that sites can simply block visitors who block ads; that’s true, and it’ll likely be early return fire in an escalating arms race.
Here are a few articles in this area:
Most web users tolerate ads; many web users hate advertising with the fiery passion of a thousand suns. There are many good reasons that users dislike ads (they’re bad for performance, security, and privacy) as well as less universal, more arguable, grievances (e.g. annoyance factor, disagreement about the value exchange for ad-funded services, etc).
Apple, a company that makes ~80%ish of their revenue from iOS-based products, recently announced that iOS 9 will ship with a compelling ad-filtering API for the Safari browser.
In what is surely a huge coincidence, Apple and iOS’s only significant competitor makes ~90%ish of its revenue from advertising.
If you thought that websites’ “Install our app” prompts were annoying before, imagine what’s going to happen when the only way to reliably show ads is via a native app? That “No thanks” link is probably not going to be there, especially when the site detects your ad-blocker (scroll to “Evaluation of Blocking Mechanisms“).
Let’s review:
It’s an utterly brilliant plan.
In the Microsoft anti-trust case, Microsoft was infamously accused of a trying to “cut off Netscape’s air-supply.” This summer, Apple will be quietly putting its hand on Google’s money-spigot.
It’s far from clear how it will end, but collateral damage seems inevitable.
-Eric
Update: My responses to reactions to this post.
text/plain 