https://feeds.feedburner.com/eligrey

Choosing the right browser is crucial for your security, privacy, and overall experience on the web. This is especially important now that Chrome is dropping support for the popular uBlock Origin adblocker browser extension.

I have evaluated the security, privacy, extensibility, and ethical alignment of today’s most popular browsers in order to determine which is best, depending on your needs. Overall, I recommend Brave* for most people, as it has the best default settings favoring personal agency (i.e. minimal anti-features on by default) and meets my privacy and security expectations. If you need more extensibility, choose Firefox.

The contenders:

• Chrome
• Brave
• Firefox
• Safari
• Edge

These browsers form the basis of our modern web infrastructure. However, none live up to an ideal standard of what browsers should be. I believe that we can do better.

* iOS users have no choice other than WebKit-based browser engines, such as Safari. Although Apple may technically allow third-party browser engines in the EU, this in not yet the case in practice due to Apple not allowing third-party browser engine developers to easily test their software outside of the EU.

Privacy: Brave wins

Brave and Safari block many trackers by default with their EasyPrivacy tracker blocklist integrations, which can help protect people from personally targeted advertising and discriminatory pricing based on their personal information. Safari’s tracker blocklist integration is limited to Private Browsing mode.

Chrome, Firefox, Safari, and Edge use network and device resources in order to help with ‘privacy-preserving’ measurement of ad effectiveness by default. This is unnecessary and only serves to further enrich advertisers at cost to the user.

Chrome and Edge turn it up a notch by tracking user behavior in-browser, sharing inferred interest topics with advertisers, and enabling these advertisers to abusively share data cross-site using third-party cookies, a concept supported in their default configuration.

Safari has caused systemic damage to privacy across the web ecosystem on all browsers through its cookie-preferential storage partitioning model, amplified by its iOS market dominance. Safari’s partitioning model incentivizes site owners to use cookies to synchronize data cross-subdomain, which unnecessarily leaks user data over the network. All other browsers also support synchronizing state cross-subdomain locally on-device, but many site owners don’t do this as it’s often much easier to implement a single solution for the common denominator.

Firefox and Edge make a decent attempt at baseline privacy with some tracker blocking features, but lack an EasyPrivacy-based tracker blocker enabled by default.

For a technical comparison of browser privacy behaviors, check out PrivacyTests.org.

Security: Chrome wins

In terms of technical competency and proclivity for security best practices, I believe that the teams behind Chrome, Safari, Firefox, Brave, and Edge all reach my minimum expectations.

Chrome was built around a multi-process architecture that was later adopted by other browsers, sandboxing each tab to prevent malicious code from affecting other tabs or the entire browser. Chrome also benefits from Google’s substantial resources dedicated to security research and frequent updates, ensuring that vulnerabilities are both promptly patched and proactively prevented. These measures make Chrome one of the most secure browsers available. Chrome beats Safari due to its faster release cycle, and both Brave and Edge by being closer to the source of fixes for most Chromium security issues.

Firefox’s integration into projects like the Tor Browser makes it a more enticing target for attackers looking to compromise the systems of individuals who may handle sensitive information. Their owner Mozilla has also faced criticism for ineffective and incorrect reviews by gatekeepers to their add-on site. If reviewers aren’t properly reviewing extensions, they might not catch a targeted security attack in an extension update. Fortunately, Mozilla’s security response for reported issues is top-notch. They have recently won an award by Trend Micro’s Zero Day Initiative for being the fastest vendor to patch security issues in August 2024.

Extensibility: Firefox wins

Chromium browsers such as Chrome, Edge, and Brave are transitioning to Manifest V3, and Google has decided to restrict certain APIs particularly impacting ad blockers and privacy tools. Google has deprecated the webRequestBlocking API supported by Manifest V2 and disallowed the upload of new Manifest V2 extensions to the Chrome Web Store. This reduces the capabilities of content-blocking extensions and has raised concerns among developers and privacy advocates, as it weakens users’ ability to block unwanted content (e.g. ads and trackers).

Safari extensions have similar limitations to Chromium browsers, and developers need to pay Apple $99 per year in order to distribute their extensions.

Firefox supports Manifest V3 while retaining the webRequestBlocking API, meaning that extensions can continue to use runtime logic to arbitrarily block content such as trackers and ads. This sets Firefox apart from other browsers as the most extensible overall.

Ethical alignment: Everyone loses

Brave offers an optional, purportedly attention-based, monetization scheme and skims 30% of the value. Fortunately, Brave only has one anti-feature enabled by default: dismissible advertisements to enable this monetization scheme.

Chrome, Edge, and Safari offer browser-level features that unjustly enrich advertisers at cost to the user in their default configuration.

