Simon Willison's Weblog: safari

Default styles for h1 elements are changing

2025-04-11T03:54:43+00:00

Default styles for h1 elements are changing

Wow, this is a rare occurrence! Firefox are rolling out a change to the default user-agent stylesheet for nested <h1> elements, currently ramping from 5% to 50% of users and with full roll-out planned for Firefox 140 in June 2025. Chrome is showing deprecation warnings and Safari are expected to follow suit in the future.

What's changing? The default sizes of <h1> elements that are nested inside <article>, <aside>, <nav> and <section>.

These are the default styles being removed:

/* where x is :is(article, aside, nav, section) */
x h1 { margin-block: 0.83em; font-size: 1.50em; }
x x h1 { margin-block: 1.00em; font-size: 1.17em; }
x x x h1 { margin-block: 1.33em; font-size: 1.00em; }
x x x x h1 { margin-block: 1.67em; font-size: 0.83em; }
x x x x x h1 { margin-block: 2.33em; font-size: 0.67em; }

The short version is that, many years ago, the HTML spec introduced the idea that an <h1> within a nested section should have the same meaning (and hence visual styling) as an <h2>. This never really took off and wasn't reflected by the accessibility tree, and was removed from the HTML spec in 2022. The browsers are now trying to cleanup the legacy default styles.

This advice from that post sounds sensible to me:

Do not rely on default browser styles for conveying a heading hierarchy. Explicitly define your document hierarchy using <h2> for second-level headings, <h3> for third-level, etc.

Always define your own font-size and margin for <h1> elements.

Via Hacker News

Tags: browsers, chrome, css, firefox, html, mozilla, safari, web-standards

Simple Push Demo

2023-03-27T20:48:27+00:00

Simple Push Demo

Safari 16.4 is out (upgrade to iOS 16.4 to get it) and the biggest feature for me is mobile support for Web Push notifications. This little demo tool was the first I found that successfully sent a notification to my phone: frustratingly you have to add it to your home page first in order to enable the feature. The site also provides a curl command for sending push notifications through the Apple push server once a token has been registered, which is the crucial step to figuring out how to build applications that can send out notifications to users who have registered to receive them.

Via @simon

Tags: safari, web-standards, webpush

Web Push for Web Apps on iOS and iPadOS

2023-02-17T00:28:55+00:00

Web Push for Web Apps on iOS and iPadOS

iOS and iPadOS 16.4 beta 1 finally brings web push notifications to iOS. User’s need to add an app to their home screen and then approve notification access to get this functionality, which also includes the ability for apps to update a badge on their icon. Thankfully you don’t need paid membership of the Apple Developer Program ($99/year) in order to send notifications.

Tags: safari, ios

Supporting logical properties

2022-10-01T01:03:21+00:00

Supporting logical properties

A frustrating reminder from Jeremy Keith that Safari is not an evergreen browser: older iOS devices (1st gen iPad Air for example) get stuck on the last iOS version that supports them, which also sticks them with an old version of Safari, which means they will never get support for newer CSS properties such as inline-start and block-end. Jeremy shows how to use the @supports rule to hide this new syntax from those older browsers.

Tags: css, jeremy-keith, safari, web-standards, ios

Exploring the SameSite cookie attribute for preventing CSRF

2021-08-03T21:09:02+00:00

In reading Yan Zhu's excellent write-up of the JSON CSRF vulnerability she found in OkCupid one thing puzzled me: I was under the impression that browsers these days default to treating cookies as SameSite=Lax, so I would expect attacks like the one Yan described not to work in modern browsers.

This lead me down a rabbit hole of exploring how SameSite actually works, including building an interactive SameSite cookie exploration tool along the way. Here's what I learned.

Background: Cross-Site Request Forgery

I've been tracking CSRF (Cross-Site Request Forgery) on this blog since 2005(!)

A quick review: let's say you have a page in your application that allows a user to delete their account, at https://www.example.com/delete-my-account. The user has to be signed in with a cookie in order to activate that feature.

If you created that page to respond to GET requests, I as an evil person could create a page at https://www.evil.com/force-you-to-delete-your-account that does this:

<img src="https://www.example.com/delete-my-account">

If I can get you to visit my page, I can force you to delete your account!

But you're smarter than that, and you know that GET requests should be idempotent. You implement your endpoint to require a POST request instead.

Turns out I can still force-delete accounts, if I can trick a user into visiting a page with the following evil HTML on it:

<form action="https://www.example.com/delete-my-account" method="POST">
<input type="submit" value="Delete my account">
</form>
<script>document.forms[0].submit()</script>

