The purpose of ITP is to prevent tracking tools’ access to data stored and processed in the browser. This involves things like blocking all third-party cookies and restricting the lifetime of first-party cookies.
In this article, I want to show you how to use the ITP Debug Mode. It’s a console logger that outputs all the actions taken by Intelligent Tracking Prevention on the user’s device or browser.
You can enable the logger using the “Enable Intelligent Tracking Prevention Debug Mode” option the Debug Menu.
One of the features of the Web Share API is that it allows you to share files along with your share intent:
if (navigator.canShare && navigator.canShare({ files: filesArray })) {
navigator.share({
files: filesArray,
title: 'Vacation Pictures',
text: 'Photos from September 27 to October 14.',
})
.then(() => console.log('Share was successful.'))
.catch((error) => console.log('Sharing failed', error));
} else {
console.log(`Your system doesn't support sharing files.`);
}
As unearthed by redteam.pl there’s a big security issue with it in Safari/MobileSafari:
The problem is that file: scheme is allowed and when a website points to such URL unexpected behavior occurs. In case such a link is passed to the navigator.share function an actual file from the user file system is included in the shared message which leads to local file disclosure when a user is sharing it unknowingly. The problem is not very serious as user interaction is required, however it is quite easy to make the shared file invisible to the user. The closest comparison that comes to mind is clickjacking as we try to convince the unsuspecting user to perform some action.
In their tests they’ve successfully stolen the local /etc/passwd or even the entire MobileSafari history (which is nothing more than a .sqlite file).
Apple first stated that they are only going to fix it in the Spring 2021 (!) Security Update, but after the post went public it now looks that they’ve changed course, as by now a fix has been committed into the Webkit Source:
+static Optional<URL> shareableURLForShareData(ScriptExecutionContext& context, const ShareData& data)
+{
+ if (data.url.isNull())
+ return WTF::nullopt;
+
+ auto url = context.completeURL(data.url);
+ if (!url.isValid())
+ return WTF::nullopt;
+ if (!url.protocolIsInHTTPFamily() && !url.protocolIsData())
+ return WTF::nullopt;
+
+ return url;
+}
+
- Optional<URL> url;
- if (!data.url.isNull()) {
- url = context.completeURL(data.url);
- if (!url->isValid())
- return false;
- }
+ if (!data.url.isNull() && !shareableURLForShareData(context, data))
+ return false;
+
Bonus points for naming that class WTF 😅
Apart from that quick fix in the code, the issue is also being discussed at the spec level in order to prevent other implementers from making the same mistake.
This year’s spring releases of Safari 13.1 for macOS Catalina, iPadOS, iOS, and watchOS bring a tremendous number of WebKit improvements for the web across Apple’s platforms. All of this with many more updates for improved privacy, performance, and a host of new tools for web developers.
Media APIs: Picture-in-Picture API and Remote Playback API
Subtitles and Captions
Great to see things like ResizeObserver finally make it into Safari. The Web Anmations even have gotten their own entry on the WebKit Blog.
~
The enterkeyhint attribute is something new to me. As the spec states, it allows you to set the word to be used on the enter button on virtual keyboards:
The enterkeyhint content attribute is an enumerated attribute that specifies what action label (or icon) to present for the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key in order to make it more helpful for users.
Allowed values are:
enter: Typically inserting a new line.
done: Typically meaning there is nothing more to input and the IME will be closed.
go: Typically meaning to take the user to the target of the text they typed.
next: Typically taking the user to the next field that will accept text.
previous: Typically taking the user to the previous field that will accept text.
search: Typically taking the user to the results of searching for the text they have typed.
send: Typically delivering the text to its target.
Mattias recently tweeted that his website can now be served over HTTP/3 “even though no browser supports it yet”.
While it’s true that no browser supports it out of the box right now, there are options to enable HTTP/3. Here’s how.
🧪 As with all experimental technolgy/features: things might break! Be warned!
~
Google Chrome
If you search chrome://flags you’ll find an option named “Experimental QUIC Protocol” which you can enable:
That alone however won’t do. You’ll also need to enable a specific HTTP3 version, apparently. This extra change cannot be done through chrome://flags, but only through a command line option.
To fully enable HTTP/3 in Chrome, you must launch it with the command line options --enable-quic --quic-version=h3-27 :
If you’re running (the unreleased) macOS 10.16 / iOS 14, you can now use the Develop menu and underneath Experimental Features enable it.
🙏 Thanks to Kai for digging up the fact that macOS 10.16 is required.
~
How to test this?
A good site to test your connection is https://www.litespeedtech.com/. Visit that site and open the DevTools of your browser (SHIFT+CMD+I). In the Network tab enable the protocol column and refresh the page.
Here’s an example of Firefox:
quic.rocks is also a good site you can use. I did notice that Firefox for example sometimes loads that site using HTTP/1.1 and sometimes using HTTP/3 … experimental features, right? 😉
~
Did this help you out? Like what you see? Thank me with a coffee.
I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!
Jonathan Davis – Web Technologies Evangelist for Apple – has done a writeup on the new features that have landed in Safari 12.1, which is included with macOS Mojave 10.14.4 and iOS 12.2.
This release delivers web platform features that improve website integration with the operating system, new real-time communication capabilities, more compatible encrypted media support, and features that help developers reduce the need for polyfills.
Supporting <input type="color" /> looks handy, yet (on iOS) I’d also like to be able to input a color hex code myself.
The <datalist> element also forms a nice addition, but the implementation (on iOS) needs some more work imho: the triangle on the right of the input makes me think it’s a dropdown. Upon tapping the input I get to see three of the defined options. Since I am under the impression that this control is a dropdown, I’m also left with the impression that I can only choose one of those three options that are initially presented … confusing.
Not mentioned in the post, but mentioned in the release notes, is the fact that Safari will now implicitly add rel="noopener" onto links that have target="_blank" set.
By default, the new iPhone X in landscape mode will contain sites in the so called “safe area”, resulting in white bars being rendered on either side of the site(src).
The color, white by default, can be tweaked by altering the background-color on the <body> element. Do note that it’s only background-color though: it doesn’t take gradients/background images into account, so you won’t jump very far with this …
Cover it up!
By adding viewport-fit=cover to the viewport meta tag, it’s possible to make the site stretch out beyond the safe area so that it takes up the full width of the device (src)
Safari in macOS High Sierra uses an automatic inference engine to block media elements with sound from auto-playing by default on most websites. Safari 11 also gives users control over which websites are allowed to auto-play video and audio by opening Safari’s new “Websites” preferences pane, or through the “Settings for This Website…” option in the Safari menu. Further, a new power-saving feature prevents silent videos from auto-playing when either hidden in a background tab or otherwise off-screen.
Calling .play() on a <video> element will now return a Promise:
var promise = document.querySelector('video').play();
if (promise !== undefined) {
promise.catch(error => {
// Auto-play was prevented
// Show a UI element to let the user manually start playback
}).then(() => {
// Auto-play started
});
}
Safari Technology Preview is a version of Safari for OS X, distributed by Apple, that includes a cutting-edge, in-development version of the WebKit browser engine. It’s a great way to test upcoming WebKit features and give feedback to the people building them when it’s most useful — early in development.
Think Webkit Nightly, but then in a Safari wrapped featureset (iCloud History, and iCloud Tabs). Features you can try now – which are currently not included in the latest stable Safari release – are ES6, Shadow DOM, CSP2, etc.
The viewport is set incorrectly when the viewport meta tag is specified with initial-scale=1 or width=device-width, and the page contains an element (e.g. div tag) that is wider than the desired viewport’s boundary.
In the screenshot above (courtesy @RWD) you can see that the off-screen menu actually appears on-screen in iOS9. Apple changed how iOS9 responds to width=device-width as it, according to them, got abused too much.
To fix this, append shrink-to-fit=no to your viewport meta tag, as such: