bwindels

Hypocrisy is not something our governments are immune from, and the words of commissioner Johansson are not encouraging:

> She wants tech companies to face mandatory detecting and reporting obligations

> “The problem is that many of these communications are now being end-to-end encrypted,” she said, whereby only the users exchanging messages have access to the content.

> While encryption is "really important," she said, "we don't want pedophiles to be able to do whatever they want, to not be seen, we have to protect [children] so this is not an easy challenge to tackle.”

https://www.politico.eu/article/encryption-could-hinder-chil...

As long as politicians pretend that you can have both I'll assume they are either disingenuous or ignorant and I won't be at ease.

Up to people who do understand it to expose the ones voting for it.

do you have a source for this?

Is this the correct list? The document at https://www.europarl.europa.eu/doceo/document/PV-9-2021-07-0... seems to list votes for multiple proposals. AFAICT, the voting list for this proposal starts on page 5:

Use of technologies for the processing of data for the purpose of combating online child sexual abuse (temporary derogation from Directive 2002/58/EC)

In favour:

ECR: Aguilar, Berg, Berlato, Bielan, Bourgeois, Brudziński, Buxadé Villalba, Czarnecki, de la Pisa Carrión, Dzhambazki, Fidanza, Fiocchi, Fitto, Fotyga, Fragkos, Ilčić, Jaki, Jurgiel, Jurzyca, Kanko, Karski, Kempa, Kloc, Kopcińska, Krasnodębski, Kruk, Kuźmiuk, Legutko, Lundgren, Mazurek, Melbārde, Milazzo, Możdżanowska, Poręba, Procaccini, Rafalska, Ruissen, Rzońca, Saryusz-Wolski, Slabakov, Sofo, Stancanelli, Stegrud, Szydło, Tarczyński, Tertsch, Tobiszowski, Tomaševski, Tošenovský, Van Overtveldt, Vondra, Vrecionová, Waszczykowski, Weimers, Wiśniewska, Zahradil, Zalewska, Zīle, Złotowski

ID: Adinolfi Matteo, Androuët, Annemans, Baldassarre, Bardella, Basso, Bay, Beigneux, Bilde, Bizzotto, Bonfrisco, Borchia, Bruna, Campomenosi, Casanova, Ceccardi, Ciocca, Collard, Conte, Da Re, David, De Man, Dreosto, Gancia, Garraud, Grant, Griset, Hakkarainen, Huhtasaari, Jamet, Joron, Juvin, Kofod, Lacapelle, Lancini, Laporte, Lebreton, Lechanteux, Lizzi, Madison, Mariani, Mélin, Olivier, Panza, Pirbakas, Rinaldi, Rivière, Rougé, Sardone, Tardino, Tovaglieri, Vandendriessche, Zambelli, Zanni

NI: Beghin, Bocskor, Castaldo, Deli, Deutsch, Ferrara, Furore, Gál, Gemma, Giarrusso, Gyöngyösi, Győri, Gyürk, Hidvéghi, Járóka, Kolakušić, Kósa, Lagos, Pignedoli, Regimenti, Rondinelli, Schaller-Baross, Tóth, Trócsányi, Uspaskich, Vuolo

