I think most people would use the publisher’s website first and then resort to scihub, because scihub requires a doi or publisher’s link to get the paper.

I don’t think this causes much concern, even if so, I believe a good amount of blame should still fall on the publishers and academic systems that encourages gatekeeping knowledge. Especially when these knowledges are generated by public money, then the public should rightfully have access to them.

Yes, from the announcement, it seems true.

I feel one of the hardship for Linux to catch on is the lack of commercial interest to make it usable for consumers.

If this problem happened on Windows and macOS, MS and Apple would just send an engineer to spend a week or a day to have it fixed. This change has been in electron for months, and no one bother to fix it.

Same with bugs in chrome and libsecrate, which have been open for 4 freaking years… https://gitlab.gnome.org/GNOME/libsecret/-/issues/49

It also took chrome half a decade to support text-input-v3: https://issues.chromium.org/issues/40113488#comment1, which is added by a third party developer. And it still breaks KDE’s implementate https://bugs.kde.org/show_bug.cgi?id=492225 …

It is understandable people are frustrated, I am frustrated, and joined several conversation regarding this problem. However, I don’t appreciate some of the rant from many users. This change is certainly out-of-touch, potentially due to them don’t quite foresee the amount of flatpak/kde users who are affected by this change.

But many complaints have been dangerously close to the line, if not over the line. Their quiet month policy is reasonable IMO, developers need breaks, especially those interacts frequently with the community. Love or hate electron (same apply to CEF), these works clearly bring many wonderful apps into the linux world.

I personally don’t believe that non-contributors have the right to demand free work from the electron developers.

You are right. I have done some research, it seems most people think that client side hashing is unnecessary in an HTTPS setting.

That is my misunderstanding.

it says it is encrypted but it is encrypred using keys that google has access to as they are unlocked with you logging in into google account.

First it uses lock screen password, so google do not have access to this password.

Even if your lock screen is unfortunately your Google password, I think proper authentication protocol do not send your password to Google to authenticate, but only the hash, which cannot be reverted to derive your password.

Obviously, the above is assuming that Google is not malicious. Otherwise it can just use play service, which is privileged and closed source, to get all your data. If your threat model including Google itself trying to steal your key, you will probably need to install a trusted rom or use iOS (however, apple and the rom developer can also steal your key).

I think these are different. They mostly find vulnerability in the iOS system as opposed to try to crack the backup system.

I think iOS or Android backup system are rather secure compared to other components because of the following: hacker will also need to break into a cloud drive to retrieve them, which adds extra work; the backup is simple, just bunch of files and a password, apple/google can use standard well-tested encryption to encrypt them.

However, guaranteeing there is no way to break into an operating system, especially with all the features that a modern system requires, is much harder.