Tags: uri

203

sparkline

Wednesday, October 2nd, 2019

Same-Site Cookies By Default | text/plain

This is good news. I have third-party cookies disabled in my browser, and I’m very happy that it will become the default.

It’s hard to believe that we ever allowed third-party cookies and scripts in the first place. Between them, they’re responsible for the worst ills of the World Wide Web.

Sunday, September 1st, 2019

Bandstands: The industry built on Victorian social engineering - BBC News

As a resident of Brighton—home to the most beautiful of bandstands—this bit of background to their history is fascinating.

Wednesday, August 7th, 2019

Turing Tumble - Build Marble-Powered Computers

Boolean logic manifested in a Turing-complete game

Tuesday, July 16th, 2019

How to Kill IE11 - What the Deaths of IE6 and IE8 Tell Us About Killing IE | Mike Sherov

An interesting look at the mortality causes for Internet Explorer 6 and Internet Explorer 8, and what they can tell us for the hoped-for death of Internet Explorer 11.

I disagree with the conclusion (that we should actively block IE11—barring any good security reasons, I don’t think that’s defensible), but I absolutely agree that we shouldn’t be shipping polyfills in production just for IE11. Give it your HTML. Give it your CSS. Withhold modern JavaScript. If you’re building with progressive enhancement (and you are, right?), then giving IE11 users a sub-par experience is absolutely fine …it’s certainly better than blocking them completely.

Monday, July 15th, 2019

Spurious Correlations

Correlation does not imply causation.

Saturday, July 6th, 2019

The Hiding Place: Inside the World’s First Long-Term Storage Facility for Highly Radioactive Nuclear Waste - Pacific Standard

Robert McFarlane’s new book is an exploration of deep time. In this extract, he visits the Onkalo nuclear waste storage facility in Finland.

Sometimes we bury materials in order that they may be preserved for the future. Sometimes we bury materials in order to preserve the future from them.

Thursday, May 30th, 2019

Is CSS Turing Complete? | Lara Schenck

This starts as a good bit of computer science nerdery, that kind of answers the question in the title:

Alone, CSS is not Turing complete. CSS plus HTML plus user input is Turing complete!

And so the takeaway here is bigger than just speculation about Turing completeness:

Given that CSS is a domain-specific language for styling user interface, this makes a lot of sense! CSS + HTML + Human = Turing complete.

At the end of that day, as CSS developers that is the language we really write. CSS is incomplete without HTML, and a styled interface is incomplete without a human to use it.

Wednesday, April 24th, 2019

Untold History of AI - IEEE Spectrum

A terrific six-part series of short articles looking at the people behind the history of Artificial Intelligence, from Babbage to Turing to JCR Licklider.

  1. When Charles Babbage Played Chess With the Original Mechanical Turk
  2. Invisible Women Programmed America’s First Electronic Computer
  3. Why Alan Turing Wanted AI Agents to Make Mistakes
  4. The DARPA Dreamer Who Aimed for Cyborg Intelligence
  5. Algorithmic Bias Was Born in the 1980s
  6. How Amazon’s Mechanical Turkers Got Squeezed Inside the Machine

The history of AI is often told as the story of machines getting smarter over time. What’s lost is the human element in the narrative, how intelligent machines are designed, trained, and powered by human minds and bodies.

Thursday, April 11th, 2019

Accessibility Events | CSS-Tricks

If you’re using Apple’s VoiceOver, both your phone and your computer will broadcast your assumed disability to the entire internet, unless and until you specifically tell it to stop.

Thursday, April 4th, 2019

Apple’s new feature a step towards digital apartheid - Axess Lab

I also discussed this accessibility events feature with my friend who is a screen reader user herself. She said it feels like it’s a first step towards a well-meant digital apartheid.

Monday, March 18th, 2019

Brendan Dawes - The Art of Cybersecurity

Some lovely data visualisation by Brendan:

The work features three main components — the threats, represented by black obelisk style objects, the system which detects and deals with these threats, represented by an organic mesh like structure, and finally the creativity that is allowed to flow because the threats have been neutralised.

Friday, March 15th, 2019

Tuesday, February 19th, 2019

Blockchain and Trust - Schneier on Security

Honestly, cryptocurrencies are useless. They’re only used by speculators looking for quick riches, people who don’t like government-backed currencies, and criminals who want a black-market way to exchange money.

Bruce Schneier on the blockchain:

What blockchain does is shift some of the trust in people and institutions to trust in technology. You need to trust the cryptography, the protocols, the software, the computers and the network. And you need to trust them absolutely, because they’re often single points of failure.

Sunday, January 27th, 2019

