felsokning
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
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.
[1] - https://innocenceproject.org/exonerations-data/ [2] - https://falseconfessions.org/fact-sheet/
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?
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?
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.
[1] - https://en.wikipedia.org/wiki/Directory_Harvest_Attack
Correlated: SVT did a concert in one[1][2].
[1] - https://www.svtplay.se/video/e56v35j/radiokoren-i-reaktorhal...
[2] - https://youtu.be/Q560cKnreSk
Edit: Added Trailer
This reads like a "we did a cool thing" but without qualitatively demonstrating the merits for the need.
No problem. Why the hostility?
> 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.
[1] - https://archive.is/T7nz8
[2] - https://archive.is/MMY2b
[3] - https://archive.is/lCfNX
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]
[1] - https://archive.is/dwQWh
If you unwind the stack (say in a debugger), you'll find that there's no "interruption" occurring.
For example, the most popular show I've heard of, Skram[1], requires a login -- but Storst av alt (another I've heard of) does not.
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.
[2] - https://www.svt.se/kontakt/anvand-svt-play-utomlands
[3] - https://tv.nrk.no/serie/vikingane
[4] - https://www.netflix.com/ie/title/80180182
Edit: List formatting fix.
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.
Ozone is still hole'ing[1]. The hole is no longer growing, sure, but that's a far fetch from "fixed".
[1] - https://www.bbc.com/future/article/20220321-what-happened-to...
To be fair, carbon is the only base that we have (first-hand) experience with. There _could_ be other bases.
Obviously -- that's inferred by the 2.0.
Paywall 2.0?
In company's with forced attrition rates, it becomes a hell of a popularity contest.
When Kevin Turner (former Wal-Mart exec) headed CSS (Customer Services and Support) at M$FT, it was a shit show and a half - creating something like a mandatory 5% attrition rate per year.
Nothing boosts morale better than people vying to NOT be the person let go that year. /s
...and...
> The requests were made under the guise of anti-terrorism laws, despite the primary activities of the Democratic Tsunami involving protests and roadblocks, which raises questions about the proportionality and justification of such measures.
As I understand it, Catalonia has long desired for independence[1]. Is the Democratic Tsunami movement something different, entirely? If not, can someone fill-in the blanks of how vying for independence (in this case) gets umbrella'ed under terrorism?
[1] - https://en.wikipedia.org/wiki/Catalan_independence_movement
Edit: Accidental caps-lock on a word. My bad.
To be clear: The issue with FACTA is that saying "yes" to an American citizen (or national) adds costs to the foreign bank (in free labour on-behalf of the US). The US doesn't fund any of the work of reporting these accounts back to US.
Its almost as if the US has internal sources of free labour and expects no repercussions from expecting the same from their international counterparts...
If you're talking about ADS-B, the only parallel to a database that is owned/operated by manufactures of the vehicles is that they broadcast a signal -- but that's where any form of parallel stops/ends, because the signal from vehicles is not intended not to be broadcasted in such way as to be publicly consumable; which is precisely why the car manufacturers control a monopoly on that data and why law enforcement goes to them for the data.
Planes could arguably operate just as safely before those transponders -- they just couldn't be tracked publicly by anyone (or each other) in real time. Being able to track something doesn't - automatically - infer any upsides, whatsoever, just that we know where the plane is and/or went.
It's not like the US is funding that foreign work to be done on their behalf, either. So the reticence to even bother with creating bank accounts for American citizens makes sense.
For example, if I want to discover new movies in German, Swedish, Norwegian, etc., I have to know the name, first, for the search operation; otherwise, I just movies with the term in the title (e.g.: Svenska returns Svenska tv-historier, Svenska fall, Svenska Hollywoodfruar, Barncancergalan - Det Svenska humorpriset, Svenska Truckers, and Svenska Powerkvinnor).
Which leads me to a suggestion, based on that:
If there's no steam available, don't return the result in the search[1]. The whole intent of the site to show "where to stream" but if there's no stream, returning a result with the message 'Sorry, we couldn't find any streaming information.' is a bit of a false positive -- in a "we have it but we don't" sense.
Perhaps, it's easy enough to do some .NET manipulation, just to get PowerShell to be able to handle the string for the next Invoke-RestMethod -- but its far easier to just curl those urls, instead.
[1] - https://learn.microsoft.com/en-us/rest/api/keyvault/keyvault...