PPE: Adamowicz, Ademov, Adinolfi Isabella, Alexandrov Yordanov, Amaro, Arias Echeverría, Arimont, Arłukowicz, Asimakopoulou, Băsescu, Bellamy, Benjumea Benjumea, Bentele, Berendsen, Berger, Berlusconi, Bernhuber, Bilčík, Blaga, Bogdan, Bogovič, Buda, Buşoi, Caroppo, Carvalho, Casa, Caspary, del Castillo Vera, Christoforou, Clune, Colin-Oesterlé, van Dalen, Danjean, De Meo, Didier, Doleschal, Dorfmann, Duda, Düpont, Ehler, Estaràs Ferragut, Evren, Falcă, Ferber, Fernandes, Fitzgerald, Fourlas, Frankowski, Gahler, García-Margallo y Marfil, Geuking, Gieseke, Glavak, González Pons, Halicki, Hansen, Hava, Herbst, Hetman, Hohlmeier, Hölvényi, Hortefeux, Hübner, Jahr, Jarubas, Juknevičienė, Kalinowski, Kalniete, Kanev, Karas, Kefalogiannis, Kelly, Kopacz, Kovatchev, Kubilius, Kympouropoulos, Kyrtsos, de Lange, Lega, Lenaers, Lewandowski, Lexmann, Liese, Lins, López Gil, López-Istúriz White, Łukacijewska, Lutgen, McAllister, Maldeikienė, Manders, Mandl, Marinescu, Markey, Martusciello, Mato, Maydell, Mažylis, Meimarakis, Melo, Metsola, Millán Mon, Monteiro de Aguiar, Montserrat, Morano, Mortler, Motreanu, Mureşan, Niebler, Niedermayer, Nistor, Novak, Novakov, Ochojska, Olbrycht, Patriciello, Pereira Lídia, Pieper, Pietikäinen, Polčák, Polfjärd, Pollák, Pospíšil, Radev, Radtke, Rangel, Ressler, Sagartz, Salini, Sander, Sarvamaa, Schmiedtbauer, Schneider, Schreijer-Pierik, Schulze, Schwab, Seekatz, Sikorski, Simon, Skyttedal, Šojdrová, Sokol, Spyraki, Štefanec, Tajani, Terras, Thaler, Thun und Hohenstein, Tobé, Tomac, Tomc, Vaidere, Vandenkendelaere, Verheyen, Vincze, Virkkunen, Voss, Vozemberg-Vrionidi, Walsh, Walsmann, Warborn, Weber, Weiss, Wieland, Wiezik, Winkler, Winzig, Wiseler-Lima, Zagorakis, Zarzalejos, Zdechovský, Zoido Álvarez, Zovko, Zver

Renew: Alieva-Veli, Al-Sahlani, Andrews, Ansip, Auštrevičius, Azmani, Bauzá Díaz, Bijoux, Bilbao Barandica, Botoş, Boyer, Brunet, Cañas, Canfin, Chabaud, Charanzová, Chastel, Christensen, Cicurel, Cioloş, Cseh, Danti, Decerle, Dlabajová, Donáth, Durand, Ďuriš Nicholsonová, Farreng, Flego, Gade, Garicano, Gheorghe, Goerens, Gozi, Groothuis, Grošelj, Grudler, Guetta, Hayer, Hlaváček, Hojsík, Huitema, Ijabs, in 't Veld, Karleskind, Karlsbro, Katainen, Kelleher, Keller Fabienne, Knotek, Kovařík, Kyuchyuk, Loiseau, Løkkegaard, Mihaylova, Mituța, Müller, Nagtegaal, Nart, Paet, Pagazaurtundúa, Pekkarinen, Petersen, Pîslaru, Rafaela, Ries, Riquet, Rodríguez Ramos, Schreinemacher, Séjourné, Semedo, Šimečka, Solís Pérez, Ştefănuță, Strugariu, Søgaard-Lidell, Tolleret, Toom, Torvalds, Trillet-Lenoir, Tudorache, Vautmans, Vedrenne, Verhofstadt, Vázquez Lázara, Wiesner, Yon-Courtin, Zacharopoulou, Zullo

S&D: Agius Saliba, Aguilera, Ameriks, Andrieu, Androulakis, Angel, Ara-Kovács, Arena, Avram, Balt, Bartolo, Belka, Benea, Benifei, Beňová, Bergkvist, Biedroń, Blinkevičiūtė, Bonafè, Borzan, Brglez, Bullmann, Calenda, Carvalhais, Cerdas, Chinnici, Cimoszewicz, Ciuhodaru, Číž, Cozzolino, Crețu, Cutajar, Danielsson, De Castro, Dobrev, Durá Ferrandis, Engerer, Ertug, Fajon, Fernández, Fritzon, Fuglsang, Gálvez Muñoz, García Del Blanco, García Muñoz, García Pérez, Gardiazabal Rubial, Gebhardt, Geier, Glucksmann, González, González Casares, Grapini, Gualmini, Guillaume, Guteland, Hajšel, Heide, Heinäluoma, Homs Ginel, Hristov, Incir, Jerković, Kaili, Kaljurand, Kohut, Köster, Krehl, Kumpula-Natri, Lalucq, Lange, Larrouturou, Leitão-Marques, López, López Aguilar, Luena, Maestre Martín De Almagro, Majorino, Maldonado López, Marques Margarida, Marques Pedro, Matić, Mavrides, Maxová, Mebarek, Mikser, Miller, Molnár, Moreno Sánchez, Moretti, Negrescu, Neuser, Nica, Olekas, Papadakis Demetris, Penkova, Picierno, Picula, Pisapia, Pizarro, Plumb, Regner, Roberti, Rodríguez-Piñero, Rónai, Ros Sempere, Ruiz Devesa, Sánchez Amor, Sant, Santos, Schaldemose, Schieder, Schuster, Sidl, Silva Pereira, Sippel, Smeriglio, Stanishev, Tarabella, Tinagli, Toia, Tudose, Ujhelyi, Ušakovs, Van Brempt, Vind, Vitanov, Vollath, Yoncheva, Zorrinho