Mozilla has acquired an adtech company that uses behaviorally targeted advertising without stating a clear commitment to end behavioral targeting. I believe that this goes against their own publicly-stated manifesto. Unlike contextual targeting, behavioral targeting can be abused much more easily for personalized advertising and discriminatory pricing. Contextual targeting is the practice of customizing content (e.g. ads) to be relevant to the site being viewed as opposed to the determinable characteristics of the person viewing the site.

What’s next

We need browsers that truly put users in control, and that means building them in the open, without the conflicts of interest that plague ad-driven giants. This is a call to action for everyone, from grassroots communities to philanthropic individuals and forward-thinking developers: let’s fund, create, and sustain new high-quality open source browsers. A truly open web can’t be dominated by a handful of companies who profit from surveillance and lock users into limited ecosystems.

One early in-development browser project is Ladybird, initially created within the open-source SerenityOS community and now developed by the non-profit Ladybird Browser Initiative. Instead of relying on established engines like Chromium or WebKit, it aims to build a new browser engine entirely from scratch, free from for-profit interests. Although still in the early stages, Ladybird demonstrates a commitment to transparency and user control. This model seeks to avoid the conflicts of interest often found in browser development and marks a promising direction for the future of browsing.

Another browser project worth mentioning is the Servo browser engine and the Verso browser powered by Servo. Servo was initially developed by Mozilla, and is now developed by the Servo Project Developers. Servo is intended to be a lightweight, high-performance, and secure browser engine framework. Servo is written in the Rust programming language which has improved memory safety properties and concurrency features over many existing languages used to develop browser engines.

Link fraud is increasingly undermining trust in major online platforms, including Google, Bing, and X (Twitter).

These platforms allow advertisers to spoof links with unverified ‘vanity URLs’, laundering trust in their systems, while simultaneously deflecting blame onto advertisers when these mechanisms are exploited for fraudulent purposes. 

I believe that this status quo must be abolished. Commercial entities that maintain advertising systems that systemically enable link fraud must contend with their net-negative impact on society.

What are vanity URLs and what is link fraud?

URL spoofing is the act of presenting an internet address that appears to lead to one destination but actually leads to another, unexpected, location. URL spoofing is commonly referred to as “vanity URLs” or “display URLs” by the adtech industry when provided as a first-class feature on adtech platforms.

Link fraud is the use of URL spoofing to achieve financial gain or other illicit objectives. It is a staple practice in spam emails and scam websites, where links may appear legitimate but lead to harmful content.

Examples of preventable link fraud

Link fraud is commonly used on popular websites to hijack ecommerce and software downloads. People that don’t block ads can get convincing link fraud whenever they search for web browsers[1][2], videoconferencing apps[3], password managers[4], task management apps[5], authenticators[6], software development tools[7], open source image editors[8], and cryptocurrency wallet managers[9]. People are more likely to input their sensitive account information when they see valid links to trusted sites on ‘trustworthy’ search engines.

An industry-wide lack of effective technical protections allows scam operations to scale up such that it becomes practical to farm low-value targets en-masse. There are instances where scammers use link fraud just to collect media streaming provider credentials[10], likely for resale.

This compilation thread on X includes all of the examples below.

const showAllExamples = () => { [...document.querySelectorAll('details')].forEach((details) => { details.open = true; }) }, examplesLink = document.querySelector('a[href$="#examples"]'); if (examplesLink) { examplesLink.addEventListener('click', showAllExamples); } document.addEventListener('DOMContentLoaded', () => { if (location.hash === '#examples') { showAllExamples() } }) details>summary .expand-toggle { width: 1.5em; height: 1.5em; transition: all 0.2s; margin: 1.8em 0.5em auto 0; display: inline-block; text-align: center; font-size: 1.4em; } details[open] summary .expand-toggle { transform: rotate(45deg); transform-origin: center; } summary { display: flex; cursor: pointer; } summary::-webkit-details-marker { display: none; } li:target { background-color: rgba(255,224,0,0.11); }

Google Search

• See this compilation of reports on X by Germán Fernández.
• See this post on X by Eric Lawrence about a spoofed YouTube ad.
• See this post on X by Karl Emil Nikka about a spoofed Bitwarden ad.
• See this post on X by Scott Chacon about a spoofed Todoist ad.
• See this post on X by nixCraft about a spoofed ad for GNU Image Manipulation Program.
• See this post on X by Samruddhi Mokal about a spoofed Disney+ ad.
• See this article on BleepingComputer by Bill Toulas about a spoofed Google Authenticator ad.
• See this post on X by Ryan Chenkie about a spoofed Homebrew package manager ad.
• See this post on X by Radiant.
• See this post on X by Robby Russell.
• See this post on X by Ronin.
• See this post on X by Phantom.
• See this post on X by Trader Joe XYZ.
• See this post on X by winston.
• See this post on X by vrypan.eth.
• See this post on X by Rabby Wallet.
• See this post on X by Grills.
• See this post on X by John Macleod.
• See this post on X by Ian Lim.
• See this post on X by betaplux.
• See this post on X by MacCallister Higgins.
• See this post on X by Scott Redgate.
• See this post on X by (22)c.