Deface

A browser extension that encrypts and decrypts posts on Facebook—if two users have the extension installed, they can communicate without Facebook being able read their messages.

Wednesday, January 16th, 2019

Security Checklist

Exactly what it sounds like: a checklist of measures you can take to protect yourself.

Most of these require a certain level of tech-savviness, which is a real shame. On the other hand, some of them are entirely about awareness.

Tuesday, January 1st, 2019

Friday, December 28th, 2018

Malicious AI Report

Well, this an interesting format experiment—the latest Black Mirror just dropped, and it’s a PDF.

Wednesday, December 12th, 2018

What’s the difference between JavaScript event delegation, bubbling, and capturing? | Go Make Things

I can never keep these straight—this is going to be a handy reference to keep on hand.

Sunday, November 11th, 2018

Push without notifications

On the first day of Indie Web Camp Berlin, I led a session on going offline with service workers. This covered all the usual use-cases: pre-caching; custom offline pages; saving pages for offline reading.

But on the second day, Sebastiaan spent a fair bit of time investigating a more complex use of service workers with the Push API.

The Push API is what makes push notifications possible on the web. There are a lot of moving parts—browser, server, service worker—and, frankly, it’s way over my head. But I’m familiar with the general gist of how it works. Here’s a typical flow:

  1. A website prompts the user for permission to send push notifications.
  2. The user grants permission.
  3. A whole lot of complicated stuff happens behinds the scenes.
  4. Next time the website publishes something relevant, it fires a push message containing the details of the new URL.
  5. The user’s service worker receives the push message (even if the site isn’t open).
  6. The service worker creates a notification linking to the URL, interrupting the user, and generally adding to the weight of information overload.

Here’s what Sebastiaan wanted to investigate: what if that last step weren’t so intrusive? Here’s the alternate flow he wanted to test:

  1. A website prompts the user for permission to send push notifications.
  2. The user grants permission.
  3. A whole lot of complicated stuff happens behinds the scenes.
  4. Next time the website publishes something relevant, it fires a push message containing the details of the new URL.
  5. The user’s service worker receives the push message (even if the site isn’t open).
  6. The service worker fetches the contents of the URL provided in the push message and caches the page. Silently.

It worked.

I think this could be a real game-changer. I don’t know about you, but I’m very, very wary of granting websites the ability to send me push notifications. In fact, I don’t think I’ve ever given a website permission to interrupt me with push notifications.

You’ve seen the annoying permission dialogues, right?

In Firefox, it looks like this:

Will you allow name-of-website to send notifications?

[Not Now] [Allow Notifications]

In Chrome, it’s:

name-of-website wants to

Show notifications

[Block] [Allow]

But in actual fact, these dialogues are asking for permission to do two things:

  1. Receive messages pushed from the server.
  2. Display notifications based on those messages.

There’s no way to ask for permission just to do the first part. That’s a shame. While I’m very unwilling to grant permission to be interrupted by intrusive notifications, I’d be more than willing to grant permission to allow a website to silently cache timely content in the background. It would be a more calm technology.

Think of the use cases:

  • I grant push permission to a magazine. When the magazine publishes a new article, it’s cached on my device.
  • I grant push permission to a podcast. Whenever a new episode is published, it’s cached on my device.
  • I grant push permission to a blog. When there’s a new blog post, it’s cached on my device.

Then when I’m on a plane, or in the subway, or in any other situation without a network connection, I could still visit these websites and get content that’s fresh to me. It’s kind of like background sync in reverse.

There’s plenty of opportunity for abuse—the cache could get filled with content. But websites can already do that, and they don’t need to be granted any permissions to do so; just by visiting a website, it can add multiple files to a cache.

So it seems that the reason for the permissions dialogue is all about displaying notifications …not so much about receiving push messages from the server.

I wish there were a way to implement this background-caching pattern without requiring the user to grant permission to a dialogue that contains the word “notification.”

I wonder if the act of adding a site to the home screen could implicitly grant permission to allow use of the Push API without notifications?

In the meantime, the proposal for periodic synchronisation (using background sync) could achieve similar results, but in a less elegant way; periodically polling for new content instead of receiving a push message when new content is published. Also, it requires permission. But at least in this case, the permission dialogue should be more specific, and wouldn’t include the word “notification” anywhere.

Monday, October 22nd, 2018

So We Got Tracked Anyway

Even using a strict cookie policy won’t help when Facebook and Google are using TLS to fingerprint users. Time to get more paranoid:

HTTPS session identifiers can be disabled in Mozilla products manually by setting ‘security.ssl.disablesessionidentifiers’ in about:config.