CopperheadOS isn't in a position to do that. And breaking use cases or adding lots of friction is unacceptable.
-
-
Replying to @CopperheadOS @RichFelker
We're not designing the API for apps to use. Any changes need to be compatible with the existing app ecosystem.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
There's a reason iOS did it this way. It's not feasible to do anything else for existing apps, only new ones.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
And introducing a restriction only for a new API level just means that the malicious apps will use the old one.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
The solution is to make the old API freeze the app and pop up a modal confirmation each time it's used.
1 reply 0 retweets 0 likes -
Replying to @RichFelker @CopperheadOS
users should have the option in the confirmation to whitelist the app for trusted apps that are used frequently.
1 reply 0 retweets 0 likes -
Replying to @thearkadia_ @CopperheadOS
Yes, but the option to whitelist should be clearly labeled "allow app to read clipboard at any time".
1 reply 0 retweets 0 likes -
Replying to @RichFelker
API level change is the ideal way to deal with it, with a long wait before actually adding legacy annoyance.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @RichFelker
Need to be Google to take that approach though, or at least convince them to do that (which would be hard).
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS
My thought is just get KB apps implementing via-KB paste then switch the old clipboard to be always-empty.
1 reply 0 retweets 0 likes
The point being that normal applications don't have to use any new API. Only keyboard apps do.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.