Archive for July 15, 2021

Thursday, July 15, 2021

Xcodes.app

Robots & Pencils (via Christian Selig):

The easiest way to install and switch between multiple versions of Xcode.

[…]

  • List all available Xcode versions from Xcode Releases’ data or the Apple Developer website.
  • Install any Xcode version, fully automated from start to finish. Xcodes uses aria2, which uses up to 16 connections to download 3-5x faster than URLSession.
  • Just click a button to make a version active with xcode-select.
  • View release notes, OS compatibility, included SDKs and compilers from Xcode Releases.

Distributing Unnotarized Mac Apps in an RTFD File

Jeff Johnson (tweet):

Gatecrasher is an empty Mac app that I created in Xcode in a few minutes. It has no code other than the standard NSApplicationMain and the default MainMenu.xib file with the main menu and window. Gatecrasher isn’t signed with an Apple code signing certificate and isn’t notarized; it has only an “ad hoc” (codesign -s -) code signature with no identity. I compressed Gatecrasher into a zip file, but as you’ll see, that’s not what you’re downloading. Instead, I embedded the zipped app into a “rich text” document (.rtfd file) in TextEdit and then compressed it. That’s what you’re downloading. You can unzip the rtfd, double-click to open it in TextEdit, follow the simple instructions written inside, and you’ll end up with an app that you can double-click to launch — all without any macOS Gatekeeper alert, and all without any Developer ID or notarization.

[…]

You can distribute an unsigned, unnotarized .pkg file inside an .rtfd file, and when you double-click the package (after saving to remove the quarantine), TextEdit will run the macOS installer.

[…]

I’ve been told that double-clicking an embedded .zip file doesn’t work right if a third-party app such as The Unarchiver is the default handler for archives on your Mac rather than the built-in Archive Utility. However, after removing the quarantine on the .zip, you can still drag it out of TextEdit and drop it into Finder, and then unarchive it to bypass Gatekeeper.

This relies on his previously reported issue where saving a document in TextEdit removes the quarantine attribute. (Apple did not consider this a security issue and thus wouldn’t pay the bounty.)

Previously:

Leaking Files With TextEdit

Paulos Yibelo (tweet, Hacker News):

I quickly realized that TextEdit can be tricked into thinking the file opened is an RTF-HTML file even when the file extension is TXT. The ability to inject HTML into a TXT file obviously opened lots of potential attack vectors.

[…]

I found out the CSS property <style> @import { "url "} </style> was allowed to load local CSS files. However, the only scheme that worked was file:/// and not even http/s://. While this means we can’t make external requests, it also means we can hit or open other files that are stored locally on the device. This creates a very obvious DOS vulnerability that acts like a blind SSRF by writing a recursive file inclusion or, reading files with infinite data streams like /dev/urandom, /dev/zero. a 2kb text file can crash your mac. COOL, but completely useless.

[…]

While they did a good job blocking TextEdit from making external requests, [AutoFS] was the one thing they forgot when they allowed file:/// scheme, on OSX file:///net/11.22.33.44/a.css connects to 11.22.33.44.

[…]

By combining the <style> CSS attribute with the <iframedoc> attribute, an attacker can first include an unclosed style tag, embed the contents of the file they want to steal and then leak the content as dangling parameters to their evil site as soon as the file is open.

This was addressed in macOS 10.15.1.

Previously:

Safari 15 Changes in Beta 3

Juli Clover (tweet, Hacker News):

In the third developer beta of macOS Monterey, which came out this morning, Apple has overhauled the design of Safari, making the tab bar more similar to the current tab bar in macOS Big Sur.

[…]

The new and separate tab bar is enabled by default when upgrading to macOS Monterey beta three, but Apple has included an option to revert to the original Monterey design. If you to go View and toggle off "Show Separate Tab Bar," you can use the original design.

Dieter Bohn:

I’m sorry these tabs are STILL terrible. Why are they floating buttons? Which one is active?

Jeff Johnson:

It looks like there are 3 address bars.

Francisco Tolmasky:

You know, like, I dunno, make the buttons still look like textfields since they used to literally be the URL field, but now just won’t make any sense at all.

Dan Masers:

This still looks like a usability nightmare – I had to check the address bar to figure out which tab was selected. Not to mention, it is aesthetically atrocious.

