Last of October [Placeholder]

October

[August Placeholder]

July Motivation Post TBD

Coming soon. Subject: motivation.

Still June?

bla bla

Unverified Identities on Websites

Unverified Identities on Websites

Earlier article for context: 

"//impossible-is-development.blogspot.com/2015/04/simplest-email-identity.html" 

During my re-implementing to simplify the email identity thing, I realized that it could be useful to allow unverified identities, and I have now implemented that. At first, I tried simply not verifying email adresses of certain patterns; for example emails ending in "@example.com". Which works, of course, but I feel hesitant about it for a bunch of reasons. 

Firstly, an email is a lot to type just to get an unverified nickname. If you want to try a site, it should really be even simpler. Of course, many sites don't even tell you that they give you a temporary identity, tracking visitors by cookies. Yeah, you're now by law in many places required to inform the user that they're being tracked. But it would also be good to have the user be a little more aware of what their id is, so that they can be more recognizable in pages where that is useful. So, I'll either allow typing in a nickname, or have it be generated for the user, probably something readable. 

Secondly, it may be prone to user confusion. Well, everything is, but of course I'd like to minimize that. I can even have a separate page to set an unverified identity, which I hope will give maximum clarity and simplicity for everybody. 

Thirdly, it doesn't 'feel' good, architecturally. It's coat-tailing, re-purposing. Alternatives are not clearly demarcated, which I feel is a cornerstone of good software architecture. 

Fourthly, I'd like to implement it as a separate module from the email identity, for simplicity, and to be able to exclude the email identity module in favor of something else, like OpenId or Facebook identities, if an application so requires. 

I think I'll add a little clarifying detail on the 'unverified' identity idea. It will not be the case that the access token cookie is not verified. It will still be a signed access token that the server has to issue and check. One could of course dispense with that too, since the id is not really verifed to start with, but I think it's best to limit identity access tokens to only be available via the server. Perhaps to limit their number. But there's also the advantage of not having separate paths. The 'outer' format of the tokens is always the same; and the signature is always checked. Simpler, less room for mistakes resulting in security problems. 

And finally, some low-level implementation details, which don't really matter, but might still put a little meat on the conceptual bones. The token content is JSON, of the form {"id": [id], "utcs":...}. An email identity is of the form {"email": "some.email@example.com"}. An unverified identity is of the form {"unver": "anything_goes_here"}. This is the 'id' field, in the JSON object that also contains the "utcs" field, which holds the number of seconds since 1970 of the moment the server issued the token. Having a time-of-issue allows expiration to be checked. 

Next, perhaps something about how to implement this in Java, or more on sending email links with access tokens. I hope this scheme gets implemented in place of the awful username/password scheme on the internet, unless something better is available. 

Simplest Email Identity

Simplest Email Identity

--- 

Ah, last of the month again. Why not write about something useful? 

One things that bugs me, is how web sites do identity or login in ways more or less clumsy and terrible. 

But let's not get into rant mode, I'll just tell you of a simple solution. And _then_ maybe go on a rant. 

It's really simple: show an email input field. Send access token to that email as a link. When user clicks link and reaches your web site, add the token, or a variation of it, as a cookie. Done. Now you have a cookie that verifies the email identity, and can be used to authorize operations. 

Note that the access token can be simply a signed message. That way, no storage is needed on the server. So no statefulness _at_ _all_. So no scalability limit here. 

Encode a time of issue in the access token, and have a max age for some operations. Sill no storage needed. Just keep your server clocks somewhat accurate. 

The email can be used for easier reissuing of a new token. No need to fill it in again. Can even be sent out automatically before expiry, or when user accesses site, for instance tries operation requiring an access token younger than the one set as cookie. 

The email input field should have the type='email' attribute. This way, the browser can check syntax, or even fill in the email for the user. So 'signing up' for a site could be done with minimum effort, and then only require waiting for an email that should be arriving shortly. 

-- 

So, that's the gist of it. I've implemented this in Java, and am currently re-implementing it, simplifying it further, and I might publish more details helping to implement this, or even code or a jar to run a demo of such a site. 

