#41 link con subtitulos en castellano
http://download.ted.com/talks/YoavMedan_2011P-480p-es.mp4

#39 Hay diferencia, en Europa las cuotas son cuotas máximas para no producir más ... en la URSS comunista también había cuotas, pero cuotas mínimas para no producir menos. Quien quiera entender que entienda.

#56 Bien, si por estándares te refieres a HTML5, las versiones definitivas se han "aprobado" ayer mismo como quien dice. Normal que ningún navegador cumpla al 100% todo el estándar (los navegadores más aventajados en cada área específica del estándar son los que han conseguido colar desarrollos propios en los estándares y/o su implementación era la mejor/más adecuada y los estándares la han reflejado como la solución óptima, luego están los que se han arriesgado a implementar borradores de esas partes y que han tenido que hacer pocos cambios o ninguno, y por último están aquellas cosas que requieren una modificación profunda en el diseño del navegador para poder ser implementados o aquellos navegadores que esperan a que se termine de definir esa parte del estándar para implementar).

Aún así, hay páginas cojonudas que todo diseñador web debe conocer y manejar como http://caniuse.com que facilitan mucho el decidir si meterse en berenjenales o no. Dicho esto, la mayor parte de cosas necesarias para casi todos los desarrollos están soportadas por todos (¿que se pueden hacer mejor o más elegantes si el navegador X soportara la característica Y? seguro, pero se pueden hacer igualmente), e incluso olvidándonos de usar HTML5 directamente, hay muchas librerías que nos abstraen de todo eso y nos permiten hacer el desarrollo sin tener que preocuparnos por la compatibilidad (empezando por jquery).

Sobre la firma de documentos, es complicado hacerlo directamente vía web por las limitaciones que todos sabemos. Pero siempre puedes descargar el formulario, rellenarlo y firmarlo (aplicaciones para trabajar y firmar con pdfs libres y gratuítas haberlas haylas, formas de comprobar que no se ha modificado la estructura del pdf para evitar problemas de seguridad también las hay). Incluso es más factible y funcionará mejor y será más sencillo hacer un "editor pdf" en java para el escritorio que no una aplicación web (ya te quitarías de problemas de navegadores, sólo necesitarías un ordenador con java). Ahora bien, eso tampoco solucionaría el problema de poder hacer las gestiones desde móviles, y aunque hay implementaciones de java para las arquitecturas mayoritarias, siempre quedarían los problemas de seguridad inherentes a la tecnología (que en arquitecturas como x86 se parchea mucho y a menudo, pero en otras minoritarias el esfuerzo no es tan grande).

La solución de un "navegador gubernamental" no me parece incorrecta o descabellada, pero tampoco creo que sea la mejor solución (más que nada porque mira lo que tardaron en encontrarle las cosquillas a aquella versión especial de firefox que venía torificada, y los plugins pueden ser "sustituíbles" por versiones pirateadas con algo de ensayo y error).

Una solución alternativa y que funcionaría en el 100% de los casos con un navegador HTML5 (pero que necesitaría una infraestructura potente, tanto a la hora de dar servicio como a la hora de protección y seguridad) o en su defecto si es necesario una pequeña aplicación que embeba un navegador html5 o una alternativa parecida (aunque entonces no sería universal ni 100% accesible) sería el paradigma del thin client: hacerlo todo en el servidor. Poner un sistema en la nube, acceso remoto desde el cliente y que todos los programas se ejecuten en servidores estatales. Algo así como esto: http://guac-dev.org/, donde el cliente tiene una cuenta accesible con su dni electrónico o certificado digital y algún código recibido vía mensaje sms para aumentar la seguridad y dependiendo del dispositivo desde donde se conecte le envíe directamente a un programa adaptado para escritorio o móvil donde hacer sus gestiones. La parte buena: tu te lo cocinas como quieres: lenguaje, plataforma, seguridad, etc. porque todo está en servidor y sabes que VA A FUNCIONAR porque está en un entorno controlado. Si montas un gestor de escritorio muy ligero y con lo mínimo (exportar un display y tratar eventos para poder interactuar) podrías atender a mucha gente simultaneamente bajo tus propias condiciones y permitiendo un acceso universal y seguro.

Pero creo que hoy en día, con nuestras conexiones, seguiría siendo sci-fi. Quizá en Japón...

PD: de chapa nada, es bueno ver distintas opiniones y puntos de vista y cómo alguien desarrollaría lo mismo que tu de otro modo, te ayuda a ver cosas buenas y a percatarte de las cosas malas, a tomar apuntes para ti mismo, que nunca se sabe qué te pueden mandar a hacer en un futuro.

#54 Precisamente porque trabajo en web se de lo que me hablo. Si te ciñes a los estándares no tienes ningún problema con ningún navegador actual o con menos de cinco años (y no me vale estándares en periodo de discusión o con implementaciones de prueba o no completas).

El java tiene muchos problemas:
-Es un plugin; hay que instalarlo en el sistema (y muchos navegadores lo bloquean directamente, al menos las versiones que se saben peligrosas).
-No va en todos los equipos porque es muy pesado y lento y no está soportado por todas las plataformas o arquitecturas.
-La versión java para dispositivos móviles recorta muchas cosas en pos de la flexibilidad y ahorro de recursos, lo que no permite usar programas java normales en ella.
-Frecuentes problemas GORDOS de seguridad.
-Versiones incompatibles unas con otras, necesidad de portar tus programas a la nueva versión.
-NO es accesible. Una persona con deficiencias con su navegador adaptado no puede acceder a contenidos hechos en java.

Tomemos la administración media que hizo en su día un programa para java 6. Así a bote pronto estás dejando fuera a:
-Todo aquel que use dispositivos móviles para hacer gestiones.
-Todo aquel que no use una implementación java oracle (las implementaciones de referencia, libres y abiertas no funcionan igual de bien, al menos con java 7 y 8 la brecha entre la de referencia y la de oracle es menor) porque le va a dar problemas en algún momento dado o le va a hacer inservible.
-Todo aquel que no use internet explorer, porque siendo java un entorno "neutro" se las apañan para tirar esa neutralidad a la basura.

Los móviles solo son millones de potenciales usuarios de tu aplicación que no pueden usarla (en españa ahora mismo hay registrados 53 millones, de los cuales 26 millones se conectan a internet con ellos, de los cuales 10 millones pueden usarlos para algo más que el whatsapp, de los cuales...). Si contamos que ahora mismo solo un tercio de españoles usan explorer, estarías limitando aún más el número de personas que podrían acceder a.

Y te repito otra vez más: no 5000 millones de versiones de un producto que resuelvan cada pequeña variación de características, solo una y que siga los estándares, que solo con eso ya permites que potencialmente TODO el mundo pueda acceder a tus servicios. Y repito de nuevo, si algún navegador no cumple un estándar o falla, basta entrar en su bugzilla y crear un bug, que ya se encargarán ellos de resolver el problema (porque la culpa no será de tu producto).

Porque ahora mismo hay una, pero falla por todos lados por pensarse y hacerse para un entorno concreto fuera de estándares.

Sobre tu propuesta: ¿Qué navegador escogerías? ¿te venderías a google? ¿irías por mozilla por aquello de ser una fundación y tal? ¿desarrollarías tu propio navegador? ¿por qué elegirías de ese modo? ¿qué razones darías para ello? ¿por qué la gente tendría que bajar tu navegador si ya está contento con el que tiene? ¿qué pasa si alguien no puede acceder a las cosas porque le has obligado a instalar un navegador que igual no tiene versión para su arquitectura/SO/loquesea o tu tienes binarios para él o no has portado tu código a esa versión del navegador?

Hablas de criptografía (en cliente) como escudo para darle valor a java, Http dispone de formas de encriptar los datos que transmites (no es lo mismo que encriptar antes de mandar, claro, pero tampoco es que los datos vayan por cauces inseguros, hay millones de webs de tiendas y tal que realizan operaciones bastante sensibles para los datos de los usuarios y no necesitan java).

Lo de los lectores de dni electrónico fue una chapuza total, y en gran parte la poca extensión que ha tenido ha sido culpa de unos drivers de mierda (y cerrados) y la implementación en java (que vino muy bien para que todas las administraciones que ya tenían sus programas en java no tuvieran que tocar mucho, pero que ha ignorado al resto del mercado potencial). Conozco mucha gente que en su día consiguió el lector de marras y no ha podido usarlo (alguno ni siquiera en windows).

#55 (NOTA: De verdad, que esta conversación me viene muy bien para saber si la idea que tengo es buena o no y me viene bien alguien escéptico que me de la contraréplica).

Creo que ambos estamos deacuerdo en que Java NO ha de usarse en el lado cliente al igual que no usamos Flash, limita los dispositivos a los que puedes ir además de crear un lio de narices a los usuarios. Creo que no me has entendido que digo de usar plugins de navegador pero me refiero a extensiones nativas del propio navegador no a usar Java ni otra tecnología.

