/s4s/ - anime pillow fight

>>21916 (OP) 
How to do this?

>>21916 (OP) 
>Disable webp in your browser
Why?

>>21948
Depends on what your browsers config is but there should be something like about:config with flags where you can find image.webp.enabled or the like and set it to false.
If you're building your own you can just not enable the use flag generally.
>>21951
They suck
Websites have stopped serving png over webpsunless your browser is flagged as not accepting webp
There are no good webp libraries so it's a massive point of insecurity
Compare/contrast svg, which is disabled by default in most 'secure' browsers already (and webp support is just not even built in) because even though that format serves a purpose unlike webp, it's also insecure.

Webps are basically strictly inferior to pngs though.

>>21956
the reason svgs can be insecure is because they're xml based and they can contain arbitrary code which obviously doesn't apply to a raster image format like webp 

>Webps are basically strictly inferior to pngs though.

in what way? webp supports both lossless and lossy compression and it's better  at it  than png/jpeg

>>21956
I tried it already in librewolf and it didn't work;_;

694637.jpg
[Hide] (476.8KB, 896x1152)

>>21957
>the reason svgs can be insecure is because they're xml based
That has literally nothing to do with anything
>they're xml based and they can contain arbitrary code which obviously doesn't apply to a raster image format like webp 
You can stick arbitrary code into any format, you just need to exploit whatever is interpreting it to run your code. There have been multiple major webp vulnerabilities.
>in what way? webp supports both lossless and lossy compression and it's better  at it  than png/jpeg
Webp's implementation of the same compression as png is just slower, with no benefit. Webp's implementation of other encodings is slower than just compressing the bitmap directly, and obviously it's lacking most formats anyway. Webp is so slow, infact, that many sites are losing space by using webp because they cache thumbnails when they used to generate them and benchmarks usually show that downloading and opening a png is faster than downloading and opening a webp even on throttled networks like tor. It's hard to imagine a situation where you'd actually care about stronger compression than png where you'd also download the image outside of an archive anyway.
As to lossy compression, yes, the existing formats are all terrible (webp isn't much better). Animation has better options in webm than in webp, and lossy image compression outside of animation is practiced almost exclusively out of ignorance (where it's still going to be jpg regardless) these days.
Have some slop, because it's all you deserve (and look at that! Even people who are generating GBs of images daily don't use webp).
>>21960
Looks like zoomer firefox has removed the pref. You should be on an ESR fork rather than something that's tracking main anyway.
I guess you've got till ESR hits the 120s to find a working browser instead
You can still set image.http.accept to
*/*
To request that sites don't send you webp but your browser will attempt to decode any that it does receive. I tried it in librewolf and this is respected at least by most wikis

neuro-sama_makeup.png
[Hide] (2.5MB, 2500x3200)

All webp garbage is being pushed to you by cloudflare CDNs when they see your chrome user-agent and send you a .webp even if you asked for .png, the only way to avoid this is to use a user-agent spoofer and pretend your browser is Microsoft Edge on a windows machine because for some reason Edge doesn't support .webp so it'll never serve them to you.

i think it took me like 10 tries to save this image as a .png from reddit because it kept shoving a crushed tiny .webp at me.

webp.webp
[Hide] (2.3MB, 2500x3200)

>>21961
how does code being able to be directly parsed from the file instead of relying on an underlying library  vulnerability that was patched isn't the main thing that makes svg potentially insecure 

>Webp's implementation of the same compression as png is just slower, with no benefit. 

but webp is smaller while still being lossless, idk about your other points but somehow i don't think it would see such a wide adoption you claim it has if it didn't actually work as advertised

>>21968
webp sucks forever because you can NEVER tell if it's a lossless webp or not, and which do you think CDNs are gonna use?
it's sure as fuck not gonna be the lossless setting that's only marginally smaller than the format they're trying to get rid of

spoonfeeding.png
[Hide] (82.1KB, 435x450)

>>21968
>how does code being able to be directly parsed from the file instead of relying on an underlying library  vulnerability that was patched isn't the main thing that makes svg potentially insecure 
You wanna try that again?
>how does code being able to be directly parsed from the file instead of relying on an underlying library  vulnerability
The only difference between running machine code out of a file in an exploited program and running malicious script in an exploited interpreter is interoperability. Given that there's only really one webp library it really makes no difference. Almost all of the attacks on svg that aren't library vulnerabilities of the same sort as webp (e.g. the 2.40.20 -> 2.40.21 fixes) just cause a crash with no further consequence anyway.
In any case both libraries are insecure. You shouldn't download and open either unless you're pulling something out of a known-trusted source, and I can't imagine when you ever would want to.
>i don't think it would see such a wide adoption you claim it has
I literally never claimed this. I strongly implied the direct opposite and made no claims besides that 'many sites' use webp, which is not a comment on the proportion of sites that do.
>but webp is smaller while still being lossless
Again, it literally is not. A similarly archived bitmap is smaller.
>idk about your other points but somehow i don't think it would see such a wide adoption you claim it has if it didn't actually work as advertised
Webp has basically zero adoption. There are non-profit sites that have ideological 'nu thing good' design philosophies, but they're the minority. Every other use of webp I've seen is some out of the box webtrash that a pajeet set up. Even gnome doesn't use webp and they have a rust dependency for svg for fucking icons.
>>21967
>All webp garbage is being pushed to you by cloudflare CDNs when they see your chrome user-agent and send you a .webp even if you asked for .png, the only way to avoid this is to use a user-agent spoofer and pretend your browser is Microsoft Edge on a windows machine because for some reason Edge doesn't support .webp so it'll never serve them to you.
The minimal useragent of legacy firefox also works. It's a smaller bucket but it's also probably not a bucket that instantly excludes you in trivially detectable ways.
It's kind of odd that fingerprint is such a real and easily accessible attack vector that people worry about but despite that literally none of the attempted solutions work at all I've never heard of it ever being used as an attack.

>when you ever would want to.
when you ever would want to either.

I can imagine grabbing people's icons, especially since media usually has permissive licenses rather than copyleft

>>21969
apparently you can check if an image is lossy or lossless but yeah not at glance like you can do with pngs 

>>21971
>A similarly archived bitmap is smaller

i don't follow, what do you exactly mean by this?

elgoog.png
[Hide] (33.7KB, 558x364)

>>21973
>i don't follow, what do you exactly mean by this?
If you want me to download a 2GB image or 2GBs worth of images, the best way to do so is to archive the uncompressed images, compress them with lzma or the like, and send me that to decompress on my end.
Here's a compare/contrast straight from the horse's mouth (zopfli/brotli inventor's paper, the same guy responsible for adding the lossless option to webp). The default webp lossless compression is zopfli; as of today, gimp only supports exporting webp with this (zopfli). Note that this is a heavily cherry picked comparison (the paper is essentially a brotli advertisement): these are the scores on an english language text file, which the google compression algorithms are written against. PNGs score close to what bzip2 does here on images because they use a predictive sorting method before deflate, such that the default compression level of every png from this side of 2010 (before the conception of lossless webp, mind you) literally outcompetes the lossless webp format in every regard. The only time lossless webp was shown to 'beat' png compression was when the author cherrypicked 40+ year old pngs with minimum compression and even then it was like 23% or something. Lossless webps are roughly comparable to 50 year old compression formats but take literally at least 30 times longer to create.

>apparently you can check if an image is lossy or lossless but yeah not at glance
>>21969
>webp sucks forever because you can NEVER tell if it's a lossless webp or not, and which do you think CDNs are gonna use?
>it's sure as fuck not gonna be the lossless setting that's only marginally smaller than the format they're trying to get rid of
>the format they're trying to get rid of
webp is a replacement format for jpg. It's a lossy format. Lossless webps are literally the volunteer project of one indian working at google (who, as far as I can tell, isn't responsible for anything to do with compression or cryptography that google actually uses or cares about). There is no attempt to get rid of png and there never has been. If at some point people actually have a problem with them (say, an unforeseen massive increase in media production due to the rise of AI slop) someone competant will write a better format.
The implementation and use of webp on the internet is all wrong anyway, I imagine because nu = betterer fags combined with the misconception that it's a png replacement. The idea was that people would stop making new jpgs, and the fucking retards that run wikis used jpgs as thumbnails instead of just serving the fucking png. Now these samre retards (through no fault of google, to be honest) have created a problem where one no longer existed by continuing to fail to serve the png (which is smaller than the fullscale webp anyway) while also storing both the full scale webm and png (which is obviously larger than either). The original motivation was that the network was too slow to serve the full image and storing a loseless thumbnail used up too much valuable space but neither is a concern and the current practice violates both principles. Just serve the fucking png. There isn't an alternative, because there doesn't need to be one. There is no demand.
As a jpg replacement it's a non-sequitur. Nobody should be making new jpgs, but they do, so we pass around the jpg 'as is' because it is literally a lossless format in that circumstance; the jpg is "the original" because the genuine raw doesn't fucking exist, the artist never uploaded it they probably never even saved it. The genuine raw is probably a fucking project file for clip studio or krita or whatever and we sure as fuck don't see that on their pixiv or twitter. The wikis and the like have no excuse for making jpg thumbnails. Just serve the image, or if it's a supermassive image, serve a png thumbnail that's to-scale with it's presentation on the page. This shit ain't rocket science.

>>21961
Thanks for the webp tricke! 
I'm not too up to date on this. What's the downside to using a browser that tracks main? What browser do you use?

693362.jpg
[Hide] (603.2KB, 1682x2914)

>>21996
>I'm not too up to date on this. What's the downside to using a browser that tracks main?
You get (non-security) updates faster. As an end user that's about it. I mean, if you're using librewolf obviously you've got a problem with many of the recent firefox updates so that seems like it's reason enough.
As a developer having less stable versions to work on and getting a constant stream of other people's patches (that may be to things you've changed) adds a lot of overhead to maintaining your fork. I don't know how librewolf functions (is it just a patchset that gets applied ontop of firefox?) but I can't imagine that there are substantial changes from firefox if a small team is keeping it up to date with current firefox rather than ESR. It takes the TBB team weeks to catch up to new ESR major versions and that's one of the best funded cryptography projects in the world with several people who work on TBB as a full time job.
>What browser do you use?
I'm definitely not following best practices.
For lazily using sites like this I mostly use the tor browser bundle binary (which is a firefox ESR fork, essentially).
For sites where I'm enabling javascript or sharing my public identity (ecommerce, package tracking sites, banks, etc.) I used to use firefox ESR (built locally, this was pre-rust) and currently am using the mullvad browser binary (which is a TBB fork, with fairly minimal changes i.e. it's still basically firefox ESR). At some point I'm going to have to bite the bullet and switch to something functional but it's not obvious to me that there is anything. With regards to teh future, the fingerprinting protection on TBB/MVB is a total meme and not worth anything so it's not like rolling my own whatever would be an issue from that perspective, but it's not like I can trivially write a patchset to revert the webp changes etc. without installing librsvg, and stripping modern gtk out of it would be a collossal task.
For actual serious business like downloading packages I just use either "links" or wget (and curl as appropriate). This is a minority of cases though.
>>21975
Should mention:
Compare/contrast the adoption of webm to webp. People actually wanted webm and it started getting used by programmers and nerds on image boards more than half a decade before the sites that people are jumping through hoops to avoid webps from started adopting it (webm) because actual human beings have an actual use for webm.

>every image I have that starts with 693, regardless of the ID system used, is a solo pic of anzu
heh

>>22002
>You get (non-security) updates faster.
It's marginal but worth mentioning that this is, itself, a security issue (attacks on new features are usually discovered and deployed when it hits main, not written against the experimental builds; by the time the features hit ESR they've already been patched for whatever attacks were found in the interim).