Hacker Newsnew | past | comments | ask | show | jobs | submit | masswerk's commentslogin

Back in the day, it was useful, as in, "Expect awkward phrasing and unintended effects of autocorrection, because mobile device. This message doesn't necessarily reflect the intent of the sender." (Considerate users would/could edit the signature to something w/o a product name in it.) Nowadays, this is pretty much the norm and no explicit warning ist required anymore.

That just means the person sending the message didn’t bother to proof read their message before sending. And you don’t need to be on an iPhone to mistype a message.

A simpler explanation was that it was a shameful advert injected into the end of people’s emails.


I guess, it was probably intended as the second one (it was also the default email signature, so advertising that feature, as well), but its usefulness was definitely in the implied warning.

Mind that a written message used to be the gold standard for expressed intent, which changed quite radically with smartphones. (Historically, this development is probably an important prerequisite for the acceptability of LLM generated text, I guess.)


So an automatic "I am a lazy piece of shit and think my time and convenience are worth more than yours" warning? I guess that's useful.

I always felt like it was "I prioritized a speedy response on my phone instead of an elegant response from my computer at a later time".

As in, "I put it on you to better check and follow-up before acting on this…" ;-)

On the dark side, it will take quite a while to offset the environmental costs of this war, even if this provided an essential incentive for switching. (In reality, energy infrastructure is often locked in longterm and not easy to switch in just in a decade or so.)

I guess, this means logging out as the current user and logging in again, so that the various services are relaunched with changed settings.

> And education is much, much worse almost everywhere by leaning more to memorization

The idea that (correct) answers are something that can and may be known is all over the place, lately also in technology (LLMs, curve fitting, etc). Notably, answers must be able to validate themselves, every time. (Western) education used to be about this, before it reoriented towards instruction.


It's still impressing how the entire chrome can be collapsed into a single background bit of information, indicating a presence that may be attended to for interaction. In contrast, the newer interfaces seem to be made to reduce the attention span anyone may apply to the content. (It's really stress inducing.)


Mind that freedom of speech (US) and freedom of opinion (Europe) are different concepts. E.g., while you may harbour a certain opinion in the EU, expressing this in a way generally considered harmful (concept: speech may establish an act) may get you in trouble. On the other hand, crossing the US border may trigger an attempt to infer your opinion from extracted public or semi-public expressions, which may get you in even more serious trouble, you may be even considered a viable target based on such inferences (and there is no clear law for this, there isn't even due process.) Both concepts come with their own freedoms, implications and caveats.


The slogan of ape thinking (deliberately adjusted for machine readability): "Not AI, not machine generated slop <em-dash> genuine human intelligence."


> We recruited 8 participants across 8 different countries, deliberately seeking diversity in age, digital savviness, and cultural background.

> 5 out of 8 points versus just 3 for "I am human." For the verifying state, it was even more dramatic — 7.5 versus 0.5.

n × p >= 5? (Sample size and margins of errors. Is 5:3 even meaningful or is this rather random personal preference?) Apparent splitting of missing or inconclusive data points? (7.5 vs. 0.5 out of a total of 8 subjects.) What kind of (social) research is this supposed to be?


Thank you for your work, it's an invaluable resource!


For clarification, here's the actual quote from the article describing the process:

> I verified the issue with the minimum access necessary to confirm the scope - and stopped immediately after.

No notion of a script, "every password" out of a set of a single default password may be open to interpretation, no mention of data downloads (the wording suggests otherwise), no mention of actual number of accesses (the text suggest a low number, as in "minimum access necessary to confirm the scope").

Still, some data was accessed, but we don't know to what extent and what this actually was, based on the information provided in the article. There's a point to be made about the extent of any confirmation of what seems to be a sound theory at a given moment. But, in order to determine whether this is about a stalled number generator or rather a systematic, predictable scheme, there's probably no way around a minimal test. We may still have a discussion, if a security alert should include dimensions like this (scope of vulnerability), or should be confined to a superficial observation only.


True, but the article also says:

> That's it. No rate limiting. No account lockout.

To me, if he confirmed that there’s no rate limiting on the auth API, this implies a scripted approach checking at least tens (if not more) of accounts in rapid succession.


Granted. I guess, unless it's applied very aggressively, assessing the existence of rate limiting may require some sort of automation (and probably some heuristics – how much data points do you actually need? do you have to retrieve any data at all, while looking for a single signal? The article doesn't tell.) Same goes for lockout.

On the other hand, as mentioned already, all that's required is really looking for a return code and not for any data. Is accessing an API endpoint the same as retrieving data? Is there proof or evidence of intent of the latter? I guess, there remains much to be defined. Especially, if it's not so much about protecting reputation than it is about protecting data and ensuring trust, and the intent is to protect and secure this in the first place.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: