This blog post discusses the top challenges faced by web developers in 2021 based on a quarterly survey. The findings reveal that the top pain points remain consistent with previous years, including browser compatibility, testing, documentation, debugging, framework usage, and security/privacy concerns. The survey data highlights the difficulties developers face in keeping up with evolving web standards and the ever-expanding ecosystem of tools and frameworks. Cross-browser compatibility and testing remain significant hurdles. While initiatives like Compat 2021 aim to address these challenges, their impact is yet to be fully realized. The data consistently shows the need for improved developer tooling and a more streamlined web development experience.
This post discusses the importance of developer satisfaction, particularly for web developers, and how the MDN Web Developer Needs Assessment has influenced Chrome's web platform priorities for 2020. My hypothesis is that improving the web platform will lead to increased developer satisfaction, more content creation, and happier end-users. Based on the MDN survey data, key areas for improvement include browser compatibility, testing, documentation, debugging, framework integration, and privacy & security. Chrome is committed to working with the web ecosystem to address these challenges and increase developer productivity and satisfaction. We'll share more specific plans in the coming weeks and welcome your feedback on these focus areas and how Chrome can better engage with the developer community.
I'm looking for a Developer Advocate to join the Chrome team and help us improve web privacy. We have many ongoing and upcoming projects within the Privacy Sandbox initiative. This role will focus on advocating for cross-browser privacy solutions, working with external developers, and ensuring our internal teams prioritize user and developer needs. This will involve explaining potentially disruptive changes (like the SameSite cookie attribute update) and helping developers adapt.
I recently noticed Twitter has adopted the Well-Known URL for Changing Passwords, which is a simple yet effective way to improve user experience. This spec allows browsers to offer a UI for quick password resets without navigating complex site structures, simply by checking a well-known URL. This sparked an idea: could we expand this concept to other common user actions? Imagine well-known locations for managing GDPR consent, browser permissions, account details, or mailing list subscriptions. It's a powerful concept that could simplify many online interactions, and I've even raised an issue with Chrome to explore implementation.
Feature Policy is a powerful web platform tool that allows developers to control the behavior of APIs and features, similar to CSP. It helps manage third-party content by enabling or disabling functionalities like autoplay, geolocation, and sensor access within iframes, giving embedders more control over their page experience. Additionally, Feature Policy assists in maintaining performance budgets during development by flagging potential violations, such as excessive image downscaling, as demonstrated with the 'max-downscaling-image' policy used during Chrome Dev Summit. Developers can explore more about Feature Policy, code samples, and demos at featurepolicy.rocks, submit feedback at https://bit.ly/2B3gDEU, and learn about the Reporting API at https://bit.ly/rep-api. For the latest Chrome implementations, visit Chrome Status.
I recently had the pleasure of attending and thoroughly enjoying a live stream hosted by This Dot, featuring browser representatives from Brave, Beaker, Edge, Chrome, and Mozilla. They discussed recent updates and the future direction of browsers. Key highlights included Beaker Browser's innovative work on the distributed web, Edge's significant updates like Service Worker support and WebP integration, Mozilla's focus on Web Assembly, and Brave's progress with BAT. My team at Google is focused on Discovery, Speed & Reliability, UI Responsiveness, UX, Security, and Privacy. We're working to improve how developers build sites for headless services, optimizing for speed and reliability using metrics like TTI and FID, improving UI responsiveness with techniques like FLIP and Houdini, prioritizing user experience, and addressing security and privacy concerns in light of Intelligent Tracking Prevention and GDPR. It was also exciting to see a shared interest in bringing back Web Intents.
Feature Policy is a new web platform API designed to help developers maintain control over their web app's performance, security, and user experience. It allows developers to define policies that restrict access to certain features or modify the browser's default behavior. Examples include controlling autoplay, access to sensitive APIs, usage of fullscreen, preventing use of outdated APIs, and managing image sizes. Policies act as a contract between the developer and the browser, ensuring the developer's intent is followed even as the project grows and evolves. While adoption is a concern, its potential benefits for performance, security and privacy are substantial, especially if tied to incentives like app store listings.
Tired of typing in usernames and passwords? So are your users. Autofill helps, but the Credential Management API gives developers more control. It lets you securely store and retrieve user credentials, simplifying logins with just a couple of taps. This Chrome-only API allows access to a PasswordCredential object, rather than raw passwords. It works with other improvements like proper autofill fields (email, username, new-password, current-password) and offers a potential future where landing and login pages are obsolete. Imagine a web where users stay logged in seamlessly, only re-authenticating when necessary. This post covers how to implement the API, including a demo and sample code. Plus, explore how it might combine with the Web Payment Request API to streamline e-commerce.
WebMessaging (postMessage) seems simple but has quirks. Different browsers handle data differently (structured clones vs. strings). The biggest problem is sending messages to a newly opened window/iframe. You can't just send a message immediately; you have to wait for the window to load and signal back. This adds complexity, requiring the new window to postMessage back to the opener, which then sends the actual data. A workaround involves passing data via window.name, but this has security implications as the data's origin is uncertain and the name persists, potentially exposing data.
I've been working on Web Intents, a project to simplify client-to-client service discovery and communication on the web using technologies like IFrames and SharedWorkers. It addresses the current issue of apps needing to integrate with third-party services, which restricts user choices. However, I recently discovered a similar project, Web Introducer, also by a Googler. It tackles the same problems with more in-depth security considerations. So, I'll be shifting my focus to contribute to Web Introducer. Web Intents remains a valuable example of using SharedWorkers and messaging effectively within web apps. More on Web Introducer and SharedWorkers coming soon!
Concerned about Facebook privacy? I've created a Facebook application called "Know Your Privacy" to help you understand how third-party apps access your profile data. It highlights potential risks and offers common-sense advice. Find it at http://apps.facebook.com/knowyourprivacy/. Your feedback is welcome! Disclaimer: This app is for informational purposes only and doesn't imply any misuse of data by installed apps. It's not professional advice; contact authorities for accurate information. Resources on identity theft are included.
DevWeek Conference Day 1: Jeff Prosise's keynote covered the history of web programming, from CGI to ASP.NET AJAX and WPF/E. While I enjoyed his talk, I would've preferred more focus on the future. The "Attack and Defense" session was disappointing, lacking depth compared to available online resources. David Wheeler's "Practical Patterns" was a highlight, with clear explanations and code examples of design patterns. The vendor presence was smaller than expected. Infragistics showcased promising XAML controls, while TechExcel impressed with their enthusiasm and software demo. Other vendors, like NAG and the Enterprise Architect distributors, could have been more engaging.
Arrived at DevWeek 2007 last night. Looking forward to the keynote by Jeff Prosise on ASP.NET AJAX and then attending architect track sessions on securing ASP.NET 2.0 apps and practical patterns in .NET. Hoping to post summaries if internet access allows.
I'm really enjoying working with WSE 3.0, especially its policy mechanism. It allows for Aspect Oriented Programming (AOP) through SoapFilters, enabling me to add functionality like security, auditing, and exception handling via configuration rather than hardcoding it into my web service. This keeps my service code clean and maintainable. I demonstrated this with a simple example of an OrderService, comparing the cleaner policy-based approach to a more complex, hardcoded alternative. The policy configuration significantly simplifies adding and managing cross-cutting concerns.
The Ajax Tagger has been updated with a number of bug fixes and improvements. Key changes include using my own Tag Directory for related tags, providing Yahoo search results as RSS in OPML output, and fixing issues with menu item classes, OPML apostrophe escaping, and image selection persistence. Planned future enhancements include a Blogger interface, Kelkoo integration, addressing a cross-domain CGI request security warning, and Del.icio.us OPML integration.
This post is a follow-up to my earlier one about using SOAP requests in ASP.Net to access the eBay API. I've finally figured out how to make it work! A few key things to note: most requests need the "version" attribute, some require the "DetailLevel" attribute, and you'll need an eBay Authentication Token (a cryptographic hash) for security. When using the WSDL URL, remember to include query string parameters so eBay knows what to do. I've included some sample C# code demonstrating how to build the request URL, set credentials, and handle the response.
This excerpt from my final year project explores different types of telecom fraud, which I'll use as a basis for a C# neural network. Telecom fraud can be categorized into subscription fraud (false identities or payment evasion), call surfing (unauthorized network access through methods like call forwarding or cloning), ghosting (manipulating systems to avoid billing), accounting fraud (internal manipulation of billing systems), and information abuse (misuse of client or system data). I discuss the financial impact of these methods, such as bad debt from subscription fraud and costs incurred from call surfing via PABX manipulation. I also touch upon the vulnerabilities of older analogue mobile phones to cloning and the methods used in ghosting, like tone generating hardware. The project aims to address these fraud types through a neural network approach.
My site, DeliTag, is being flagged as suspicious by IE7, likely due to the username and password fields for Delicious. I've created a privacy statement to address concerns about how this information is used. In short, the credentials are passed directly to Delicious without any further processing. The transmission is unsecured, mirroring Delicious's own security. The privacy statement at http://www.kinlan.co.uk/Deli/DeliPrivacy.htm offers more details. Please contact me with any questions.
This post discusses the security implications of cross-domain XMLHttpRequest access. While some argue that such access increases the risk of phishing attacks and unauthorized data access, others contend that these risks are minimal and that the benefits of cross-domain access, such as reduced bandwidth costs for "mash-up" applications, outweigh the potential downsides. The current security model, which requires proxying requests through the originating server, is seen as costly. I propose a server-side security model where third-party servers can control which clients can directly access their data, addressing the bandwidth theft concerns.
I'm excited to share a bunch of new videos on Channel 9, offering tons of insights into Windows Vista! Check out discussions with Rob Franco's team on IE 7 security, Steve Ball on audio enhancements, and Abolade Gbadegesin's team on networking. Even more videos are available on Channel 9's forum.
In part two of this series on the failures of my first AJAX application, I discuss how my initial plan to reduce bandwidth by having the client directly access third-party web services didn't work out. Due to cross-domain scripting issues in Firefox and IE 6/7, I had to implement proxy scripts on my server. This means all client requests now go through my server, increasing my bandwidth demands. While using a proxy server offers benefits like hiding security information (like Technorati developer tokens) and enabling data manipulation/request merging, it comes with the major downside of increased bandwidth usage and the need to create/maintain proxy scripts. I hope to support cross-domain data sources in the next version to mitigate these issues but acknowledge there might still be scenarios where proxy scripts are necessary.
I've been exploring how Microsoft's Start.com retrieves data from external web feeds. It appears they use a server-side script to tunnel requests to the remote server, effectively acting as a proxy. This workaround is necessary due to browser security restrictions that prevent cross-domain data fetching in Firefox and certain Internet Explorer configurations. Consequently, my AJAX application will need to handle the additional bandwidth required for retrieving data from Yahoo and Technorati directly, as redirecting XMLHttpRequest calls isn't a viable option.
My AJAX application has a minor cross-site data access security issue, similar to one I've encountered in Firefox. A workaround in IE6/7 involves enabling "Access data sources across domains" in Internet Options -> Security -> Custom Level, though this isn't ideal.
I'm developing an AJAX application to automatically generate Technorati, Feedster, and MSN search boxes with relevant tags for my blog posts. It's a JavaScript webservice queryer that uses results from one service as input for another. Currently, it only supports IE6/7 due to cross-domain data source import restrictions in Firefox. I'm exploring JavaScript code signing as a potential solution. The application integrates with Yahoo webservices, with plans to include Technorati and hopefully Feedster. There are security concerns regarding my Yahoo key. I aim to have a prototype available for feedback soon.
I had this brilliant idea to create a merged RSS feed using client-side processing. The idea was to have a main RSS feed that linked to other feeds. My custom XML would include a list of sources. Then, using XSLT in the browser, the client could merge these external feeds into a single view. It worked perfectly locally! However, I hit a roadblock with cross-domain security restrictions when I uploaded it to my server. The browser wouldn't let me pull in feeds from other domains due to security concerns. Additionally, client-side XSLT processing isn't universally supported. So, even if the security issue wasn't there, many feed readers wouldn't be able to display the merged feed. In the end, the project failed. But, I learned a lot about browser security, XSLT limitations and client/server interactions!
I've been pondering an ASP.Net security concern: while it blocks potentially harmful querystring characters by default, turning this off puts the onus of validation on developers. I'm exploring the idea of a declarative approach to query parameter validation, where developers define predicates (like data types) for expected parameters within the Page Class definition itself. This could simplify validation and ensure data is HTML-safe before reaching the developer. This would streamline validation compared to using custom validators. I'm considering the benefits and implementation details of such an approach.
