Can the title be altered to contain the truth? (That this is a hypothetical scenario, and no data has been stolen.) The article is a bait and switch but that doesn't mean HN should do the same. Changing "stole" to "could steal" would work.
I think that these days it is safe to assume that one could always be locked out of their google account for whatever reason. It is best practice to simply create a local account with whatever app/service that one wants to use.
I personally use an email with a custom domain which I pay for so I am relatively secure of keeping access to my email address. Moreover, I use a local password manager to store all my passwords. This setup is a bit of a pain but it is also liberating as I am not at the mercy of any third party when I am transacting with a service.
Clickbait is about links to subpar/worthless content.
This is just a teasing/enticing title to well researched and detailed content.
Wikipedia re: clickbait:
"something designed to make readers want to click on a hyperlink, especially when the link leads to content of dubious value or interest" (...) "A more commonly used definition is a headline that intentionally over-promises and under-delivers."
Blog writers don't owe HN readers anything specific, nor are they beholden to them to give them the titles/content they like. Besides clickbait there is such a thing as wanting a nice title to grab the readers attention as opposed to some description that gives away your whole ruse inside the article (which is the point here).
>Even the readers of HN do not owe the blog writers anything, nor are they beholden to them to give them the votes/comments they like.
The difference being authors and posts can exist without caring about HN, but HN can't exist without content to link to. So I'd say the reverse is not true, except to individual authors. Authors dont owe HN anything, but HN does owe authors that make it to the frongpage something.
On the matter of clickbait, let's agree to disagree.
To me it's only "bait" if the result is the fish being hooked, taken out of the sea, killed and/or eaten - or, in this case, a person served BS and ads in exchange for their link clicking attention.
If the fisherman just tries to grab the fishes attention to feed it instead, and the fish even likes the food, it wouldn't be clickbait, or it wouldn't have the negative form. And same if a post author wants to use an attractive title (it's not as if all titles should be utilitarian description by decree).
Now, some decide to downvote a (IMO) good post, on the grounds they didn't like the title. I find that shallow. And I'm with the post authors on their right to give whatever title the want (but I don't agree with the readers right to complain about it when the content is good).
It's HN policy to not keep misleading titles. "Otherwise please use the original title, unless it is misleading or linkbait" [1]. Flagging things that do not meet it would seem reasonable to me.
I believe this flaw was closed last year. Google no longer allows web auth inside app-controlled browsers. If an app can inject JS, Google won't let you log in from it on mobile.
It led to outcry from people who have custom compiled browser builds that were also caught up in the restrictions.
I was wondering why Google did this. Still seems disturbing that the master token is something that once acquired is still useful even after hours of use. Even if they did plug the web auth hole via app-controlled browsers.
I'm surprised a limited time + per app + per user code isn't used, where limited time is enough to be useful for app purposes but not worth storing for long enough to be swept up in some data grab.
Time limited tokens don't lend a lot of security. Someone malicious can simply scrape your entire account in the 15 minutes or whatever the validity period is.
Scope limited is far better, and something android is bad at. I suspect they are highly constrained by the need to maintain compatibility all the way back to Android 1.0.
In my opinion, they should drop support for old android versions by default, and if you want the ability to sign into an old non-updated device, force you to go to a real browser and enable some option like "allow insecure devices".
Author here, the exact same thing that I did is possible for any 3rd party SSO on mobile apps. It's not a Google exploit, it's an exploit in the idea of SSO.
I'm always suspicious when I click "Sign in with X" and it prompts me to enter details. Normally I would already by logged in. But not always, for instance I mostly use Firefox on my phone, and those sessions aren't shared with webviews. So one can never know.
There's really nothing stopping anyone from making an entirely fake "Sign in with X" popup and people would believe it (me included), I think teaching people to give away their Google, FB, GH etc credentials on random pages is scary.
The problem is that, its not very easy to have 10s ( or 100+) usernames and passwords in memory ( or manage them on a password manager), track if any of them are leaked etc.
From usability perspective this is better. The question is trust and security.
Can you expand on this? Having been a user of multiple password managers over the years (LastPass previously, BitWarden currently) and this is exactly why I use a password manager. I have at current count, 253 different logins/passwords all with different passwords (none of which I know) saved and accessing them is automatic in my browser and a quick search (on first time use) on Android. After that it's automatic.
My use case is not normal. I keep using different computers, sometimes I work on a newly installed OS on raspberry pi etc. I did not find a secure web based password manager the last time I checked.( I am also a little scared of storing passwords encrypted on the cloud). I am not sure if things like yubikey are better for these use cases.
I agree that keeping different usernames and passwords in your memory is not easy, but to my mind this is exactly the sue case for my password manager. I don’t need to sign in with Google because it’s just a couple of clicks to generate a username and a password I never need to remember because my password manager does that for me.
I used to use sign in with Facebook/Google like the careless pleb I was until I discovered how privacy-invasive these corps are. Am never signing in to any casual site without a proton mail coupled with Bitwarden password manager now.
The problem is I can't trust Google not to send me ads (sometimes just right in my email) related to the services am signed in to.
I sleep much better these days with the above remedy.
I stopped using OAuth "Sign in with..." because I kept of forgetting which provider I used for which website, and started recording it in my password manager. Realising how silly this was I went back to my password manager with website specific usernames and passwords.
Exact same issue here, i love the idea of it but until there is a universal OAuth I will stop using it. I’ve also not deleted Facebook despite mostly wanting to because I know it’s my OAuth for many services and some make it very hard to change.
Not sure what you mean? A good password manager (like 1Password or the thing that comes with Apple) makes it easy to keep hundreds of usernames and passwords. They will track if you are using leaked credentials, as well.
Apart from $work, I've always opted for username, password, and 2nd factor over federated authentication. A password manager makes this very easy.
There are of course tools for that, password managers are ubiquitous in digital teams. But I also just loathe having so many accounts.
Even desktop software requires accounts these days. I tried to get started on a Unity project again and I spent an hour managing accounts for all the related software instead. Half my day is logging in and out of stuff.
Without something like u2f on the originating service, I could see this attack. Never thought about it, eeek.
Let's say you were Google and to "help" people, you were going to "login on their behalf" to "index and organize" their info. No need to obtain consent, just fake a login and scrape away.
The rest of us can replace with quoted words with 'exploit', 'hack', and 'sell their personal info on the market to the highest bidder' but when Google does it, its ok.
They only require it if you already support other third-party authentication methods in the app. If you exclusively use your own authentication it is not required.
Sign in with Apple is pretty good and it doesn't ask you for a password, and you confirm with the power button/faceid if I'm not mistaken. It's very hard to spoof.
> As many of you may have suspected, this post is not entirely truthful. I have not released this fitness app onto the Play Store, nor have I collected millions of master tokens. Thanks to this post for inspiration. But yes, these methods do work. I absolutely could release such an app, and so could anyone else (and maybe they have).
I wouldn't either, since people aren't expected to enter the discussion based on a cursory reading of just the headline. At least not when they think they discuss the article (of which they only know the headline) -- it's still OK if they jump in to discuss other comments.
