Archive for September 23, 2019

Monday, September 23, 2019

Sending E-mail for Sign in With Apple

Manton Reece:

Apple’s private email relay server is almost completely undocumented. In this blog post I’ll describe how I got it working.

The key issue is that the “return path” of your emails must be using a subdomain that can be verified by Apple. This blog post from SendGrid describes the solution in detail.

[…]

Upload the apple-developer-domain-association.txt file from Apple to the new subdomain web site. Wait a few extra minutes to make sure the DNS has changed before clicking Verify at Apple.

Previously:

Update (2019-09-25): Curtis Herbert:

For Slopes this is sitting at 75% of users opting to use the email relay.

Intelligent Tracking Prevention 2.3

John Wilander:

By limiting the ability to use any script-writeable storage for cross-site tracking purposes, ITP 2.3 makes sure that third-party scripts cannot leverage the storage powers they have gained over all these websites.

[…]

Our research has found that trackers, instead of decorating the link of the destination page, decorate their own referrer URL and read the tracking ID through document.referrer on the destination page.

ITP 2.3 counteracts this by downgrading document.referrer to the referrer’s eTLD+1 if the referrer has link decoration and the user was navigated from a classified domain. Say the user is navigated from social.example to website.example and the referrer is https://sub.social.example/some/path/?clickID=0123456789. When social.example’s script on website.example reads document.referrer to retrieve and store the click ID, ITP will make sure only https://social.example is returned.

[…]

Safari on macOS Catalina now has ITP Debug Mode.

[…]

Our blog post on ITP 2.1 provided guidance on how to protect cookies. We specifically encourage the use of Secure and HttpOnly cookies.

Previously:

Swift 5.1 Released

Ted Kremenek:

Swift 5.1 builds on the strengths of Swift 5 by extending the stable features of the language to compile time with the introduction of module stability. With module stability it’s now possible to create and share binary frameworks that will work with future releases of Swift. Swift 5.1 also extends the capabilities of the language and the standard library with new features such as property wrappers, opaque result types, key path member lookup, diffing for appropriate collection types, and new APIs for String. Altogether the new features of Swift 5.1 make it easier to design better APIs and reduce the amount of common boilerplate code.

John Sundell:

While that’s still possible, the scope of Self has now been extended to also include concrete types — like enums, structs and classes — enabling us to use Self as a sort of alias referring to a method or property’s enclosing type, like this[…]

Note that this is just syntactic sugar. It’s not like instancetype in Objective-C.

Previously:

Update (2019-09-24): As Joe Groff notes, I misinterpreted Sundell’s comments about Self. It doesn’t refer to the lexically enclosing type, but rather to the dynamic type. So, when used in an expression, it’s like type(of: self):

class Base {
    class func printClass() {
        print("Base")
    }
    
    func selfPrintClass() {
        Self.printClass()
    }
}
class Derived: Base {
    override class func printClass() {
        print("Derived")
    }
}
Derived().selfPrintClass() // prints Derived

This will be useful when calling helper functions from initializers.

His comment that it’s “purely syntactic sugar” only applies to this use of Self. When used to specify the return type, Self is not a mere substitution of the current class name. Instead, it refers to the type of the object (not the type that the method was defined on). So it’s just like instanceof in Objective-C. And you can similarly use it to declare factory methods, in which case Swift will require you to implement them in terms of required initializers:

class Base {
    required init() {} // must be provided unless Base is final

    class func make() -> Self {
        return Self.init()
    }
}
class Derived: Base {}
Base.make() // makes a Base
Derived.make() // makes a Derived

So, Self is really cool, and it can now be used in many more places than before. It’s still not allowed as a parameter type, though. I have a case where I want to ensure that a method has a parameter of the receiver’s own type. I wasn’t able to do this with Self, but I found a workaround using a protocol with an associated type.