Nice work! May I inquire as to the design decision behind storing a hash of the long token server-side for verification of the long token, versus digitally signing the short token plus a nonce and including this signature in the API key (instead of a long token), as some other API key schemes do?

Both are valid approaches of course, I'm just interested to hear your thoughts on the relative tradeoffs.

The signature approach is interesting because it couples the short token the api key, so they're a pair rather than totally independent. Introducing a signature changes the math to create the shortest possible API key with at least 128 bits of entropy (that are not stored server-side). But it's worth looking into!

Looks like this has already been created, back in March?

Here's their charter: https://github.com/WebView-CG/charter/blob/main/charter.md

This reminds me, back when I used to do app security, one of the issues with webviews was that some apps would hide much of the UI that users are used to seeing in browsers to make security decisions. So if an attacker could, via some vulnerability, redirect the site being viewed in the webview to one of their choosing, the user wouldn't be any the wiser.

I think it would generally be better if webviews, by default, have restricted navigation, and the developer has to deliberately whitelist domains they wish to view in it. Rather than having to write a navigation delegate or similar to implement their own whitelist, which most developers won't bother with.

The VPN software we used was configured one day to start presenting web view for oauth sign-in with no announcements this would change. The view had no navigation bar. Could not right click and get properties. No way to verify that what was loaded was secure or valid. Whether any of that could be trusted is additional question, but yes, some presentations of web views are terrible.

> No way to verify that what was loaded was secure or valid.

Signed software from your VPN provider isn't enough?

What type of attack, theoretical or otherwise, are you avoiding?

An Oauth request loads an external website. A Network-Level attacker anywhere on the path might try to send the request elsewhere.

This seems a tad hyperbolic. And the comparison between encryption and abortion is really weak - the differences are much greater than the parallels.

Especially when the author then goes on a tirade about law enforcement. Encryption helps conceal evidence of crimes, which is why many of those who enforce the laws seek to curb it, but abortion is controversial because those who oppose it believe that it's essentially a type of murder. It's not really comparable to just hiding one's tracks. I don't see how the two are intrinsically linked, like the author seems to be arguing they are.

I agree with the legal right both to encryption (albeit with penalties for refusing to decrypt specific data that could plausibly be considered evidence of a crime) and abortion (where the foetus is sufficiently undeveloped, or where necessary for medical reasons), but this article is just too much over the top.

I think the link is much more general. Take any act that today isn't a crime, for instance drinking alcohol, and at some point the government could decide it is against the law.

When thinking about this, try to pick an act you enjoy. For instance, practicing as a software engineer with out a license? I know it isn't a thing today, but as more software mistakes are blamed for more deaths it could happen.

Her argument is that having strong rights to encryption will enable us to continue to do these acts, write software w/o license, drink alcohol, have abortions, and be Jewish (see WWII), once they're no longer allowed.

She then argued that we should stop treating the US government as the good guys (by default) in conversations about encryption.

Encryption rights becomes another front in the war over any of these other rights.