The form submits with JavaScript the instant they load the page!

CSRF is an extremely common and nasty vulnerability - especially since it's a hole by default: if you don't know what CSRF is, you likely have it in your application.

Traditionally the solution has been to use CSRF tokens - hidden form fields which "prove" that the user came from a form on your own site, and not a form hosted somewhere else. OWASP call this the Double Submit Cookie pattern.

Web frameworks like Django implement CSRF protection for you. I built asgi-csrf to help add CSRF token protection to ASGI applications.

Clearly it would be better if we didn't have to worry about CSRF at all.

As far as I can tell, work on specifying the SameSite cookie attribute started in June 2016. The idea was to add an additional attribute to cookies that specifies the policy for if they should be included in requests made to a domain from pages hosted on another domain.

Today, all modern browsers support SameSite. MDN has SameSite documentation, but a summary is:

SameSite=None - the cookie is sent in "all contexts" - more-or-less how things used to work before SameSite was invented. Update: One major edge-case here is that Safari apparently ignores None if the "Prevent cross-site tracking" privacy preference is turned on - and since that is on by default, this means that SameSite=None is effectively useless if you care about Safari or Mobile Safari users.
SameSite=Strict - the cookie is only sent for requests that originate on the same domain. Even arriving on the site from an off-site link will not see the cookie, unless you subsequently refresh the page or navigate within the site.
SameSite=Lax - cookie is sent if you navigate to the site through following a link from another domain but not if you submit a form. This is generally what you want to protect against CSRF attacks!

The attribute is specified by the server in a set-cookie header that looks like this:

set-cookie: lax-demo=3473; Path=/; SameSite=lax

Why not habitually use SameSite=Strict? Because then if someone follows a link to your site their first request will be treated as if they are not signed in at all. That's bad!

So explicitly setting a cookie with SameSite=Lax should be enough to protect your application from CSRF vulnerabilities... provided your users have a browser that supports it.

