It is intentional. It's caused by `funnyButton` function which after beautifying looks like this.

            funnyButton() {
                document.addEventListener("mouseover", e => {
                    if (e.target.closest(".chefcookie__button--settings")) {
                        if (window.innerWidth < 1e3 || r.default.isTouch() || r.default.isMobile()) return;
                        if (!0 === this.funnyButtonStop || !0 === this.funnyButtonAnimation) return;
                        this.funnyButtonAnimation = !0;
                        let e = document.querySelector(".chefcookie__button--settings"),
                            t = parseInt(e.getAttribute("data-mode") || 1);
                        e.setAttribute("data-mode", t % 2 + 1), setTimeout(() => {
                            this.funnyButtonAnimation = !1
                        }, 550)
                    }
                }), document.addEventListener("click", e => {
                    e.target.closest(".chefcookie__button--settings") && (this.funnyButtonStop = !0)
                })
            }

Yes. You should be updating your web browser regularly, otherwise you will be affected by security vulnerabilities.

> PostgreSQL table and column names aren't case sensitive

They are case-sensitive. The thing is however that is that PostgreSQL will automatically lowercase names that aren't explicitly double quoted.

Filenames in HFS+ filesystem (an old filesystem used by Mac OS X) are normalized with a proprietary variant of NFD - this is a filesystem feature. APFS removed this feature.

By “proprietary variant” you mean “publicly documented variant” which IIRC is just the normalization tables frozen in time from an early version of Unicode (the idea being that updating your OS shouldn’t change the rules about what filenames are valid).

As for APFS, it ~~doesn’t~~didn’t normalize but I believe it still requires UTF-8. And the OS will normalize filenames at a higher level. EDIT: they added native normalization. At least for iOS, I didn’t dig enough to check it macOS is doing native normalizing or is just normalization-insensitive.

Normalisation is expressly done with the composition of version 3.1 for compatibility: see <https://www.unicode.org/reports/tr15/#Versioning>. IF that’s what HFS+ does, then “proprietary variant” is wrong. And if not, I’m curious what it does differently.