So, there it would obviously be much better if this was handled some other way, perhaps as a standard interaction with browsers, where the user is asked if it wants to reveal his or her identity to a site asking for it. Or partially reveal. 

And/or there could be trust networks; e.g. there could be sites issuing or guaranteeing identities. There already is standards and players here, of course; OpenID, Facebook. But then you'd have to trust them. And Facebook reveals too much, I'd say. There should be steps, so that you have the option to only establish an identity without going further with details like names and friends. 

Now, you might say that an email is already too much. But a user could have a secondary email just for testing sites out. A problem then might be transferring to a real email if you want to be known more as yourself, e.g. if the site provides social services where people can get to know you by email. 

--- 

There is the ever-present safety and security considerations. What can of damage can an attacker do to the described scheme? 

Using the signed-token implementation, scalability is of course a first defence. 

A serious issue with email verification is always sending too many unwanted emails to people; even though there is not much an attacker could get out of it, except hurting the reputation of the targeted site. Rate limits per email address, is one thing. This requires storage and synchronization, thus hurting scalability. 

An attacker could create unlimited numbers of email accounts, perhaps using a mail server specifically for this purpose, and register each of them automatically. Using the encrypted-token implementation, no storage is used, so this attack is not so useful in a first stage, but the attacker might go on to use whatever resources are afforded by the site to each identity. Per-domain limits might help. 

-- 

Additional small things to help. 

Email apps could have separate folders or filtered tabs for identity mail, like 'forgot password' messages. 

Email apps could throw away reset link messages after they are used or after they're expired. Or perhaps just default to discarding them after a month. 

-- 

Now for the ranting. (Separate article?) A web site should not... 

A web site should not require a username. This means the user must come up with, and remember a user name. Come on, I've better things to do. We all have, I hope. 

A web site should not require a password, if there is any other way to do it. 

A web site should do this in their own interest. How many simply balk at signing up, and just leave the site? 

A web site should not require a real name on sign-up. In addition to requiring even more extra work, unless auto-fill can be leveraged, a user might not want to tell. A user may want to gain confidence in the utility and seriousness of a site before contributing private information. 

Worst case when a web site requires a username and a password: you forget them both. You'll have to: 

(*) guess username/password. Get told 'username or password wrong'. 

(*) what now? Have to guess which one is wrong. Site could've told if it didn't know the username. Of course, you could still have guessed somebody else's username. 

(*) click 'forgot username'. Fill in email. By hand, no auto-fill. Click 'send', or whatever. 

(*) wait several minutes for mail. 

(*) fill in username; there not being a link in the mail doing this via URL params. 

(*) fill in password again, it was not saved in browser's local storage. 

(*) Get told 'wrong password'. 

(*) click 'forgot password'. Fill in email. By hand, no auto-fill. Click 'send', or whatever. 

(*) wait several minutes for mail. 

(*) now you'll have to reset your account password, filling in password twice. 

(*) you'd think the site could log you in from there, but no; now you have to log in again. 

(*) Done, if you've managed to stay. Now you can check the status of your ticket or do whatever trivial thing you needed to do. 

-- 

Odds and ends: use HTTPS, further automation, fine-grained authorization, finding similar existing implementations, compare to existing non-similar implementations and thinking about tweaks in this direction, password managers as a solution, what is the 'culture' and sociology that has made this bad state a reality, etc, etc. 

Nonreligious Articles of Belief

Nonreligious Articles of Belief

Yeah, this is another good thing to get out of the system. As with everything I say, it should be looked at as more tentative than absolute, even when formulated in a creed-y manner. I've thought about these things for a long time, and I believe writing this does me good, mentally.

So, I hereby present: six tentative beliefs of mine. A short version of, and perhaps a table of contents for, the longer version that is 70% done. I just wanted a short version out now.

I believe useful estimation is impossible in software development. (Of course 'estimation' with no further qualification is possible, duh...)

I believe interfaces types are needed to scale well, and 'distribute' well. At least type-'consciousness' is needed, but actual formal types in languages are better, because they can be processed by machines.

I believe organizing code into features or modules is superior to the common layered architecture default.

