Conversation

Notices

1. r (r@freesoftwareextremist.com)'s status on Tuesday, 17-Oct-2023 01:20:09 JST r

   • 
   • ロミンちゃん
   @mint @romin
   https://git.freesoftwareextremist.com/bloat/commit/?id=67b13c71baea56eeb15532ca1b1377f6da8d18ac
   •  likes this.
   •  (mint@ryona.agency)'s status on Tuesday, 17-Oct-2023 01:21:32 JST 

     in reply to

     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @r @romin Nice. I'm applying mine via nginx already, but it should come handly regardless. @p
   • r (r@freesoftwareextremist.com)'s status on Tuesday, 17-Oct-2023 01:27:14 JST r

     in reply to

     • 
     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @mint @p @romin Yeah, the only interesting part here is that it also allows custom CSS.
      likes this.
   •  (mint@ryona.agency)'s status on Tuesday, 17-Oct-2023 01:50:55 JST 

     in reply to

     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @romin @r @p Add the proxy_hide_header directive to brush off concerns and leave only the directive from webserver proper.
   • ロミンちゃん (romin@shitposter.club)'s status on Tuesday, 17-Oct-2023 01:50:56 JST ロミンちゃん

     in reply to

     • 
     • pistolero :thispersondoesnotexist:
     @r @p @mint what happens if you already had set a csp header on the reverse proxy? How does the browser behave with the two headers?
   • r (r@freesoftwareextremist.com)'s status on Tuesday, 17-Oct-2023 02:10:18 JST r

     in reply to

     • 
     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @romin @p @mint
     https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#multiple_content_security_policies
      likes this.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Tuesday, 17-Oct-2023 13:06:56 JST pistolero :thispersondoesnotexist:

     in reply to

     • 
     • ロミンちゃん
     @mint @r @romin Seems like it'd be easier to just serve up the custom CSS from its own endpoint and then disable all inline CSS.
      likes this.
   •  (mint@ryona.agency)'s status on Tuesday, 17-Oct-2023 13:06:56 JST 

     in reply to

     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @p @r @romin Eh, adding custom CSS box to begin with is bloat. Use Stylus or something. Regardless, r's patch makes it work.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Tuesday, 17-Oct-2023 13:49:33 JST pistolero :thispersondoesnotexist:

     in reply to

     • 
     • ロミンちゃん
     @mint @r @romin I ended up using nonces so that the custom CSS wasn't further special-cased. Threading it might be ugly and shoving it in the HTML might be unappealing so doing the SHA might be preferable; your mileage may vary. https://git.freespeechextremist.com/gitweb/?p=bloat;a=commitdiff;h=29c6be06340b6c62e381199e94bd92593c74ba12
      likes this.
   •  (mint@ryona.agency)'s status on Tuesday, 17-Oct-2023 13:50:05 JST 

     in reply to

     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @p @r @romin The path of least resistance would've probably been the make a special endpoint that just returns the user's CSS and whitelist it together with the only other CSS file used by bloat.
   • r (r@freesoftwareextremist.com)'s status on Tuesday, 17-Oct-2023 14:24:46 JST r

     in reply to

     • 
     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @mint @p @romin That'd mean an extra roundtrip for the data that was already there when the page was rendered. And then, you'd have to add Cache-Control header to explicitly allow caching.
      likes this.
   • r (r@freesoftwareextremist.com)'s status on Tuesday, 17-Oct-2023 14:25:39 JST r

     in reply to

     • 
     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @p @mint @romin Yeah, that works too. I was just going to ask why you added unsafe-inline and then saw the other commit.
      likes this.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Tuesday, 17-Oct-2023 16:34:23 JST pistolero :thispersondoesnotexist:

     in reply to

     • 
     • ロミンちゃん
     @mint @r @romin
     
     > Use Stylus or something.
     
     That sounds like a browser extension and all of those, 100% of them, either suck or rely on an API that Mozilla will deprecate in the next version. Plus I'm using Seamonkey or mothra 90% of the time anyway.
     
     (I should probably switch to lanodan's browser; I haven't tried it because every new Mozilla situation is a new hell.)
      likes this.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Tuesday, 17-Oct-2023 17:24:51 JST pistolero :thispersondoesnotexist:

     in reply to

     • 
     • ロミンちゃん
     @r @mint @romin I removed it for exactly that reason. It makes me feel uneasy and it's not really needed.
      likes this.
   • pistolero :thispersondoesnotexist: (p@freespeechextremist.com)'s status on Tuesday, 17-Oct-2023 17:25:59 JST pistolero :thispersondoesnotexist:

     in reply to

     • 
     • ロミンちゃん
     @r @mint @romin
     
     > That'd mean an extra roundtrip for the data that was already there when the page was rendered.
     
     I mean, if it is cached, that's effectively one round-trip per session.
      likes this.
   • r (r@freesoftwareextremist.com)'s status on Tuesday, 17-Oct-2023 18:39:44 JST r

     in reply to

     • 
     • pistolero :thispersondoesnotexist:
     • ロミンちゃん
     @p @mint @romin Oh, I meant to say explicit caching and cache invalidation. Invalidation would require generating some unique value on changing the custom CSS and then passing it in the CSS URL or something.
     The hash based or nonce based approach is a bit more simple I'd say.
      likes this.