Day 14 - #adventOfIOSAccessibility. iOS and Xcode provide a wide variety of tools and options to deal with color, and help us providing good color contrast ratios. From system colors that automatically support Increase Contrast, to high contrast (and light and dark mode) color asset variants, automatic checks with the Audit feature in the Accessibility Inspector, and even a built-in contrast calculator.
IDN, International Domain Names, is the concept that lets us register and use international characters in domain names, and by international we of course mean characters outside of the ASCII range.
IDN-based phishing is the reason I turned of punycode translation in Firefox. So, whenever I see a URL beginning with "xn--" I know this is most likely a phishing attempt.
And if one knows how domain names work, one also knows there mostly is a "replacement" for special non-ASCII characters (for example in German we replace "ä" with "ae" if necessary).
I see the use of curated library (white-list regexps, with some heuristics, perhaps context-aware) that can be shared among tools such as browsers or command-line tools, so that they refuse with a warning of a suspicious idn is used.
But I don't see the need to ban any 📯 emojis there.
If needed, the user shall of course be able to bypass such warning, but no short should be tolerated (--bypass-idn-check, not just -b).
it would be fair if you used for homographs examples domains, where registrars allow mixing of such letters. I am quite certain .com is not such domain, doubt .se also. Registrars are primary defense and on serious TLD you can get serious protection. I didn't know heterograph strangeness however. Interesting anyway. Thank you for it.
@pemensik Maybe, but TLDs can only ban them when used in the domain name. My examples show them used in the next level name, where they can be used fine even in .com etc. Besides, I'm explaining a concept and I trust the reader can transpose that to other domains if wanted.
Yes. I have tried few homographic letters mentioned. slash and fragment are refused by idn2 command, but homographic ? is not refused by tested libidn2. But it seems safe to scan hostname for non-ascii letters. If they appear, normalize displayed name by converting to punnycode and then decoding back again. Can help ridding of strange characters while keeping name presentable in foreign alphabets too. I thought iterpunction were generally forbidden in names.
The really sad part? All this complexity, all this surface area for nasty bugs, all these opportunities for social engineering.. and they don't even work for their intended purpose!! Earlier this year, I needed a new domain, with my last name in it — which contains an ø. I got one version with the "ø" and one with "o" instead just in case IDNs caused issues.
I've learned that virtually nothing supports IDNs. I've stopped using the "ø" version because "xn--blah-54a" showed up everywhere.
IDNs use IDNA not just punycode. While punycode is an algorithm that can encode any Unicode character into ASCII, IDNA adds further rules and hence not all characters can end up in a domain name. Plus registries add their rules. And ICANN for gTLDs (see SAC095 at itp.cdn.icann.org/en/files/sec…). So lots of attacks can't work as domains can't exist for real. Then, yes, you have the odd ones, allowing lots of things, like `.ws` TLD. I recommend this past presentation: i.blackhat.com/USA-19/Thursday…
For once, you write wrong things. Just one: the "crazy" example you show is disallowed since IDN does not allow many of these characters: afnic.fr/en/observatory-and-re…
Hello Windows Insiders,
Today we are beginning to gradually roll out the ability to seamlessly share files between your iPhone® and Windows 11 or Windows 10 PC when they are connected via Phone Link and the Link to Windows app.
To use this feature
The four most popular ways to use RDF-based metadata on websites are RDFa-Core, RDFa-Lite, Microdata, and inline JSON-LD.
I can’t use RDFa-Lite because I need rel HTML attributes. rel silently upgrades RDFa-Lite to RDFa-Core, which parses differently. I doubt all parsers upgrade correctly; some will try to parse RDFa-Core as RDFa-Lite. Conformant RDFa parsers upgrade RDFa-Lite pages to RDFa-Core despite many authors only being familiar with RDFa-Lite. I suppose resources like Schema.org and Google’s documentation only documenting RDFa-Lite markup worsens the confusion. Update 2024-12-16: Sarven Capadisli has clarified on the Fediverse that this is the behavior of one faulty parser; rel only triggers an upgrade when used with an RDFa namespace. I may re-evaluate RDFa.
With RDFa split between two incompatible alternatives with a confusing upgrade mechanism, the alternatives are Microdata and JSON-LD. I use structured data extensively; JSON-LD would duplicate most of the page. Let’s use this relatively short article as an example. Exruct can convert the embedded Microdata into a massive JSON document featuring JSON-LD. Take a look at the JSON-LD and HTML side by side. Microdata attributes take a fraction of the footprint, encode the same information, and don’t require duplicating nearly the entire page.
* all human-readable information is visible and actionable in markup languages (HTML, SVG, MathML..) * anything significant has a URI and machine-readable.
For my purposes, publishing various types of content and working on an application ( dokie.li/ ) - it comes down to using the full expressivity of #RDFa.
Hope I understood you correctly; not trying to change your mind:
Unless you've already checked w/ other #RDFa parsers, I wouldn't rely on GRRT (referenced blog post). AFAICT, GRRT wasn't parsing the HTML snippet correctly back then nor now for that HTML snippet.
If you don't use the `vocab` attribute, values like `license` are ignored by the RDFa parser (unless host language's default vocab is applied). For anything else parsing plain ol' rel=license, that's not an issue anyway.
Update 2024-12-16: @csarven has clarified on the Fediverse that I described the behavior of one faulty parser; rel only triggers an upgrade when used with an RDFa namespace. I may re-evaluate RDFa.
We're very disappointed Let's Encrypt is ending support for proper revocation checks via OCSP Must-Staple which is the only efficient, private and secure method not depending on a browser-specific service:
Earlier this year we announced our intent to provide certificate revocation information exclusively via Certificate Revocation Lists (CRLs), ending support for providing certificate revocation information via the Online Certificate Status Protocol (O…
The built-in nginx support for OCSP stapling doesn't have a way to properly save the last valid result and reuse it but nginx fully supports handling it via an external service. We use github.com/tomwassenberg/certb… for reliable OCSP stapling and it has always worked very well for us.
A tool that primes the OCSP cache of nginx for certificates managed by Certbot, in order to make OCSP stapling work reliably. - tomwassenberg/certbot-ocsp-fetcher
Short-lived certificates are officially defined as having a 7 day or lower lifetime. It would be a good replacement for OCSP Must-Staple not requiring any client/server support. Let's Encrypt doesn't support short-lived certificates and hasn't announced any plans for adding them.
I think the ideal solution would be replacing live lookups with CRL shards, and preserving must-staple until either OS-level CRLite- or Let’s Revoke- like filters roll out or until short-lived certs become available.
But I understand the decision. A fraction of a percent of websites have must-staple, an even smaller fraction use a good implementation like ocsp-fetcher or caddy, and a small fraction of traffic is from a browser that does OCSP stapling properly. The massive amount of engineering effort for the tiny gain isn’t something they can justify.
I’m disappointed that they probably won’t go with ACME-STAR, which is the most robust option I looked at in that post (especially when combined with delegated credentials).
Check out this great listen on Audible.com. From the Booker Prize finalist, author of The Island of Missing Trees, an enchanting new tale about three characters living along two great rivers, all connected by a single drop of water.
New York Times has run FOUR op-eds in the last 2 days mouthpiecing woe-is-me sympathy for UnitedHealthcare and scolding the public for not performing solemnity. They have spoken to zero families bankrupted by UHC's avaricious chasing of profit at any cost. Manufactured consent in action. Offensive.
Jeseň ubehla rýchlejšie než som plánoval, ale to nie je to podstatné, čo som chcel povedať. Dosť som totiž uvažoval, ako poňať pokračovanie môjho predchádzajúceho blogu, a teda ako by mala vyzerať lekcia 2. Nakoniec som sa rozhodol nenosiť drevo do lesa a prichádzam iba s prekladom článku z eff.org - How to: Understand and Circumvent Network Censorship licencovaného pod otvorenou licenciou CC-BY takže to čo teraz budete čítať, nie je moje dielo, iba môj pokus o preklad.
My partner and I first broached the possibility that we might need to flee the country last summer. After election day, we began that preparation in earnest. I’m making the document we used t…
"Ein juristisches Gutachten klärt, in welchen Fällen digitale Dienstleistungen auch analog angeboten werden müssen. Es kommt zu dem Schluss, dass ein Verbot von #Digitalzwang ins #Grundgesetz gehört."
Ein juristisches Gutachten klärt, in welchen Fällen digitale Dienstleistungen auch analog angeboten werden müssen. Es kommt zu dem Schluss, dass ein Verbot von Digitalzwang ins Grundgesetz gehört.
The FBI encouraging citizens to use E2EE, yet another massive Synapse Admin Update, and a schedule for FOSDEM. That and much more happened This Week in Matrix!
Ozzelot
in reply to Archos • • •Archos
in reply to Ozzelot • • •Archos
Unknown parent • • •Archos
in reply to Archos • • •PepikHipik
in reply to Archos • • •Archos
in reply to PepikHipik • • •Dědek FraZi
in reply to Archos • • •Kateřina
in reply to Archos • • •Archos
in reply to Kateřina • • •Kateřina
in reply to Archos • • •Archos
in reply to Kateřina • • •Kateřina
in reply to Archos • • •Archos
in reply to Kateřina • • •