(Can I Use reports 93.95% global support for the attribute - not quite high enough for me to stop habitually using CSRF tokens, but we're getting there.)

What if the SameSite attribute is missing?

Here's where things get interesting. If a cookie is set without a SameSite attribute at all, how should the browser treat it?

Over the past year, all of the major browsers have been changing their default behaviour. The goal is for a missing SameSite attribute to be treated as if it was SameSite=Lax - providing CSRF protection by default.

I have found it infuriatingly difficult to track down if and when this change has been made:

Chrome/Chromium offer the best documentation - they claim to have ramped up the new default to 100% of users in August 2020. WebViews in Android still have the old default behaviour, which is scheduled to be fixed in Android 12 (not yet released).
Firefox have a blog entry from August 2020 which says "Starting with Firefox 79 (June 2020), we rolled it out to 50% of the Firefox Beta user base" - but I've not been able to find any subsequent updates. Update 26th August 2024: It turns out Firefox didn't ship this after all, going with their own Total Cookie Protection solution instead, which rolled out in April 2023.
I have no idea at all what's going on with Safari!

I started a Twitter thread to try and collect more information, so please reply there if you know what's going on in more detail.

The Chrome 2-minute twist

Assuming all of the above, the mystery remained: how did Yan's exploit fail to be prevented by browsers?

After some back-and-forth about this on Twitter Yan proposed that the answer may be this detail, tucked away on the Chrome Platform Status page for Feature: Cookies default to SameSite=Lax.

Note: Chrome will make an exception for cookies set without a SameSite attribute less than 2 minutes ago. Such cookies will also be sent with non-idempotent (e.g. POST) top-level cross-site requests despite normal SameSite=Lax cookies requiring top-level cross-site requests to have a safe (e.g. GET) HTTP method. Support for this intervention ("Lax + POST") will be removed in the future.

It looks like OkCupid were setting their authentication cookie without a SameSite attribute... which opened them up to a form-based CSRF attack but only for the 120 seconds following the cookie being set!

Building a tool to explore SameSite browser behaviour

I was finding this all very confusing, so I built a tool.

The code lives in simonw/samesite-lax-demo on GitHub, but the tool itself has two sides:

A server-side Python (Starlette) web application for setting cookies with different SameSite attributes. This is hosted on Vercel at https://samesite-lax-demo.vercel.app/
An HTML page on a different domain that links to that cookied site, provides a POST form targetting it, embeds an image from it and executes some fetch() requests against it. This is at https://simonw.github.io/samesite-lax-demo/

Hosting on two separate domains is critical for the tool to show what is going on. I chose Vercel and GitHub Pages because they are both trivial to set up to continuously deploy changes from a GitHub repository.

Using the tool in different browsers helps show exactly what is going on with regards to cross-domain cookies.

A few of the things I observed using the tool:

SameSite=Strict works as you would expect. It's particularly interesting to follow the regular <a href=...> link from the static site to the application and see how the strict cookie is NOT visible upon arrival - but becomes visible when you refresh that page.
I included a dynamically generated SVG in a <img src="/cookies.svg"> image tag, which shows the cookies (using SVG <text>) that are visible to the request. That image shows all four types of cookie when embedded on the Vercel domain, but when embedded on the GitHub pages domain it differs wildly:
- Firefox 89 shows both the SameSite=None and the missing SameSite cookies
- Chrome 92 shows just the SameSite=None cookie
- Safari 14.0 shows no cookies at all!
Chrome won't let you set a SameSite=None cookie without including the Secure attribute.
I also added some JavaScript that makes a cross-domain fetch(..., {credentials: "include"}) call against a /cookies.json endpoint. This didn't send any cookies at all until I added server-side headers access-control-allow-origin: https://simonw.github.io and access-control-allow-credentials: true. Having done that, I got the same results across the three browsers as for the <img test described above.

Safari ignoring SameSite=None looked like it was this bug: Cookies with SameSite=None or SameSite=invalid treated as Strict - it's marked as fixed but it's not clear to me if the fix has been released yet - I still saw that behaviour on my macOS 10.15.6 laptop or my iOS 14.7.1 iPhone.

Update: krinchan on Hacker News has an answer here:

The Safari "bug" is a new setting that's turned on by default: "Prevent cross-site tracking". It treats all cookies as SameSite=Lax, even cookies with SameSite=None.

Full Third-Party Cookie Blocking and More on the WebKit blog has more about this.

Most excitingly, I was able to replicate the Chrome two minute window bug using the tool! Each cookie has its value set to the timestamp when it was created, and I added code to display how many seconds ago the cookie was set. Here's an animation showing how Chrome on a form submission navigation can see the cookie that was set with SameSite missing at 114 seconds old, but that cookie is no longer visible once it passes 120 seconds.

Consider your subdomains

One last note about CSRF that you should consider: SameSite=Lax still allows form submissions from subdomains of your primary domain to carry their cookies.

This means that if you have a XSS vulnerability on one of your subdomains the security of your primary domain will be compromised.

Since it's common for subdomains to host other applications that may have their own security concerns, ditching CSRF tokens for Lax cookies may not be a wise step!

A Login CSRF attack is when a malicious forces a user to sign into an account controlled by the attacker. Why do this? Because if that user then saves sensitive information the attacker can see it.

Imagine I trick you into signing into an e-commerce account I control and saving your credit card details. I could then later sign in myself and buy things on your card!

Here's how that would work: Say the site's login form makes a POST to https://www.example.com/login with username and password as the form fields. If those credentials match, the site sets an authentication cookie.

I can set up my evil website with the following form:

<form action="https://www.example.com/login">
  <input type="hidden" name="username" value="my-username">
  <input type="hidden" name="password" value="my-password">
</form>
<script>document.forms[0].submit()</script>

I trick you into visiting my evil pge and you're now signed in to that site using an account that I control. I cross my fingers and hope you don't notice the "you are signed in as X" message in the UI.

An interesting thing about Login CSRF is that, since it involves setting a cookie but not sending a cookie, SameSite=Lax would seem to make no difference at all. You need to look to other mechanisms to protect against this attack.

But actually, you can use SameSite=Lax to prevent these. The trick is to only allow logins from users that are carrying at least one cookie which you have set in that way - since you know that those cookies could not have been sent if the user originated in a form on another site.

Another (potentially better) option: check the HTTP Origin header on the oncoming request.

Final recommendations

As an application developer, you should set all cookies with SameSite=Lax unless you have a very good reason not to. Most web frameworks do this by default now - Django shipped support for this in Django 2.1 in August 2018.

Do you still need CSRF tokens as well? I think so: I don't like the idea of users who fire up an older browser (maybe borrowing an obsolete computer) being vulnerable to this attack, and I worry about the subdomain issue described above.

And if you work for a browser vendor, please make it easier to find information on what the default behaviour is and when it was shipped!

Tags: chrome, cookies, csrf, safari, security, samesite, starlette

Evolution of : Gif without the GIF

2017-12-04T19:28:03+00:00

Evolution of <img>: Gif without the GIF

Safari Technology Preview lets you use <img src="movie.mp4">, for high quality animated gifs in 1/14th of the file size.

Via Malte Ubl

Tags: gifs, safari, video

Release Notes for Safari Technology Preview 44

2017-11-15T23:35:00+00:00

Release Notes for Safari Technology Preview 44

The big news is support for the W3C Payment Request API for devices with Apple Pay enabled. Chrome, Firefox and Edge have been working on this as well.

Tags: safari

Visualizing WebKit's hardware acceleration

2011-06-27T10:31:00+00:00

Visualizing WebKit's hardware acceleration

Command line flags for launching Safari (and the iOS simulator) in a way that highlights areas of the screen that are being hardware accelerated—particularly useful if you are using the “-webkit-transform: translate3d(0,0,0)” trick.

Tags: css, safari, webkit, ios, recovered

Surfin' Safari: Announcing... MathML!

2010-08-18T13:49:00+00:00

Surfin' Safari: Announcing... MathML!

MathML is now supported by the WebKit nightlies. Worth checking out for the typographical discussion that’s broken out in the comments.

Tags: mathml, safari, typography, webkit, recovered

Jeremiah Grossman: I know who your name, where you work, and live

2010-07-22T08:44:00+00:00

Jeremiah Grossman: I know who your name, where you work, and live

Appalling unfixed vulnerability in Safari 4 and 5 —if you have the “AutoFill web forms using info from my Address Book card” feature enabled (it’s on by default) malicious JavaScript on any site can steal your name, company, state and e-mail address—and would be able to get your phone number too if there wasn’t a bug involving strings that start with a number. The temporary fix is to disable that preference.

Tags: apple, autocomplete, browsers, exploit, safari, security, vulnerability, recovered

SublimeVideo - HTML5 Video Player

2010-02-02T09:50:43+00:00

SublimeVideo - HTML5 Video Player

Still a fair way to go (no Firefox support yet, and they plan to add a Flash fallback for IE) but in Safari this is pretty extraordinary. Smooth video, beautiful UI, full window mode and full screen mode in the latest WebKit nightlies. I’d go as far as saying that this is the nicest online video implementation I’ve seen (at least on the Mac).

Tags: flash, html5, safari, video, webkit

HTML 5 audio player demo

2010-02-01T09:58:47+00:00

HTML 5 audio player demo

Scott Andrew’s experiments with the HTML5 audio element (and jQuery)—straight forward and works a treat in Safari, but Firefox doesn’t support MP3. Presumably it’s not too hard to set up a fallback for Ogg.

Tags: audio, firefox, html5, javascript, jquery, mp3, ogg, safari, scott-andrew

Dinky pocketbooks with WebKit transforms

2009-05-22T00:33:49+00:00

Dinky pocketbooks with WebKit transforms

Nat used 90 degree CSS transform rotations in print stylesheets for WebKit and Safari to create printable cut-out-and-fold pocketbooks from A4 pages. Very neat.

Tags: css, csstransforms, natalie-downe, pocketbooks, printstyles, rotation, safari, webkit

Pwn2Own trifecta: Hacker exploits IE8, Firefox, Safari

2009-03-19T15:30:36+00:00

Pwn2Own trifecta: Hacker exploits IE8, Firefox, Safari

You just can’t trust browser security: Current versions of Safari, IE8 and Firefox all fell to zero-day flaws at an exploit competition. None of the vulnerabilities have been disclosed yet.

Tags: browsers, firefox, ie8, internet-explorer, pwn2own, safari, security

Gears for Safari Beta

2008-08-26T16:27:57+00:00

Gears for Safari Beta

“Chances are it will break your browser. Please proceed with caution.”

Tags: beta, gears, google, safari

SquirrelFish

2008-06-03T07:57:11+00:00

SquirrelFish

WebKit’s JavaScript engine was no slouch, but that hasn’t stopped them from replacing it with a brand new “register-based, direct-threaded, high-level bytecode engine, with a sliding register window calling convention”. It runs 1.6x faster and has the Best Logo Ever.

Tags: bytecode, javascript, logo, performance, safari, squirrelfish, webkit

Google Gears renamed "Gears"

2008-05-29T00:38:43+00:00

Google Gears renamed "Gears"

“We want to make it clear that Gears isn’t just a Google thing. We see Gears as a way for everyone to get involved with upgrading the web platform.” Support for Firefox 3 and Safari is being added and Opera are integrating Gears with both their desktop and mobile browsers.

Tags: firefox3, gears, google, opera, safari

getElementsByClassName pre Prototype 1.6

2008-03-26T08:28:05+00:00

getElementsByClassName pre Prototype 1.6

Older releases of Prototype break in Firefox 3 and Safari 3.1 due to unsafe namespace management—getElementsByClassName is now a browser built-in but with different semantics to the Prototype method of the same name. Prototype 1.6 is fine.

Tags: firefox3, getelementsbyclassname, javascript, john-resig, namespaces, prototype-js, safari

querySelector and querySelectorAll

2008-02-08T11:21:03+00:00

querySelector and querySelectorAll

WebKit now supports the W3C Selectors API. Expect the various JavaScript libraries to add this as an optimisation to achieve massive speedups (Prototype are already working on it).

Tags: javascript, libraries, prototype-js, queryselector, safari, selectors, w3c, webkit

Jash: JavaScript Shell

2007-12-09T12:36:51+00:00

Jash: JavaScript Shell

An advanced JavaScript interactive shell bookmarklet that works in IE, Firefox, Opera and Safari.

Via Gareth Rushgrove

Tags: bookmarklets, firefox, gareth-rushgrove, internet-explorer, jash, javascript, opera, safari, shell

Safari CSS Reference

2007-11-22T23:51:42+00:00

Safari CSS Reference

Official documentation covering the CSS properties supported by Safari, including the -webkit proprietary extensions.

Tags: browsers, css, documentation, safari, webkit

Ten New Things in WebKit 3

2007-11-16T01:19:52+00:00

Ten New Things in WebKit 3

Does “incremental updates for persistent server connections” for XMLHttpRequest mean Safari now has native support for Comet?

Tags: ajax, comet, javascript, safari, safari3, webkit, xmlhttprequest

HTML5 Media Support in WebKit

2007-11-12T23:21:40+00:00

HTML5 Media Support in WebKit

WebKit continues to lead the pack when it comes to trying out new HTML5 proposals. The new audio and video elements make embedding media easy, and provide a neat listener API for hooking in to “playback ended” events.

Tags: audio, events, html5, javascript, macos, media, safari, video, webkit

CSS Transforms

2007-10-26T21:45:01+00:00

CSS Transforms

WebKit can now do transforms (scale, rotate, translate and skew) in CSS via a new -webkit-transform property. Transforms behave like position relative in that they don’t affect the layout of the page. You can also provide a full affine transform matrix as a shortcut.

Tags: affinetransformation, apple, browsers, css, graphics, matrix, safari, transforms, webkit

Site-specific browsers and GreaseKit

2007-10-25T07:56:01+00:00

Site-specific browsers and GreaseKit

New site-specific browser tool which lets you include a bunch of Greasemonkey scripts. For me, the killer feature of site-specific browsers is still cookie isolation (to minimise the impact of XSS and CSRF holes) but none of the current batch of tools advertise this as a feature, and most seem to want to share the system-wide cookie jar.

Tags: chris-messina, cookies, csrf, greasekit, greasemonkey, javascript, safari, security, sitespecificbrowsers, webkit, xss

WebKit Does HTML5 Client-side Database Storage

2007-10-20T12:03:21+00:00

WebKit Does HTML5 Client-side Database Storage

SQLite strikes again. The WebKit team have included a neat update to their Web Inspector that lets you browse and modify your client-side databases.

Tags: apple, html5, offline, safari, sqlite, webinspector, webkit, whatwg

Native DOMContentLoaded is coming to Safari

2007-10-08T01:07:01+00:00

Native DOMContentLoaded is coming to Safari

I filed this bug over two years ago. They’ve just committed the resulting patch to trunk.

Tags: browsers, domcontentloaded, javascript, onload, safari, webkit

Multi-Safari

2007-10-05T23:51:53+00:00

Multi-Safari

Lets you run multiple versions of Safari on the same Mac. As with the multi-IE hacks, all versions use the same underlying HTTP libraries (which belong to the OS) so the simulation isn’t entirely accurate.

Tags: browsers, multisafari, safari

DOMContentLoaded for IE, Safari, everything, without document.write

2007-09-26T12:19:07+00:00

DOMContentLoaded for IE, Safari, everything, without document.write

Stuart has taken Hedger’s recent IE technique, combined it with the others and compressed it in to a short-as-possible code snippet that you can paste in to your scripts without having to include the whole of jQuery/YUI/Dojo/Prototype.

Tags: documentwrite, dom-scripting, internet-explorer, javascript, ondomready, safari, stuart-langridge, unobtrusive-javascript

Some Notes on the YUI Rich Text Editor

2007-08-15T20:13:19+00:00

Some Notes on the YUI Rich Text Editor

Dav Glass explains how he achieved the impressive feat of building a rich text editor widget that also works in Safari.

Tags: dav-glass, javascript, richtext, safari, yui