Tldr:
To balance AOSP’s open nature with its product development strategy, Google maintains two primary Android branches: the public AOSP branch and its internal development branch. The AOSP branch is accessible to anyone, while Google’s internal branch is restricted to companies with a Google Mobile Services (GMS)licensing agreement.
Beginning next week, all Android development will occur within Google’s internal branches, and the source code for changes will only be released when Google publishes a new branch containing those changes. As this is already the practice for most Android component changes, Google is simply consolidating its development efforts into a single branch.
Thanks for the detailed write up!
There is Go Map!! as an alternative on iOS. Have been using it, not as gamified but works well!
They just used the self reported labels on Apple‘s Appstore for this “study”, who knows what a company “forgot” to put in there.
Ah sry, i just read through the bug report to get a grasp of the timeline.
It has been fixed for a while for new installs, bit I agree, there should have been some kind of notification, that manual intervention is required. It was even mentioned in the bug report, so I don’t know why the dev neglected to implement the notification
The second factor is the app on your phone. It‘s not Totp. When you log in somewhere or make a transaction it will send a notification to the app asking you to confirm.
When you open the bank account you get a letter with a code to register in the app, which authorizes it to receive the notification.
I don‘t know where you are from, but the EU requires banks to use 2FA for login even via a browser. This is commonly implemented via a banking app, where you grant permissions for login/payments. So it is a huge dealbraker when those apps are not working on GrapheneOs
And before anyone goes blaming the EU as it‘s fashionable right now: mandatory 2FA for banks is a good idea, this is entirely Googles and the banks fault.
Like others have mentioned, change your provider. Prices are going down again, as there have been advancements on installing renewables. Energy prices at the end of 2024 were 30,5% cheaper than at the start of 2023 (Source. This is the case even though we are paying more for the modernization of the grid, because renewables are that much cheaper than other sources.
It‘s coming along in Thunderbird, they continuously mention it in their monthly development blog.
Exchange Web Services support in Rust
November saw an increase in the number of team members contributing to the project and to the number of features shipped! Users on our Daily release channel can help to test newly-released features such as copy and move messages from EWS to another protocol, marking a message as read/unread, and local storage functionality. Keep track of feature delivery here.
If you aren’t already using Daily or Beta, please consider downloading to get early access to new features and fixes, and to help us uncover issues early.
On iOS you can enable Guided Access and restrict what one can do, for example disable touch and lock it to an app, until you enter a Code. I imagine Android will have something similar.
This obviously doesn’t protect against electronic forensics, but it does protect against just opening different apps and searching through the phone manually.
Update: A license was added
This is an important issue IMO that needs to be addressed and the official response by Bitwardens CTO fails to do so.
There is not even a reason provided why such a proprietary license is deemed necessary for the SDK. Furthermore this wasn’t proactively communicated but noticed by users. The locking of the Github Issue indicates that discussion isn’t desired and further communication is not to be expected.
It is a step in the wrong direction after having accepted Venture Capital funding, which already put Bitwardens opensource future in doubt for many users.
This is another step in the wrong direction for a company that proudly uses the opensource slogan.
The problem with passkeys is that they’re essentially a halfway house to a password manager, but tied to a specific platform in ways that aren’t obvious to a user at all, and liable to easily leave them unable to access of their accounts.
Agreed, in its current state I wouldn‘t teach someone less technically inclined to solely rely on passkeys saved by the default platform if you plan on using different devices, it just leads to trouble.
If you’re going to teach someone how to deal with all of this, and all the potential pitfalls that might lock them out of your service, you almost might as well teach them how to use a cross-platform password manager
Using a password manager is still the solution. Pick one where your passkeys can be safed and most of the authors problems are solved.
The only thing that remains is how to log in if you are not on a device you own (and don’t have the password manager). The author mentions it: the QR code approach for cross device sign in. I don’t think it’s cumbersome, i think it’s actually a great and foolproof way to sign in. I have yet to find a website which implements it though (Edit: Might be my specific setup‘s fault).
Thanks for the link! Learned something new today.
The author of your blog post comes to this conclusion:
So do yourself a favour. Get something like bitwarden or if you like self hosting get vaultwarden. Let it generate your passwords and manage them. If you really want passkeys, put them in a password manager you control. But don’t use a platform controlled passkey store, and be very careful with security keys.
The protocol (CXP) which the article is about, would allow you to export the passkeys from the “platform controlled passkey store” and import them into e.g. Bitwarden. So i would imagine the author being in favor of the protocol.
The lock-in effect of passkeys is something that this protocol aims to solve though. The “only managed by your device” is what keeps us locked in, if there is no solution to export and import it on another device.
The protocol aims to make it easy to import and export passkeys so you can switch to a different provider. This way you won’t be stuck if you create passkeys e.g. on an Apple device and want to switch to e.g. Bitwarden or an offline password manager like KeyPassXC
The specifications are significant for a few reasons. CXP was created for passkeys and is meant to address a longstanding criticism that passkeys could contribute to user lock-in by making it prohibitively difficult for people to move between operating system vendors and types of devices. […] CXP aims to standardize the technical process for securely transferring them between platforms so users are free […].
I had the same idea a while back and was wondering why no one has implemented something like this yet. This seems like an actual useful application for LLMs.
I am using Zotero (Citation Management Software) to collect scientific Articles I have read. Sometimes I forget in which Article I read about something specific. A search, where you could describe what you are looking for in a sentence, which then returns the Article with the relevant part, would be a gamechanger.
Seems like people in the comments are misunderstaning the announcement entirely. This protocol is about import and export from password managers and not about having them synced between devices. It would prevent a lock in effect. This is a great development!
FIDO Alliance’s draft specifications – Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) – define a standard format for transferring credentials in a credential manager including passwords, passkeys and more to another provider in a manner that ensures transfer are not made in the clear and are secure by default.
So much needless negativity. Not all features need to be for you.
I would welcome a local model with good integration, I have use for it.