Microsoft Bing

• See this Forbes article by Jason Evangelho and my analysis of the incident on X. I reproduced the issue at the time and triaged the root cause to be uncontrolled use of vanity URLs.
• See this post on X by Ti Zhao.
• See this post on X by sedat kapanoğlu.
• See this post on X by Steve Trout.
• See this post on X by 0xngmi. Note: DuckDuckGo uses Bing Ads and largely sources results from Bing.

X (Twitter)

• See this post on X by Justin.
• See this post on X by Colin Fraser.
• See this post on X by Logan Williams.
• See this post on X by Dan Morley.

I’ve also personally witnessed link fraud twice on X but didn’t screenshot it.

Culprits

Google, Microsoft, and X all appear to have similarly ineffective enforcement methods and policies for vanity URL control on their advertising platforms.

I suspect that Facebook and Reddit also have similar limitations as they also allow link spoofing for ads, although I haven’t sufficiently confirmed a lack of effective domain ownership verification.

Implicit regulatory capture

Adtech companies play the victim by claiming that fraudsters and scammers are ‘abusing’ their unverified vanity URL systems. These companies should not be able to get away with creating systems that enable link fraud and then pretend to tie their hands behind their back when asked to combat the issue. They have created systems for trust-laundered URL spoofing, and then disclaimed ethical or legal responsibility for the fundamental technical failures of these systems.

It is not possible to automatically prevent link fraud in systems that allow for unverified URL spoofing to occur. If adtech providers do not perform domain ownership verification on vanity URLs, advertisers are technically free to commit fraud as they please.

How did we get here?

The adtech industry may excuse these practices as an unavoidable consequence of the complexity of online advertising. However, this overlooks the responsibility that these companies bear for prioritizing profit over user safety and the integrity of their platforms.

Corporate greed has gotten so out-of-control that companies such as Google, Microsoft, and Brave now all deeply integrate advertising technologies at the browser-level, with some effects ranging from battery drain to personal interest tracking, and even taking a cut of the value of your attention.

National security risks

The risk of malvertising and fraud through adtech platforms has become so concerning and prevalent that the FBI now recommends all citizens install ad blockers. Interestingly, some of the FBI’s advice for checking ad authenticity is inadequate in practice. The FBI suggests “Before clicking on an advertisement, check the URL to make sure the site is authentic. A malicious domain name may be similar to the intended URL but with typos or a misplaced letter.” — this is useless advice in the face of unverified vanity URLs. Instead of asking private citizens to block an entire ‘legal’ industry, the FBI should be investigating adtech platforms for systemically enabling link fraud.

Intelligence agencies such as the NSA and CIA also use adblockers in order to keep their personnel safe from malware threats. I anticipate that the US federal government may start requiring adblockers on all federal employee devices at some point in the future.

What can be done? Verification & enforcement

Companies are generally mandated by law to provide true statements to consumers where technically possible. Unverified vanity URLs as a first-class feature flies in the face of these requirements.

Adtech providers should validate ownership of the domain names used within vanity URLs, or alternatively vanity URLs should be banned entirely. Validating domain ownership can easily be done through automated or manual processes where domain name owners place unique keys in their domain name’s DNS records.

A common, yet fundamentally flawed ‘verification’ mechanism that adtech platforms such as Google Ads employ is the use of sampled URL resolution, which involves visiting a website at given points in time from one or more given computers. This technique can easily be bypassed with dynamic redirection software to hide fraud and malware from URL scanning servers.

Petition your elected government officials to let them know that big tech is willingly ignoring their role in the rise of effective link fraud, spurred by their support of unverified vanity URLs. The United States FTC should investigate companies that knowingly enable link fraud through unverified vanity URL systems that are fundamentally impossible to audit.

On a personal level, you can install an adblocker such as uBlock Origin to block advertising, which has a nice added side effect of increasing web browsing privacy and performance.

Favioli is a productivity extension that makes it easier to recognize tabs within Chrome.

Favioli was originally inspired by two things. The first thing that spurred the idea was Eli Grey’s personal site and its use of Emoji Favicon Toolkit to make randomized emoji favicons. The favicon of their site shows different emoji on-load that persist within a session. It’s pretty creative and fun! This was the creative inspiration for Favioli.

