Archive for March 26, 2020

Thursday, March 26, 2020

Safari 13.1: Third-Party Cookie Blocking and 7-Day Script-Writeable Storage

John Wilander (tweet):

Cookies for cross-site resources are now blocked by default across the board. This is a significant improvement for privacy since it removes any sense of exceptions or “a little bit of cross-site tracking is allowed.”

[…]

Safari continues to pave the way for privacy on the web, this time as the first mainstream browser to fully block third-party cookies by default.

[…]

Now ITP has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site.

[…]

That is the case in Safari. Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer. We do not expect the first-party in such a web application to have its website data deleted.

The existing cookie restrictions have been really frustrating. There are many sites that I visit monthly, and so I need to enter my username and password every single time. I don’t understand why cookies, of all things, don’t have site-specific settings in Safari. I don’t like cookies in general, but there are some sites that I want to trust. Sometimes I wonder whether I should write a script to auto-open them weekly to keep the cookies warm.

Ole Begemann:

I love the WebKit/Safari teams’ continuing work on limiting third-party cookies and other forms of tracking. I hope they tackle first-party tracking next.

Of the hundreds of websites I visit, I really only want to allow a handful to set cookies, and then perhaps only for a short time.

Safari now has 11 categories of site-specific configuration. It’s strange thatookies/local storage is not one of them.

Aral Balkan:

On the face of it, WebKit’s announcement yesterday titled Full Third-Party Cookie Blocking and More sounds like something I would wholeheartedly welcome. Unfortunately, I can’t because the “and more” bit effectively kills off Offline Web Apps and, with it, the chance to have privacy-respecting apps like the prototype I was exploring earlier in the year based on DAT.

[…]

If I use the app in Safari on iOS without adding it to Home Screen and leave it for seven days, will my shopping list be deleted?

If I do the same thing on Safari for macOS (which doesn’t have a Home Screen), will my shopping list be deleted?

Andre Garzia (via Hacker News):

There is a huge opportunity for the creation of private client-side-only PWAs in the world but developers wanting to build such apps are in for an uphill battle against the status quo and now against Apple as well.

[…]

I want to remind everyone that installing to the home screen is not what makes a PWA, it is an optional step. A PWA is still a PWA if the user access it only occasionally by typing the URL on the browser or keeping a bookmark. I access many PWAs on my phone but they are not in my home screen because I like to keep it clean. My browser “new tab” lists them for me, they are still as much a PWA as the ones in your home screen.

Saying that you should build a native app is not an answer. Native apps need to go through gatekeepers, the web does not. The web is the only mass communication media where we all have publishing access (to some degree at least), native iOS apps are not like this. There is a reason Mozilla can’t ship Firefox with Gecko on iOS and the reason is not because they don’t know how to do it. Apple is doing this in the name of privacy but what it actually does is force developers closer to their app store.

Jasper Patterson:

At 1Password we are concerned about the sudden announcement that LocalStorage will expire after 7 days, and want to provide our use case of browser storage and how this will cause harm to our users (including irreversible data loss to some).

We have a full featured web app at 1Password.com that allows users to signup for an account, access their vaults, and perform admin functions for their business.

[…]

The Secret Key is a randomly generated string generated locally during signup and stored on devices users have previously used. This key is required for users to decrypt their vaults. Given that most signups occur in a web browser, that is the first place we store this critical piece of data. While we do try to encourage users to install our native applications, for some (unknown) number of users out there LocalStorage in their browser will be the only place they have this key saved, and in 7 days may now become irreversibly locked out of their 1Password vaults.

Previously:

Half of me knows I’ll rarely use and never prefer a PWA on iOS over a native app, so I know that none of this really matters nor will affect me.

The other half of me wants everyone to adhere to the platonic ideal of the web and thinks Apple should stop doing this shit.

1Password:

When you set up the 1Password apps, your Secret Key will be saved in the apps. So if it gets removed from Safari, you’ll still be able to access your account. It’s an important first step, but there’s more you can do to protect your account.

I’ve seen a new bug since updating to Safari 13.1: specifying Finder tags when using File ‣ Save As in Web Archive format doesn’t actually add the tags to the file.

WebKit/Safari announcement to delete local storage after 7 days of non-use is a terrible thing since it doesn’t mention file:// origins nor UX overrides, particularly per-site settings. Apart from big, public issues like password managers, what about internal tools?

Deleting local storage after 7 days without any user control has the possibility to lose valuable user data. It also kills an entire class of applications. Users do actually want web apps that are able to store some data locally, under the user’s control.

Retina MacBook Air Staingate