(On the use of version 3.1, note that in practice version 3.2 is used, correcting one typo: see <https://www.unicode.org/versions/corrigendum3.html>.)

I find a few references to it being slightly different, but not one of them actually says what’s different; Wikipedia is the only one with a citation (<https://en.wikipedia.org/wiki/HFS_Plus>: “and normalized to a form very nearly the same as Unicode Normalization Form D (NFD)[12]”), and that citation says it’s UAX #15 NFD, no deviations. One library that handles HFS+ differently switches to UCD 3.2.0 for HFS+ <https://github.com/ksze/filename-sanitizer/blob/e990e963dc5b...>, but my impression from UAX #15 is that this should be superfluous, not actually changing anything. (Why is UCD 3.2.0 still around there? Probably because IDNA 2003 needs it: <https://bugs.python.org/issue42157#msg379674>.)

Update: https://developer.apple.com/library/archive/technotes/tn/tn1... has actual technical information, but the table in question doesn’t show Unicode version changes like they claim it does, so I dunno. Looks like maybe from macOS 10.3 it’s exactly UAX #15, but 8.1–10.2 was a precursor? I’m fuzzy on where the normalisation actually happens, anyway.

The `filename-sanitizer` library you have linked has the following comment.

                # FIXME: improve HFS+ handling, because it does not use the standard NFD. It's
                # close, but it's not exactly the same thing.
                'hfs+': (255, 'characters', 'utf-16', 'NFD'),

I wonder what does that mean...

The technote linked by the parent has a note saying

> The characters with codes in the range u+2000 through u+2FFF are punctuation, symbols, dingbats, arrows, box drawing, etc. The u+24xx block, for example, has single characters for things like "(a)". The characters in this range are not fully decomposed; they are left unchanged in HFS Plus strings. This allows strings in Mac OS encodings to be converted to Unicode and back without loss of information. This is not unnatural since a user would not necessarily expect a dingbat "(a)" to be equivalent to the three character sequence "(", "a", ")" in a file name.

> The characters in the range u+F900 through u+FAFF are CJK compatibility ideographs, and are not decomposed in HFS Plus strings.

The bit about the u+24xx block is misleading, the decomposition of the characters I looked at there (such as ⒜) are compatibility canonicalizations. However the CJK compatibility ideographs is a working example. U+F902 (車) decomposes to U+8ECA (車) regardless of normalization form but the technote says these must not be decomposed.

ZFS can support normalization also:

    $ echo test > $'\xc3\xb6'
    $ cat $'\x6f\xcc\x88'
    cat: ö: No such file or directory

    $ zfs create -o normalization=formD pool/dataset
    $ echo test > $'\xc3\xb6'
    $ cat $'\x6f\xcc\x88'
    test

>APFS removed this feature.

And then brought it back. It normalizes now.

Out of curiosity, I decided to check your website with adblocker turned off. After rejecting (!) GDPR consent, the website decided to send my personal information to the following companies: Google, Facebook, Amazon, Ad Lightning, Setupad, UniConsent, Adagio, ID5, Criteo, Magnite, RTB House, Casale Media, EMX Digital, Adform, Pubmatic, Between Digital, Lijit Networks, AppNexus, 33Across, Adx Premium, Sharethrough, Smart Adserver, OpenX, BRealTime, bumlam.com (couldn't find information about owner of this domain), BidSwitch, Getintent, Yahoo, and more - at some point I gave up trying to figure out who owns given domain names.

The privacy policy which is quite hidden on the website (https://www.photopea.com/privacy.html) says nothing about that. All it says is the following:

> We use third party tracking tools to improve the performance and features of the Service (e.g. Google Analytics). Such tools are created and managed by parties outside our control. As such, we are not responsible for what information is actually captured by such third parties or how such third parties use and protect that information.

This won't fly under GDPR, just saying. Not only you are responsible for third party behavior, but you didn't even mention all tracking scripts that are directly used (I see Facebook Pixel Code right in the source code for photopea.com). You are in Czech Republic, right? I think it is in European Union.

I just checked the same thing. I didn’t get a consent banner at all, not sure why.

I’d just like to add that a decent chunk of the traffic to this site is from people typing “free photo editor” or things along those lines.

The creator of this site is specifically targeting people who want a free photo editor… And then complaining about people wanting to use it for free.

Are you in European Union? I imagine the consent banner may skipped when not in European Union.

I’m in the UK. So not anymore. But we still apply GDPR rules as far as I’m aware

GDPR still applies in the UK via their "equivalent" UK GDPR, as does the PECR (which is their implementation of the ePrivacy Directive, which covers cookies).

UK cookie law is pretty strict, and also pretty clear to read - https://ico.org.uk/for-organisations/guide-to-pecr/guidance-...

The issue is nobody bothers to follow it, and enforcement isn't likely enough, or crippling enough, to drive compliance.

And what exactly is "your personal information", that has been sent to so many websites?

That is what you should document on your privacy page, exactly.

If you know how the web works, you must know, that websites do not have access to your device. You do not tell Photopea your name or your address.

The only thing a website can know, is, that "someone with a screen resolution of 1920x1080 pixels visited www.Photopea.com at 18:37". It can be useful to know the number of visitors, or the usual screen resolutions.

> Google, Facebook, Amazon, Ad Lightning, Setupad, UniConsent, Adagio, ID5, Criteo, Magnite, RTB House, Casale Media, EMX Digital, Adform, Pubmatic, Between Digital, Lijit Networks, AppNexus, 33Across, Adx Premium, Sharethrough, Smart Adserver, OpenX, BRealTime, bumlam.com (couldn't find information about owner of this domain), BidSwitch, Getintent,

Which one of those do you need to know usual screen resolutions of users? Or maybe there are some other reasons those all get contacted?

(You also missed some "minor" details like IP addresses and fingerprinting profiles overall, and I'm honestly not sure if you are as ignorant as you act or just pretend to do so, and which one would be more offensive)

I do not know a lot about the ad mechanism, which my partners use. But it usually works by contacting several servers and asking them "hey, there is someone visiting www.Photopea.com, probably from Canada, with a screen resolution of 1920x1080 pixels, how much would you pay for showing them your ad?" ... there is an auction, and the ad from the highest bidder is shown to you. The more servers take part in the auction, the more money I can make.

Like really, if you open a website for the first time in your life, what kind of secret information could it know about you?

The trackers in your site use cookies, and browser fingerprinting to create a profile of the visitors to your site, which combined with other data on the visitors is used to identify them personally.

That on its own should give you pause. But that data is then used by companies like Facebook or Google to allow the highest bidder to alter that users behaviour - by getting them to believe some propaganda, to vote for a political party, or to spend money on something they don’t need.

That’s the business model. That is how you make money on your site.

There are other ways of making money – I’m sure that had ad revenue not been available you would have found a different way.

Browsers require certificates to be in Certificate Transparency logs. Therefore, a valid certificate would need to be submitted to CT logs, and a Certificate Authority found to generate certificates without permission would quickly find themselves removed out of browsers' trusted CA lists.

If I had to guess, they probably don't care about home usage of Hex-rays. Businesses have more to lose when using cracked versions of Hex-rays.

I disagree with you here. I live in Poland which has a very popular e-commerce website known as Allegro.pl - it's very similar to Amazon. It has its own version of Prime which is known as Allegro Smart which provides benefits such as free shipping and easy returns. A seller that wants to make their products have Smart badge don't have to use Allegro's own delivery method (Allegro One). The requirements for a Smart badge are as follows:

- have at least 5 positive reviews

- at least 98% rating (if their deliveries are slow, they shouldn't expect a high rating from customers)

- passing Allegro transaction identifier to a delivery service

- they have to provide at least one of the following parcel delivery services as a delivery method: Poczta Polska (which is owned by government), DPD or UPS

Amazon forces third-party sellers to use Fulfilment by Amazon in order to have Prime badge, something that a very similar service doesn't do.

Freedom of speech is not absolute in United States either, see https://www.uscourts.gov/about-federal-courts/educational-re....

Well, technically the rule only talks about entries that "fail to compile". An entry that still compiles is fine, see rule 12. In practice this means the Unicode abuse like this is only allowed in strings.

When the rule was originally introduced in 2001 [1] it was a total ban. It seems that the rule was slightly relaxed in 2013 [2], but I think it still massively discourages any octet >= 128 because there is no portable way to set the input encoding (like GCC `-finput-charset`, which is ignored by Clang AFAIK).

[1] https://www.ioccc.org/2001/rules

[2] https://www.ioccc.org/2013/rules.txt