There is an Emoji Favicon Toolkit usage example here on eligrey.com.

The practical inspiration for Favioli came from my day job. We have a lot of internal tools and sites, and they tend to either not have favicons, or have the standard Sony logo. For me this was a bit of a pain, because I love to pin my tabs. I couldn’t tell these sites apart.

I could use a Chrome extension that lets me set custom favicons, but then I’d have to go through and specify each one. If I were to use emojis, I wouldn’t have to deal with finding art for each individual site, and I could make something that could automatically make all of these pages recognizable at a glance.

This project has been a fun exploration of javascript strings, chrome extensions, and browser/os string support.

As we look through everything, feel free to follow along by looking at Favioli’s source code! All the Favioli code that is my own is licensed with the Unlicense, so feel free to go crazy with it.

Structure of a Browser Extension

There are essentially 4 pieces of any fully-local web extension that modifies a web page:

• Options: The internal website that extensions use for full-screen setting updates
• Popup: The mini-website that pops up when you click the extension icon
• Background: The background extension process that does stuff… in the background…
• ContentScript: The script that gets added to websites you visit in your web browser.

We use all of these except popup for Favioli.  The general structure of our extension looks like this:

Settings: Options and Popup Pages

This is the simplest piece of Favioli, and for a good reason; it doesn’t really do much. All we do here is run a basic website, “options.html”, which saves data to a browser-provided storage mechanism. Similar to using localStorage, key differences being that it can sync between different browsers on multiple computers, and is available to other areas of our Chrome Extension that don’t interact with a webpage. What this boils down to in Favioli is simply saving custom overrides and, in the future, things like icon packs and other settings.

The most complicated piece of the options page is the emoji selector, adapted from Dominic Valenicana’s Emoji Selector. We use this to define a custom HTML element that we can use for the options page.

One thing we haven’t implemented in Favioli is a popup page. In Chrome Extension land, the “popup” is the mini-site that shows up when you click the extenstion icon. We currently don’t use this for Favioli, but it would be extremely useful for quick-pinning specific emojis to sites we are currently visiting. It would essentially follow the same formula as our Options page, though; featuring a user interface that simply feeds information to our background process.

Background: The Decision Engine

The Background process is Favioli’s primary decision engine. It takes information from our content script and background process, and spits the correct emoji to each page. Our decision is a simple priority list: we just check each item and use the first rule to apply:

Priority Rule 1 User-set Overrides: If a user has specified a favicon match via the options page, then the site will use that favicon. 2 Site Default: If the site has a favicon, then use that. 3 Random Emoji: If the site has not natural favicon, we generate a random one via a hashing algorithm.

The user-set overrides and site defaults are pretty straightforward; we can match pieces of a url, or match a regex. If it doesn’t use those, then fall back to the site’s default favicon. The more interesting case is if a site doesn’t have a native Favicon.

Random Emoji Hash

The reasoning for using a non-cryptographic hash to determine emojis is based on one idea: there’s no way in hell we’re storing the settings of each site a person visits. THAT would be a pain in the ass. We use a hash of the website’s host to map to an emoji with a custom set of char codes (we don’t really want to randomly apply flag and symbol emojis to all the sites. It’s just not as fun). This creates a function that creates a random emoji that is always the same for an individual website host, without storing any data.

Background: Applying the Favicon

Our decision process is run in 3 cases, which are in the background.js:

// After we fetch our settings, start listening for url updates
init().then(function() {
  // If a tab updates, check to see whether we should set a favicon
  chrome.tabs.onUpdated.addListener(function(tabId, opts, tab) {
    tryToSetFavicon(tabId, tab)
  })
})

// Manually sent Chrome messages
chrome.runtime.onMessage.addListener(function(message, details) {
  // If we manually say a tab has been updated, try to set favicon
  // This happens when contentScript loads before settings are ready
  if (message === "updated:tab") tryToSetFavicon(details.tab.id, details.tab)

  // If our settings change, re-run init to fetch new settings
  if (message === "updated:settings") init()
})

tryToSetFavicon decides what emoji we want to use and sends it to our content script as an emoji message string, to render our emoji as a favicon. Our content script has a few additional checks for whether we should show our favicon, because there are some checks that can only be done on each individual site.

We can think of our bakground process as determining WHEN to set a favicon, and WHAT to set it as. The content script will determine IF a favicon truly gets set.

Content Script: Building Text Favicons

Our content script is the script that runs on each website we visit, appending or replacing the favicon when our background process tells it to. This scripts could be quite a bit simpler than we made it. The reason? Essentially, this boils down to one thing:

Favicons are images. Emojis are not images.