Joe Rossignol (tweet):

Apple this week acknowledged that MacBook Air models with Retina displays can exhibit anti-reflective coating issues, as indicated in a memo shared with Apple Authorized Service Providers and obtained by MacRumors.

[…]

Apple’s internal service documentation for this issue previously only mentioned MacBook Pro and discontinued 12-inch MacBook models with Retina displays, but the MacBook Air is now mentioned in at least two places. Apple added a Retina display to the MacBook Air in October 2018 and all models of the notebook have featured once since.

This has been going on for even longer than the butterfly keyboards. So far the repair program is only for MacBook Pros.

Marcin Krzyzanowski:

Apple Care just

1. Rejected my claim for broken screen #staingage
2. Rejected my claim for broken keyboard (clean with air instead)
4. Rejected my battery claim

[…]

this is via Reseller (of course). When I was at Apple Store, they were ready to replace the screen, I just couldn’t wait a few days.

this is ridiculous. They advise me to go to the Apple Store instead. The nearest Apple Store is 580km away.

Previously:

Update (2020-03-27): John Gruber:

I don’t understand how this is still an issue. My beloved 2014 13-inch MacBook Pro is afflicted with this, and I never bothered getting it repaired. Whatever causes this, you’d think Apple would’ve identified the problem after a few years.

Zoom Attention Tracking and Facebook

Wolfgang (Hacker News):

ZOOM monitors the activity on your computer and collects data on the programs running and captures which window you have focus on.

If you manage the calls, you can monitor what programs users on the call are running as well.

EFF (Hacker News):

The host of a Zoom call has the capacity to monitor the activities of attendees while screen-sharing. This functionality is available in Zoom version 4.0 and higher. If attendees of a meeting do not have the Zoom video window in focus during a call where the host is screen-sharing, after 30 seconds the host can see indicators next to each participant’s name indicating that the Zoom window is not active.

[…]

Zoom allows administrators to see detailed views on how, when, and where users are using Zoom, with detailed dashboards in real-time of user activity. Zoom also provides a ranking system of users based on total number of meeting minutes. If a user records any calls via Zoom, administrators can access the contents of that recorded call, including video, audio, transcript, and chat files, as well as access to sharing, analytics, and cloud management privileges.

See also: Nick Heer.

discreditable:

When someone sends you a zoom invite, cancel the download, then click the having problems link to download again. Cancel it again. It will show you a link to join by browser.

Joseph Cox (tweet, Hacker News):

What the company and its privacy policy don’t make clear is that the iOS version of the Zoom app is sending some analytics data to Facebook, even if Zoom users don’t have a Facebook account, according to a Motherboard analysis of the app.

This sort of data transfer is not uncommon, especially for Facebook; plenty of apps use Facebook’s software development kits (SDK) as a means to implement features into their apps more easily, which also has the effect of sending information to Facebook. But Zoom users may not be aware it is happening, nor understand that when they use one product, they may be providing data to another service altogether.

Previously:

Update (2020-04-10): Joseph Cox:

On Friday video-conferencing software Zoom issued an update to its iOS app which stops it sending certain pieces of data to Facebook.

David Heinemeier Hansson:

Zoom has stopped the data leakage to Facebook. That’s good. But their privacy policy is still a complete trash fire that belittles privacy legislation, and grants themselves the right to do exactly what they were just caught doing.

Eric S. Yuan (Hacker News):

We originally implemented the “Login with Facebook” feature using the Facebook SDK for iOS (Software Development Kit) in order to provide our users with another convenient way to access our platform. However, we were made aware on Wednesday, March 25, 2020, that the Facebook SDK was collecting device information unnecessary for us to provide our services.

Will Strafach:

absolutely wild how companies are comfortable admitting that they have no clue what kinds of code they are including in their apps, and have to be “made aware” of what their own apps are doing.

John Gruber (tweet):

This Facebook data issue is nowhere near as bad as the web server issue. But it betrays Zoom’s institutionally cavalier attitude to privacy. Their privacy policy more or less grants them carte blanche to do whatever the hell they want.

Mistakes happen. Bugs happen. I not only forgive mistakes, I enjoy forgiving mistakes. But Zoom’s callous disregard for privacy does not seem to be a mistake. As Zoom itself said about the hidden web server they secretly installed on Macs, it’s a feature not a bug.

Joseph Cox:

On Monday a user of the popular video-conferencing software Zoom filed a class action lawsuit against the company for sending data to Facebook. The lawsuit argues that Zoom violated California's new data protection law by not obtaining proper consent from users about the transfer of the data.