search

WICG / local-font-access

Web API for enumerating fonts on the local system
https://wicg.github.io/local-font-access
Apache License 2.0
75 stars 16 forks source link

API should be compatible with iOS font privacy model #62

Open my2iu opened 3 years ago

my2iu commented 3 years ago

This is a continuation of issue #60 . It was closed with a request for more information and told to reopen the issue, but I can't figure out how to reopen that issue, so I'll just create a new one.

Anyway, the information about the iOS font privacy model is described in this video https://developer.apple.com/videos/play/wwdc2019/227/

Unlike your font privacy model, iOS doesn't allow applications to enumerate the list of fonts. Applications can show a font picker, allowing the user to authorize a single font be made available to an app, or applications can present a list of fonts to the system, and the system will check which ones are installed and ask the user to make them available to the application. It looks like your font privacy model is just a switch that makes all fonts available to an application or not. This will likely never be implemented in Safari on iOS because then apps could bypass the iOS font security model by simply embedding a WebView in their app and grabbing the font list from the browser.

So my general concerns with the proposed standard (I haven't looked at it in a couple of months, so I apologize if the standard has changed) are

  1. you may be pursuing a font security model that differs from and is incompatible with the direction that other major systems are going with, which is fine but it should be acknowledged
  2. the fact that your design docs don't mention this other security model suggests a general lack of due diligence
  3. the API you propose is looser than the iOS model, but you could design your API to offer a more restrictive subset that would be compatible with the iOS model. That way, developers could code to the more restrictive subset if they want something compatible with iOS
  4. Web developers won't use an API unless it's available on iOS too. Making your API more compatible with iOS will make it more likely that Apple will implement it in Safari.
oyiptong commented 3 years ago

Thanks for this information.

We are working on a more restricted mode that hasn't surfaced in the explainer or specs. You can try it out by enabling both #font-access-chooser and #font-access in chrome://flags

Right now, the chooser is exposed separately from the enumeration API. We are working on potentially unifying the two interfaces.

If you've got the time, please take a look. I think that will be compatible the iOS font privacy model.

oyiptong commented 3 years ago

This would be a good site to use as a demo: https://oyiptong.github.io/opentype.js/glyph-inspector-picker.html

inexorabletash commented 3 years ago

The API has shifted to being a query() model, which can include hints about what fonts to include, e.g. {select: ['Menlo-Regular', 'HiraMinProN-W3']}

The UA is free to present any UI to the user - including a picker that allows selecting a single font, multiple fonts, or all fonts.

One challenge with this approach is that the web app won't know whether the returned font(s) represent all fonts available on the system (and thus the user should not be prompted again) or a subset (and thus re-prompting the user makes sense). In the iOS model, the app can be designed with a single UX in mind, but this precludes some use cases e.g. where app wants to present its own font selection experience with local fonts.