Unfortunately, favicons still must be images, so we have to do a bit of hackery magic in order to show our native text emojis show up as favicons. This was the clever bit of code Eli wrote that I borrowed to make Favioli an image-less experience.

I should probably mention that there’s definitely some over-engineering in Favioli. Practically, using the same clever method as Eli for creating legitimate emoji text favicons is not reeeeally necessary, and makes for some complications when it comes to multi-platform support. So this script coooould be “use a pre-rendered emoji image and add it as a favicon.” That script would be easy, but WHAT FUN WOULD THAT BE?!?!

Let’s jump into a condensed version of the code we use to create our favicons:

// Initialize canvas and context to render emojis

const PIXEL_GRID = 16 // Standard favIcon size 16x16
const EMOJI_SIZE = 256 // 16 x 16

const canvas = document.createElement("canvas")
canvas.width = canvas.height = EMOJI_SIZE

const context = canvas.getContext("2d")
context.font = `normal normal normal ${EMOJI_SIZE}px/${EMOJI_SIZE}px sans-serif`
context.textAlign = "center"
context.textBaseline = "middle"

function createEmojiUrl(char) {
const { width } = context.measureText(char)

// Bottom and Left of the emoji (where we start drawing on canvas)
// Since favicons are a square, we can use the same number for both
const center = (EMOJI_SIZE + EMOJI_SIZE / PIXEL_GRID) / 2
const scale = Math.min(EMOJI_SIZE / width, 1) // Adjust canvas to fit
const center_scaled = center / scale

// Scale and resize the canvas to adjust for width of emoji
context.clearRect(0, 0, EMOJI_SIZE, EMOJI_SIZE)
context.save()
context.scale(scale, scale)

// context.fillText(char, bottom, left)
context.fillText(char, center_scaled, center_scaled)
context.restore()

// We need it to be an image
return canvas.toDataURL("image/png")

We make a canvas, draw a centered piece of favicon text, then convert that canvas drawing into a png data url. We can set favicons with data urls, so at this point, we just need to add our favicon to the site!

Content Script: Appending Favicons

The last step of Favioli is appending a favicon to the site we visit. Appending a favicon to an existing site can have a few complications, mainly stemming from the fact that different sites apply their favicons in different ways. We have a few different cases that affect how Favioli adds favicons:

1. Custom Favicon Path

This is the easiest to deal with; when a site has a custom favicon path, we can be assured that it has a favicon, and we can either override it or leave it be, depending on our settings.

2. Weird path changes

Sometimes a site changes path and expects the favicon to persist through the site. To maintain consistency, and to avoid unnecessary work, favioli memoizes the decision of whether a site has a custom favicon within the context of a session.

3. No Favicon in the HTML

When there is no specified favicon, there are two things it could mean. It could mean that a website is either using the default favicon.ico, or it doesn’t have a favicon. It could be confusing if we try to determine which of these is happening, though. So instead, Favioli simply appends a favicon.ico link after it appends our emoji favicon in cases where we shouldn’t override the default emoji. This way, our emoji favicon gets overridden by the default one.

const href = memoizedEmojiUrl(name);

if (existingFavicon) {
  existingFavicon.setAttribute("href", href);
} else {
  const link = createLink(href, EMOJI_SIZE, "image/png");
  existingFavicon = documentHead.appendChild(link);

  if (!shouldOverride) {
    const defaultLink = createLink("/favicon.ico");
    documentHead.appendChild(defaultLink);
  }
}

Now we have done it!

At this point, we have appended a text emoji as a favicon, so we’ve successfully completed our mission to emoji-fy the universe! With Favioli, we no longer need to worry about the dreaded favicon-less existence that some people still somehow call life.

Where do we go from here?

There are a myriad of ways we can extend Favioli in the future. To give you an idea, here are some ideas we have been thinking about:

Custom sets for Randomly Selected Emojis

This would be the easiest way to deal with cross-platform compatibility; just change the set that we randomly select from. This will let people better customize their experience.

Custom pngs as Favicons

This would create more utility for Favioli. I feel our default offering is better than most favicon replacement extensions. But not being able to set custom pngs is a real killer from being the best one out there. Also, though… gif favicons. Imagine how hilarious (and technically dumb) that could be. Using pngs as a fallback could also be used for browsers, os that are insufficient for life and don’t have the new emojis.

Custom Application Overrides

It would be cool to be able to override some aspects of page load in a smarter and more fun way. Image emojis for 404/500 page responses, for non-https sites or something like that. These would be configured in settings, but could be a fun way to interact with the web.

Popup Page

This is a pretty obvious one; A useful UI update

Stats for nerds

Being able to apply Favioli to browser history would be fun. We’d have to play with permission settings so that Favioli is only enabled on this page, but could be interesting…

Anywhoooooo

This is Favioli! Check it out! Edit the source code and send a PR if you want to help, or just use it!

,
Ben Pevsner

We are announcing Zerodrop, an open-source stealth URL toolkit optimized for bypassing censorship filters and dropping malware. Zerodrop is written in Go and features a powerful web UI that supports geofencing, datacenter IP filtering, blocklist training, manual blocklisting/allowlisting, and advanced payload configuration!

Zerodrop can help you elude the detection of the automatic URL scanners used on popular social media platforms. You can easily blocklist traffic from the datacenters and public Tor exit nodes commonly used by URL scanners. For scanners not included in our default blocklists, you can activate blocklist training mode to automatically log the IP addresses of subsequent requests to a blocklist.

When used for anti-forensic malware distribution, Zerodrop is most effective paired with a server-side compromise of a popular trusted domain. This further complicates incident analysis and breach detection.

Live demo

A live demo is available at dangerous.link. Please keep your usage legal. Infrastructural self-destruct has been disabled for the demo. To prevent automated abuse, users may be required to complete CAPTCHA challenges in order to create new entries.

Update: We have decided to restrict access to the demo to prevent abuse.

Zerodrop geofencing & blocklist training

Auto-expiration

Entries may expire after reaching an optional request limit. After an entry expires, all requests to the entry trigger the denial condition resulting in 404 or a redirect.

Blocklisting, allowlisting, and geofencing

We support gitignore-style blocklists processed line-by-line top to bottom. Blocklists consist of allowlist inversions, IP address ranges, geofences, and ipcat queries, interspersed with comments. We added IPv6 support to ipcat to make it datacenter traffic detection more reliable.

Geofencing is implemented using MaxMind’s GeoIP databases and configured inside an entry’s blocklist and allowlist. Geofencing entries are specified in the form @ lat, long (radius) for blocklisting and the inverted form !@ lat, long (radius) for allowlisting. Currently we only support radial geofences. A graphical geofencing UI is planned for a future release.

Traffic from datacenters and public Tor exit nodes is blocked using a new version of ipcat, which now includes IPv6 support. The syntax to block each is db datacenters and db tor.

Redirects to other Zerodrop payloads may optionally be specified in the “Redirect On Deny” field under the blocklist. Payloads can be redirects, proxies, uploaded files, or plain text with a MIME media type.

Example blocklist

The following example blocklist blocks datacenters, public tor exit nodes, and everyone outside of San Francisco.

# Block all
*
# Allow San Francisco
!@ 37.7749, -122.4194 (24140m)
# Block datacenters
db datacenters
# Block public Tor exit nodes
db tor

Anti-censorship

This tool is useful for evading automatic censorship filters in use on popular social media websites. With blocklist training and ipcat, it’s very easy to build up a blocklist to block these filters and continue to share content that would otherwise be automatically censored on most sites. Zerodrop also includes CloudFlare integration to help hide the IP address of your server and avoid further blocklisting from censorship filters.

Anti-forensics

Complete infrastructure self-destruct can be triggered with blocklist redirects to the “” internal identifier. When triggered, Zerodrop will attempt to delete all traces of itself from the host system. External navigation to “/💣” will not trigger self-destruct.

Example usage of Zerodrop’s self-destruct functionality

What’s next?

There are many areas where the current release of Zerodrop can be improved. Over the coming months we hope to implement some of the following changes. This is an open source project, so feel free to contribute yourself by reporting issues and submitting pull requests.

Blocklist groups & machine learning

Blocklists will get an improved UI and reusable blocklist groups. Currently you must copy and paste blocklists and allowlists to copy list information into new entries. We can also improve training mechanisms with paid IP address services and machine learning techniques.

Geofencing improvements

In addition to the currently-support radial geofences, we plan to implement polygonal geofencing and a graphical geofence creation widget for the new entry UI. It will probably be based off Google Maps and require an API key for deployment. For now, the text-based blocklist should be just as powerful albeit less visually accessible.

On May 4th, 2017 I discovered and privately reported a recipient spoofing vulnerability in Google Inbox. I noticed that the composition box always hid the email addresses of named recipients without providing a way to inspect the actual email address, and figured out how to abuse this with mailto: links containing named recipients.

The link mailto:​”support@paypal.com”​<scam@phisher.example> shows up as “support@paypal.com” in the Google Inbox composition window, visually identical to any email actually sent to PayPal.

In order to exploit this vulnerability, the target user only needs to click on a malicious mailto: link. It can also be triggered by clicking on a direct link to Inbox’s mailto: handler page, as shown in this example exploit link.

This vulnerability was still unfixed in all Google Inbox apps as of May 4th, 2018, a year after private disclosure.

Update: This vulnerability has been fixed in the Google Inbox webapp as of May 18, 2018. The Android app still remains vulnerable.

The recipient “support@paypal.com” being spoofed in the Google Inbox composition window. The actual recipient is “scam@phisher.example”.

On July 3rd, 2017 I noticed that Google had added hover tooltips to this field in Inbox, which made it possible for users to manually confirm the recipient email address. The default presentation of the email address was still vulnerable to spoofing, so I sent another email to Google.

I received no response for over 8 months, so I sent yet another email on March 16th, 2018.

Nine months after sending my emails I received this response, which doesn’t lead me to believe that Google is serious about fixing this vulnerability.

Opera users were vulnerable to a publicly-disclosed UXSS exploit for most of 2010-2012.

I privately disclosed a UXSS vulnerability (complete SOP bypass) to Opera Software in April 2010, and recently discovered that Opera suffered a regression of this issue and continued to be vulnerable for over two years after disclosure. The vulnerability was that data: URIs could attain same-origin privileges to non-opening origins across multiple redirects.

I asked for a status update 50 days after disclosing the vulnerability, as another Opera beta release was about to be published. Opera responded by saying that they were pushing back the fix.

I publicly disclosed the vulnerability with a PoC exploit on Twitter on June 15, 2010. This was slightly irresponsible of me (at least I included a kill switch), but please keep in mind that I was 16 at the time. The next week, Opera published new mainline releases (10.54 for Windows/Mac and 10.11 for Linux) and said that those releases should fix the vulnerability. I tested my PoC and it seemed to be fixed.

Shortly after, this vulnerability regressed back into Opera without me noticing. I suspect that this was due to the rush to fix their mainline branch, and lack of coordination between their security and release teams. The regression was caught two years later by M_script on the RDot Forums, and documented in English by Detectify Labs.

Opera Software’s management should not have allowed this major flaw to regress for so long.

Security advisories

• Initial fix (June 22, 2010): http://www.opera.com/security/advisory/955/ (CVE-2010-2665)
• Regression fix (November 11, 2012): http://www.opera.com/support/kb/view/1031/ (CVE-2012-6463)

Some time between Aug 27, 2012 and May 3, 2014, the Macmillan Publishers subsidiary Bedford/St. Martin’s suffered a data breach that leaked the unique email address that I provided to them. I have previously informed them of the breach and it appears that they do not care to investigate.

I don’t appreciate large companies getting away with not disclosing or investigating data breaches, so I’m disclosing it for them.

(Update) Standardization

I have standardized navigator.cores as navigator.hardwareConcurrency, and it is now supported natively in Chrome, Safari, Firefox, and Opera. Our polyfill has renamed the APIs accordingly. Since the initial blog post, Core Estimator has been updated to estimate much faster and now has instant estimation in Chrome through PNaCl.

navigator.cores

So you just built some cool scalable multithreaded feature into your webapp with web workers. Maybe it’s machine learning-based webcam object recognition—or a compression algorithm like LZMA2 that runs faster with the more cores that you have. Now, all you have to do is simply set the number of worker threads to use the user’s CPU as efficiently as possible…

You might be thinking “Easy, there’s probably a navigator.cores API that will tell me how many cores the user’s CPU has.” That was our thought while porting xz to JavaScript (which will be released in the future as xz.js), and we were amazed there was no such API or any equivalent whatsoever in any browser! With all the new features of HTML5 which give more control over native resources, there must be a way to find out how many cores a user possesses.

I immediately envisioned a timing attack that could attempt to estimate a user’s CPU cores to provide the optimal number of workers to spawn in parallel. It would scale from one to thousands of cores. With the help of Devin Samarin, Jon-Carlos Rivera, and Devyn Cairns, we created the open source library, Core Estimator. It implements a navigator.cores value that will only be computed once it is accessed. Hopefully in the future, this will be added to the HTML5 specification.

Live demo

Try out Core Estimator with the live demo on our website.

How the timing attack works and scales

The estimator works by performing a statistical test on running different numbers of simultaneous web workers. It measures the time it takes to run a single worker and compares this to the time it takes to run different numbers of workers simultaneously. As soon as this measurement starts to increase excessively, it has found the maximum number of web workers which can be run in parallel without degrading performance.

In the early stages of testing whether this would work, we did a few experiments on various desktops to visualize the data being produced. The graphs being produced clearly showed that it was feasible on the average machine. Pictured are the results of running an early version of Core Estimator on Google Chrome 26 on an Intel Core i5-3570K 3.4GHz Quad-Core Processor with 1,000 time samples taken for each core test. We used 1,000 samples just to really be able to see the spread of data but it took over 15 minutes to collect this data. For Core Estimator, 5 samples seem to be sufficient.

The astute observer will note that it doesn’t test each number of simultaneous workers by simply counting up. Instead, Core Estimator performs a binary search. This way the running time is logarithmic in the number of cores—O(log n) instead of O(n). At most, 2 * floor(log2(n)) + 1 tests will be done to find the number of cores.

Benefits

Previously, you had to either manually code in an amount of threads or ask the user how many cores they have, which can be pretty difficult for less tech savvy users. This can even be a problem with tech savvy users—few people know how many cores their phone has. Core Estimator helps you simplify your APIs so thread count parameters can be optional. The xz.js API will be as simple as xz.compress(Blob data, callback(Blob compressed), optional int preset=6, optional int threads=navigator.cores), making it this easy to implement a “save .xz” button for your webapp (in conjunction with FileSaver.js):

save_button.addEventListener("click", function() {
    xz.compress(serializeDB(), function(compressed) {
        saveAs(compressed, "db.xz");
    });
});

Supported browsers and platforms

Early Core Estimator has been tested to support all current release versions of IE, Firefox, Chrome, and Safari on ARM and x86 (as of May 2013). The accuracy of Core Estimator on systems with Intel hyper-threading and Turbo Boost technology is somewhat lesser as the time to complete a workload is less predictable. In any case it will try to tend towards estimating a larger number of cores than actually available to provide a somewhat reasonable number.

Have you ever wanted to add a Save as… button to a webapp? Whether you’re making an advanced WebGL-powered CAD webapp and want to save 3D object files or you just want to save plain text files in a simple Markdown text editor, saving files in the browser has always been a tricky business.

Usually when you want to save a file generated with JavaScript, you have to send the data to your server and then return the data right back with a Content-disposition: attachment header. This is less than ideal for webapps that need to work offline. The W3C File API includes a FileSaver interface, which makes saving generated data as easy as saveAs(data, filename), though unfortunately it will eventually be removed from the spec.

I have written a JavaScript library called FileSaver.js, which implements FileSaver in all modern browsers. Now that it’s possible to generate any type of file you want right in the browser, document editors can have an instant save button that doesn’t rely on an online connection. When paired with the standard HTML5 canvas.toBlob() method, FileSaver.js lets you save canvases instantly and give them filenames, which is very useful for HTML5 image editing webapps. For browsers that don’t yet support canvas.toBlob(), Devin Samarin and I wrote canvas-toBlob.js. Saving a canvas is as simple as running the following code:

canvas.toBlob(function(blob) {
    saveAs(blob, filename);
});

I have created a demo of FileSaver.js in action that demonstrates saving a canvas doodle, plain text, and rich text. Please note that saving with custom filenames is only supported in browsers that either natively support FileSaver or browsers like Google Chrome 14 dev and Google Chrome Canary, that support <a>.download or web filesystems via LocalFileSystem.

How to construct files for saving

First off, you want to instantiate a Blob. The Blob API isn’t supported in all current browsers, so I made Blob.js which implements it. The following example illustrates how to save an XHTML document with saveAs().

saveAs(
      new Blob(
          [(new XMLSerializer).serializeToString(document)]
        , {type: "application/xhtml+xml;charset=" + document.characterSet}
    )
    , "document.xhtml"
);

Not saving textual data? You can save multiple binary Blobs and ArrayBuffers to a Blob as well! The following is an example of setting generating some binary data and saving it.

var
      buffer = new ArrayBuffer(8) // allocates 8 bytes
    , data = new DataView(buffer)
;
// You can write uint8/16/32s and float32/64s to dataviews
data.setUint8 (0, 0x01);
data.setUint16(1, 0x2345);
data.setUint32(3, 0x6789ABCD);
data.setUint8 (7, 0xEF);

saveAs(new Blob([buffer], {type: "example/binary"}), "data.dat");
// The contents of data.dat are <01 23 45 67 89 AB CD EF>

If you’re generating large files, you can implement an abort button that aborts the FileSaver.

var filesaver = saveAs(blob, "video.webm");
abort_button.addEventListener("click", function() {
    filesaver.abort();
}, false);

I recently discovered a method to title image files in Opera. I was experimenting with CSS generated content in regards to the <title> element in various browsers, and discovered that as long as the <head> and <title> elements are not display: none, generated content applied before and after the <title> element is added to the page title itself in Opera. It was obvious to me that I should combine this with HTTP Link: headers containing stylesheets, as to make it possible to modify the title of usually non-titleable media, such as images, plain text, audio, and video.

In this demo, the following CSS rules are applied in Opera.

head, title {
	display: block;
	width: 0;
	height: 0;
	visibility: hidden;
}

title::before {
	content: "Just an image — ";
}