I Use This!
Very High Activity


Analyzed 11 days ago. based on code collected 12 days ago.
Posted about 14 hours ago by Smokey
Michael Tsai recently linked to Ricardo Mori’s lament on the unfashionable state of the Mac, quoting the following passage: Having a mandatory new version of Mac OS X every year is not necessarily the best way to show you’re still caring, Apple. This ... [More] self-imposed yearly update cycle makes less and less sense as time goes by. Mac OS X is a mature operating system and should be treated as such. The focus should be on making Mac OS X even more robust and reliable, so that Mac users can update to the next version with the same relative peace of mind as when a new iOS version comes out. I wonder how much the mandatory yearly version cycle is due to the various iOS integration features—which, other than the assorted “bugs introduced by rewriting stuff that ‘just worked,’” seem to be the main changes in every Mac OS X (er, macOS, previously OS X) version of late. Are these integration features so wide-ranging that they touch every part of the OS and really need an entire new version to ship safely, or are they localized enough that they could safely be released in a point update? Of course, even if they are safe to release in an update, it’s still probably easier on Apple’s part to state “To use this feature, your Mac must be running macOS 10.18 or newer, and your iOS device must be running iOS 16 or newer” instead of “To use this feature, your Mac must be running macOS 10.15.5 or newer, and your iOS device must be running iOS 16 or newer” when advising users on the availability of the feature. At this point, as Mori mentioned, Mac OS X is a mature, stable product, and Apple doesn’t even have to sell it per se anymore (although for various reasons, they certainly want people to continue to upgrade). So even if we do have to be subjected to yearly Mac OS X releases to keep iOS integration features coming/working, it seems like the best strategy is to keep the scope of those OS releases small (iOS integration, new Safari/WebKit, a few smaller things here and there) and rock-solid (don’t rewrite stuff that works fine, fix lots of bugs that persist). I think a smaller, more scoped release also lessens the “upgrade burnout” effect—there’s less fear and teeth-gnashing over things that will be broken and never fixed each year, but there’s still room for surprise and delight in small areas, including fixing persistent bugs that people have lived with for upgrade after upgrade. (Regressions suck. Regressions that are not fixed, release after release, are an indication that your development/release process sucks or your attention to your users’ needs sucks. Neither is a very good omen.) And when there is something else new and big, perhaps it has been in development and QA for a couple of cycles so that it ships to the user solid and fully-baked. I think the need not to have to “sell” the OS presents Apple a really unique opportunity that I can imagine some vendors would kill to have—the ability to improve the quality of the software—and thus the user experience—by focusing on the areas that need attention (whatever they may be, new features, improvements, old bugs) without having to cram in a bunch of new tentpole items to entice users to purchase the new version. Even in terms of driving adoption, lots of people will upgrade for the various iOS integration features alone, and with a few features and improved quality overall, the adoption rate could end up being very similar. Though there’s the myth that developers are only happy when they get to write new code and new features (thus the plague of rewrite-itis), I know from working on Camino that I—and, more importantly, most of our actual developers1—got enormous pleasure and satisfaction from fixing bugs in our features, especially thorny and persistent bugs. I would find it difficult to believe that Apple doesn’t have a lot of similar-tempered developers working for it, so keeping them happy without cranking out tons of brand-new code shouldn’t be overly difficult. I just wish Apple would seize this opportunity. If we are going to continue to be saddled with yearly Mac OS X releases (for whatever reason), please, Apple, make them smaller, tighter, more solid releases that delight us in how pain-free and bug-free they are.          1 Whenever anyone would confuse me for a real developer after I’d answered some questions, my reply was “I’m not a developer; I only play one on IRC.”2 ↩︎ 2 A play on the famous television commercial disclaimer, “I’m not a doctor; I only play one on TV,” attributed variously, perhaps first to Robert Young, television’s Marcus Welby, M.D. from 1969-1976.3 ↩︎ 3 The nested footnotes are a tribute to former Mozilla build/release engineer J. Paul Reed (“preed” on IRC), who was quite fond of them. ↩︎ [Less]
Posted 2 days ago by Daniel Stenberg
Back in 2013, it came to light that Wget was used to to copy the files private Manning was convicted for having leaked. Around that time, EFF made and distributed stickers saying wget is not a crime. Weirdly enough, it was hard to find a high ... [More] resolution version of that image today but I’m showing you a version of it on the right side here. In the 2016 movie Jason Bourne, Swedish actress Alicia Vikander is seen working on her laptop at around 1:16:30 into the movie and there’s a single visible sticker on that laptop. Yeps, it is for sure the same EFF sticker. There’s even a very brief glimpse of the top of the red EFF dot below the “crime” word. Also recall the wget occurance in The Social Network. [Less]
Posted 2 days ago by Yunier J
En el día de hoy Mozilla a publicado una nueva actualización para su navegador, en esta ocasión la 49.0.2. Esta liberación resuelve pequeños problemas que han estado confrontando algunos usuarios, por lo que recomendamos actualizar. La pueden obtener desde nuestra zona de Descargas para Linux, Mac, Windows y Android en español e inglés.
Posted 2 days ago by Air Mozilla
Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on in...
Posted 2 days ago by Petruta Rasa
Hello Mozillians, We are happy to let you know that Friday, October 28th, we are organizing Firefox 51.0 Aurora Testday. We’ll be focusing our testing on the following features: Zoom indicator, Downloads dropmaker. Check out the detailed instructions ... [More] via this etherpad. No previous testing experience is required, so feel free to join us on #qa IRC channel where our moderators will offer you guidance and answer your questions. Join us and help us make Firefox better! See you on Friday! [Less]
Posted 3 days ago
Using Auto Increment Fields to Your Advantage I just found, and read, Clément Delafargue’s post “Why Auto Increment Is A Terrible Idea” (via @CoreRamiro). I agree that an opaque primary key is very nice and clean from an information architecture ... [More] viewpoint. However, in practice, a serial (or monotonically increasing) key can be handy to have around. I was reminded of this during a recent situation where we (app developers & ops) needed to be highly confident that a replica was consistent before performing a failover. (None of us had access to the back end to see what the DB thought the replication lag was.) Read more... [Less]
Posted 3 days ago by Chris Heilmann
At SmashingConf Freiburg this year I was lucky enough to find some time to sit down with Monica Dinculescu (@notwaldorf) and chat with her about Web Components, extending the web, JavaScript dependency and how to be a lazy but dedicated developer. ... [More] I’m sorry about the sound of the recording and some of the harsher cuts but we’ve been interrupted by tourists trying to see the great building we were in who couldn’t read signs that it is closed for the day. You can see the video and get the audio recording of our chat over at the Decoded blog: I played a bit of devil’s advocate interviewing Monica as she has a lot of great opinions and the information to back up her point of view. It was very enjoyable seeing the current state of the web through the eyes of someone talented who just joined the party. It is far too easy for those who have been around for a long time to get stuck in a rut of trying not to break up with the past or considering everything broken as we’ve seen too much damage over the years. Not so Monica. She is very much of the opinion that we can trust developers to do the right thing and that by giving them tools to analyse their work the web of tomorrow will be great. I’m happy that there are people like her in our market. It is good to pass the torch to those with a lot of dedication rather than those who are happy to use whatever works. [Less]
Posted 3 days ago by Michał
Hello, SUMO Nation! We had a bit of a break, but we’re back! First, there was the meeting in Toronto with the Lithium team about the migration (which is coming along nicely), and then I took a short holiday. I missed you all, it’s great to be back ... [More] , time to see what’s up in the world of SUMO! Welcome, new contributors! superzorro Just Sew Cris cell_division julianocristian sarthak_1011 paymon23 Marto Nieto G. m.emeksiz OCMichael syam3526 jgmaldo If you just joined us, don’t hesitate – come over and say “hi” in the forums! Contributors of the week All the forum supporters who tirelessly helped users out for the last week. All the writers of all languages who worked tirelessly on the KB for the last week. We salute you! Don’t forget that if you are new to SUMO and someone helped you get started in a nice way you can nominate them for the Buddy of the Month! SUMO Community meetings LATEST ONE: 19th of October – you can read the notes here and see the video at AirMozilla. NEXT ONE: happening on the 26th of October! If you want to add a discussion topic to the upcoming meeting agenda: Start a thread in the Community Forums, so that everyone in the community can see what will be discussed and voice their opinion here before Wednesday (this will make it easier to have an efficient meeting). Please do so as soon as you can before the meeting, so that people have time to read, think, and reply (and also add it to the agenda). If you can, please attend the meeting in person (or via IRC), so we can follow up on your discussion topic during the meeting with your feedback. Community The Firefox Release Report for version 49 (including your input) has been published recently! Thanks to everyone who contributed to the document (and to the whole release). You make things happen :-) Platform Check the notes from the last meeting in this document. (and don’t forget about our meeting recordings). You can also follow the migration through our public Trello board. Highlights from the last few days include a walkthrough of the basic style and layout of the site (watch the video for more details) and locking down a list of locales for the first wave of migration (more details in the L10n section). There was a test migration performed by the Lithium team… More details as we get them! Giorgos (our glorious technical admin for the duration of the migration) has also proposed creating a snapshot of Kitsune’s state as an archive version of the site. More details to follow as we get them, but now you can be sure that none of the previously invested work is going to disappear from the web. Take a look at the first iteration of the upcoming post-migration community page – you can find the background and provide feedback for this here. For the front page, take a look here (background and feedback are here) – huge thanks to Joni for working on these two! Don’t forget about the main migration thread, with the list of areas that can benefit from your input: Roles Gamification: ranks & badges Metrics and measurement Design ideas (1st wave) Forum moderation Shutting down Kitsune If you are interested in test-driving the new platform now, please contact Madalina. IMPORTANT: the whole place is a work in progress, and a ton of the final content, assets, and configurations (e.g. layout pieces) are missing. QUESTIONS? CONCERNS? Use the migration thread to put questions/comments about it for everyone to share and discuss. Social Sierra from the Social team joined us recently for a meeting – you can reach out to her anytime! Want to join us? Please email Rachel and/or Madalina to get started supporting Mozilla’s product users on Facebook and Twitter. We need your help! Use the step-by-step guide here. Take a look at some useful videos: Getting started & replying to users Replying to users (continued) Got question about the changes coming up for the toolkit used in Social? Email us! Support Forum You probably haven’t missed it, but just in case… A Flash Player update! Don’t forget that the support forum for forum supporters is there for you if you need more help helping others ;-) Knowledge Base & L10n We are 3 weeks before next release / 1 week after current release What does that mean? (Reminder: we are following the process/schedule outlined here). Joni will finalize next release content by the end of this week; no work for localizers for the next release yet All existing content is open for editing and localization as usual; please focus on localizing the most recent / popular content Migration: please check this spreadsheet to see which locales are going to be migrated in the first wave Locale packages that will be migrated are marked as “match” and “needed” in the spreadsheet Other locales will be stored as an archive at sumo-archive.mozilla.org – and will be added whenever there are contributors ready to keep working on them We are also waiting for confirmation about the mechanics of l10n, we may be launching the first version without an l10n system built in – but all the localized content and UI will be there in all the locales listed in the spreadsheet above Remember the MozPizza L10n Hackathon in Brazil? Take a look here! Firefox for Android HLS video may (or may not) be in version 50. for Desktop Version 49.0.2 update is looming. for iOS No news, keep biting the apple ;-) …Whew, that’s it for now, then! I hope you could catch up with everything… I’m still digging through my post-holiday inbox ;-) Take care, stay safe, and keep rocking the helpful web! WE <3 YOU ALL! [Less]
Posted 3 days ago by nore...@blogger.com (ClassicHasClass)
Ars Technica is reporting an interesting attack that uses a side-channel exploit in the Intel Haswell branch translation buffer, or BTB (kindly ignore all the political crap Ars has been posting lately; I'll probably not read any more articles of ... [More] theirs until after the election). The idea is to break through ASLR, or address space layout randomization, to find pieces of code one can string together or directly attack for nefarious purposes. ASLR defeats a certain class of attacks that rely on the exact address of code in memory. With ASLR, an attacker can no longer count on code being in a constant location. Intel processors since at least the Pentium use a relatively simple BTB to aid these computations when finding the target of a branch instruction. The buffer is essentially a dictionary with virtual addresses of recent branch instructions mapping to their predicted target: if the branch is taken, the chip has the new actual address right away, and time is saved. To save space and complexity, most processors that implement a BTB only do so for part of the address (or they hash the address), which reduces the overhead of maintaining the BTB but also means some addresses will map to the same index into the BTB and cause a collision. If the addresses collide, the processor will recover, but it will take more cycles to do so. This is the key to the side-channel attack. (For the record, the G3 and the G4 use a BTIC instead, or a branch target instruction cache, where the table actually keeps two of the target instructions so it can be executing them while the rest of the branch target loads. The G4/7450 ("G4e") extends the BTIC to four instructions. This scheme is highly beneficial because these cached instructions essentially extend the processor's general purpose caches with needed instructions that are less likely to be evicted, but is more complex to manage. It is probably for this reason the BTIC was dropped in the G5 since the idea doesn't work well with the G5's instruction dispatch groups; the G5 uses a three-level hybrid predictor which is unlike either of these schemes. Most PowerPC implementations also have a return address stack for optimizing the blr instruction. With all of these unusual features Power ISA processors may be vulnerable to a similar timing attack but certainly not in the same way and probably not as predictably, especially on the G5 and later designs.) To get around ASLR, an attacker needs to find out where the code block of interest actually got moved to in memory. Certain attributes make kernel ASLR (KASLR) an easier nut to crack. For performance reasons usually only part of the kernel address is randomized, in open-source operating systems this randomization scheme is often known, and the kernel is always loaded fully into physical memory and doesn't get swapped out. While the location it is loaded to is also randomized, the kernel is mapped into the address space of all processes, so if you can find its address in any process you've also found it in every process. Haswell makes this even easier because all of the bits the Linux kernel randomizes are covered by the low 30 bits of the virtual address Haswell uses in the BTB index, which covers the entire kernel address range and means any kernel branch address can be determined exactly. The attacker finds branch instructions in the kernel code such as by disassembling it that service a particular system call and computes (this is feasible due to the smaller search space) all the possible locations that branch could be at, creates a "spy" function with a branch instruction positioned to try to force a BTB collision by computing to the same BTB index, executes the system call, and then executes the spy function. If the spy process (which times itself) determines its branch took longer than an average branch, it logs a hit, and the delta between ordinary execution and a BTB collision is unambiguously high (see Figure 7 in the paper). Now that you have the address of that code block branch, you can deduce the address of the entire kernel code block (because it's generally in the same page of memory due to the typical granularity of the randomization scheme), and try to get at it or abuse it. The entire process can take just milliseconds on a current CPU. The kernel is often specifically hardened against such attacks, however, and there are more tempting targets though they need more work. If you want to attack a user process (particularly one running as root, since that will have privileges you can subvert), you have to get your "spy" on the same virtual core as the victim process or otherwise they won't share a BTB -- in the case of the kernel, the system call always executes on the same virtual core via context switch, but that's not the case here. This requires manipulating the OS' process scheduler or running lots of spy processes, which slows the attack but is still feasible. Also, since you won't have a kernel system call to execute, you have to get the victim to do a particular task with a branch instruction, and that task needs to be something repeatable. Once this is done, however, the basic notion is the same. Even though only a limited number of ASLR bits can be recovered this way (remember that in Haswell's case, bit 30 and above are not used in the BTB, and full Linux ASLR uses bits 12 to 40, unlike the kernel), you can dramatically narrow the search space to the point where brute-force guessing may be possible. The whole process is certainly much more streamlined than earlier ASLR attacks which relied on fragile things like cache timing. As it happens, software mitigations can blunt or possibly even completely eradicate this exploit. Brute-force guessing addresses in the kernel usually leads to a crash, so anything that forces the attacker to guess the address of a victim routine in the kernel will likely cause the exploit to fail catastrophically. Get a couple of those random address bits outside the 30 bits Haswell uses in the BTB table index and bingo, a relatively simple fix. One could also make ASLR more granular to occur at the function, basic block or even single instruction level rather than merely randomizing the starting address of segments within the address space, though this is much more complicated. However, hardware is needed to close the gap completely. A proper hardware solution would be to either use most or all of the virtual address in the BTB to reduce the possibility of a collision, and/or to add a random salt to whatever indexing or hashing function is used for BTB entries that varies from process to process so a collision becomes less predictable. Either needs a change from Intel. This little fable should serve to remind us that monocultures are bad. This exploit in question is viable and potentially ugly but can be mitigated. That's not the point: the point is that the attack, particularly upon the kernel, is made more feasible by particular details of how Haswell chips handle branching. When everything gets funneled through the same design and engineering optics and ends up with the same implementation, if someone comes up with a simple, weapons-grade exploit for a flaw in that implementation that software can't mask, we're all hosed. This is another reason why we need an auditable, powerful alternative to x86/x86_64 on the desktop. And there's only one system in that class right now.Okay, okay, I'll stop banging you over the head with this stuff. I've got a couple more bugs under investigation that will be fixed in 45.5.0, and if you're having the issue where TenFourFox is not remembering your search engine of choice, please post your country and operating system here. [Less]
Posted 3 days ago by Air Mozilla
Weekly project updates from the Mozilla Connected Devices team.