The Left: Maurel

Verts/ALE: Dalunde, Holmgren, Kuhnke, Ropė

I'm looking as well, so far have only found https://www.europarl.europa.eu/sed/doc/votingList/(A9-0258_2... which doesn't say much.

Gnome web has proven a great replacement for me, to reproduce safari specific bugs.

> I'd rather advocate for a proper block-level filesystem API that could be used as backing storage for a WASM SQLite library.

This is happening at https://web.dev/storage-foundation/ fwiw

Is this extension trustworthy? It is "recommended" and says GPL3 but there is no link to the source code anywhere.

As I understand it, the idea would be to make respecting these automatic signal mandatory in an update to the GDPR. See https://techcrunch.com/2021/06/14/europe-needs-to-back-brows... for some more context.

Granted though that enforcement of the existing rules seems to be the biggest problem today.

Granted that the DOM event API feels clunky, but I actually think they got things mostly right: - low-level storage primitive with support for indices, "you pay only for what you use". - very fast if used in the right way - very large sizes supported - built-in version support, making it easy to do schema and data migrations. - basic query api that again gives you a lot of flexibility and control over performance - can be abstracted away by higher level libraries like Dexie

I've built a web-app heavily relying on IDB, and storage operations are generally much faster than the native app on Android using Realm DB. IDB is backed by leveldb on Chrome, which in benchmarks is consistently faster than sqlite. I'm happy we didn't end up with websql for one.

My biggest gripes are: - The incompatibility with ES6 promises early on (but IE11 still suffers from) was unfortunate. - The auto-commit behaviour of transactions is somewhat annoying and usually has an impact on your architecture if you want to write multiple things in one transaction, but it would have been easy to have memory leaks and deadlocks without this. - Quota management and eviction is wildly inconsistent between browsers, even on Chrome you get evicted when storage gets critically low. - Safari has a history of pretty bad IDB bugs.

Firefox can require more bandwidth for WebRTC calls I think, see https://bugzilla.mozilla.org/show_bug.cgi?id=1600698

I also have some memory of asking all participants in Jitsi meetings to not use firefox, because the call would start to lag for all participants if bandwidth was an issue for the firefox users in the call. Don't know if that is still the case or not though.

Hackles [1], is that you?

1: http://www.hackles.org/

You can only do recurring donations, no thank you.

One reason is that it allows to run the same code in the browser and in node without any transpilation.

I can relate, and agree front-end frameworks and tooling feel overly complicated.

The good news is that there is another way. It's completely feasible to develop without any tooling but a static web server and a browser nowadays. Just bundle for production.

I've developed [1] (a +10k LoC chat app) and [2] (a small web app) using just a 600 LoC template library [3] (which I should really extract), and I vastly prefer it over more traditional setups. Being so close to the browser makes it so easy to see what is going on. I've never spent hours or days debugging the infrastructure code because there is barely any, which is usually what ruins the fun for me.

Everybody is different, but for me the accidental complexity of the commonplace front-end stack (webpack, react, typescript, ...) isn't worth what you get out of it.

1: https://github.com/vector-im/hydrogen-web 2: https://github.com/matrix-org/matrix.to 3: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...

> I'm rather convinced at this point that all of these people chanting "Can we just go back to traditional approaches!" have never built a web app of reasonable complexity, never used something like React, or have some sort of combination of FOMO and/or comfort in their long-held approach.

I've got plenty of React & front-end experience and vastly prefer a thin library on top of the DOM than something like React, also for large applications. React is ok if all goes well, but when you have to debug or profile something, all the complexity behind the scenes occludes what you are looking for. Most of the time, people want JSX so you need a transpiler. Also keeping up with changes in new React releases seems like a lot of lost time.

I've been building [1] without a transpiler and just a 600 lines template library (see [2]), and it has been such a breath of fresh air. The fact that there is so little code between you and the browser makes it very easy to see what is going on. Call stacks of max around 15 frames.

