Archive for June 3, 2020

Wednesday, June 3, 2020

Google Chrome Incognito Lawsuit

Tim Hardwick (also: Hacker News):

A proposed class action lawsuit in the U.S. has accused Google of violating federal wiretap laws by tracking the online activities of users when in Incognito mode.

According to Reuters, the class action argues that by surreptitiously collecting information about what people view online and where they browse when they use Chrome’s private browsing mode, Google has been intentionally deceiving customers into believing that they have control over the information they share with the company.

When you open a new incognito tab, Chrome tells you:

Now you can browse privately, and other people who use this device won’t see your activity.

[…]

Your activity might still be visible to:

  • Websites you visit
  • Your employer or school
  • Your internet service provider

Not deceptive at all.

Update (2021-03-14): Tim Hardwick:

A judge in California has ruled that Google must face a class action lawsuit alleging that it secretly tracks the online activity of Chrome users even when they’re using the browser in its privacy-oriented Incognito mode (via Bloomberg).

Claquette 2.0

Peakstep:

Adds support for importing and converting videos and GIFs

Adds support for iOS device recording

[…]

Adds cursor click and drag visualizations for screen recordings

Adds support for creating and managing export presets

Previously:

Unable to Enable Safari Extensions

Jeff Johnson (tweet):

In macOS 10.15.3, Apple introduced a bug that can prevent you from enabling or disabling Safari extensions. In order to enable or disable an extension, you must click the checkbox next to the extension in the Extensions pane of Safari Preferences. […] When the bug occurs, however, then clicking the checkbox does nothing: the checkbox doesn’t get checked, and the extension doesn’t get enabled either.

[…]

I believe that this Safari bug was introduced by Apple in a bungled attempt to prevent extensions from getting enabled via “synthetic clicks.” […] In theory it may be a good idea for Apple to prevent synthetic clicks in this case, but in practice the code that Apple shipped here was buggy and caused more harm than help. Safari incorrectly identifies real user clicks as fake synthetic clicks, preventing users from enabling their installed Safari extensions.

[…]

The other issue here is the lack of a visible error message for the user. I found a message buried among thousands of other unrelated messages in Console log, but no normal Safari user will ever see that. There ought to be a warning in the Safari Preferences window. Silent failure is a security failure. If an unauthorized process were in fact trying to secretly enable Safari extensions, shouldn’t the user be made aware of that immediately?

It still happens in macOS 10.15.5.

Rob Griffiths:

Here’s the bug I filed: Safari’s Extensions prefs panel behavior can confuse users

In 10.15, Apple prevents users from enabling Safari extensions if they’re running an app with a full-screen invisible window. But with zero feedback, it just looks broken.

Rudy Richter:

its a constant complaint by users of 1Password that they can’t click it

Previously:

Update (2020-07-29): Apple (via Jeff Johnson):

Learn what to do if you can’t select the checkbox to turn on a Safari extension.

Update (2020-09-28): Safari 14 adds a visible error message, but as chucker notes:

So that’s new, but not great… it can’t say what “app or service”?

(I tried again and it worked. …what?)

Previously:

Apple’s Linker & Deterministic Builds

Milen Dzhumerov:

  • Universal deterministic builds require that all paths in artifacts must be repo checkout independent.
  • On Apple platforms, the linker will insert absolute paths to object files in executables.
  • In Xcode 11, Apple added a new linker option, -oso_prefix, that can relativise OSO absolute paths.
  • Another source of non-determinism in object files are the OSO timestamp entries.

Copyright © 2000–2024 Michael Tsai.