I think you're conflating two precepts. Just because you can write an exploit, it doesn't - inherently - mean that you have the skills/knowledge/tools of where to look for all signs of exploit having occurred on your device(s).
From the inference of that logic, every developer should be able to use gdb or Windbg to ascertain where they shot themselves in the foot - but we know that this specific set of skills isn't inherently required to be a developer.
So, the same logic would be true here: Just because you can write a hand full of exploits, it doesn't inherently mean that you have the tools/know-how to be able to ascertain if any of all of the available exploits in the wild (or in private, re: tools for Trenchat) have been used on your phone.
> The rule of law means that nobody is above the law
If the stats from the Innocence Project are correct[1,2], then it would also mean that nobody is above being a victim of the rule of law, either.
The rule of law is not infallible - and any sort of blind "rule of law" worship is akin to the worship for a dictator; its just merely dressed in different clothing.
> If you and I had been introduced, you would have a [email protected] designating me in your address book, and I would have a [email protected] for your address in my address book.
The description, here, is no different than S/MIME encryption exchange - in that the guid exchange has to be done before it could be used.
You still have the issue of [A]Guid and [C]Guid correlating between themselves _and_ it being "unique" per SMTP session (after all, you said before that each guid has to be unique per session). This is where my earlier reference to generated guids being exchanged during the SMTP session comes into play. However, leaving that aside...
A single-use guid is no different than an SMTP address, if we're going based on the single guid inferred from that line -- and that guid has to be stored elsewhere in your system for it to be resolved to a recipient. So, you need something like a guid history array on the object for the forest to be able to resolve that guid (on recipient resolve) to a mail object inside your forest.
You have no mechanism (from your description) for B sending to [A]Guid or [C]Guid junk mail (assuming they've been able to discover the guids) using those guids. You say you would invalidate [A]Guid or [C]Guid -- but this doesn't resolve the issue of [A] and [C] now having to re-exchange Guids, for something that B has done.
So, now, all valid email between [A]Guid and [C]Guid is invalidated (per your description) and they're calling into your helpdesk, trying to understand why valid email isn't being delivered.
Do you tell them to re-exchange guids? How do they re-exchange guids when the mail system is dependent (directly) on those guids already being established on both sides? How do they "re-introduce" themselves, in other words, in that scenario?
> ...the idea here is that every entity gets their own guid designating you, so the same guid is not known by more than one entity
Ok, now you're sending a list of guids that _can_ be emailed to, per negotiation? Otherwise, how are they sending to that specific guid? A guid is not a hash of an object but an identifier object (a 16-byte array, if I recall correctly) - it has to map to the recipient _somehow_.
In other words, in each SMTP exchange, that information would have to be stored in some form of look-up table, _somewhere_, on both the sending and receiving servers.
How do you enforce the senders destroying that table, so that many versions of it don't expose your half of the signature? Do you generate a new key per session? If so, where are you storing that key, in memory? How would you prevent the heap from exposing those keys in a process crash (say, where a dump is automatically generated - like in Windows)? How do you prevent a nefarious actor using A, B, or C from generating a flood of SMTP sessions and creating a tonne (yes, the metric kind) of these look-up tables in memory? What happens when back-pressure is hit? Do you force everything else to paging but keep the tables in memory?
> ...your email address is actually a cryptographically generated guid rather than something easily guessed or harvested. If you combine that with a background handshake procedure for introductions, so that all of your contacts get their own guid alias mapped to your canonical one, then you can revoke any of those if they get compromised at any time...
Here, you're kicking the problem further down the road, though, to another known attack vector: Directory Harvest Attack[1].
In this case, though, the directory (presumably) contains the guid mapping (which - by definition - would have to be a different guid than the object) and would have to process parsing these guids against the users. (This already occurs on recipient receive for some SMTP servers [just before BDATA/DATA] via the email address).
What would one bad email to an email guid do? Would it force rotation of the guid[s] throughout the entire forest? If so, how would that be communicated externally? How would you communicate it for just the one address, if you just changed the one guid?
Would you, instead, have to keep a guid history to check against -- or lose all of the email between possible compromise and the sender's database update? Would you just keep it in the Transport Queue, until manual intervention could check out email between the possible compromise of the guid and new mail would be received for the new guid? That wouldn't scale for large enterprises.
Keep in mind that nothing has to be sent for recipient validation to occur. The SMTP Server[s] just respond[s] to the recipient block with the next step -- but the caller doesn't have to complete the SMTP negotiation from this point, they already have validation if the addresses (even these proposed guids) are valid.
Tarpitting is somewhat of a viable option, here, but it isn't foolproof.
> You selectively quoted a fraction of my statement and threw in a strawman.
I disagreed with the first part of your statement and agreed with the second part. Are you only reading to respond and not to comprehend? Also, how are studies or facts "a strawman".
What does dealing with those 4 things have to do with your initial gross oversimplification?
Expediency is a gross over-simplification of why the cashless society is a growing tend.
For example, it costs more wealth than the value of lower denominational coins to produce said coins.[1] There's a correlation between the decrease in financial-related crimes and cashless vendors.[2] It is believed that cashless systems lead to less tax evasion.[3]
Having said this, I agree with the remainder of your statement - that it has the potential to discriminate against people who don't have and/or are unable to obtain bank accounts.
In one example (in the 10's), the owner of the building that Unisys used to lease wanted to disproportionately increase the cost of the lease; it was so much so, that it was cheaper for Unisys to close the site and offer relocation to the workers (notably, New York being a favoured relocation site).[1]
> NRK is only georestricting because the licenses forbids them from not doing it.
I would be more inclined to say that they're doing it to be "safe". For example, their immediate neighbour, Sweden, has a selection "Kan ses utomlands"[2] -- which, roughly, means can see outside of the country.
Presumably, like elsewhere in the world, not everything NRK is showing is licensed only for Norway.
To the original point: The issue isn't that BankId is being used, it's saying you can just watch the originals, in their mother-tongue (person-tongue?).
For example, NRK produces some originals, like Vikingane[3] that eventually became Norsemen[4] on Netflix.
Clearly, that's been licensed for semi-global (if not global) consumption via Netflix; however, as you can see from the NRK link, you still need to login via BankId to watch it in it's original form.
Again: None of this is a problem, per se, but saying that one can just watch original shows - in their original language - isn't congruent at all with reality, these days.
> ...OR Series in target language and subtitles in English or native language...
In the ever-growing geo-restrictions world, this is no longer as easy as it was in the days of yore.
For example, if you're learning Norwegian and you want to watch anything on NRK, you need to get a BankId[1] - for which you need to be a resident _in_ Norway to have.
The alternative, of course, is buying DVDs/Blu-Rays on Amazon -- but you have to know what you want to watch and what is "good" before buying it.
From the inference of that logic, every developer should be able to use gdb or Windbg to ascertain where they shot themselves in the foot - but we know that this specific set of skills isn't inherently required to be a developer.
So, the same logic would be true here: Just because you can write a hand full of exploits, it doesn't inherently mean that you have the tools/know-how to be able to ascertain if any of all of the available exploits in the wild (or in private, re: tools for Trenchat) have been used on your phone.
Edit: gbd != gdb