Sean Heber Heber:

I’m excited to see that Apple is changing the Safari tab situation so much during beta, but at least for macOS, the screenshots I’ve seen still look pretty wrong. There’s no clear hierarchy there and the tab buttons are disconnected from the content. This shouldn’t be so hard.

The hierarchy is wrong. The tabs should be on the top (like b2), but not so close you can’t grab the window and safely move it. The address bar should be inside the space of the active tab and visually connected together. Only the active tab/address bar should be tinted.

Steve Troughton-Smith:

IMO, browser tabs should be attached to their content; it is already excruciating trying to teach tabs to non-technical people, and floating roundrects in a toolbar just makes it worse.

beezischillin:

I might be alone with this but I really dislike Apple increasing the overall height / element margins on the top controls of Safari. They’ve been consistently doing it bit by bit with each new release and it constantly feels like I’m losing screen estate that could be filled with content to bits that are not and that I rarely interact with enough to justify it taking up so much space. I really liked the slim header part of Safari previously, especially switching from Windows and its set of browser design conventions.

• • •

Juli Clover:

Apple today released the third betas of iOS 15 and iPadOS 15, and the company is continuing to refine the suite of new features that are coming in the update. There have been multiple complaints about Safari on iOS, so in the third beta, Apple has introduced some refinements.

Federico Viticci:

In beta 3, the address bar is now docked above the keyboard. There is a new search UI and support for quick website searches too. Getting better!

Peter Steinberger:

The new Safari input method is better; this animation from bottom to top on edit was so attention-grabbing. But ugh look at the clear button clipping! And the animation is a total hack.

Federico Viticci:

Oh my, what happened to Safari in iPadOS 15 beta 3? 😬

Tabs flying around more than before, distracting animations, new tabs now open on the right, but new links don’t every time.

[…]

Having used Safari for iPadOS 15 beta 3 some more, I don’t think any of it makes sense right now. I’d be shocked if it doesn’t revert to previous design like Monterey did.

Marco Arment:

A simple answer to make iOS 15’s Safari more usable and readable, without messing up web content, and keeping the controls on the bottom like in beta 3:

A toolbar.

A standard iOS toolbar.

Fixed in size and place.

No modes.

No content behind or around it.

We have the space.

Adam Bell:

Safari in iOS 15 has this wild new swipe gesture for opening a new tab

Previously:

Update (2021-07-26): Jeff Kirvin (tweet):

As far as the tab crowding in the first iPad screenshot, that’s why if you’ll notice in the other two, I’ve got the tabs split out into a tab group called “Safari.” This, again, is the reason that tab groups and this new UI came out at the same time. They’re designed to be used together to prevent having too many address bars on screen at once by subdividing your pages by subject or some other logical grouping.

This is why I’m depressed that Apple backed off of this on the Mac and from what Gruber was saying, will be backing off on the iPad as well. The new beta 3 interface on the Mac doesn’t make any sense because it has the address bar of the site you’re using on a different line from the address bars of other sites you have open. It breaks the UI logic. The first thing I did when I installed the new Monterey beta was turn that off and revert it all to one line. It’s not so much that I need the vertical space, but I think the new design makes more sense.

Via John Gruber:

There’s a general sense of “everyone dislikes the new Safari designs” and I know that’s not true, even though public sentiment is strongly against them. So even though I don’t find Kirvin’s arguments compelling, I thought it was worth linking to them, because I do think he explains what the designers of the new Safari UIs were shooting for.

That this is the best defense I’ve seen of the Safari 15 redesign makes me more convinced that it was a mistake.

Peter Maurer:

The new tab bar was supposed to save vertical space. But now that the tab bar is separate from the location bar again, the new look actually uses more vertical space. Worst of both worlds!

Federico Viticci:

Just another day being unable to order takeout because iOS 15 Safari’s bottom bar makes this checkout button untappable.

John Gruber:

The arrogance of this design is really something when you consider that all the sites that it breaks are sites that were designed for the way Mobile Safari previously defined the mobile web.

Abner Li:

Chrome for Android tried a similar Safari on iOS 15 redesign years ago, and a designer on that project provided some interesting insight into why Google abandoned it.

See also: The Talk Show.

Copyright © 2000–2024 Michael Tsai.