I believe polyglot programming is really difficult, a really big risk. Something to avoid, the more the languages differ. And one has to consider incongruent data types and gaps in tooling more than just different syntax.

I believe databases as entities separate from the application is one of the things that makes software development terrible. Also, see polyglottism.

I believe optimization (I mean that thing that compilers or query engines do for us) is kind of useless because it is unpredictable, unreliable.

So, in closing; I believe that some of the common thinking and so-called best practices make development projects not scale well, make code less understandable, make tooling harder, make analysis harder. And make me depressed. When in contact with them. And that is one of the reasons for this article. 

Three Big Bad Things

Aha, I'm writing about motivation again. And this time I'm motivated about it. 

I want to just get some things out of my system. The theme is, sort of, things about software development that have been sort of depressing. If I write it up, and put it out there, it might bring about a relaxed state of mind, I hope. 

So, there are mainly two things that are, or have been depressing. Well, actually, one thing that has been depressing, and one that only laterly has crept up on me as a factor of un-motivation, or whatchamacallit. 

Thing one, is this thing about estimation. Thing two, is about the meaning of doing things; and particularly in this case, the point, meaning, or 'why', of developing software. 

Uh, wait, there are actually _three_ things about developing software, that are cause for suboptimal states of mind. 

Third thing: fuck there are a lot of bad ideas, tools, libraries, methodologies out there, some of which I have had encountered. Note that I could not really say 'had the unfortunate luck of encountering' or some such; because it's inevitable to come upon these things, so I don't know if I've been particularly unlucky here, and there might be much worse things, that I've had the luck to not have to contend with. 

So; well I might actually say that the idea about estimation is one of those bad ideas, or methodologies out there. But it is such a big thing with software development. It's inevitable, sort of; I might give the anti-NoEstimation camp half a point there, about it being a fundamental part of human activity, the human pattern of behavior, or that wonderful expression: The Human Condition. OTOH, I am not sure the NoEstimates crowd really disagrees. It's all a bit muddled. The subject matter is muddled itself, by its very nature. 

But I am not writing to set anything straight. I'll let it be muddled. I only intend to write about what I have been thinking about all of this, for the last few years mainly. 

Actually, estimation might be a blog post all unto itself. And so could the meaning or why of developing software. And also the suckiness things. So, that's three blog posts queued up to write. And I feel good about that. 

Last of the month

Whoa: last day of the month again. Happens all the time. I'll just put up a placeholder for now. I want there to be a post every month, and apparently I am not above cheating.

Ten-minute Soul-selfie.

Ouch, hours left of January, but I only have a few minutes to bring together some bits of text from some drafts I made for a more ambitious post.

I think I may just be succeeding in overcoming the major obstacle to worry-free life: the friction/motivation problem. I have been trying to write a post about motivation in particular, a few drafts are the result. I will probably turn it into a blog post here.

For this post, among other bits and pieces, I made a list of motivators and turn-offs, because my current thinking is that it might be good to self-identify of sorts. Painting yourself in a good corner.

But, I'll just make do with my general principles.

Possible demotivator: seemingly pointless businesses. Immoral or amoral could be an interpretation. Examples: the gaming or gambling industries. Not that I could not work for them, but it'd have to be mostly for the money; short term, unless I would be in dire straits, of course.

Possible motivators: utilitarian stuff. Examples: medical stuff; science, research; bioinformatics; tools like travel planners; knowledge, education; or the super-meta-good of them all: developing computer meta-software, such as developer tools, better databases, etc.

Techical demotivators: high-friction technologies. Impedance mismatches, misadaptations, unsuitable tools. ORM. Slow tests. The common arbitrary project structure. Motivators: the opposite. Well, this actually demonstrates that technologies can really only be friction. You want low friction, small demotivators. 

Psychological demotivators: gung-ho-itude. Opinion. Attitude. Pessimism, optimism. Dis-humbleness. Self-evidential, gut thinking. Common sense. Motivational speech, motivational travels, motivational money (besides pay, of course). Paradoxical, huh? Nope. I wrote a draft post to explain this from how I believe creative processes work, but look up recent motivational research that shows this result.

Well, got to be going.