skysight-inc/HackerNews huggingface dataset:
Great companies are not just defined by their products. Example for Google and Amazon is to illustrate that they've built a _system_ (consisting of brand, culture, values, etc) that can explore, prototype and execute in multiple different areas from scratch, and without being first to market.
Well you got your wish. Gonna be honest and say I’m not sure I’m enjoying HNs move to follow twitter and facebook to micromanage discussion to this degree. I really don’t think we were being uncivil in having a discussion about what we appreciate about this guy.
The brown paper bag being laser printed really cuts down the field of who could have done it... A paper bag won't go through a typical home laser easily... and if it does, it will leave dents in the transfer roller with the folds of the bag, identifying it.

I'm gonna guess it's an insider... And there is probably a managed commercial printer in the building which will have a job log showing who printed it...

Most commercial printers leave yellow microdots too...
Doesnt unicode just encode country abbreviations? I thought they washed their hands of which abbreviations are which glyphs.
This is a common problem in enterprise single-sign-on systems.

The issue is: If the user presses the 'log out' button, you want it to take effect within a few seconds. But if logouts are simply a timestamped record expiring, they'd have to expire within seconds, and that would basically mean re-authenticating on every single request.

And at the same time, some webapps have shitty re-authentication flows (like discarding any unsaved work-in-progress and kicking the user back to the homepage) and they're only usable with a re-authentication periods measured in days.
How refreshing to see something else than foo and bar
just switch to 'onion', 'ay praise' and 'cotton fields'.
I thought ICANN can forcibly transfer a domain that is not being used to another entity who can prove a legitimate need for it?

That was supposed to end a lot of domain squatting, especially since web addresses are kind of crucial to modern companies and in the wild west of the internet, anyone can setup e.g. cocacola.org or something and start trying to steal your customers.
There is simply no reason to believe that the human brain is anywhere near optimal on this tradeoff.
Session tokens are easy to shard / partition to any number of machines. Just use a random identifier like a GUID. Allocate IDs to machines using either the prefix or any one of the scalable hashing algorithms.
I've recently received my https://frame.work laptop (64 GB RAM 2 TB NVME) and with its expansion card system I can have 4 usb-c, or 2 usb-c and HDMI and DP on it, and if a connector fails the replacement expansion card is 10-20 EUR.
A big limitation is forced early expiration. If you need to do that then you end up needing to share expiration information and therefore need to share something that might as well be a password hash.

So for example it's not great to use instead of a session key. You could design a system where you have, say, 6 API endpoints and instead of the API endpoints needing access to the authentication db, you use bearer tokens from a single sign on to grant access to the API.

That works great until Bob realizes that Eve has got access to his password and hits a password reset to force Eve out the system.

But with bearer tokens, Eve still has access until those tokens expire.

You could add a check for expiration against the calls, but then we're back to session keys being more straightforward because we're back to having some central information (has Bob's token expired) that needs propagation to the different services.

You could have extremely short expiration but then you're back to having to round-trip to re-authenticate often (or in an auto-refresh situation, one where you're back to checking for expiration yet again).

I think bearer tokens work best for internal proxies / APIs to avoid hitting the data store, they aren't a great replacement for session keys.
Those are crimes, for sure! I was comparing the former (cheating) with the potential of the same person for committing worse crimes which impact more people more forcefully. Not absolving them of their crimes.
You don't need AC for isolation, you need transformers. Isolated DC to DC is a big area of power supplies. You've also got cabling size backwards: you need thinner conductors for higher V due to lower I.
I bought a LG Velvet one week before the company announced its withdraw from smartphone market. It's a very good device and - surprisingly - still receives updates up to now.

This is the second LG smartphone I have had and I feel a bit sad that it will also be the last one.
I also wonder how feasible would be to use TPM. Is it even supported for use from web applications? I'm also don't aware about similar hardware solutions for mobile devices.

Another thing, it's mentioned that we don't control how tokens are created by some third-party, but still, we can use something like Keycloak with external identity provider and client in this case would use token from our Keycloak.
In that case we can ensure that for our purposes token will expire quickly.
One piece of e waste I had was an entire MacBook Air which was bricked by a USB-C hub with power delivery which Dane highly recommended. Apple fixed that problem by updating their firmware. Apparently even Apple has trouble with USB-C.
I can't speak for @kragen, but I recognise the format from the Long Now Foundation: https://longnow.org/
My laptop has enough ports. But I don't want to plug them all out and in again when taking it from one desk to another one.
So I have a service using openid and I use google to authenticate the person logging in. I do that, then that's done.

