> My guess is that OP's browser is getting banned because his WebKitGTK has a weird fingerprint, not because of webgl or whatever.
So why is Cloudflare saying the author got blocked because of WebGL?
> > Such things are blocked in WebKit, and have been for years. Meaning it's tracking so awful that even Apple would block it, and as far as I can tell it's not the kind of privacy protection you can easily disable in it.
> This is also false. Webgl fingerprinting works just fine on Safari. They might try to mitigate it by adding some noise, but that's not so different than what firefox does, and is certainly not "blocked".
> Plenty of internal-only systems are not locked down securely and only thing preventing mass exploitation is browsers CORS settings.
CORS has no relation to this issue. Cross-origin means there are at least two origins, but in this case there is only one (where you're trying to navigate).
> But if request is originating from inside the network (as it would from a terminal emulator)
Why would the terminal make requests? Obviously it will dispatch the link to another program specialized in making requests to a protocol, like... a browser?
> Granted, on its own, this should be safe. But attacks are usually composed from multiple bugs and/or weaknesses in design. Hence why security folk keep talking about “defence in depth”
Every feature can be part of an exploit chain, but the "clicking a URL will always lead to the text it is under" ship has sailed 30+ years ago. If your system cannot safely handle this operation then you're in deep trouble, and I don't see how crippling every program in existence is the right solution to that.
> I actually voiced some concerns with this original hyperlink proposal several years back. In fact lots of developers and security researchers did.
Based on what you've written: you and other self-claimed "security researchers" started spamming this spec with concern trolling about hypothetical (non-existent) "security issues", then the author finally got tired and locked down comments, which were obviously intended for people interested in the feature, not those trying to sabotage it.
> Just one persons mission to dictate how everyone else’s terminal, and security model, should operate.
Nowhere does the proposal say that your terminal has to implement this. Indeed, if you have a working ANSI parser the escape sequence is ignored automatically (as the spec also explains).
Have you considered that the person trying to dictate how others' terminals should operate might be you?
Validation errors aren't really "exceptions" to be thrown, they are indicators for authors that something is probably wrong but they make no visible difference in the output. I'm not sure if any browser even tracks them (and if one did, the best it could do is complain in the dev tools).
Also, this is not limited to HREF, it's defined in URL[0] so you can also put newlines in new URL("...") etc.
The greatest mistake IMO is the way float state leaks out of blocks, as this
is both extremely unintuitive and undesirable for performance reasons.[1]
Floats should've been restricted to inline formatting contexts, with all
in-flow blocks behaving as if they had `clear: both' set.
I also don't understand why they never specced the (much simpler)
`text-align: -moz-left/-moz-right/-moz-center' which already had precedent
in HTML with `<div align=left/right/center>'. It's the saddest part of the
"center a div" saga, all the W3C had to do to fix it is to assign a standard
keyword to a feature that everybody already implemented, but to this day
it still hasn't happened.[2]
[2]: After many long decades, they did finally specify block-level
`justify-items'. Two problems: a) it's backwards-incompatible with
text-align, b) it still doesn't work in Gecko.
I actually wonder if transpiling calc/min/max/etc. expressions to JS is a viable path to implementation, considering that you already need a fast interpreter for these.
Markdown is a superset of HTML, so your assertion cannot be true. But even an HTML-less subset is very hard to parse efficiently (or, at all) because of the various grammatical ambiguities. And then there's the various competing definitions...
> 1) pledge() lets you give high level "I just want to do I/O on what I
already have", and it doesn't matter if new syscalls "openat2" (should be
blocked) or "getrandom" (should be allowed) are created. (see the
`newfstatat` example on printf).
You can do this with seccomp if you're libc. A new syscall is of no
consequence for the seccomp filter unless libc starts using it, in which
case libc can just add it to the filter. (Of course the filter has to be an
allow-list.)
> And 2) OpenBSD limits syscalls to be done from libc, and libc & kernel are
released together. Other libs need to go through libc.
That avoids one failure mode, but I think you assign too much importance to
it. If your dependency uses a raw syscall (and let's be honest this isn't
that common), you'll see your program SIGSYS and add it manually.
If you have so many constantly changing dependencies that you can't
tell/test which ones use raw syscalls and when, you have no hope of
successfully using pledge either.
> But I don't think that we need to throw out the baby with that bathwater.
We agree here, just not on which baby :)
> And it's not just about libfoo doing raw syscalls. `unveil()` allows
blocking off the filesystem.
You're right, seccomp is unsuitable for implementing unveil because it can't
inspect contents of pointers. I believe Cosmopolitan uses Landlock for it.
> Though another problem is that it doesn't help child processes with a
statically compiled newer libc
If you're trying to pledge a program written by somebody else, expect
problems on OBSD too because pledge was not designed for that. (It can work
in many cases, but that's kind of incidental.)
If it's your own program, fine, but that means you're compiling your binaries
with different libcs and then wat.
> So yeah, because they mandate syscalls from libc, ironically OpenBSD
should have been able to make pledge/unveil a libc feature using a
seccomp-like API, or hell, implemented entirely in user space. But Linux,
which has that API, kinda can't.
My take is "it can, with caveats that don't matter in 99% the cases pledge
is useful in." (Entirely in user space no, with seccomp yes.)
> So even if one uses Cosmopolitan libc, if you link to some other library
that library may also do direct syscalls. And which syscalls is does, and
under which circumstances, is generally not part of the ABI promise. So this
can still break between semver patch version upgrades.
Well but isn't that a more general problem with pledge? I can link to
libfoo, drop rpath privileges, and it'll work fine until libfoo starts
lazily loading /etc/fooconf (etc.)
A nice thing about pledge is that it's modularized well enough so such
problems don't occur very often, but I'd argue it's not less common of an
issue than "libfoo started doing raw syscalls." The solution is also the
same: a) ask libfoo not to do it, or b) isolate libfoo in an auxiliary
process, or c) switch to libbar.
> And at the very least you'll also be linking to libseccomp. :-)
libseccomp proponents won't tell you this, but you can in fact use seccomp
without libseccomp, as does Cosmopolitan libc. All libseccomp does is
abstract away CPU architecture differences, which a libc already has to do
by itself anyway.
I've just tried and when I open a bunch of new tabs, Firefox truncates the
"new tab" text to "new" and a Firefox logo. Same thing happens with other
titles.
(Then at some point it stops truncating and scrolls off the screen.)
Popular browsers support tabs. When you have many tabs open, it's hard to
show a meaningful title for each one. An icon takes up less place and is
easier to scan for visually.
It's barely usable by itself but I don't think it's an inherent problem of
seccomp-bpf, rather the lack of libc support. Surely the task of "determine
which syscalls are used for feature X" belongs in the software that decides which
syscalls to use for feature X.
So why is Cloudflare saying the author got blocked because of WebGL?
> > Such things are blocked in WebKit, and have been for years. Meaning it's tracking so awful that even Apple would block it, and as far as I can tell it's not the kind of privacy protection you can easily disable in it.
> This is also false. Webgl fingerprinting works just fine on Safari. They might try to mitigate it by adding some noise, but that's not so different than what firefox does, and is certainly not "blocked".
While I don't have an iDevice to try, the assumption that they are special cased is fair... because they are: https://blog.cloudflare.com/eliminating-captchas-on-iphones-...
(Yes, this is basically WEI in a shinier package.)