netrox

When there are bugs, most of the time, it is the website causing the bug, not the manager. The website HTML should have clear semantics to provide the login credentials. Some HTML code are confusing password managers due to improper HTML structure or the paranoia of IT techs that think somehow the password manager is a bad thing so they put code that block password managers or autofills. It's a huge no no. I always send feedback to those websites and warn them that it's a security risk as it only motivates users to create easy passwords when they're denied the ability to automatically generate hard to guess passwords. 




  

I used Grammarly but cancelled it after it took way too much RAM in Safari. 

I don't use 1Password, I always used the system manager and I am glad the update will provide a standalone app instead of being nested in System Settings. 

I am disappointed that Journal is not coming to MacOS. I would do that. I don't want to deal with that on a mobile. 

zoetmb said:

 

In fact, the entire password/keychain system seems screwed up to me. I have multiple entries for the same sites when there should be only one - the one with the latest password.   I hope the new password system is more than a rename and new skin. 

It's really the website's problem. I am so fed up with websites being so inept with implementing the correct login credentials. The credentials should provide clear information to password managers (in HTML) or stay in its domain rather than redirecting back and forth in URL confusing password managers. There's no excuse. 

ravnorodom said:

All these gadgets sounds good on paper but in real life usage, they are more suitable for people with disabliities.

I agree with this one. I think it's a great tool for people with disabilities as they can automatically summarize and rephrase or do real time captioning. People with learning disabilities can benefit from using them as AI can help rephrase to help them understand better. 
 

That is great news.

Thread is a protocol and we need that to help with improved networking resilience.

Thread requires a low power radio and it needs Matter to automatically adjust networks that are required for users. It is designed for little data to be transmitted and should not be used for mice, keyboard, or anything like that (that's where Bluetooth comes in) but to transmit for devices to ack and send their statuses. It's ideal for home automation and computing networks than data transmission which is where Thread/Matter will notify those devices to use when handshaking for high speed communication.

For example, if home security video is being transmitted, it will never happen in Thread but in WiFi. What would happen is that the Thread enabled device provide Matter the status and the Matter then sends the Thread device (home security camera) with WiFi information which is necessary for high data bandwidth communication and the camera then kicks in WiFi connection and sends video. WiFi itself consumes a lot of power and that's why you don't see many battery-operated WiFi devices.

Thread devices work much better as battery operated and often works as router if it requires constant power (like plugin or complex device requiring high processing resources).

The more thread devices we have, the more robust the network will be.

However, I am not sure if any of those Thread will be "routers" - Apple TV and HomePod are the only ones with the routers.