Love the idea! Yes there are challenges (ref: 'Embrace and extend') but there is a very clear value: both for end users (that ultimately drive value) and for paying companies (startups or other) that have have great new products but have to deal with a market in which 'the current generation' of products are used.
From a different angle (that you're probably already considering :-): What about SaaS companies that also want to give customers a smooth way out if they are not satisfied. I can imagine that there is value in having some sort of 'seal' that makes it clear that: yes you can get out of here if our product is not what you want it to be.
Final note: I just hope that we’re not going to end up in a situation where we need to do a “ReCaptcha” again after logging in because some SaaS, x, is wary of scrapes….
I understand from [0] that the attestation key is shared across all instances (SNs) of the same model (PN): "...For example, all YubiKey 4 devices would have the same attestation certificate; or all Samsung Galaxy S8’s would have the same attestation certificate". So you would not need to to buy them at the same time.
But of course, despite this, still a unique key is generated for each identity upon sign up [0]. I am not sure (as in 'have no knowledge of') the entropy for these devices.
A little anecdote/legend from the Philips Research Labs (Nat. Lab.):
When the team demonstrated the first CD they drilled some holes in them, and showed: "Look how robust, they even work when they are this damaged" (paraphrased).
In reality the locations of these holes were chosen very precisely. Not sure if this is true, but this is a story that my colleagues told me in the 90's...
This seems unlikely. CDs don't have physical sectors. But they do have generous error correction, with cross-interleaved versions of the data combined with parity spread out along the "groove".
The rule of thumb is that error correction can compensate for gaps of up to 2.4mm. So if a hole is smaller a CD should be able to cope.
Hey thank you very much. No login needed for submitting an issue. However follow up is handled differently:
Public repos: the reporter is given the link on successful submission, so to communicate further a GitHub account is required
Private repos: the reporter needs to supply an email (not shared with repo) which will be held by Issue Embed and handle communication from the issue to email (and visa-versa)
I gave the reporting a try, and I like the flow in the demo (which is for a Public repo); easy to use.
For a private repo, I would probably also want people to be able to leave anonymous replies (to get 'as much feedback as possible'), but that's just my n=1 opinion.
Thanks for the feedback, I have been thinking of whether making email optional or allowing the admin to not show it. Your feedback is a noted data point, thank you!
Yep, feedback is valuable. And the earlier the more valuable (it's like NPV...).
I love coding so much, and find it really hard to express ideas in natural language, so that in the end documentation... doesn't happen as much as it should.
What I find that really helps is the following:
1. Write down architecture specs (with interface specs etc), before coding. Not bloated, but really minimalistic.
2. Review these ideas with peers.
3. Happy coding and refine the docs.