Ambos estamos deacuerdo en usar estándares establecidos. El problema es que los navegadores no cumplen nunca al 100% ( http://www.quirksmode.org/ ).

También estamos deacuerdo en la pedazo de chapuza de los lectores de DNI electrónico. Tengo uno y vaya tela hacerlo funcionar en Windows, en Linux curiosamente no me costó nada. No me escudo en el cifrado, los navegadores a día de hoy saben usar SSL/TLS perfectamente. El problema es cuando quieres firmar un documento, por ejemplo la Declaración de IRPF con tu certificado de usuario en el lado cliente. Hay que cruzar los dedos muy fuerte para esperar que te funcione a la primera a día de hoy.

La idea sería la siguiente:

Desde la Administración se crearía un proyecto en el que podría concurrir cualquier empresa bajo la premisa de coger un navegador Open Source (Firefox/Chromium) que fuera multiplataforma y crear un fork del mismo en el que los únicos cambios a hacerle serían el añadirle los bookmarks de la Administración, añadirle el certificado raiz de la FNMT (que por defecto no lo lleva ningún navegador, manda narices) y crearle plugins para hacer tareas específicas que actualmente no están soportadas por los estándares. Pongo el punto específicamente en el firmado de documentos y criptografía porque actualmente cada vez que quieres hacer algo en ese sentido siempre se recurre a Java, si hemos quedado en no usar Java y que no hay estándar para eso actualmente entonces la única opción disponible es crear un plugin para el navegador elegido.

A partir de ese momento, la Administración podría "empaquetar" el navegador para todas las plataformas mayoritarias (Linux, Mac, Win, Android, iOS) y dejarlo listo para descarga. Cualquier persona física o jurídica que quisiera acceder a las webs de la Administración a realizar gestiones debería utilizar el navegador "oficial" de la Administración y cualquier empresa que hiciera desarrollos para la administración sólo tendría que preocuparse de tener que desarrollar para el navegador "oficial".

Evidentemente, debería existir un grupo específico que se encargase del mantenimiento de los navegadores para ir actualizándolos con parches de seguridad los cuales recibirían actualizaciones automáticas al igual que las reciben Firefox y Chrome/Chromium.

Respecto a tus preguntas:

¿Qué navegador escogerías? ¿te venderías a google? ¿irías por mozilla por aquello de ser una fundación y tal?

No, iría a concurso, pero evidentemente tendría que ser Open Source (chromium/mozilla) y el ganador sería por méritos tanto de funcionalidades como de precio. Como se indicase en el pliego

¿desarrollarías tu propio navegador? ¿por qué elegirías de ese modo? ¿qué razones darías para ello?

No, lo haría la Administración como método de unificación, creo que esta idea no quedó clara cuando puse mis anteriores comentarios. La razón es forzar a que realmente el sistema funcione, piensa en este navegador como en tu "Ventanilla única" para acceder a la Administración.

¿por qué la gente tendría que bajar tu navegador si ya está contento con el que tiene?

Porque puedes tener instalados varios navegadores y porque a día de hoy es incluso obligatorio tenerlos todos. Por experiencia personal, la web de Catastro va muy bien con Chrome pero mal con Firefox, sin embargo la de la DGT por narices tienes que ir con Internet Explorer....vamos, que al final tengo que tener instalados todos e ir probando cuando veo que uno falla. Mi mujer trabaja en una gestoría y tiene el mismo problema y la misma solución, si con un navegador ve errores prueba con otro hasta que da con el que le funciona... Con esta idea tú tendrías el navegador que quisieras para hacer tus cosas y luego el de la Administración para hacer las gestiones.

¿qué pasa si alguien no puede acceder a las cosas porque le has obligado a instalar un navegador que igual no tiene versión para su arquitectura/SO/loquesea o tu tienes binarios para él o no has portado tu código a esa versión del navegador?

Sólo serían necesarias 4 versiones: Windows, Mac, Linux32, Linx64. Si ya quieres rizar el rizo añade dos versiones más, iOS y Android. (Nota: Firefox está a punto de sacar versión para iOS y ya la tiene para Android y ambas soportan plugins). De hecho tanto Chrome como Firefox sólo tienen esas versiones, parece que es más que suficiente. Si mañana aparece un sistema operativo nuevo o actualización, tranquilo que tanto la Fundación Mozilla como Google sacarán adaptaciones para ese sistema/versión y tú lo único que tendrás que hacer es un nuevo fork/merge.

PD. siento la pedazo de chapa de comentario pero espero haber explicado mejor la idea. thnx!

#56 Bien, si por estándares te refieres a HTML5, las versiones definitivas se han "aprobado" ayer mismo como quien dice. Normal que ningún navegador cumpla al 100% todo el estándar (los navegadores más aventajados en cada área específica del estándar son los que han conseguido colar desarrollos propios en los estándares y/o su implementación era la mejor/más adecuada y los estándares la han reflejado como la solución óptima, luego están los que se han arriesgado a implementar borradores de esas partes y que han tenido que hacer pocos cambios o ninguno, y por último están aquellas cosas que requieren una modificación profunda en el diseño del navegador para poder ser implementados o aquellos navegadores que esperan a que se termine de definir esa parte del estándar para implementar).

Aún así, hay páginas cojonudas que todo diseñador web debe conocer y manejar como http://caniuse.com que facilitan mucho el decidir si meterse en berenjenales o no. Dicho esto, la mayor parte de cosas necesarias para casi todos los desarrollos están soportadas por todos (¿que se pueden hacer mejor o más elegantes si el navegador X soportara la característica Y? seguro, pero se pueden hacer igualmente), e incluso olvidándonos de usar HTML5 directamente, hay muchas librerías que nos abstraen de todo eso y nos permiten hacer el desarrollo sin tener que preocuparnos por la compatibilidad (empezando por jquery).

Sobre la firma de documentos, es complicado hacerlo directamente vía web por las limitaciones que todos sabemos. Pero siempre puedes descargar el formulario, rellenarlo y firmarlo (aplicaciones para trabajar y firmar con pdfs libres y gratuítas haberlas haylas, formas de comprobar que no se ha modificado la estructura del pdf para evitar problemas de seguridad también las hay). Incluso es más factible y funcionará mejor y será más sencillo hacer un "editor pdf" en java para el escritorio que no una aplicación web (ya te quitarías de problemas de navegadores, sólo necesitarías un ordenador con java). Ahora bien, eso tampoco solucionaría el problema de poder hacer las gestiones desde móviles, y aunque hay implementaciones de java para las arquitecturas mayoritarias, siempre quedarían los problemas de seguridad inherentes a la tecnología (que en arquitecturas como x86 se parchea mucho y a menudo, pero en otras minoritarias el esfuerzo no es tan grande).

La solución de un "navegador gubernamental" no me parece incorrecta o descabellada, pero tampoco creo que sea la mejor solución (más que nada porque mira lo que tardaron en encontrarle las cosquillas a aquella versión especial de firefox que venía torificada, y los plugins pueden ser "sustituíbles" por versiones pirateadas con algo de ensayo y error).

Una solución alternativa y que funcionaría en el 100% de los casos con un navegador HTML5 (pero que necesitaría una infraestructura potente, tanto a la hora de dar servicio como a la hora de protección y seguridad) o en su defecto si es necesario una pequeña aplicación que embeba un navegador html5 o una alternativa parecida (aunque entonces no sería universal ni 100% accesible) sería el paradigma del thin client: hacerlo todo en el servidor. Poner un sistema en la nube, acceso remoto desde el cliente y que todos los programas se ejecuten en servidores estatales. Algo así como esto: http://guac-dev.org/, donde el cliente tiene una cuenta accesible con su dni electrónico o certificado digital y algún código recibido vía mensaje sms para aumentar la seguridad y dependiendo del dispositivo desde donde se conecte le envíe directamente a un programa adaptado para escritorio o móvil donde hacer sus gestiones. La parte buena: tu te lo cocinas como quieres: lenguaje, plataforma, seguridad, etc. porque todo está en servidor y sabes que VA A FUNCIONAR porque está en un entorno controlado. Si montas un gestor de escritorio muy ligero y con lo mínimo (exportar un display y tratar eventos para poder interactuar) podrías atender a mucha gente simultaneamente bajo tus propias condiciones y permitiendo un acceso universal y seguro.

Pero creo que hoy en día, con nuestras conexiones, seguiría siendo sci-fi. Quizá en Japón...

PD: de chapa nada, es bueno ver distintas opiniones y puntos de vista y cómo alguien desarrollaría lo mismo que tu de otro modo, te ayuda a ver cosas buenas y a percatarte de las cosas malas, a tomar apuntes para ti mismo, que nunca se sabe qué te pueden mandar a hacer en un futuro.

#51 ¿Pero por qué tenemos NOSOTROS que crear algo para soportar algo que debería servirnos a todos, que ha sido hecho CON NUESTRO DINERO? ¿no deberían hacer que las cosas funcionen para todos y en todos los casos que cubran los estándares? (que pa eso están) y de paso seguir sus propias directrices. Que yo he programado cosas para la administración y nos exigían todo lo que ellos mismos no se exigen. ¡Y nos ponían pegas porque querían hacerlo todo en java, que es todo lo contrario a lo que piden!

#53 Creo que no has programado en entorno web----ya de por sí intentar soportar IE es un logro y eso sólo en una versión, ya si luego intentas que sea compatible en varias versiones de IE con el cachondo, y jodido, "modo de compatibilidad" es un milagro que te funcione, si le añades Firefox y Chrome alucinas y eso que éstos dos últimos cumplen los estándares muy bien.

Por otro lado tenemos el lado Java, no hay ningún problema con él salvo que los plugins para enlazar con los navegadores son una patata con problemas de seguridad, incompatibilidades y múltiples problemas ( https://support.google.com/chrome/answer/2429779?hl=en ). De hecho el año que viene Chrome deja de permitir plugins NPAPI ( http://www.firebreath.org/display/documentation/Browser+Plugins+in+a+post-NPAPI+world ) y Java dejará de funcionar, lo mismo para Firefox.

Por eso la mejor opción no es hacer que 200 empresas hagan 500 productos en las Administraciones compatibles con todo lo habido y por haber que puede existir en el PC de millones de usuarios. Lo más sencillo es coger un navegador, añadirle plugins nativos (nada de Java) para realizar alguna tarea que a día de hoy no se soporta de forma estándar (el Crypto todavía es un draft no es estándar), empaquetarlo y distribuirlo. De esa forma, esas 200 empresas sólo deberán desarrollar para una plataforma que además seguirá los estándares lo más fielmente posible y no podrán cobrar el doble o el triple para que funcione en todas las plataformas cuando además al final no funcionará de forma correcta a la primera actualización de navegador/java/sistema operativo disponible.

#54 Precisamente porque trabajo en web se de lo que me hablo. Si te ciñes a los estándares no tienes ningún problema con ningún navegador actual o con menos de cinco años (y no me vale estándares en periodo de discusión o con implementaciones de prueba o no completas).

El java tiene muchos problemas:
-Es un plugin; hay que instalarlo en el sistema (y muchos navegadores lo bloquean directamente, al menos las versiones que se saben peligrosas).
-No va en todos los equipos porque es muy pesado y lento y no está soportado por todas las plataformas o arquitecturas.
-La versión java para dispositivos móviles recorta muchas cosas en pos de la flexibilidad y ahorro de recursos, lo que no permite usar programas java normales en ella.
-Frecuentes problemas GORDOS de seguridad.
-Versiones incompatibles unas con otras, necesidad de portar tus programas a la nueva versión.
-NO es accesible. Una persona con deficiencias con su navegador adaptado no puede acceder a contenidos hechos en java.

Tomemos la administración media que hizo en su día un programa para java 6. Así a bote pronto estás dejando fuera a:
-Todo aquel que use dispositivos móviles para hacer gestiones.
-Todo aquel que no use una implementación java oracle (las implementaciones de referencia, libres y abiertas no funcionan igual de bien, al menos con java 7 y 8 la brecha entre la de referencia y la de oracle es menor) porque le va a dar problemas en algún momento dado o le va a hacer inservible.
-Todo aquel que no use internet explorer, porque siendo java un entorno "neutro" se las apañan para tirar esa neutralidad a la basura.

Los móviles solo son millones de potenciales usuarios de tu aplicación que no pueden usarla (en españa ahora mismo hay registrados 53 millones, de los cuales 26 millones se conectan a internet con ellos, de los cuales 10 millones pueden usarlos para algo más que el whatsapp, de los cuales...). Si contamos que ahora mismo solo un tercio de españoles usan explorer, estarías limitando aún más el número de personas que podrían acceder a.

Y te repito otra vez más: no 5000 millones de versiones de un producto que resuelvan cada pequeña variación de características, solo una y que siga los estándares, que solo con eso ya permites que potencialmente TODO el mundo pueda acceder a tus servicios. Y repito de nuevo, si algún navegador no cumple un estándar o falla, basta entrar en su bugzilla y crear un bug, que ya se encargarán ellos de resolver el problema (porque la culpa no será de tu producto).

Porque ahora mismo hay una, pero falla por todos lados por pensarse y hacerse para un entorno concreto fuera de estándares.

Sobre tu propuesta: ¿Qué navegador escogerías? ¿te venderías a google? ¿irías por mozilla por aquello de ser una fundación y tal? ¿desarrollarías tu propio navegador? ¿por qué elegirías de ese modo? ¿qué razones darías para ello? ¿por qué la gente tendría que bajar tu navegador si ya está contento con el que tiene? ¿qué pasa si alguien no puede acceder a las cosas porque le has obligado a instalar un navegador que igual no tiene versión para su arquitectura/SO/loquesea o tu tienes binarios para él o no has portado tu código a esa versión del navegador?

Hablas de criptografía (en cliente) como escudo para darle valor a java, Http dispone de formas de encriptar los datos que transmites (no es lo mismo que encriptar antes de mandar, claro, pero tampoco es que los datos vayan por cauces inseguros, hay millones de webs de tiendas y tal que realizan operaciones bastante sensibles para los datos de los usuarios y no necesitan java).

Lo de los lectores de dni electrónico fue una chapuza total, y en gran parte la poca extensión que ha tenido ha sido culpa de unos drivers de mierda (y cerrados) y la implementación en java (que vino muy bien para que todas las administraciones que ya tenían sus programas en java no tuvieran que tocar mucho, pero que ha ignorado al resto del mercado potencial). Conozco mucha gente que en su día consiguió el lector de marras y no ha podido usarlo (alguno ni siquiera en windows).

#55 (NOTA: De verdad, que esta conversación me viene muy bien para saber si la idea que tengo es buena o no y me viene bien alguien escéptico que me de la contraréplica).

Creo que ambos estamos deacuerdo en que Java NO ha de usarse en el lado cliente al igual que no usamos Flash, limita los dispositivos a los que puedes ir además de crear un lio de narices a los usuarios. Creo que no me has entendido que digo de usar plugins de navegador pero me refiero a extensiones nativas del propio navegador no a usar Java ni otra tecnología.

Ambos estamos deacuerdo en usar estándares establecidos. El problema es que los navegadores no cumplen nunca al 100% ( http://www.quirksmode.org/ ).

También estamos deacuerdo en la pedazo de chapuza de los lectores de DNI electrónico. Tengo uno y vaya tela hacerlo funcionar en Windows, en Linux curiosamente no me costó nada. No me escudo en el cifrado, los navegadores a día de hoy saben usar SSL/TLS perfectamente. El problema es cuando quieres firmar un documento, por ejemplo la Declaración de IRPF con tu certificado de usuario en el lado cliente. Hay que cruzar los dedos muy fuerte para esperar que te funcione a la primera a día de hoy.

La idea sería la siguiente:

Desde la Administración se crearía un proyecto en el que podría concurrir cualquier empresa bajo la premisa de coger un navegador Open Source (Firefox/Chromium) que fuera multiplataforma y crear un fork del mismo en el que los únicos cambios a hacerle serían el añadirle los bookmarks de la Administración, añadirle el certificado raiz de la FNMT (que por defecto no lo lleva ningún navegador, manda narices) y crearle plugins para hacer tareas específicas que actualmente no están soportadas por los estándares. Pongo el punto específicamente en el firmado de documentos y criptografía porque actualmente cada vez que quieres hacer algo en ese sentido siempre se recurre a Java, si hemos quedado en no usar Java y que no hay estándar para eso actualmente entonces la única opción disponible es crear un plugin para el navegador elegido.

A partir de ese momento, la Administración podría "empaquetar" el navegador para todas las plataformas mayoritarias (Linux, Mac, Win, Android, iOS) y dejarlo listo para descarga. Cualquier persona física o jurídica que quisiera acceder a las webs de la Administración a realizar gestiones debería utilizar el navegador "oficial" de la Administración y cualquier empresa que hiciera desarrollos para la administración sólo tendría que preocuparse de tener que desarrollar para el navegador "oficial".

Evidentemente, debería existir un grupo específico que se encargase del mantenimiento de los navegadores para ir actualizándolos con parches de seguridad los cuales recibirían actualizaciones automáticas al igual que las reciben Firefox y Chrome/Chromium.

Respecto a tus preguntas:

¿Qué navegador escogerías? ¿te venderías a google? ¿irías por mozilla por aquello de ser una fundación y tal?

No, iría a concurso, pero evidentemente tendría que ser Open Source (chromium/mozilla) y el ganador sería por méritos tanto de funcionalidades como de precio. Como se indicase en el pliego

¿desarrollarías tu propio navegador? ¿por qué elegirías de ese modo? ¿qué razones darías para ello?

No, lo haría la Administración como método de unificación, creo que esta idea no quedó clara cuando puse mis anteriores comentarios. La razón es forzar a que realmente el sistema funcione, piensa en este navegador como en tu "Ventanilla única" para acceder a la Administración.

¿por qué la gente tendría que bajar tu navegador si ya está contento con el que tiene?

Porque puedes tener instalados varios navegadores y porque a día de hoy es incluso obligatorio tenerlos todos. Por experiencia personal, la web de Catastro va muy bien con Chrome pero mal con Firefox, sin embargo la de la DGT por narices tienes que ir con Internet Explorer....vamos, que al final tengo que tener instalados todos e ir probando cuando veo que uno falla. Mi mujer trabaja en una gestoría y tiene el mismo problema y la misma solución, si con un navegador ve errores prueba con otro hasta que da con el que le funciona... Con esta idea tú tendrías el navegador que quisieras para hacer tus cosas y luego el de la Administración para hacer las gestiones.

¿qué pasa si alguien no puede acceder a las cosas porque le has obligado a instalar un navegador que igual no tiene versión para su arquitectura/SO/loquesea o tu tienes binarios para él o no has portado tu código a esa versión del navegador?

Sólo serían necesarias 4 versiones: Windows, Mac, Linux32, Linx64. Si ya quieres rizar el rizo añade dos versiones más, iOS y Android. (Nota: Firefox está a punto de sacar versión para iOS y ya la tiene para Android y ambas soportan plugins). De hecho tanto Chrome como Firefox sólo tienen esas versiones, parece que es más que suficiente. Si mañana aparece un sistema operativo nuevo o actualización, tranquilo que tanto la Fundación Mozilla como Google sacarán adaptaciones para ese sistema/versión y tú lo único que tendrás que hacer es un nuevo fork/merge.

PD. siento la pedazo de chapa de comentario pero espero haber explicado mejor la idea. thnx!

#56 Bien, si por estándares te refieres a HTML5, las versiones definitivas se han "aprobado" ayer mismo como quien dice. Normal que ningún navegador cumpla al 100% todo el estándar (los navegadores más aventajados en cada área específica del estándar son los que han conseguido colar desarrollos propios en los estándares y/o su implementación era la mejor/más adecuada y los estándares la han reflejado como la solución óptima, luego están los que se han arriesgado a implementar borradores de esas partes y que han tenido que hacer pocos cambios o ninguno, y por último están aquellas cosas que requieren una modificación profunda en el diseño del navegador para poder ser implementados o aquellos navegadores que esperan a que se termine de definir esa parte del estándar para implementar).

Aún así, hay páginas cojonudas que todo diseñador web debe conocer y manejar como http://caniuse.com que facilitan mucho el decidir si meterse en berenjenales o no. Dicho esto, la mayor parte de cosas necesarias para casi todos los desarrollos están soportadas por todos (¿que se pueden hacer mejor o más elegantes si el navegador X soportara la característica Y? seguro, pero se pueden hacer igualmente), e incluso olvidándonos de usar HTML5 directamente, hay muchas librerías que nos abstraen de todo eso y nos permiten hacer el desarrollo sin tener que preocuparnos por la compatibilidad (empezando por jquery).

Sobre la firma de documentos, es complicado hacerlo directamente vía web por las limitaciones que todos sabemos. Pero siempre puedes descargar el formulario, rellenarlo y firmarlo (aplicaciones para trabajar y firmar con pdfs libres y gratuítas haberlas haylas, formas de comprobar que no se ha modificado la estructura del pdf para evitar problemas de seguridad también las hay). Incluso es más factible y funcionará mejor y será más sencillo hacer un "editor pdf" en java para el escritorio que no una aplicación web (ya te quitarías de problemas de navegadores, sólo necesitarías un ordenador con java). Ahora bien, eso tampoco solucionaría el problema de poder hacer las gestiones desde móviles, y aunque hay implementaciones de java para las arquitecturas mayoritarias, siempre quedarían los problemas de seguridad inherentes a la tecnología (que en arquitecturas como x86 se parchea mucho y a menudo, pero en otras minoritarias el esfuerzo no es tan grande).

La solución de un "navegador gubernamental" no me parece incorrecta o descabellada, pero tampoco creo que sea la mejor solución (más que nada porque mira lo que tardaron en encontrarle las cosquillas a aquella versión especial de firefox que venía torificada, y los plugins pueden ser "sustituíbles" por versiones pirateadas con algo de ensayo y error).

Una solución alternativa y que funcionaría en el 100% de los casos con un navegador HTML5 (pero que necesitaría una infraestructura potente, tanto a la hora de dar servicio como a la hora de protección y seguridad) o en su defecto si es necesario una pequeña aplicación que embeba un navegador html5 o una alternativa parecida (aunque entonces no sería universal ni 100% accesible) sería el paradigma del thin client: hacerlo todo en el servidor. Poner un sistema en la nube, acceso remoto desde el cliente y que todos los programas se ejecuten en servidores estatales. Algo así como esto: http://guac-dev.org/, donde el cliente tiene una cuenta accesible con su dni electrónico o certificado digital y algún código recibido vía mensaje sms para aumentar la seguridad y dependiendo del dispositivo desde donde se conecte le envíe directamente a un programa adaptado para escritorio o móvil donde hacer sus gestiones. La parte buena: tu te lo cocinas como quieres: lenguaje, plataforma, seguridad, etc. porque todo está en servidor y sabes que VA A FUNCIONAR porque está en un entorno controlado. Si montas un gestor de escritorio muy ligero y con lo mínimo (exportar un display y tratar eventos para poder interactuar) podrías atender a mucha gente simultaneamente bajo tus propias condiciones y permitiendo un acceso universal y seguro.

Pero creo que hoy en día, con nuestras conexiones, seguiría siendo sci-fi. Quizá en Japón...

PD: de chapa nada, es bueno ver distintas opiniones y puntos de vista y cómo alguien desarrollaría lo mismo que tu de otro modo, te ayuda a ver cosas buenas y a percatarte de las cosas malas, a tomar apuntes para ti mismo, que nunca se sabe qué te pueden mandar a hacer en un futuro.

#50 Pero todos esos millones siguen unos estándares. Si tu sigues unos estándares y el navegador no los soporta, no es problema tuyo, es del navegador. Si tu diseñas programas para que funcionen en explorer 6 con java 6 te aseguras que nadie más pueda usar eso precisamente porque se pasan por el forro todos los estándares habidos y por haber (explorer porque si -si los explorers posteriores tienen modos de "emulación" o compatibilidad con el 6, porque no hay forma de seguir estándares y ser compatible con ese-, java porque si instalas la versión de referencia u otras basadas en las especificaciones no funciona, si instalas la de sun/oracle si ¿curioso?).

Que el problema no es estandarizar un cliente, porque el problema no somos los clientes. El problema es que los programas no están concebidos para ser respetuosos con los clientes, sino para ser serviles con uno en concreto (que en aquella época era el que copaba el mercado y lo más fácil era producir las cosas para el). La visión cortoplacista y de pasarse los controles de calidad por el forro típica de siempre en este país, donde es más importante tener un producto más rápido que la competencia a hacerlo bien (con todos los cambios intermedios en las especificaciones posibles). Luego se sorprenden del resultado.

#47 ¿Y si da la casualiad de que ese navegador tiene boquetes de seguridad que no pueden ser eliminados porque precisamente son parte de lo que hace que sean compatibles con esas operaciones? ¿y si resulta que justamente tapar esos agujeros es lo que ha hecho que hayan dejado de ser funcionales para esas operaciones? ¿dejarías todos los ordenadores de las distintas administraciones con problemas de seguridad conocidos? ¿abrirías las puertas para que entre cualquiera y te saquee los datos de todos los ciudadanos?

La solución es que los programas de la administración cumplan las propias propias leyes de la administración que dicen que han de ser accesibles (que dudo mucho que algo que necesite un plugin de java y encima no cualquiera, sea accesible), luego han de cumplir los estándares y por último, han de responder a las quejas de la gente que no puede usarlos. No es de recibo que todo el que llame quejándose le digan que se pase a otro navegador o SO porque es la única solución, hay una queja sobre el funcionamiento, el producto no está terminado o funcionando bien, tienes que arreglarlo.

#48 Creo que no has cogido la idea. El problema es los millones de versiones de navegadores, IE, Firefox, Chrome, cada uno con sus versiones, Java con múltiples versiones, los doscientos plugins distintos que usa cada administración para hacer el firmado seguro de documentos, las plataformas Linux, Mac, Win, .... Todos esos problemas para los usuarios te los quitas de un plumazo estandarizando un cliente. Los servidores seguirán siendo tan seguros, o inseguros, con este cliente como lo es a día de hoy. ¿qué tiene que ver el cambiar un cliente para que el servidor se vuelva inseguro?

#50 Pero todos esos millones siguen unos estándares. Si tu sigues unos estándares y el navegador no los soporta, no es problema tuyo, es del navegador. Si tu diseñas programas para que funcionen en explorer 6 con java 6 te aseguras que nadie más pueda usar eso precisamente porque se pasan por el forro todos los estándares habidos y por haber (explorer porque si -si los explorers posteriores tienen modos de "emulación" o compatibilidad con el 6, porque no hay forma de seguir estándares y ser compatible con ese-, java porque si instalas la versión de referencia u otras basadas en las especificaciones no funciona, si instalas la de sun/oracle si ¿curioso?).

Que el problema no es estandarizar un cliente, porque el problema no somos los clientes. El problema es que los programas no están concebidos para ser respetuosos con los clientes, sino para ser serviles con uno en concreto (que en aquella época era el que copaba el mercado y lo más fácil era producir las cosas para el). La visión cortoplacista y de pasarse los controles de calidad por el forro típica de siempre en este país, donde es más importante tener un producto más rápido que la competencia a hacerlo bien (con todos los cambios intermedios en las especificaciones posibles). Luego se sorprenden del resultado.

#43 #45 #47 Una distro basada en linux no sé, pero estaría bien que ReactOS estuviera lo suficientemente maduro como para eso.

#49 Yo no hablo de estandarizar una distribución Linux, digo de crear un navegador basado en Firefox/Chrome, que sea open source y que esté para el mayor número de plataformas posible: Linux, Mac, Win, (Android, iOS etc ya sería mucho pedir)

#51 ¿Pero por qué tenemos NOSOTROS que crear algo para soportar algo que debería servirnos a todos, que ha sido hecho CON NUESTRO DINERO? ¿no deberían hacer que las cosas funcionen para todos y en todos los casos que cubran los estándares? (que pa eso están) y de paso seguir sus propias directrices. Que yo he programado cosas para la administración y nos exigían todo lo que ellos mismos no se exigen. ¡Y nos ponían pegas porque querían hacerlo todo en java, que es todo lo contrario a lo que piden!

#53 Creo que no has programado en entorno web----ya de por sí intentar soportar IE es un logro y eso sólo en una versión, ya si luego intentas que sea compatible en varias versiones de IE con el cachondo, y jodido, "modo de compatibilidad" es un milagro que te funcione, si le añades Firefox y Chrome alucinas y eso que éstos dos últimos cumplen los estándares muy bien.

Por otro lado tenemos el lado Java, no hay ningún problema con él salvo que los plugins para enlazar con los navegadores son una patata con problemas de seguridad, incompatibilidades y múltiples problemas ( https://support.google.com/chrome/answer/2429779?hl=en ). De hecho el año que viene Chrome deja de permitir plugins NPAPI ( http://www.firebreath.org/display/documentation/Browser+Plugins+in+a+post-NPAPI+world ) y Java dejará de funcionar, lo mismo para Firefox.

Por eso la mejor opción no es hacer que 200 empresas hagan 500 productos en las Administraciones compatibles con todo lo habido y por haber que puede existir en el PC de millones de usuarios. Lo más sencillo es coger un navegador, añadirle plugins nativos (nada de Java) para realizar alguna tarea que a día de hoy no se soporta de forma estándar (el Crypto todavía es un draft no es estándar), empaquetarlo y distribuirlo. De esa forma, esas 200 empresas sólo deberán desarrollar para una plataforma que además seguirá los estándares lo más fielmente posible y no podrán cobrar el doble o el triple para que funcione en todas las plataformas cuando además al final no funcionará de forma correcta a la primera actualización de navegador/java/sistema operativo disponible.

#54 Precisamente porque trabajo en web se de lo que me hablo. Si te ciñes a los estándares no tienes ningún problema con ningún navegador actual o con menos de cinco años (y no me vale estándares en periodo de discusión o con implementaciones de prueba o no completas).

El java tiene muchos problemas:
-Es un plugin; hay que instalarlo en el sistema (y muchos navegadores lo bloquean directamente, al menos las versiones que se saben peligrosas).
-No va en todos los equipos porque es muy pesado y lento y no está soportado por todas las plataformas o arquitecturas.
-La versión java para dispositivos móviles recorta muchas cosas en pos de la flexibilidad y ahorro de recursos, lo que no permite usar programas java normales en ella.
-Frecuentes problemas GORDOS de seguridad.
-Versiones incompatibles unas con otras, necesidad de portar tus programas a la nueva versión.
-NO es accesible. Una persona con deficiencias con su navegador adaptado no puede acceder a contenidos hechos en java.

Tomemos la administración media que hizo en su día un programa para java 6. Así a bote pronto estás dejando fuera a:
-Todo aquel que use dispositivos móviles para hacer gestiones.
-Todo aquel que no use una implementación java oracle (las implementaciones de referencia, libres y abiertas no funcionan igual de bien, al menos con java 7 y 8 la brecha entre la de referencia y la de oracle es menor) porque le va a dar problemas en algún momento dado o le va a hacer inservible.
-Todo aquel que no use internet explorer, porque siendo java un entorno "neutro" se las apañan para tirar esa neutralidad a la basura.

Los móviles solo son millones de potenciales usuarios de tu aplicación que no pueden usarla (en españa ahora mismo hay registrados 53 millones, de los cuales 26 millones se conectan a internet con ellos, de los cuales 10 millones pueden usarlos para algo más que el whatsapp, de los cuales...). Si contamos que ahora mismo solo un tercio de españoles usan explorer, estarías limitando aún más el número de personas que podrían acceder a.

Y te repito otra vez más: no 5000 millones de versiones de un producto que resuelvan cada pequeña variación de características, solo una y que siga los estándares, que solo con eso ya permites que potencialmente TODO el mundo pueda acceder a tus servicios. Y repito de nuevo, si algún navegador no cumple un estándar o falla, basta entrar en su bugzilla y crear un bug, que ya se encargarán ellos de resolver el problema (porque la culpa no será de tu producto).

Porque ahora mismo hay una, pero falla por todos lados por pensarse y hacerse para un entorno concreto fuera de estándares.

Sobre tu propuesta: ¿Qué navegador escogerías? ¿te venderías a google? ¿irías por mozilla por aquello de ser una fundación y tal? ¿desarrollarías tu propio navegador? ¿por qué elegirías de ese modo? ¿qué razones darías para ello? ¿por qué la gente tendría que bajar tu navegador si ya está contento con el que tiene? ¿qué pasa si alguien no puede acceder a las cosas porque le has obligado a instalar un navegador que igual no tiene versión para su arquitectura/SO/loquesea o tu tienes binarios para él o no has portado tu código a esa versión del navegador?

Hablas de criptografía (en cliente) como escudo para darle valor a java, Http dispone de formas de encriptar los datos que transmites (no es lo mismo que encriptar antes de mandar, claro, pero tampoco es que los datos vayan por cauces inseguros, hay millones de webs de tiendas y tal que realizan operaciones bastante sensibles para los datos de los usuarios y no necesitan java).

Lo de los lectores de dni electrónico fue una chapuza total, y en gran parte la poca extensión que ha tenido ha sido culpa de unos drivers de mierda (y cerrados) y la implementación en java (que vino muy bien para que todas las administraciones que ya tenían sus programas en java no tuvieran que tocar mucho, pero que ha ignorado al resto del mercado potencial). Conozco mucha gente que en su día consiguió el lector de marras y no ha podido usarlo (alguno ni siquiera en windows).

#55 (NOTA: De verdad, que esta conversación me viene muy bien para saber si la idea que tengo es buena o no y me viene bien alguien escéptico que me de la contraréplica).

Creo que ambos estamos deacuerdo en que Java NO ha de usarse en el lado cliente al igual que no usamos Flash, limita los dispositivos a los que puedes ir además de crear un lio de narices a los usuarios. Creo que no me has entendido que digo de usar plugins de navegador pero me refiero a extensiones nativas del propio navegador no a usar Java ni otra tecnología.

Ambos estamos deacuerdo en usar estándares establecidos. El problema es que los navegadores no cumplen nunca al 100% ( http://www.quirksmode.org/ ).

También estamos deacuerdo en la pedazo de chapuza de los lectores de DNI electrónico. Tengo uno y vaya tela hacerlo funcionar en Windows, en Linux curiosamente no me costó nada. No me escudo en el cifrado, los navegadores a día de hoy saben usar SSL/TLS perfectamente. El problema es cuando quieres firmar un documento, por ejemplo la Declaración de IRPF con tu certificado de usuario en el lado cliente. Hay que cruzar los dedos muy fuerte para esperar que te funcione a la primera a día de hoy.

La idea sería la siguiente:

Desde la Administración se crearía un proyecto en el que podría concurrir cualquier empresa bajo la premisa de coger un navegador Open Source (Firefox/Chromium) que fuera multiplataforma y crear un fork del mismo en el que los únicos cambios a hacerle serían el añadirle los bookmarks de la Administración, añadirle el certificado raiz de la FNMT (que por defecto no lo lleva ningún navegador, manda narices) y crearle plugins para hacer tareas específicas que actualmente no están soportadas por los estándares. Pongo el punto específicamente en el firmado de documentos y criptografía porque actualmente cada vez que quieres hacer algo en ese sentido siempre se recurre a Java, si hemos quedado en no usar Java y que no hay estándar para eso actualmente entonces la única opción disponible es crear un plugin para el navegador elegido.

A partir de ese momento, la Administración podría "empaquetar" el navegador para todas las plataformas mayoritarias (Linux, Mac, Win, Android, iOS) y dejarlo listo para descarga. Cualquier persona física o jurídica que quisiera acceder a las webs de la Administración a realizar gestiones debería utilizar el navegador "oficial" de la Administración y cualquier empresa que hiciera desarrollos para la administración sólo tendría que preocuparse de tener que desarrollar para el navegador "oficial".

Evidentemente, debería existir un grupo específico que se encargase del mantenimiento de los navegadores para ir actualizándolos con parches de seguridad los cuales recibirían actualizaciones automáticas al igual que las reciben Firefox y Chrome/Chromium.

Respecto a tus preguntas:

¿Qué navegador escogerías? ¿te venderías a google? ¿irías por mozilla por aquello de ser una fundación y tal?

No, iría a concurso, pero evidentemente tendría que ser Open Source (chromium/mozilla) y el ganador sería por méritos tanto de funcionalidades como de precio. Como se indicase en el pliego

¿desarrollarías tu propio navegador? ¿por qué elegirías de ese modo? ¿qué razones darías para ello?

No, lo haría la Administración como método de unificación, creo que esta idea no quedó clara cuando puse mis anteriores comentarios. La razón es forzar a que realmente el sistema funcione, piensa en este navegador como en tu "Ventanilla única" para acceder a la Administración.

¿por qué la gente tendría que bajar tu navegador si ya está contento con el que tiene?

Porque puedes tener instalados varios navegadores y porque a día de hoy es incluso obligatorio tenerlos todos. Por experiencia personal, la web de Catastro va muy bien con Chrome pero mal con Firefox, sin embargo la de la DGT por narices tienes que ir con Internet Explorer....vamos, que al final tengo que tener instalados todos e ir probando cuando veo que uno falla. Mi mujer trabaja en una gestoría y tiene el mismo problema y la misma solución, si con un navegador ve errores prueba con otro hasta que da con el que le funciona... Con esta idea tú tendrías el navegador que quisieras para hacer tus cosas y luego el de la Administración para hacer las gestiones.

¿qué pasa si alguien no puede acceder a las cosas porque le has obligado a instalar un navegador que igual no tiene versión para su arquitectura/SO/loquesea o tu tienes binarios para él o no has portado tu código a esa versión del navegador?

Sólo serían necesarias 4 versiones: Windows, Mac, Linux32, Linx64. Si ya quieres rizar el rizo añade dos versiones más, iOS y Android. (Nota: Firefox está a punto de sacar versión para iOS y ya la tiene para Android y ambas soportan plugins). De hecho tanto Chrome como Firefox sólo tienen esas versiones, parece que es más que suficiente. Si mañana aparece un sistema operativo nuevo o actualización, tranquilo que tanto la Fundación Mozilla como Google sacarán adaptaciones para ese sistema/versión y tú lo único que tendrás que hacer es un nuevo fork/merge.

PD. siento la pedazo de chapa de comentario pero espero haber explicado mejor la idea. thnx!

#25 Es muy grave lo que veo escrito en los comentarios de mucha gente, es decir se confirma y se da por correcto que las escuelas de negocio de este país dsarían matrícula de honor a un estafador por sabe r hacer negocios y política. La matrícula de honor es para los estafadores, son las artes que enseñan las escuelas de negocio. Y eso nos lo dejan claro lo estudiantes de esas escuelas que además no se escandalizan por ese modo de ser empresario, al revés saben que le darían matrícula de honor, un personajillo digno de ser imitado. España, país de trileros, ladrones, estafadores donde el honesto es gilipollas y el estafador merece matrícula de honor en nuestras escuelas de negocio y universidades.

#44 Yo pasé rápidamente por algunos cursos en escuelas de negocio y salí espantada porque sólo sabían enseñarte dos cosas: cómo ser empresaurio y cómo vender humo.

No sé si es que las cosas realmente importantes como cómo captar el talento o cómo invertir sabiamente en I+D es que se daban en cursos más avanzados o es que todo era así. Pero vaya, que salvo que quieras ser un listillo, las escuelas de negocio no te aportan mucho más allá de contactos.

#46 Las escuelas de negocio enseñan a hacer negocio. Para crear una empresa desde cero y llevarla a algo que te permita llevar una vida digna hay que aprender a trabajar, que es lo que no quieren hacer. Un negociete bien hecho y ya...obviamente, alguien con un poco de cerebro se daría cuenta que todo eso que se estudia son cuentos y contactos.

#44 Es muy triste, pero la capacidad para saber mentir es esencial en los negocios y en cualquier otro ambito. Decir la verdad a menudo nos conduce a ser considerados mentirosos, locos,... y sin embargo mintiendo nos ganamos la confianza de los demas. Se podria decir que esta sociedad obliga a mentir . Los politicos que dicen la verdad pocas veces tienen exito.

#44 Debí haber añadido algún smiley o indicar que era modo irónico. Para nada le daría a semejante personaje ningún título

#7 la acabo de visitar y entiendo el fracaso en matemáticas con profesores como éste, en las antípodas de Clara Grima.

#17 Todo es necesario, para eso estamos, para complementarnos, pero tú en plan destroyer con mi web, estamos apañados... ¿Piensas que Clara no enuncia teoremas en clase?

#7 GRACIAS!!!

#110 Tú has puesto la ley que permite registar a la iglesia la mezquita.
Pero todavía no has puesto una ley anterior a esa que diga que la iglesia no es la propietaria de la mezquita.

Y yo sí he aportado información, el documento del Rey que certifica que la mezquita es propiedad del Cabildo.

#100 La mezquita no ha sido nunca comunal.
Si yo poseo una casa sin registrar, el obispado puede registrarla y perder el juicio con toda seguridad, porque una cosa es no tenerla registrada y otra cosa es no tener papeles que demuestren que es mío
El obispado conserva el documento en el que Fernando III de Castilla en 1236 entrega la catedral a la Iglesia.

Hay veces que leer público te hace quedar en ridículo.

Es un bulo muy interesado decir que la Iglesia ha robado la mezquita.

#106 creeme, teniendo escrituras ante notario no registradas perdí un juicio de propiedad...

respecto al ridículo del que hablas, te he dado enlaces a leyes y tú sólo un par de comentarios sin indicar la fuente. Por ello, no pienso perder más el tiempo contigo y más cuando pierdes el respeto al contrario pensando que eso da más validez a tu argumento.

#110 Tú has puesto la ley que permite registar a la iglesia la mezquita.
Pero todavía no has puesto una ley anterior a esa que diga que la iglesia no es la propietaria de la mezquita.

Y yo sí he aportado información, el documento del Rey que certifica que la mezquita es propiedad del Cabildo.

#90 Te insto a que me muestres un papel donde se diga que el propietario es distinto a la Iglesia.
Digo yo que si no era de la iglesia, de alguien tendría que ser.
Venga, abogado.

Un edificio puede ser tuyo sin necesidad de que esté registrado. Pero como no eres abogado hablas por hablar porque lo has leído en cualquier cutrepágina de internet

#91 Ley hipotecaria de 1946, artículo 206 ( http://noticias.juridicas.com/base_datos/Privado/lh.t6.html ) - La Iglesia se convierte en registrador oficial de la propiedad pero, eso sí, para registrar la propiedad hay que certificar su propiedad (como no puede ser de otra forma por otro lado).

En la Ley 13/1996 se introdujo una modificación a ese artículo http://noticias.juridicas.com/base_datos/Admin/l13-1996.html#a144 que permite a la Iglesia el otorgar certificados de propiedad. Es decir, basta con que el Obispo, como cabeza de la Iglesia de esa región, diga que sí, que aquello era suyo, para que lo sea, un registrador oficial del Estado pediría un acta notarial o judicial antes de registrar cualquier inmueble o finca (no de culto religioso), en este caso basta simplemente con que no esté previamente registrado.

En 1998 se modifica de nuevo la Ley para permitir todo tipo de inmueble o finca ya sea de culto o no http://noticias.juridicas.com/base_datos/Privado/rd1867-1998.html#tr2

Y en eso se basa todo esto por si todavía no te has dado cuenta, que no existe título de propiedad puesto que es comunal, de todos, y la Iglesia, gracias a estas dos leyes, se puede otorgar la propiedad. No lo ha hecho sólo con la Mezquita, lo ha hecho en toda España.

Por cierto, cuidado si tienes un edificio sin registrar, el Obispo puede emitir certificado de propiedad y luego, por la potestad dada a la Iglesia, registrarlo y te quedaste sin edificio.

Y no, no soy abogado, pero sé leer, se buscar leyes y buscar información, hasta el momento soy el único de los dos que lo ha hecho. ¿me demuestras tú ahora que lo que acabo de escribir es incorrecto/falso?

#100 La mezquita no ha sido nunca comunal.
Si yo poseo una casa sin registrar, el obispado puede registrarla y perder el juicio con toda seguridad, porque una cosa es no tenerla registrada y otra cosa es no tener papeles que demuestren que es mío
El obispado conserva el documento en el que Fernando III de Castilla en 1236 entrega la catedral a la Iglesia.

Hay veces que leer público te hace quedar en ridículo.

Es un bulo muy interesado decir que la Iglesia ha robado la mezquita.

#106 creeme, teniendo escrituras ante notario no registradas perdí un juicio de propiedad...

respecto al ridículo del que hablas, te he dado enlaces a leyes y tú sólo un par de comentarios sin indicar la fuente. Por ello, no pienso perder más el tiempo contigo y más cuando pierdes el respeto al contrario pensando que eso da más validez a tu argumento.

#110 Tú has puesto la ley que permite registar a la iglesia la mezquita.
Pero todavía no has puesto una ley anterior a esa que diga que la iglesia no es la propietaria de la mezquita.

Y yo sí he aportado información, el documento del Rey que certifica que la mezquita es propiedad del Cabildo.

#80 La Mezquita es propiedad legítima de la iglesia desde la reconquista de Córdoba.
Esa noticia que indicas es mentira.

#83 una cosa es el uso y otra la propiedad. La iglesia registró la Mezquita en el año 2006 http://www.secretolivo.com/index.php/2013/04/25/informe-mezquita/ para ser de su propiedad desde la reconquista tardaron lo suyo, ¿no crees? Vamos, que me entero que algo me pertenece y tardo poco en registrarlo, no espero 500 años y una ley que me permite ser juez y parte y poder registrar a mi nombre cualquier cosa que no esté registrada previamente...

#90 Te insto a que me muestres un papel donde se diga que el propietario es distinto a la Iglesia.
Digo yo que si no era de la iglesia, de alguien tendría que ser.
Venga, abogado.

Un edificio puede ser tuyo sin necesidad de que esté registrado. Pero como no eres abogado hablas por hablar porque lo has leído en cualquier cutrepágina de internet

#91 Ley hipotecaria de 1946, artículo 206 ( http://noticias.juridicas.com/base_datos/Privado/lh.t6.html ) - La Iglesia se convierte en registrador oficial de la propiedad pero, eso sí, para registrar la propiedad hay que certificar su propiedad (como no puede ser de otra forma por otro lado).

En la Ley 13/1996 se introdujo una modificación a ese artículo http://noticias.juridicas.com/base_datos/Admin/l13-1996.html#a144 que permite a la Iglesia el otorgar certificados de propiedad. Es decir, basta con que el Obispo, como cabeza de la Iglesia de esa región, diga que sí, que aquello era suyo, para que lo sea, un registrador oficial del Estado pediría un acta notarial o judicial antes de registrar cualquier inmueble o finca (no de culto religioso), en este caso basta simplemente con que no esté previamente registrado.

En 1998 se modifica de nuevo la Ley para permitir todo tipo de inmueble o finca ya sea de culto o no http://noticias.juridicas.com/base_datos/Privado/rd1867-1998.html#tr2

Y en eso se basa todo esto por si todavía no te has dado cuenta, que no existe título de propiedad puesto que es comunal, de todos, y la Iglesia, gracias a estas dos leyes, se puede otorgar la propiedad. No lo ha hecho sólo con la Mezquita, lo ha hecho en toda España.

Por cierto, cuidado si tienes un edificio sin registrar, el Obispo puede emitir certificado de propiedad y luego, por la potestad dada a la Iglesia, registrarlo y te quedaste sin edificio.

Y no, no soy abogado, pero sé leer, se buscar leyes y buscar información, hasta el momento soy el único de los dos que lo ha hecho. ¿me demuestras tú ahora que lo que acabo de escribir es incorrecto/falso?

#100 La mezquita no ha sido nunca comunal.
Si yo poseo una casa sin registrar, el obispado puede registrarla y perder el juicio con toda seguridad, porque una cosa es no tenerla registrada y otra cosa es no tener papeles que demuestren que es mío
El obispado conserva el documento en el que Fernando III de Castilla en 1236 entrega la catedral a la Iglesia.

Hay veces que leer público te hace quedar en ridículo.

Es un bulo muy interesado decir que la Iglesia ha robado la mezquita.

#106 creeme, teniendo escrituras ante notario no registradas perdí un juicio de propiedad...

respecto al ridículo del que hablas, te he dado enlaces a leyes y tú sólo un par de comentarios sin indicar la fuente. Por ello, no pienso perder más el tiempo contigo y más cuando pierdes el respeto al contrario pensando que eso da más validez a tu argumento.