It sounds like you are comparing React to jquery code without components, and I justed wanted to highlight that DOM APIs have evolved since those days, and that you don't need a library like React to structure your code.

React has popularized good ideas in front-end development, like components, but I think the complexity cost of a virtual DOM is often underestimated.

1: https://github.com/vector-im/hydrogen-web/ 2: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...

I share the frustration with everything moving to slow and bloaty electron apps.

But wrt to electron apps and using web technology instead of native frameworks, I think it depends a lot as well how well the web code is designed. I've been prototyping a Matrix chat app [1] in a very minimalist way:

- no framework or library used for UI, "state", ... to have complete control on how and when things are updated and rendered.

- use indexeddb optimally to keep as little things in memory as possible.

My 2 main conclusions from this are:

- Web technology can perform very well. The chat client uses only 3.5mb of Javascript VM memory on a 200 room account. It visually outperforms some native apps as an installed PWA on Android on a low-end device. I attribute this to the fact that web browsers are very optimized.

- It takes more time to engineer an app properly like this, even in a language like javascript. I can imagine it's hard to justify the expense, when most people don't know who to blame when their computer is slow.

1: https://github.com/bwindels/brawl-chat

I went with this syntax as well for a project [1], being just a simple wrapper on top off createElement, with functions as children/attributes being used as one-way bindings.

1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...

Works very well, and don't need to transpile.

Sorry for this inconvenience. We're working on it, see linked issues to your issue.

True, cars are very bad for climate change as well. I think that the reason people focus on airplanes is that they tend to take you a lot further. Almost nobody flies for a 100km trip, like very few people undertake a 10.000km car trip.

The co2 numbers don't seem to take radiative forcing [1] into account, so the actual total climate impact would be 2-4 times the numbers mentioned in the article.

1: https://en.wikipedia.org/wiki/Environmental_impact_of_aviati...

I think you can get pretty close to the comfort of JSX with plain JS, without needing a preprocessor. Local development is so much nicer without webpack, babel, source maps, ...

I've been trying trying this out [1] with a thin 300-line DOM wrapper, and works wonderfully well so far.

There are also libraries like lit-html but I prefer to construct html as an object tree, and not a string.

1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...

The article talks about energy and resource consumption in the US, but production of most electronics happens in China, whos emissions are exploding. Energy used in production of electronics is often greater than the energy consumed during the entire lifetime of a device [1].

1: https://solar.lowtechmagazine.com/2009/06/embodied-energy-of...

ES modules with relative URLs have shipped in browsers, and when import maps [1] land, it could become viable to not bundle or transpile for local development and only do so for production builds.

1: https://github.com/WICG/import-maps

I hope/suspect transpilation will not be a given any more in the future. In that scenario, it's good to have alternatives to JSX.

The linux aio syscalls (io_submit, ...) work well on some filesystems (xfs, ext4, ...) but block on others (btrfs). It limits your file system choices but allows for a single threaded, concurrent web-server. This is what I ended up using for my hobby web-server wwwee [1] as low memory usage and good performance on a single core was an important constraint. It is sort of an opinionated design though.

1: https://github.com/bwindels/wwwee

This is what I'm trying to do with wwwee [1], a low-resource web server written in Rust. The request / response buffer is a growing anonymous mmap mapping, but all parsing (http headers, ...) and decoding (base64, JSON) is done borrowing from the buffer. It works especially well in Rust, with it's borrow checker preventing use-after-free.

1: https://github.com/bwindels/wwwee/

Not sure what PHP escape method is used in the example on the server, but shouldn't \" escape to \\\" instead of \\"?

Whether it happens or not, if the disruptor doesn't have a business model not based on targeted advertisement, I don't see how it will be different once it becomes large enough.

My hope would be a decentralized service, where everyone hosting an instance determines their own business model, or a paid service. None of which will be as fast to iterate, and be able to crank out features as fast as Facebook can ...

Thought so too, but MS has apparently said it is a fork:

https://www.neowin.net/news/whats-powering-spartan-internet-...:

> The Spartan rendering engine (edgehtml.dll) is a new component and separate from Trident (mshtml.dll). The new engine began as a fork of Trident, but has since diverged rapidly over the past many months, similar to how several other browser engines have started as forks prior to diverging. The new rendering engine is also being built with a very different set of principles than Trident - for example: a focus on interoperability and the removal of document modes.