Some comments on the new features:
I really dislike an authentication flow which mandates a call out to a browser. It makes command line applications basically impossible. It makes consistent UIs for specific platforms very hard (e.g. iPhone), as you basically have to dump the user into a web browser with an entirely different UI. It also adds very little practical security. The idea is that the user is conditioned to only enter their authentication details into the StackExchange UI, but there's nothing stopping malicious applications chroming a fake login page, presenting that, then proxying the entered data onto the "real" OAuth endpoint (or, having cached the illegal data, just telling the user that it was the wrong password, and redirecting them to the real site).
If I can't turn the tide on this, and I doubt I can, I would like to lobby heavily for an alternative authentication flow, with normal "POST user/pass to secure endpoint, get token" XAuth style process. This flow might be restricted to trusted applications of some form, as is provided by Facebook for certain partners. Failing that, the ability to various parameters to the authentication system stylesheet would be useful - enough so that we can make the transition less jarring for people.
The expiry of access tokens after 24 hours is also a huge pain. Imagine your smartphone Twitter client if it had to prompt you to login every day - it would be unusable. It also eliminates e.g. push notification systems that check your inbox on your behalf, and send messages to your phone. This is probably enough of a problem that it would make most of my use cases unusable.
I like this, if either:
- Filters created programatically exist forever. Or, more pragmatically, application owners can create filters that are associated with their application tokens via some web UI, and these exist forever.
- Enough useful pre-defined filter tokens are created.
What concerns me is the complexity of having to bake in a filter existence check, and filter creation process to every single request. This would be a big pain in the otherwise natural workflow of "Send request. Get response or error", which would mutate into "Send request; Did filter work? Create filter. Resend request. Get response or error". It also adds the certainty that many copies of the same filter are created - every client app instance will end up having to create its own copy, which might make optimisations on the server side harder. If filters were created on a web interface, and a token given that lasts forever, it would make it trivial for you to associate that ID with a query strategy optimised for it (should that become needed).
Edit: Based on comment answers about filter longevity, perhaps there could be an easy route we could call to check a filter's validity? Then the "Startup, check filter, recreate" setup might be practical with a "Bomb out if filter happens to die in mid workflow" handler case.