Now I could simply issue a session cookie, or a permament cookie, to the client so we never have to use google again. Or I could make it so that cookie lasts 10 minutes before reauthentication. I can use a refresh token which means they don't need to reauthenticate but if google expires the connection (disabled user etc), I expire mine.

Either way, that's my decision as the person running my site, and it's the clients decision as the person running the client to decide whether to send the blob, or to share that blob with other clients. The only information I know is that somebody authenticated with google at a specific time and I had proof of that, I have no control over what happens to that blob.

Google has nothing to do with what I or the client do with the information.

You're right that I can't audit the third party (google, microsoft, etc), but I don't pretend I can. Google could simply change their password checking to "if (true)", that's google's business. If I'm worried about the third party authenticator then I shouldn't use it, and I should roll my own.

(There was an early Tom Scott video imagining a world where google just says "yes" to passwords[0])

I have an internal read-only blog site using our corporate openid service to ensure that someone accesses the site. Once they authenticate, I allow them access for 30 days before forcing a reauthentication, because it's low risk. OK if they log in from a compromised machine than a hacker gets to read some internal information, its very low risk.

I've also got a site where you can make major changes. You have to reauthenticate far more frequently to make those changes (every 30 minutes). It's a matter of risk.

[0] https://www.youtube.com/watch?v=y4GB_NDU43Q
As was 1984... were there any Orwell books that weren't classist?
I don't see why you need a revocation list - you just need to check access date with the security key. And do a sweep say every couple of hours to delete the security keys that haven't been used.
I guess you also stumbled upon this after reading https://news.ycombinator.com/item?id=30903940 :D

