Earlier quoted context omitted.
I have no knowledge of DANE but its reliance on DNSSEC makes me worried that it would be difficult for people to adopt it. Also, I think it solves a different problem: it prevents spoofing/MITM but what about legitimate certificates? We would still need CAs that actually curate their customers and hold them accountable. And we would need email servers/clients to differentiate between strict CAs and ones that are used…
> I have no knowledge of DANE but its reliance on DNSSEC makes me worried that it would be difficult for people to adopt it. It's not hard to set up DNSSEC as long as your DNS server software supports it and most people don't run their own authorative DNS servers anyway.
Google flags Immich sites as dangerous
691–700 of 713 posts
Re: Google flags Immich sites as dangerous
#692Earlier quoted context omitted.
> They should be tied to cryptographic keypairs (client + server). So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link, for as long as the cookie lives (and users don't visit the website to get the rotated key). > If the web server needs a cookie, it should request one This adds a round-trip, which slows down the websi…
> So now, if a website leaks its private key, attackers can exfiltrate cookies from all of its users just by making them open an attacker-controlled link This attack already exists in several forms (leaking a TLS private key, DNS hijack, CA validation attack, etc). You could tack a DNS name onto the crypto-cookies if you wanted to, but DNS is trivial to attack. > This adds a round-trip, which slows down the website o…
> This attack already exists in several forms (leaking a TLS private key, DNS hijack, CA validation attack, etc).
An attacker who gets the TLS private key of a website can't use it easily, because they still need to fool users' browser into connecting to a server they control as the victim domain, which brings us to:
> You could tack a DNS name onto the crypto-cookies if you wanted to, but DNS is trivial to attack.
It's not. I can think of two ways to attack the DNS. Either 1. control or MITM of the victim's authoritative DNS server or 2. poison users' DNS cache.
Control/MITM of the authoritative server is not an option for everyone (only ISPs/backbone operators), and according to Cloudflare: "DNS poisoning attacks are not easy" (https://www.cloudflare.com/learning/dns/dns-cache-poisoning/)
> Requests are already slowed down by the gigantic amount of cookies constantly being pushed by default
Yes, although adding more data and adding a round-trip have different impacts (high-bandwidth high-latency connections exist). Lots of cookies and more round-trips is always worse than lots of cookies and a fewer round-trips.
> The server can send a reply-header once which will tell the client which URLs need cookies perpetually, and the client can store that and choose whether it sends the cookies repeatedly or just when requested.
Everyone hate configuring cache, so in most cases site operators will leave it to a default "send everything", and we're back to square one.
> No change is needed.
I was thinking that servers need to remember state between the initial client request and when the client sends an other request with the cookies. But on second thought that's indeed not necessary.
> So the engine of modern commerce is just a collection of easy hacks. Fantastic.
I'm afraid so
Re: Google flags Immich sites as dangerous
#693Earlier quoted context omitted.
Is the subdomain named immich or something more general?
The subdomain is "immich", which has crossed my mind as a potential flagging characteristic.
Thanks for the datapoint. I agree with sibling that it shouldn't be a problem, but am glad to discover from this thread that it may be.
Re: Google flags Immich sites as dangerous
#694Earlier quoted context omitted.
> They are directly calling you a scammer and "attacker". No they're not. The word "scammer" does not appear. They're saying attackers on the site and they use the word "might". This includes third-party hackers who have compromised the site. They never say the owner of the site is the attacker. I'm quite sure their lawyers have vetted the language very carefully.
You can’t possibly use the “they use the word ‘might’” argument and not mention the death red screen those words are printed over. If you are referring to abidance to the law, you are technically right. If we remove the human factor, you technically are.
> If you are referring to abidance to the law, you are technically right.
Yes, the question was literally about the law.
I wasn't trying to say anything else. I was answering the commenter's legal question.
I don't know what you are trying to imply.
Re: Google flags Immich sites as dangerous
#695Earlier quoted context omitted.
In the past, browsers used an algorithm which only denied setting wide-ranging cookies for top-level domains with no dots (e.g. com or org). However, this did not work for top-level domains where only third-level registrations are allowed (e.g. co.uk). In these cases, websites could set a cookie for .co.uk which would be passed onto every website registered under co.uk. Since there was and remains no algorithmic meth…
> Since there was and remains no algorithmic method of finding the highest level at which a domain may be registered for a particular top-level domain A centralized list like this not just for domains as a whole (e.g. co.uk) but also specific sites (e.g. s3-object-lambda.eu-west-1.amazonaws.com) is both kind of crazy in that the list will bloat a lot over the years, as well as a security risk for any platform that ne…
It looks like Mozilla does use DNS to verify requests to join the list, at least.
$ dig +short txt _psl.website.one @1.1.1.1
"https://github.com/publicsuffix/list/pull/2625"
Re: Google flags Immich sites as dangerous
#696Either they have an open redirect being misused, or their domains are being used to host phish content.
This is the way of things.
Re: Google flags Immich sites as dangerous
#697If you're going to host user content on subdomains, then you should probably have your site on the Public Suffix List https://publicsuffix.org/list/ . That should eventually make its way into various services so they know that a tainted subdomain doesn't taint the entire site....
They aren't hosting user content; it was their pull request preview domains that was triggering it. This is very clearly just bad code from Google.
Or anticompetitive behavior.
Re: Google flags Immich sites as dangerous
#698A class action lawsuit, charging anticompetitive behavior, on behalf of all Immich site operators could be a good idea here.
Of course Google will claim it's just a mistake, but large tech companies - including e.g. Microsoft - have indulged in such behavior before. A lawsuit will allow for discovery which can help settle the matter, and may also encourage Google to behave like a good citizen.
Re: Google flags Immich sites as dangerous
#699Earlier quoted context omitted.
Never heard of this. Link please?
Don't know about Honda, but there is this Mazda one [0] (Would not be surprised if it affected multiple vendors!) [0] https://www.soundandvision.com/content/remembering-time-when...
Yikes. I missed that. Makes sense it wasn't just the station it was tuned to but the particular data they broadcasted; insane there was no way to power reset the system into a good state.
Re: Google flags Immich sites as dangerous
#700Earlier quoted context omitted.
Last link the menu header: https://publicsuffix.org/submit/ Which then links to: https://github.com/publicsuffix/list/wiki/Guidelines#submitt... Fairly obvious and typical webpage > documentation flow I think, doesn't seem too hard to find.
Ok so we need a GitHub (Microsoft) account to avoid needing a Google account to in case some undocumented system decides to shut down a website we host. Great.
I agree, that's pretty dumb. But I wouldn't say "no easy way to add suffixes to the list" at the very least.