felsokning

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.

Edit: gbd != gdb

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.

[1] https://innocenceproject.org/exonerations-data/ [2] - https://falseconfessions.org/fact-sheet/

If you and I had been introduced, you would have a guid@naasking-domain.com designating me in your address book, and I would have a guid@felsokning-domain.com 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?

https://archive.is/ctb5G

...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.

[1] https://en.wikipedia.org/wiki/Directory_Harvest_Attack

Would make an amazing set for a film.

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

They don't give any numbers on the amount of resistances to the expansion of the infrastructure, based on noise alone.

This reads like a "we did a cool thing" but without qualitatively demonstrating the merits for the need.

What's your problem?

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?

While it maybe expedient for merchants...

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

Austin has had issues, long before the pandemic.

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

https://archive.is/M45as

...it will temporarily interrupt the current CPU execution process...

If you unwind the stack (say in a debugger), you'll find that there's no "interruption" occurring.

Thanks! Wasn't aware of the Archive link. Even so, it is hit and miss with what's available.

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.

[1] https://tv.nrk.no/serie/skam/sesong/1

[2] https://tv.nrk.no/serie/stoerst-av-alt

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.

[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.

...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.

[1] https://tv.nrk.no/direkte/nrk1

Ozone situation was fixed...

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...

There could be plenty of other pathways to a stable carbon cycle.

To be fair, carbon is the only base that we have (first-hand) experience with. There _could_ be other bases.

The lack of this API wasn’t stopping anyone from implementing a paywall.

Obviously -- that's inferred by the 2.0.

The Popover API provides developers with a standard, consistent, flexible mechanism for displaying popover content on top of other page content.

Paywall 2.0?

It definitely reads like a, "If we don't use it, we lose it," message - and not a, "oh, mahgerd, wE gOtTa Do SoMeThInG nOw!!!!!!" kind of message.

Normally, management, your peers, or the company as a whole are aware of your performance. They should be doing a lot of this for you, in my opinion.

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

"Learn to swim, see you down in Arizona Bay" - Bill Hicks/Tool

This individual is suspected of being a member of the Mossos d’Esquadra (Catalonia’s police force) and of using their internal knowledge to assist the Democratic Tsunami movement.

...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.

...because of US legislation, namely FATCA ...

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...

Those were radar-based (before ADS-B), I thought?

Observe, for comparison, the FAA requirements for flight plans and running a broadcasting transponder to safely operate an airplane.

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.

Some foreign banks simply don't _want_ to deal with American citizens, precisely because of the reporting requirements strong-armed in agreements with the US -- because they have to report those bank accounts back to the states every year (or quarter).

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.

Along the same lines to your suggestion (thus, piggybacking): A filter based on principal language of the movie[s].

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.

[1] https://whereto.stream/tv/113371

In the issue I ran into, the '$' comes back from Azure in the nextLink[1] value. As soon as you try to process the string, the reserved token '$' breaks any processing - precisely because it wasn't escaped before being stored.

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...