Google already indexed this page 59 minutes after posting (that's how I ended up here)
...according to math invented by a manager with an interest in pretending that their case makes sense.

Just jiggle the projection of how many people would cancel, and whalla!! You can justify anything.
Yes but then you add revocation and you are back at a centrally stored database to check against.
Yes, it gets you a long way but then on top you need things like IOMMUs to stop a driver mis-programming a hardware device and evading the memory safety that way. Fortunately all modern platforms have IOMMUs.

The point of managed code is that it compresses the space where (memory) safety problems can creep in to a small core in the runtime, which gets really well tested and reviewed. Even if there are concurrency bugs in your user-level code they can't corrupt memory in the manner C code can do - just yield objects in an invalid state that will hopefully be detected and cause exceptions very quickly. In turn you can then recover and try again or let the user know. CoModExceptions are a good example of that in action.
What are your faverite web blogs or newsletters?
What do you like to read? What are you subscribed to?
The square USB plug is intentional. USB-C is not always the best plug. Take a look at USB channel loss budgets[1]. This is a very simple read, even for people who are not at home in electronics and signals.

To summarise the document, the "square USB plug" aka USB-B was conceived when USB client devices were simple, had short traces, little noise, and thus were expected to emit a signal with very little signal loss. This allowed for a relatively long cable. USB-C was conceived to deal with complex devices, which incurred more signal loss, allowing for a shorter cable to keep the total signal loss in the system in check. So even today, A-to-B cables can be longer than C-to-C (even though it is only marginally).

The odd thing is that the spec defines legacy C-to-B cables at far below their true capabilities. According to the spec the loss budget for a C host device is 6.5dB, as opposed to the 10dB of an old A/B host. This should allow for a cable assembly with a channel loss of 11dB! And yet the spec insists on a mere 4dB. So technically someone could make a "non-standard" 11dB cable that should just work, given the guarantees by the rest of the spec.

[1]: https://usb.org/sites/default/files/USB_3.1_Loss_Budget_Rev_...
On Windows, settings and software can be enrolled remotely the moment you hook your machine up to an MDM portal, just like on chromeOS. Windows doesn't include some of the functionality ChromeOS includes, but your employer can definitely manage settings like your standard browser if they choose to. The can also enforce that all software you run is signed, is run from specific locations on the system that you may no longer have access to and they enable Bitlocker with a specific backup key.

Most companies either choose not to implement any of this, or simply do not know they can implement this. Do not sign into your personal devices with your work account on anything but an isolated browser (modern Windows has a sandbox built in!) or you might discover the hard way what kind of possibilities remote AD allows for.

Windows does prompt you to accept that the account can manage your device, but so does ChromeOS. Denying MDM may cause the login to fail if they automatically rescind any tokens that don't get MDM access on your device.
The author details some of them in the "Featuring" section in the front page [0]. There is also a comparison with different languages [1].

It seems the language is still in very early stages. Not production ready.

[0] https://vale.dev/

[1] https://vale.dev/comparisons
I think we completely agree.

I was specifically responding to this from the parent comment:

> What alternative? Talking to people, presenting them with company problems, and listening to their opinion about them, aka. "how would you do X if you had Y?" kinda questions?

Which I understood to mean that no actual coding would be done, it would be more of an open-ended interview about work history / etc. Which I would argue is far worse than Leetcode style questions.

And I'm also arguing for the idea that the fairest interview is the one that gives the most accurate answer to "will this person be a good developer for the company".

But of course if there's something that's even better than Leetcode, obviously companies should want to adopt that instead.

At our company, we do something very close to what you propose:

- an initial phone screen with a very simple "Fizzbuzz" style programming filter.

- After that, an open-ended architecture problem (how would you build such-and-such system), which can go in many different directions, and can include a few specific coding examples.

- Finally, a real programming task for ~1-2 hours. Sit down in front of a computer with access to internet etc, and do these tasks.

We find that these in combination give a great answer to all our questions (well, the "ability" portion at least, which has the most weight.)
Man what field hasn't touched by Tencent right now?
Having seen the absolutely atrocious screens in the school furnished chromebooks I half believe Vtech put higher res screens in their 90's kids laptops.
I think the article mixes up several different problems. Both cryptographic keys and opaque tokens are "possession factors", i.e. if you have them you can authenticate against a service. Signature-based authentication schemes are mostly used to protect against replay attacks, which are easy to perform with an opaque token as it won't change.

That said you can tie both opaque and cryptographic tokens to additional factors. For example, machine tokens can be tied to specific IP addresses, so an adversary won't be able to use them from a different device. Tying them to other possession factors like TOTP codes would also work, though it's often impractical.

Mobile apps can easily make use of signature-based authentication schemes based on keys stored in a secure enclave, both Apple and Android phones have good support for that. For web apps it's more complicated as there's no way to store keys in an enclave (and many older laptops/computers don't even have TPMs), so you keep them lying around in memory or in the browsers' session/local storage, which of course isn't ideal.
I think the key use case is installed hardware decoders. So rather than replace a set top box to get it to decode a next generation codec, you can send it the previous generation codec, which the hardware handles, and then use limited CPU you have to 'upscale' that.

I don't understand why you would use this in a greenfield situation or in any place that is purely software. Since surely you could just build this into the new codec and get all the benefits?
Coders may not destroy the road behind us (the software highway) - but much of our effort is spent destroying the roads other people are on. This is called progress, of course - but Amazon's dismal warehouses are 100% a side effect of the extreme efficiency gains we enable and champion.
Rebalancing Society
I like bearer tokens, but the author's terminology makes it sound like they're not thinking about them from an appropriate perspective.

My preferred way to think about tokens is a form of inter-process communication. In a scenario like 'view this document requires authorisation', the token is a way for the the 'decide whether to authorise' process to communicate some data to the 'view the document' process (that data being 'document-viewing is authorised').

Statements like 'bearer tokens allow hackers to impersonate a user' isn't congruent with what tokens are, or what they're for; in particular, tokens have no concept of "user", "logged in", "authentication", etc. They simply communicate data from one system to another.

The author's complains would be better phrased like "Caching authorisation results is vulnerable to time-of-check-to-time-of-use problems"; that's true regardless of the underlying technology.

Finally, I also consider tokens to be a 'last resort'. From a capability perspective, unauthorised clients should be unable to say what they want; for example, we can restrict access to a document by making its access URL secret and unguessable (we should also allow fresh URLs to be generated, and old ones to be revoked/deleted). That's (a) safer than telling everyone where the document is then having to decide which requests to allow/forbid, and (b) easier to use and integrate into other systems (since it's just a URL; no cookies, "are you a robot?" captchas, etc.).

If we're faced with an action that can't be made secret on its own (like gating it behind an unguessable URL), then we can make it secret by requiring an extra "dummy" parameter; AKA a 'token'.

Note that this is the complete opposite of what the author seems to be describing, which is:

- Reaching for tokens first (rather than as a last resort)

- Having them represent "data" which isn't related to the actions being performed (e.g. "this is person X", rather than "document Y is readable")

- Using this one token to access everything, rather than using fine-grained action-specific authorisation
If the author is reading this, please remove the fixed menu at the top. Eats a ton of space on a small screen and makes reading unpleasant.

This is more about data management than knowledge management. I'm the opposite of the author. I have little interest in archiving all my data. Not that there's anything wrong with it if that's your thing.
Probably, many programmers played videogames when they were little, so there's always an underlying dream of creating one.

I dabbled in games development, but I've met the same problem; videogames development is actually much more than programming (the engine), and the creative part, which is the primary one, may not appeal people who are technically-minded.

This phenomenon is very visible in Rust; there are several game engines, but very few production quality games. The most famous game engine, Bevy, is very popular, but after approximately two years of development is still an alpha (and a very changing one); contrast this with Fyrox, which is much more stable, but is considerably less popular (essentially, unused).
Human brain has very likely 10^15 synapses so these models are still behind at least 3 orders of magnitude. To put in perspective, if you want to simulate “network” of human brain, you probably need an entire data center worth of GPUs.
Some CalDigit docks have this fun issue where if you plug the wrong sort of adapter into the wrong sort of USB-C port it will brick the port if not the entire device on the other end.
I have multiple desks. Each of them has their own docking station.

The only things that move around are my laptop and I. I don't want to carry around a desktop computer and plug in power, screens, and USB hub every time I switch desks.
Talking on Twitter is not legally protected.

Talking about unionization, wages and workplace conditions however is.
That's github's service, before choosing to use it you should look at these policies (who and how github enterprise trust tokens) and see if it matches your needs.

If you were running the service, then the power to trust those tokens is with you.
seconding Brother's laser printers

They simply work with most modern Linux distros and Android releases. There's no nickel and diming. They are reliable and maintainable.

When I need high-quality photos? I drive to the drugstore and use the kiosk.
> It could be used to tie that logged in user to other web sessions that are currently anonymous.

If those other sessions are anonymous, why do they have the token?

See, I'm not very experienced in web-dev, and I'm very much aware that I may not know what I am talking about.

I'm just trying to understand how the tracking data in the bearer token will "leak". Can you give me a scenario, like "Client goes to SiteA, is then redirected to login on SiteB which grants the token, and then goes to SiteC which reads the token".
been using PARA for a few years, I can vouch for it to be a very natural way of organizing information once you get used to it.
I've never heard of eligibility for rehire being given in an external reference. There is no purpose for that other than to get sued. But it may be in the file easily accessible for internal use only.
I think the end goal of Amazon is to replace these employees with bot and to automate manual labour work. Until then all this is just ways to delay the unionization as much as possible.
>>Annoyingly, it doesn't come with a USB cable! I thought that was to save money - but they included a UK and EU power cable, so I think it's just to "encourage" using the WiFi.

I don't think any domestic laser printer came with a USB cable in the last 20 years. It's not a conspiracy to make you use wi-fi - it's just manufacturers being cheap and not including the USB cable has been the standard for a really really long time.

>>" Even more annoyingly, it doesn't use USB-C - instead it's that awful square USB plug. Eugh!"

Again, that has been the standard in printers since forever.
> And they kept getting better at what made them big in the first place at least for another decade. Go back 20 years in time, and Google was a search engine. Today they are much, much more than that. Go back 25 years in time, and Amazon was a book store.

Perhaps you picked up two bad examples. Google search is worst than ever (for their users ofc, not for the ones who get money out of it). My experience as a customer in Amazon is equally bad: bad quality products (I have to spent hours filtering and double checking in order to say "yes, that's the item I want"), reviews over 4.0 that nowadays mean nothing, intrusive ads everywhere (e.g., I searched for boots in Google image search, and suddenly all the ads in other websites are about boots sold at Amazon).

I used to trust Google (I bought domains from them, used Gmail, I even bought their Nexus 5!), but not anymore precisely because how big they have became: almost-zero human customer support, they can ban you anytime they want and give you zero reasonable excuses.
I can't believe all the catty defensive replies. The answer is that programming is designing automation (automatic computation) and functionality of computers. So getting into that mindset naturally leads to "well, what If I can automate what I'm doing too? What if I can make a function that makes these functions?". Not to mention, a gardener isn't tempted to trim his rake into a better rake, because that wouldn't work - the tools are made by a different process than what they are used for. Not so in programming
This is solved by mechanisms such as DPoP.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
I've worked at a couple of places where the session token lookups were the bulk of database traffic - to the extent that one place had to split it off to its own cluster just to stop it clogging everything up.
It's very ironic because a lot of people paid for Netflix to "cut the cable" and not get commercials in the first place. Now you're saying they have to pay for that yet again?!
> that is not being used

How will that be defined? It's not difficult to put up a small website. And just like that, the page is now used.
I, as the company paying for your service, have no direct ability to influence the policy that you apply to the tokens you issue. If you start issuing tokens that are good for decades, I have no trivial mechanism to detect that.